V tem članku bom delil svoje izkušnje pri izbiri idej za razvoj funkcionalnosti naših izdelkov in vam povedal, kako ohraniti glavne vektorje razvoja.
Razvijamo avtomatiziran poravnalni sistem (ACP) – obračunavanje. Izraz
Življenjska doba našega izdelka je 14 let. V tem času se je sistem razvil od prvih različic industrijskega tarifnega sistema do modularnega kompleksa, sestavljenega iz 18 izdelkov, ki se med seboj dopolnjujejo. Eden najpomembnejših vidikov dolgoživosti programov je stalen razvoj. In razvoj zahteva ideje.
Zamisli
viri
Obstaja 5 virov:
- Glavni prijatelj razvijalca korporativnih informacijskih sistemov je stranka. In naročnik je skupna podoba odločevalcev, nosilcev projektov, lastnikov in izvajalcev procesov, internih informatikov, običajnih uporabnikov in velikega števila zainteresiranih posameznikov v različni meri. Za nas je pomembno, da je vsak od naročnikovih predstavnikov potencialni dobavitelj idej. V najslabšem primeru dobimo le negativne povratne informacije o težavah v sistemu. V najboljšem primeru je na strani naročnika oseba, ki je nenehen vir idej za izboljšave in zagotavlja strukturirane informacije o potrebah naročnika.
- Naše prodajalci in vodje računov so drugi najpomembnejši vir idej za izboljšave. Aktivno in obsežno komunicirajo s predstavniki industrije in prejemajo povpraševanja potencialnih strank iz prve roke o funkcionalnosti zaračunavanja. Prodajalci in računi morajo biti seznanjeni z vsemi pomembnimi spremembami svojih funkcionalnosti in najnovejšimi posodobitvami programske opreme konkurence ter znati utemeljiti prednosti in slabosti različnih rešitev. To so naši zaposleni, ki prvi začutijo, če nekatere možnosti obračunavanja postanejo de facto standard, brez katerega programska oprema ne more veljati za popolno.
- Lastnik izdelka — eden od naših najvišjih vodij ali zelo izkušen vodja projektov. Upošteva strateške cilje podjetja in jim prilagaja načrte razvoja izdelkov.
- Arhitekt, oseba, ki razume zmožnosti in omejitve izbranih/uporabljenih tehnoloških rešitev ter njihov vpliv na razvoj izdelka.
Ekipe za razvoj in testiranje. Ljudje, ki so neposredno vključeni v razvoj izdelkov.
Razvrstitev zahtevkov
Prejemamo neobdelane podatke iz virov - pisma, vstopnice, ustne zahteve. Vse
pritožbe so razvrščene:
- Posvetovanja s pomenom »Kako to narediti?«, »Kako deluje?«, »Zakaj ne deluje?«, »Ne razumem ...«. Zahteve te vrste gredo na linijo za podporo 1. stopnje. Posvetovanje je mogoče prekvalificirati v druge vrste zahtev.
- Incidenti s pomenoma »Ne deluje« in »Napaka«. Obdelujejo 2 in 3 podporne linije. Če so potrebni takojšnji popravki in izdaja popravka, jih je mogoče prenesti iz podpore neposredno v razvoj. Možno ga je prekvalificirati kot zahtevo za spremembo in poslati v zaostanek.
- Zahteve za spremembe in razvoj. Pridejo v zaostanek izdelkov, mimo podpornih linij. Toda zanje obstaja ločen postopek obdelave.
Obstaja statistika o zahtevah: takoj po izdaji se število zahtev za kratek čas poveča za 10-15%. Povpraševanje se poveča tudi, ko v naše storitve v oblaku pride nova stranka z velikim številom uporabnikov. Ljudje se učijo uporabljati nove zmožnosti programske opreme, potrebujejo nasvet. Tudi majhna stranka ob začetku dela v sistemu zlahka pokuri več kot 100 ur svetovanj na mesec. Zato si ob priklopu nove stranke vedno rezerviramo čas za začetne posvete. Pogosto celo izberemo določenega strokovnjaka. Cena najema seveda ne pokrije teh stroškov dela, vendar se sčasoma stanje izravna. Prilagoditveno obdobje običajno traja od 1 do 3 mesece, po katerem se potreba po svetovanju znatno zmanjša.
Prej smo za shranjevanje zahtev uporabljali samonapisane rešitve. Toda postopoma smo prešli na izdelke Atlassian. Najprej smo prenesli razvoj za lažje delo po Agileu, nato podporo. Zdaj vsi kritični procesi živijo v Jira SD, poleg tega pa jih podpirajo različni vtičniki za Jira in Confluence. Samostojne rešitve so ostale le za procese, ki niso bili kritični za delovanje podjetja. Izkazalo se je, da so naše naloge zdaj medsektorske in jih je mogoče prenašati med podporo in razvojem brez preskakovanja iz enega sistema v drugega.
Na tej povezavi lahko pridobimo podatke o vseh nalogah, načrtovanih in dejanskih stroških dela, uporabimo različne cenovne možnosti za naročnike ter oblikujemo dokumentacijo za interne potrebe in poročanje naročnikom.
Obdelava zahtevkov za spremembe
Običajno so takšne zahteve v obliki funkcijskih zahtev. Naš analitik preuči zahtevo, izdela specifikacijo in vrhunske tehnične specifikacije. Prenese specifikacijo in tehnične specifikacije osebi, ki je predložila to zahtevo v odobritev - moramo biti prepričani, da s stranko govorimo isti jezik.
Po prejemu potrditve naročnika, da smo se prav razumeli, analitik zahtevo vnese v produktni zaostanek.
Upravljanje funkcionalnosti izdelka
Zaostanek kopiči dohodne zahteve za spremembe in razvoj. Tehnični svet, ki ga sestavljajo direktor, vodje podpore, razvoja, prodaje in sistemski arhitekt, se sestaja vsakih šest mesecev. V obliki razprave svet analizira in prednostno razvrsti aplikacije iz zaostankov ter se dogovori o 5 razvojnih nalogah za izvedbo v naslednji izdaji.
Dejansko se tehnični svet odziva na zahteve industrije in trga s pregledovanjem potreb, izraženih v prijavah. Vse, kar je malo relevantno, ostane v zaostanku in ne doseže razvoja.
Razvrstitev zahtevkov za spremembe in financ
Razvoj je drag. Zato vam bomo takoj povedali, kakšne možnosti imamo, če je zahteva za spremembo prišla s strani naročnika in ne zaposlenega.
Zahteve za spremembe razvrščamo na: potrebe industrije ali individualne značilnosti podjetja; precejšnjo količino nove funkcionalnosti ali manjši popravek. Manjši popravki in posamezne zahteve so obdelane brez kakršnih koli dodatkov. Individualne zahteve izračunamo in izvedemo za posameznega naročnika v okviru projektnega dela z njim.
Če to ni velika potreba industrije in je obseg funkcionalnosti velik, se lahko odločimo za razvoj novega ločenega modula, ki se bo prodajal poleg glavne funkcionalnosti. Če prejmemo tako zahtevo naročnika, lahko krijemo stroške razvoja modula, naročniku modul izročimo brezplačno ali z delnim plačilom in sam modul damo v prodajo. V takšni situaciji naročnik prevzame del metodološke obremenitve in v bistvu izvede pilotno implementacijo modula na sebi.
Če je to ogromna potreba industrije, se lahko sprejme odločitev, da se v osnovni izdelek vključi nova funkcionalnost. Stroški v tem primeru v celoti bremenijo nas, nova funkcionalnost pa se pojavi v trenutni različici programov.
Starim strankam je na voljo posodobitev.
Lahko se tudi zgodi, da ima več strank podobno potrebo, vendar to ne izpolnjuje pogojev za masovni izdelek. V tem primeru lahko tem strankam pošljemo specifikacijo in jim ponudimo razdelitev stroškov razvoja. Na koncu zmagajo vsi: kupci prejmejo funkcionalnost po nizki ceni, mi produkt obogatimo, čez nekaj časa pa lahko funkcionalnost dobijo v svojo uporabo tudi drugi udeleženci na trgu.
DevOps
Razvoj pripravi dve večji izdaji na leto. V vsaki objavi je rezerviran čas za izvedbo 5 nalog, prejetih s strani tehničnega sveta. Tako sredi rutine nikoli ne pozabimo na razvoj izdelkov.
Vsaka izdaja je podvržena ustreznemu nizu testiranj in dokumentacije. Nato se ta izdaja namesti v testno okolje ustrezne stranke, ki nato vse natančno preveri in šele nato se izdaja prenese v produkcijo.
Poleg sistema za izdajo je na voljo oblika za hitre popravke napak, tako da odjemalci ne živijo z napakami šest mesecev. Ta vmesni format vam bo omogočil, da se hitro odzovete na incidente prve prioritete in izpolnite navedene SLA.
Vse našteto velja predvsem za podjetniški sektor in rešitve na mestu uporabe. Pri oblačnih storitvah, namenjenih segmentu SMB, ni tako širokih možnosti za sodelovanje strank pri razvoju produkta. Oblika najema SMB tega sploh ne predvideva. Namesto zahteve za spremembo v obliki jasnih zahtev s strani podjetja, so tukaj le navadne povratne informacije in želje za storitev. Poskušamo poslušati, vendar je izdelek ogromen in želja ene stranke, da prinese nekaj znanega iz svojega starega zgodovinskega sistema, je lahko v nasprotju z razvojno strategijo sistema kot celote.
Vir: www.habr.com