Bu yazıda mən məhsullarımızın funksionallığını inkişaf etdirmək üçün ideyaların seçilməsi ilə bağlı təcrübəmi bölüşəcəyəm və inkişafın əsas vektorlarını necə qoruyub saxlamağı sizə xəbər verəcəyəm.
Biz avtomatlaşdırılmış hesablaşma sistemini (ACP) inkişaf etdiririk - billinq. Müddət
Məhsulumuzun istifadə müddəti 14 ildir. Bu müddət ərzində sistem sənaye tarif sisteminin ilk versiyalarından bir-birini tamamlayan 18 məhsuldan ibarət modul kompleksə çevrilmişdir. Proqramların uzunömürlülüyünün ən vacib cəhətlərindən biri daimi inkişafdır. İnkişaf isə ideya tələb edir.
Fikirlər
İnformasiya qaynaqları
5 mənbə var:
- Korporativ informasiya sistemləri tərtibatçısının əsas dostudur müştəri. Müştəri isə qərar qəbul edənlərin, layihə sponsorlarının, proseslərin sahibləri və icraçılarının, daxili İT mütəxəssislərinin, adi istifadəçilərin və müxtəlif dərəcədə maraqlı olan çoxlu sayda şəxslərin kollektiv obrazıdır. Müştərinin hər bir nümayəndəsinin potensial olaraq ideya tədarükçüsü olması bizim üçün vacibdir. Ən pis halda, sistemdəki problemlər haqqında yalnız mənfi rəy alırıq. Ən yaxşı halda, müştərinin tərəfində müştərinin ehtiyacları haqqında strukturlaşdırılmış məlumat verən təkmilləşdirmə üçün daimi fikir mənbəyi olan bir şəxs var.
- Bizim satış işçiləri və mühasibat menecerləri təkmilləşdirilməsi üçün ikinci ən mühüm ideya mənbəyidir. Onlar sənaye nümayəndələri ilə fəal və geniş şəkildə ünsiyyət qurur və potensial müştərilərdən billinq funksionallığı ilə bağlı ilk sorğuları alırlar. Satıcılar və hesablar funksionallıqlarındakı bütün əhəmiyyətli dəyişikliklərdən və rəqiblərin proqram təminatının ən son yeniləmələrindən xəbərdar olmalı və müxtəlif həllərin müsbət və mənfi tərəflərini əsaslandıra bilməlidirlər. Bunlar bəzi billinq imkanlarının faktiki standarta çevrildiyini ilk hiss edən işçilərimizdir, onsuz proqram təminatı tam hesab edilə bilməz.
- Məhsul Sahibi — top menecerlərimizdən biri və ya çox təcrübəli layihə meneceri. Şirkətin strateji məqsədlərini diqqətdə saxlayır və onlara uyğun olaraq məhsulun inkişaf planlarını düzəldir.
- Memar, seçilmiş/istifadə edilən texnoloji həllərin imkanlarını və məhdudiyyətlərini və onların məhsulun inkişafına təsirini başa düşən şəxs.
İnkişaf və sınaq qrupları. Məhsulun hazırlanmasında birbaşa iştirak edən insanlar.
Müraciətlərin təsnifatı
Biz mənbələrdən xam məlumatları alırıq - məktublar, biletlər, şifahi sorğular. Hamısı
müraciətlər təsnif edilir:
- Məsləhətləşmələr “Bunu necə etməli?”, “Necə işləyir?”, “Niyə işləmir?”, “Başa düşmürəm...” mənası ilə. Bu tip sorğular Səviyyə 1 Dəstək Xəttinə gedir. Məsləhətləşməni digər sorğu növləri üzrə yenidən hazırlamaq mümkündür.
- Hadisələr "İşləmir" və "Səhv" mənası ilə. 2 və 3 Dəstək Xətləri ilə işlənir. Tez düzəlişlər və yamağın buraxılması lazımdırsa, onlar dəstəkdən birbaşa inkişafa köçürülə bilər. Dəyişiklik sorğusu kimi yenidən təsnif etmək və geridə qalan siyahıya göndərmək mümkündür.
- Dəyişikliklər və inkişaf tələbləri. Dəstək xətlərini keçərək məhsulun geridə qalmasına daxil olurlar. Ancaq onlar üçün ayrıca emal proseduru var.
Müraciətlərlə bağlı statistik məlumatlar var: buraxılışdan dərhal sonra qısa müddət ərzində sorğuların sayı 10-15% artır. Bulud xidmətlərimizə çoxlu sayda istifadəçisi olan yeni müştəri gələndə də sorğularda artım olur. İnsanlar yeni proqram imkanlarından istifadə etməyi öyrənirlər, onlara məsləhət lazımdır. Hətta kiçik bir müştəri, sistemdə işə başladıqda, ayda 100 saatdan çox məsləhətləşməni asanlıqla yandırır. Buna görə də, yeni bir müştəri bağlayarkən, biz həmişə ilkin məsləhətləşmələr üçün vaxt ayırırıq. Çox vaxt hətta xüsusi bir mütəxəssis seçirik. Kirayə qiyməti, təbii ki, bu əmək xərclərini ödəmir, lakin zaman keçdikcə vəziyyət düzəlir. Uyğunlaşma müddəti adətən 1 aydan 3 aya qədər davam edir, bundan sonra məsləhətə ehtiyac əhəmiyyətli dərəcədə azalır.
Əvvəllər sorğuları saxlamaq üçün öz-özünə yazılmış həllərdən istifadə edirdik. Amma biz tədricən Atlassian məhsullarına keçdik. Əvvəlcə Agile-ə uyğun işləməyi asanlaşdırmaq üçün inkişafı köçürdük, sonra dəstək olduq. İndi bütün kritik proseslər Jira SD-də yaşayır, üstəlik onlar Jira üçün müxtəlif plaginlər, üstəgəl Confluence tərəfindən dəstəklənir. Öz-özünə yazılmış həllər yalnız şirkətin fəaliyyəti üçün kritik olmayan proseslər üçün qaldı. Belə çıxır ki, bizim vəzifələrimiz indi kəsişib və bir sistemdən digərinə keçmədən dəstək və inkişaf arasında ötürülə bilər.
Bu linkdən biz bütün tapşırıqlar, planlaşdırılmış və faktiki əmək məsrəfləri haqqında məlumatları əldə edə, müştərilər üçün müxtəlif qiymət seçimlərindən istifadə edə və daxili ehtiyaclar üçün sənədlər yarada və müştərilərə hesabat verə bilərik.
Dəyişiklik sorğuları işlənir
Tipik olaraq, bu cür sorğular funksionallıq tələbləri şəklində gəlir. Analitikimiz sorğunu öyrənir, spesifikasiya və yüksək səviyyəli texniki spesifikasiyalar yaradır. Təsdiq üçün bu sorğunu təqdim edən şəxsə spesifikasiyanı və texniki xüsusiyyətləri köçürür - müştəri ilə eyni dildə danışdığımızdan əmin olmalıyıq.
Müştəridən bir-birimizi düzgün başa düşməyimizə dair təsdiq aldıqdan sonra analitik sorğunu məhsul ehtiyatı siyahısına daxil edir.
Məhsulun funksionallığının idarə edilməsi
Arxa planda dəyişiklik və inkişaf üçün daxil olan sorğular toplanır. Direktor, dəstək, inkişaf, satış rəhbərləri və sistem memarından ibarət texniki şura altı aydan bir toplanır. Müzakirə formatında şura geridə qalan ərizələri təhlil edir və prioritetləşdirir və növbəti buraxılışda həyata keçirilməsi üçün 5 inkişaf tapşırığı ilə razılaşır.
Əslində, texniki şura ərizələrdə ifadə olunan ehtiyacları nəzərdən keçirməklə sənaye və bazar tələblərinə cavab verir. Az əhəmiyyət kəsb edən hər şey geridə qalır və inkişafa çatmır.
Dəyişiklik sorğularının təsnifatı və maliyyə
İnkişaf bahalıdır. Buna görə də, dəyişiklik tələbi işçidən deyil, müştəridən gələrsə, hansı seçimlərə malik ola biləcəyimizi dərhal sizə xəbər verəcəyik.
Biz dəyişiklik tələblərini aşağıdakı kimi təsnif edirik: sənaye ehtiyacı və ya müəssisənin fərdi xüsusiyyətləri; əhəmiyyətli miqdarda yeni funksionallıq və ya kiçik bir düzəliş. Kiçik düzəlişlər və fərdi sorğular heç bir fırıldaq olmadan işlənir. Fərdi sorğular onunla layihə işinin bir hissəsi kimi konkret müştəri üçün hesablanır və həyata keçirilir.
Əgər bu, sənayenin kütləvi tələbatı deyilsə və funksionallığın həcmi böyükdürsə, o zaman əsas funksionallığa əlavə olaraq satılacaq yeni ayrıca modulun hazırlanması barədə qərar qəbul oluna bilər. Müştəridən belə bir sorğu alınarsa, modulun hazırlanması xərclərini ödəyə, müştəriyə modulu pulsuz və ya qismən ödənişlə təqdim edə və modulun özünü satışa çıxara bilərik. Belə bir vəziyyətdə müştəri metodoloji yükün bir hissəsini öz üzərinə götürür və mahiyyətcə modulun pilot tətbiqini həyata keçirir.
Əgər bu, böyük sənaye ehtiyacıdırsa, o zaman əsas məhsula yeni funksionallığın daxil edilməsi barədə qərar qəbul oluna bilər. Bu vəziyyətdə xərclər tamamilə bizim üzərimizə düşür və yeni funksionallıq proqramların cari versiyasında görünür.
Köhnə müştərilərə yeniləmə verilir.
Bir neçə müştərinin oxşar ehtiyacı ola bilər, lakin bu, kütləvi məhsul üçün uyğun deyil. Bu halda, biz spesifikasiyanı bu müştərilərə göndərə və inkişaf xərclərini onlar arasında bölüşdürməyi təklif edə bilərik. Sonda hər kəs qalib gəlir: müştərilər aşağı qiymətə funksionallıq əldə edirlər, biz məhsulu zənginləşdiririk və bir müddət sonra digər bazar iştirakçıları da onların istifadəsi üçün funksionallıq əldə edə bilərlər.
DevOps
İnkişaf ildə iki əsas buraxılış hazırlayır. Hər buraxılışda texniki şuradan alınan 5 tapşırığın yerinə yetirilməsi üçün vaxt ayrılır. Beləliklə, gündəlik işlərin ortasında məhsulun inkişafı haqqında heç vaxt unutmuruq.
Hər buraxılış müvafiq sınaq və sənədlər toplusundan keçir. Sonra, bu buraxılış müvafiq müştərinin sınaq mühitində quraşdırılır, o da öz növbəsində hər şeyi diqqətlə yoxlayır və yalnız bundan sonra buraxılış istehsala ötürülür.
Buraxılış sisteminə əlavə olaraq, müştərilərin altı ay ərzində səhvlərlə yaşamaması üçün tez səhv düzəlişləri üçün bir format var. Bu aralıq format birinci prioritet hadisələrə tez reaksiya verməyə və qeyd olunmuş SLA-ları yerinə yetirməyə imkan verəcək.
Yuxarıda göstərilənlərin hamısı ilk növbədə korporativ sektor və yerli həllər üçün doğrudur. SMB seqmentinə yönəlmiş bulud xidmətləri üçün müştərilərin məhsulun hazırlanmasında iştirak etməsi üçün belə geniş imkanlar yoxdur. SMB icarə formatı hətta bunu nəzərdə tutmur. Korporativ tərəfdən aydın tələblər şəklində dəyişiklik tələbi əvəzinə burada xidmət üçün yalnız adi rəy və istəklər var. Biz qulaq asmağa çalışırıq, lakin məhsul kütləvidir və bir müştərinin öz köhnə tarixi sistemindən tanış bir şey gətirmək istəyi bütövlükdə sistemin inkişaf strategiyasına zidd ola bilər.
Mənbə: www.habr.com