V tomto článku sa podelím o svoje skúsenosti s výberom nápadov na rozvoj funkčnosti našich produktov a poviem vám, ako zachovať hlavné vektory vývoja.
Vyvíjame automatizovaný zúčtovací systém (ACP) - fakturácia. Termín
Životnosť nášho produktu je 14 rokov. Za tento čas sa systém vyvinul z prvých verzií priemyselného tarifného systému na modulárny komplex pozostávajúci z 18 produktov, ktoré sa navzájom dopĺňajú. Jedným z najdôležitejších aspektov dlhovekosti programov je neustály vývoj. A rozvoj si vyžaduje nápady.
nápady
zdroje
Existuje 5 zdrojov:
- Hlavným priateľom vývojára podnikových informačných systémov je zákazníka. A klient je kolektívnym obrazom rozhodovateľov, sponzorov projektov, vlastníkov a vykonávateľov procesov, interných IT špecialistov, bežných používateľov a veľkého počtu zainteresovaných jednotlivcov v rôznej miere. Je pre nás dôležité, aby každý zo zástupcov klienta bol potenciálne dodávateľom nápadov. V najhoršom prípade dostávame iba negatívnu spätnú väzbu o problémoch v systéme. V najlepšom prípade je na strane klienta osoba, ktorá je stálym zdrojom nápadov na zlepšenie a poskytuje štruktúrované informácie o potrebách klienta.
- náš predajcovia a account manažéri sú druhým najdôležitejším zdrojom nápadov na zlepšenie. Aktívne a vo veľkom rozsahu komunikujú so zástupcami odvetvia a dostávajú od potenciálnych klientov otázky týkajúce sa fakturácie z prvej ruky. Predajcovia a účtovníci si musia byť vedomí všetkých významných zmien vo svojich funkciách a najnovších aktualizáciách softvéru konkurentov a musia byť schopní zdôvodniť výhody a nevýhody rôznych riešení. Toto sú naši zamestnanci, ktorí ako prví vycítia, či sa niektoré možnosti fakturácie stanú de facto štandardom, bez ktorého nemožno softvér považovať za kompletný.
- Vlastník produktu — jeden z našich top manažérov alebo veľmi skúsený projektový manažér. Má na zreteli strategické ciele spoločnosti a v súlade s nimi upravuje plány vývoja produktov.
- architekt, osoba, ktorá rozumie možnostiam a obmedzeniam zvolených/použitých technologických riešení a ich vplyvu na vývoj produktu.
Vývojové a testovacie tímy. Ľudia, ktorí sa priamo podieľajú na vývoji produktov.
Klasifikácia žiadostí
Dostávame nespracované údaje zo zdrojov – listy, lístky, ústne žiadosti. Všetky
odvolania sú klasifikované:
- konzultácie s významom „Ako to urobiť?“, „Ako to funguje?“, „Prečo to nejde?“, „Nerozumiem...“. Žiadosti tohto typu smerujú na linku podpory 1. úrovne. Konzultáciu je možné preškoliť na iné typy žiadostí.
- Incidenty s významom „Nefunguje“ a „Chyba“. Spracované 2 a 3 podpornými líniami. Ak sú potrebné rýchle opravy a vydanie opravy, môžu sa preniesť z podpory priamo na vývoj. Je možné ho preklasifikovať na žiadosť o zmenu a odoslať do nevybavených vecí.
- Požiadavky na zmeny a rozvoj. Dostávajú sa do nevybavených produktov a obchádzajú podporné linky. Existuje však pre ne samostatný postup spracovania.
Existuje štatistika žiadostí: ihneď po vydaní sa počet žiadostí na krátky čas zvýši o 10-15%. Nárazy sú aj v prípade, keď do našich cloudových služieb príde nový klient s veľkým počtom používateľov. Ľudia sa učia používať nové možnosti softvéru, potrebujú poradiť. Aj malý klient pri začatí práce v systéme bez problémov spáli viac ako 100 hodín konzultácií mesačne. Pri pripájaní nového klienta si preto vždy vyhradíme čas na úvodné konzultácie. Často si dokonca vyberáme konkrétneho špecialistu. Cena prenájmu, samozrejme, tieto mzdové náklady nepokryje, no časom sa situácia vyrovná. Adaptačné obdobie zvyčajne trvá od 1 do 3 mesiacov, po ktorých sa potreba poradenstva výrazne znižuje.
Predtým sme na ukladanie požiadaviek používali samostatne písané riešenia. Postupne sme ale prešli na produkty Atlassian. Najprv sme preniesli vývoj, aby sme uľahčili prácu podľa Agile, potom podporu. Teraz všetky kritické procesy žijú v Jira SD, navyše sú podporované rôznymi zásuvnými modulmi pre Jira a Confluence. Vlastnoručne písané riešenia zostali len pre procesy, ktoré neboli pre činnosť spoločnosti kritické. Ukazuje sa, že naše úlohy sú teraz prierezové a možno ich prenášať medzi podporou a vývojom bez preskakovania z jedného systému do druhého.
Z tohto odkazu môžeme získavať údaje o všetkých úkonoch, plánovaných a skutočných nákladoch práce, využívať rôzne cenové možnosti pre klientov a generovať dokumentáciu pre interné potreby a reporting klientom.
Spracovanie žiadostí o zmenu
Zvyčajne takéto požiadavky prichádzajú vo forme požiadaviek na funkčnosť. Náš analytik preštuduje požiadavku, vytvorí špecifikáciu a špičkové technické špecifikácie. Prenesie špecifikáciu a technické špecifikácie na osobu, ktorá túto žiadosť predložila na schválenie – musíme si byť istí, že so zákazníkom hovoríme rovnakým jazykom.
Po prijatí potvrdenia od zákazníka, že sme sa správne pochopili, analytik zadá požiadavku do produktového backlogu.
Správa funkčnosti produktu
Nevybavené položky hromadia prichádzajúce požiadavky na zmenu a rozvoj. Technická rada zložená z riaditeľa, vedúcich podpory, vývoja, predaja a systémového architekta sa schádza každých šesť mesiacov. Vo formáte diskusie rada analyzuje a uprednostňuje aplikácie z nevybavených žiadostí a dohodne sa na 5 vývojových úlohách na implementáciu v ďalšom vydaní.
Technická rada v skutočnosti reaguje na požiadavky priemyslu a trhu preskúmaním potrieb vyjadrených v aplikáciách. Všetko, čo je málo relevantné, zostáva v nevybavených záležitostiach a nedosiahne vývoj.
Klasifikácia žiadostí o zmenu a financií
Vývoj je drahý. Preto vám hneď povieme, aké máme možnosti, ak žiadosť o zmenu prišla od klienta a nie od zamestnanca.
Žiadosti o zmenu klasifikujeme nasledovne: potreba odvetvia alebo individuálna charakteristika podniku; značné množstvo nových funkcií alebo menšiu opravu. Drobné opravy a individuálne požiadavky sú spracované bez akýchkoľvek zbytočností. Jednotlivé požiadavky sú kalkulované a realizované pre konkrétneho klienta v rámci projektovej práce s ním.
Ak nejde o masívnu potrebu odvetvia a objem funkcionality je veľký, potom sa môže rozhodnúť o vývoji nového samostatného modulu, ktorý sa bude predávať ako doplnok k hlavnej funkcionalite. V prípade takejto požiadavky od klienta vieme uhradiť náklady na vývoj modulu, poskytnúť klientovi modul zdarma alebo za čiastočnú úhradu a dať samotný modul do predaja. Klient v takejto situácii preberá časť metodickej záťaže a v podstate na sebe vykonáva pilotnú implementáciu modulu.
Ak ide o rozsiahlu potrebu odvetvia, možno sa rozhodnúť zahrnúť novú funkčnosť do základného produktu. Náklady v tomto prípade pripadajú výlučne na nás a nová funkcionalita sa objavuje v aktuálnej verzii programov.
Starým zákazníkom sa poskytuje aktualizácia.
Môže sa tiež stať, že viacerí zákazníci majú podobnú potrebu, ale nespĺňajú podmienky pre masový produkt. V tomto prípade môžeme týmto zákazníkom zaslať špecifikáciu a ponúknuť im rozdelenie nákladov na vývoj medzi nich. Nakoniec vyhráva každý: zákazníci dostanú funkčnosť za nízku cenu, obohatíme produkt a po určitom čase môžu funkčnosť pre svoje použitie získať aj ďalší účastníci trhu.
DevOps
Vývoj pripravuje dve veľké vydania ročne. V každom vydaní je vyhradený čas na realizáciu 5 úloh prijatých od technickej rady. Preto uprostred rutiny nikdy nezabudneme na vývoj produktov.
Každé vydanie prechádza príslušným súborom testovania a dokumentácie. Ďalej sa toto vydanie nainštaluje do testovacieho prostredia príslušného zákazníka, ktorý všetko starostlivo skontroluje a až potom sa vydanie prenesie do produkcie.
Okrem systému uvoľnenia existuje aj formát na rýchle opravy chýb, aby klienti šesť mesiacov nežili s chybami. Tento prechodný formát vám umožní rýchlo reagovať na prvoradé incidenty a splniť uvedené SLA.
Všetko vyššie uvedené platí predovšetkým pre firemný sektor a on-premise riešenia. Pri cloudových službách zameraných na segment SMB nie sú pre klientov také široké možnosti podieľať sa na vývoji produktov. Formát prenájmu SMB to ani nepredpokladá. Namiesto požiadavky na zmenu v podobe jasných požiadaviek zo strany firemného večierka je tu len obyčajná spätná väzba a priania k službe. Snažíme sa počúvať, ale produkt je masívny a túžba jedného klienta priniesť niečo známe z jeho starého historického systému môže byť v rozpore so stratégiou vývoja systému ako celku.
Zdroj: hab.com