U ovom članku ću podijeliti svoje iskustvo u odabiru ideja za razvoj funkcionalnosti naših proizvoda i reći vam kako održavati glavne vektore razvoja.
Razvijamo automatizovani sistem poravnanja (ACP) - naplatu. Termin
Životni vek našeg proizvoda je 14 godina. Tokom ovog vremena, sistem je evoluirao od prvih verzija industrijskog tarifnog sistema do modularnog kompleksa koji se sastoji od 18 proizvoda koji se međusobno nadopunjuju. Jedan od najvažnijih aspekata dugovječnosti programa je stalni razvoj. A razvoj zahteva ideje.
Ideje
Izvori
Postoji 5 izvora:
- Glavni prijatelj programera korporativnih informacionih sistema je mušterija. A klijent je zbirna slika donosilaca odluka, sponzora projekata, vlasnika i izvršilaca procesa, internih IT stručnjaka, običnih korisnika i velikog broja zainteresovanih pojedinaca u različitom stepenu. Važno nam je da svaki od predstavnika klijenta bude potencijalni dobavljač ideja. U najgorem slučaju dobijamo samo negativne povratne informacije o problemima u sistemu. U najboljem slučaju, na strani klijenta je osoba koja je stalni izvor ideja za poboljšanje, pružajući strukturirane informacije o potrebama klijenta.
- Naši prodavači i menadžeri računa su drugi najvažniji izvor ideja za poboljšanje. Oni aktivno i ekstenzivno komuniciraju s predstavnicima industrije i primaju upite iz prve ruke o funkcionalnosti naplate od potencijalnih klijenata. Prodavci i nalozi moraju biti svjesni svih značajnih promjena u svojoj funkcionalnosti i najnovijim ažuriranjima softvera konkurenata, te biti u stanju da opravdaju prednosti i nedostatke različitih rješenja. To su naši zaposlenici koji prvi osjećaju da li neke mogućnosti naplate postanu de facto standard, bez kojeg se softver ne može smatrati kompletnim.
- Vlasnik proizvoda — jedan od naših top menadžera ili vrlo iskusan projektni menadžer. Ima na umu strateške ciljeve kompanije i u skladu sa njima prilagođava planove razvoja proizvoda.
- Arhitekta, osoba koja razumije mogućnosti i ograničenja izabranih/korištenih tehnoloških rješenja i njihov utjecaj na razvoj proizvoda.
Timovi za razvoj i testiranje. Ljudi koji su direktno uključeni u razvoj proizvoda.
Klasifikacija zahtjeva
Neobrađene podatke primamo iz izvora - pisma, karte, usmeni zahtjevi. Sve
žalbe su klasifikovane:
- Konzultacije sa značenjem “Kako to učiniti?”, “Kako to radi?”, “Zašto ne radi?”, “Ne razumijem...”. Zahtjevi ove vrste idu na liniju podrške nivoa 1. Moguće je preobučiti konsultacije u druge vrste zahtjeva.
- Incidenti sa značenjem “Ne radi” i “Greška”. Obrađeno od 2 i 3 linije podrške. Ako su potrebne brze ispravke i izdavanje zakrpe, one se mogu prenijeti sa podrške direktno na razvoj. Moguće ga je reklasificirati kao zahtjev za promjenu i poslati u zaostatak.
- Zahtjevi za promjene i razvoj. Oni ulaze u zaostatak proizvoda, zaobilazeći linije podrške. Ali za njih postoji poseban postupak obrade.
Postoji statistika o zahtjevima: odmah nakon objavljivanja, broj zahtjeva se za kratko vrijeme povećava za 10-15%. Također dolazi do porasta zahtjeva kada novi klijent sa velikim brojem korisnika dođe na naše usluge u oblaku. Ljudi uče da koriste nove softverske mogućnosti, treba im savet. Čak i mali klijent, kada počne da radi u sistemu, lako potroši više od 100 sati konsultacija mesečno. Stoga, prilikom povezivanja novog klijenta, uvijek rezervišemo vrijeme za inicijalne konsultacije. Često čak biramo i određenog stručnjaka. Cijena najma, naravno, ne pokriva ove troškove rada, ali se vremenom situacija izjednači. Period adaptacije obično traje od 1 do 3 mjeseca, nakon čega se potreba za savjetovanjem značajno smanjuje.
Ranije smo koristili samopisna rješenja za pohranjivanje zahtjeva. Ali postepeno smo prešli na Atlassian proizvode. Prvo smo prenijeli razvoj kako bismo olakšali rad prema Agileu, a zatim podršku. Sada svi kritični procesi žive u Jira SD, plus su podržani od strane raznih dodataka za Jira, plus Confluence. Samostalna rješenja ostala su samo za procese koji nisu bili kritični za poslovanje kompanije. Ispostavilo se da su naši zadaci sada unakrsni i da se mogu prenositi između podrške i razvoja bez skakanja s jednog sistema na drugi.
Iz ovog paketa možemo dobiti podatke o svim zadacima, planiranim i stvarnim troškovima rada, koristiti različite cjenovne opcije za klijente i generirati dokumentaciju za interne potrebe i izvještavanje klijenata.
Obrada zahtjeva za izmjenom
Tipično, takvi zahtjevi dolaze u obliku funkcionalnih zahtjeva. Naš analitičar proučava zahtjev, kreira specifikaciju i vrhunske tehničke specifikacije. Prenosi specifikaciju i tehničke specifikacije osobi koja je podnijela ovaj zahtjev na odobrenje - moramo biti sigurni da govorimo istim jezikom sa kupcem.
Dobivši potvrdu od kupca da smo se dobro razumjeli, analitičar unosi zahtjev u zaostatak proizvoda.
Upravljanje funkcionalnošću proizvoda
Zaostatak akumulira dolazne zahtjeve za promjenom i razvojem. Tehničko vijeće, koje čine direktor, šefovi podrške, razvoja, prodaje i arhitekta sistema, sastaje se svakih šest mjeseci. U formatu diskusije, vijeće analizira i daje prioritet aplikacijama iz zaostalih predmeta i dogovara 5 razvojnih zadataka za implementaciju u sljedećem izdanju.
U stvari, tehničko vijeće odgovara na zahtjeve industrije i tržišta preispitujući potrebe izražene u aplikacijama. Sve što je malo relevantno ostaje u zaostatku i ne stiže do razvoja.
Klasifikacija zahtjeva za promjenom i financija
Razvoj je skup. Stoga ćemo vam odmah reći koje opcije možemo imati ako je zahtjev za promjenu došao od klijenta, a ne od zaposlenika.
Zahtjeve za promjenu klasifikujemo na sljedeći način: potrebe industrije ili individualne karakteristike preduzeća; značajnu količinu nove funkcionalnosti ili manju popravku. Manje popravke i pojedinačni zahtjevi se obrađuju bez ikakvih dodataka. Pojedinačni zahtjevi se izračunavaju i realizuju za konkretnog klijenta u sklopu projektnog rada sa njim.
Ako ovo nije velika potreba industrije i obim funkcionalnosti je velik, tada se može donijeti odluka o razvoju novog zasebnog modula koji će se prodavati uz glavnu funkcionalnost. Ako takav zahtjev dobijemo od klijenta, možemo pokriti troškove razvoja modula, dati klijentu modul besplatno ili uz djelimično plaćanje, te sam modul staviti na prodaju. U takvoj situaciji klijent preuzima dio metodološkog opterećenja i u suštini na sebi provodi pilot implementaciju modula.
Ako je ovo ogromna potreba industrije, tada se može donijeti odluka o uključivanju nove funkcionalnosti u osnovni proizvod. Troškovi u ovom slučaju padaju u potpunosti na nas, a nova funkcionalnost se pojavljuje u trenutnoj verziji programa.
Starim kupcima je omogućeno ažuriranje.
Također može biti da nekoliko kupaca ima sličnu potrebu, ali to se ne kvalificira za masovni proizvod. U tom slučaju možemo poslati specifikaciju ovim kupcima i ponuditi da podijelimo troškove razvoja između njih. Na kraju svi dobijaju: kupci dobijaju funkcionalnost po niskoj ceni, mi obogaćujemo proizvod, a nakon nekog vremena i drugi učesnici na tržištu mogu dobiti funkcionalnost za svoju upotrebu.
DevOps
Razvoj priprema dva velika izdanja godišnje. U svakom izdanju rezervisano je vreme za realizaciju 5 zadataka dobijenih od tehničkog saveta. Stoga, usred rutine, nikada ne zaboravljamo razvoj proizvoda.
Svako izdanje prolazi kroz odgovarajući skup testiranja i dokumentacije. Zatim se ovo izdanje instalira u testno okruženje odgovarajućeg korisnika, koji zauzvrat sve pomno provjerava i tek nakon toga se izdanje prenosi u proizvodnju.
Pored sistema za izdavanje, postoji i format za brze ispravke grešaka tako da klijenti ne žive sa greškama šest meseci. Ovaj srednji format će vam omogućiti da brzo odgovorite na incidente prvog prioriteta i ispunite navedene SLA.
Sve navedeno vrijedi prvenstveno za korporativni sektor i on-premise rješenja. Za usluge u oblaku namenjene segmentu malih i srednjih preduzeća, ne postoje tako široke mogućnosti da klijenti učestvuju u razvoju proizvoda. Format iznajmljivanja za SMB ovo čak ni ne pretpostavlja. Umjesto zahtjeva za promjenom u vidu jasnih zahtjeva korporativne strane, ovdje su samo obične povratne informacije i želje za uslugu. Pokušavamo da slušamo, ali proizvod je masivan i želja jednog klijenta da donese nešto poznato iz svog starog istorijskog sistema može biti u suprotnosti sa strategijom razvoja sistema u celini.
izvor: www.habr.com