U ovom ću članku podijeliti svoje iskustvo u odabiru ideja za razvoj funkcionalnosti naših proizvoda i reći vam kako održati glavne vektore razvoja.
Razvijamo automatizirani sustav poravnanja (ACP) - billing. Termin
Životni vijek našeg proizvoda je 14 godina. Tijekom tog vremena sustav je evoluirao od prvih verzija industrijskog tarifnog sustava 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 za razvoj su potrebne ideje.
ideje
izvori
Postoji 5 izvora:
- Glavni prijatelj programera korporativnih informacijskih sustava je klijent. A klijent je zbirna slika donositelja odluka, nositelja projekta, vlasnika i izvršitelja procesa, internih informatičara, običnih korisnika i velikog broja zainteresiranih pojedinaca u različitoj mjeri. Važno nam je da je svaki od predstavnika klijenta potencijalni dobavljač ideja. U najgorem slučaju dobivamo samo negativne povratne informacije o problemima u sustavu. U najboljem slučaju, na strani klijenta postoji osoba koja je stalni izvor ideja za poboljšanje, pružajući strukturirane informacije o potrebama klijenta.
- naš prodavači i account manageri drugi su najvažniji izvor ideja za poboljšanje. Oni aktivno i opsežno komuniciraju s predstavnicima industrije i primaju upite iz prve ruke o funkcionalnosti naplate od potencijalnih klijenata. Prodavači i računi moraju biti upoznati sa svim značajnim promjenama u svojim funkcionalnostima i najnovijim ažuriranjima softvera konkurenata, te biti u stanju opravdati prednosti i nedostatke različitih rješenja. To su naši zaposlenici koji prvi osjete hoće li neke mogućnosti naplate postati de facto standard, bez kojeg se softver ne može smatrati potpunim.
- Vlasnik proizvoda — jedan od naših vrhunskih menadžera ili vrlo iskusan voditelj projekta. Vodi računa o strateškim ciljevima tvrtke iu skladu s njima prilagođava planove razvoja proizvoda.
- arhitekta, osoba koja razumije mogućnosti i ograničenja odabranih/korištenih tehnoloških rješenja i njihov utjecaj na razvoj proizvoda.
Timovi za razvoj i testiranje. Ljudi koji su izravno uključeni u razvoj proizvoda.
Klasifikacija zahtjeva
Primamo sirove podatke iz izvora - pisma, ulaznice, usmeni zahtjevi. svi
žalbe su klasificirane:
- Konzultacije sa značenjem "Kako to učiniti?", "Kako to radi?", "Zašto ne radi?", "Ne razumijem...". Zahtjevi ove vrste idu na liniju za podršku razine 1. Konzultacije je moguće prekvalificirati u druge vrste zahtjeva.
- Incidenti sa značenjem “Ne radi” i “Greška”. Obrađuju 2 i 3 linije podrške. Ako su potrebni brzi ispravci i izdavanje zakrpe, oni se mogu prenijeti iz podrške izravno u razvoj. Moguće ga je reklasificirati kao zahtjev za izmjenom i poslati u zaostatak.
- Zahtjevi za promjenama i razvojem. Upadaju u proizvodni zaostatak, zaobilazeći linije podrške. Ali za njih postoji poseban postupak obrade.
Postoji statistika o zahtjevima: odmah nakon puštanja, broj zahtjeva se povećava za 10-15% za kratko vrijeme. Također dolazi do skokova u zahtjevima kada na naše usluge u oblaku dođe novi klijent s velikim brojem korisnika. Ljudi uče koristiti nove softverske mogućnosti, trebaju im savjeti. Čak i mali klijent, kada počne raditi u sustavu, lako spali više od 100 sati konzultacija mjesečno. Stoga pri povezivanju novog klijenta uvijek rezerviramo vrijeme za početne konzultacije. Često čak izaberemo određenog stručnjaka. Cijena najma, naravno, ne pokriva te troškove rada, ali s vremenom se situacija poravnava. Period prilagodbe obično traje od 1 do 3 mjeseca, nakon čega je potreba za savjetovanjem značajno smanjena.
Ranije smo za pohranu zahtjeva koristili rješenja koja smo sami napisali. Ali postupno smo prešli na Atlassian proizvode. Prvo smo prenijeli razvoj kako bismo lakše radili prema Agileu, zatim podršku. Sada svi kritični procesi žive u Jira SD, plus podržani su raznim dodacima za Jira, plus Confluence. Samostalno napisana rješenja ostala su samo za procese koji nisu bili kritični za aktivnosti tvrtke. Ispostavilo se da su naši zadaci sada međusektorski i mogu se prenositi između podrške i razvoja bez preskakanja s jednog sustava na drugi.
Na ovom linku možemo dobiti podatke o svim poslovima, planiranim i stvarnim troškovima rada, koristiti razne cjenovne opcije za klijente te izraditi dokumentaciju za interne potrebe i izvještavanje prema klijentima.
Obrada zahtjeva za promjenama
Tipično, takvi zahtjevi dolaze u obliku funkcionalnih zahtjeva. Naš analitičar proučava zahtjev, izrađuje specifikaciju i tehničke specifikacije najviše razine. Prenosi specifikaciju i tehničke specifikacije osobi koja je podnijela ovaj zahtjev na odobrenje - moramo biti sigurni da govorimo istim jezikom s kupcem.
Nakon što od kupca dobije potvrdu da smo se dobro razumjeli, analitičar unosi zahtjev u backlog proizvoda.
Upravljanje funkcionalnošću proizvoda
Zaostatak gomila dolazne zahtjeve za promjenama i razvojem. Tehničko vijeće koje se sastoji od direktora, voditelja podrške, razvoja, prodaje i arhitekta sustava sastaje se svakih šest mjeseci. U formatu rasprave, vijeće analizira i daje prioritet aplikacijama iz zaostataka te se slaže oko 5 razvojnih zadataka za implementaciju u sljedećem izdanju.
Zapravo, tehničko vijeće odgovara na zahtjeve industrije i tržišta pregledom potreba izraženih u prijavama. Sve što je malo bitno ostaje u zaostatku i ne doživi razvoj.
Klasifikacija zahtjeva za promjenama i financija
Razvoj je skup. Stoga ćemo vam odmah reći koje mogućnosti imamo ako je zahtjev za promjenom došao od klijenta, a ne od zaposlenika.
Klasificiramo zahtjeve za promjenama na sljedeći način: potreba industrije ili pojedinačna karakteristika poduzeća; značajna količina novih funkcija ili manji popravak. Manji popravci i pojedinačni zahtjevi obrađuju se bez ikakvih dodataka. Individualni zahtjevi se izračunavaju i realiziraju za određenog klijenta u sklopu projektnog rada s njim.
Ako ovo nije velika potreba industrije i opseg funkcionalnosti je velik, tada se može donijeti odluka da se razvije novi zasebni modul koji će se prodavati uz glavnu funkcionalnost. Ukoliko zaprimimo takav zahtjev od klijenta, mi možemo pokriti troškove razvoja modula, dati klijentu modul besplatno ili uz djelomičnu naplatu, a sam modul dati u prodaju. U takvoj situaciji klijent preuzima dio metodološkog opterećenja i u biti provodi pilot implementaciju modula na sebi.
Ako se radi o velikoj industrijskoj potrebi, može se 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.
Stari kupci dobivaju ažuriranje.
Također se može dogoditi da nekoliko kupaca ima sličnu potrebu, ali to ne ispunjava uvjete za masovni proizvod. U tom slučaju možemo poslati specifikaciju tim kupcima i ponuditi im podjelu troškova razvoja. Na kraju svi dobivaju: kupci dobivaju funkcionalnost po niskoj cijeni, mi obogaćujemo proizvod, a nakon nekog vremena i drugi sudionici na tržištu mogu dobiti funkcionalnost za svoje korištenje.
DevOps
Razvoj priprema dva velika izdanja godišnje. U svakom izdanju rezervirano je vrijeme za provedbu 5 zadataka dobivenih od tehničkog vijeća. Stoga, usred rutine, nikada ne zaboravljamo razvoj proizvoda.
Svako izdanje prolazi odgovarajući skup testiranja i dokumentacije. Zatim se ovo izdanje instalira u testno okruženje odgovarajućeg kupca, koji zauzvrat sve pažljivo provjerava i tek nakon toga se izdanje prenosi u proizvodnju.
Uz sustav izdanja, postoji format za brze popravke grešaka tako da klijenti ne žive s greškama šest mjeseci. Ovaj srednji format omogućit će vam da brzo odgovorite na incidente prvog prioriteta i ispunite navedene SLA.
Sve navedeno prvenstveno vrijedi za korporativni sektor i on-premise rješenja. Za usluge u oblaku namijenjene segmentu malih i srednjih poduzeća ne postoje tako široke mogućnosti za klijente da sudjeluju u razvoju proizvoda. Format najma za mala i srednja poduzeća to niti ne pretpostavlja. Umjesto zahtjeva za promjenom u obliku jasnih zahtjeva korporativne stranke, ovdje postoje samo obične povratne informacije i želje za uslugom. Pokušavamo slušati, ali proizvod je masivan i želja jednog klijenta da donese nešto poznato iz svog starog povijesnog sustava može biti u suprotnosti sa strategijom razvoja sustava u cjelini.
Izvor: www.habr.com