V tomto článku se podělím o své zkušenosti s výběrem nápadů pro rozvoj funkčnosti našich produktů a řeknu vám, jak zachovat hlavní vývojové vektory.
Vyvíjíme automatizovaný zúčtovací systém (ACS) - fakturace. Období
Životnost našeho výrobku je 14 let. Za tuto dobu přešel systém od prvních verzí průmyslového hodnotitele k modulárnímu komplexu skládajícím se z 18 produktů, které se vzájemně doplňují. Jedním z nejdůležitějších aspektů dlouhověkosti programů je neustálý vývoj. A k rozvoji jsou potřeba nápady.
Nápady
zdroje
Existuje 5 zdrojů:
- Hlavním přítelem vývojáře podnikových informačních systémů je zákazník. A klient je kolektivní obraz tvůrců rozhodnutí, sponzorů projektů, vlastníků a vykonavatelů procesů, interních IT specialistů, běžných uživatelů a velkého množství lidí, kteří se v různé míře zajímají. Je pro nás důležité, aby každý ze zástupců klienta byl potenciálně dodavatelem nápadů. V nejhorším případě dostaneme pouze negativní zpětnou vazbu o problémech v systému. V nejlepším případě je na straně klienta člověk, který je neustálým zdrojem nápadů na zlepšení a poskytuje strukturované informace o potřebách klienta.
- Náš prodejci a správci účtů jsou druhým nejdůležitějším zdrojem nápadů na zlepšení. Hodně a aktivně komunikují se zástupci oboru, dostávají od potenciálních zákazníků požadavky na funkcionalitu fakturace z první ruky. Obchodníci a účty si musí být vědomi všech významných změn ve své funkcionalitě a nejnovějších softwarových aktualizací konkurentů, být schopni zdůvodnit klady a zápory různých řešení. Právě tito naši zaměstnanci jako první pocítí, zda se některé fakturační funkce stávají de facto standardem, bez kterého nelze software považovat za kompletní.
- Vlastník produktu je jedním z našich top manažerů nebo velmi zkušeným projektovým manažerem. Udržuje strategické cíle společnosti na paměti a v souladu s nimi upravuje plány vývoje produktů.
- Architekt, člověk, který rozumí možnostem a omezením zvolených / používaných technologických řešení a jejich vlivu na vývoj produktu.
Vývojové a testovací týmy. Lidé, kteří se přímo podílejí na vývoji produktů.
Klasifikace hitů
Získáváme nezpracovaná data ze zdrojů – dopisy, vstupenky, ústní žádosti. Všechno
odvolání jsou klasifikována:
- konzultace s významem "Jak na to?", "Jak to funguje?", "Proč to nejde?", "Nerozumím...". Hovory tohoto typu směřují na linku podpory 1. úrovně. Konzultaci je možné přeškolit na jiné typy odvolání.
- Incidenty s významem „Nefunguje“ a „Chyba“. Obsluhováno 2 a 3 nosnými linkami. Pokud je potřeba rychle opravit a vydat opravu, lze ji přenést z podpory přímo do vývoje. Je možné jej překlasifikovat na žádost o změnu a odeslat do nevyřízeného.
- Požadavky na změny a rozvoj. Dostaňte se do produktového backlogu a obejděte linky podpory. Ale pro ně existuje samostatný postup zpracování.
Existuje taková statistika o hitech - ihned po vydání roste počet hitů krátkodobě o 10-15%. Dochází také k návalům hovorů, když do našich cloudových služeb přijde nový klient s velkým počtem uživatelů. Lidé se učí používat nové funkce softwaru, potřebují poradit. I malý klient při zahájení práce v systému snadno spálí více než 100 hodin konzultací za měsíc. Při připojování nového klienta si proto vždy vyhradíme čas na úvodní konzultace. Často dokonce vyčleňujeme konkrétního specialistu. Náklady na nájem samozřejmě tyto mzdové náklady nevyplatí, ale postupem času se situace vyrovná. Adaptační období trvá zpravidla 1 až 3 měsíce, poté je potřeba poradenství výrazně snížena.
Dříve jsme k ukládání hovorů používali vlastní řešení. Postupně ale přešel na produkty Atlassian. Nejprve se přenesl vývoj, aby se snáze pracovalo na Agile, pak podpora. Nyní všechny kritické procesy žijí v Jira SD a navíc jsou vybaveny různými pluginy pro Jira a navíc Confluence. Samostatně psaná řešení zůstala pouze na nekritických procesech pro činnost společnosti. Ukázalo se, že naše úkoly jsou nyní end-to-end, lze je přenášet mezi podporou a vývojem bez přeskakování z jednoho systému do druhého.
Z tohoto balíčku můžeme získat data o všech úkolech, plánovaných i skutečných mzdových nákladech, využít různé možnosti fakturace pro klienty a generovat dokumentaci pro interní potřeby a report klientům.
Zpracování požadavků na změnu
Tyto požadavky obvykle přicházejí ve formě požadavků na funkce. Náš analytik prostuduje požadavek, vygeneruje specifikaci a TOR nejvyšší úrovně. Předá specifikaci a TOR osobě, která podala tuto žádost ke schválení – musíme si být jisti, že se zákazníkem mluvíme stejným jazykem.
Po obdržení potvrzení od zákazníka, že jsme si správně rozuměli, zadá analytik požadavek do produktového backlogu.
Správa vlastností produktu
Nevyřízené položky shromažďují přijaté požadavky na změnu a vývoj. Jednou za půl roku se schází technická rada složená z ředitele, vedoucích údržby, vývoje, prodeje a systémového architekta. V diskusním formátu rada analyzuje a upřednostňuje aplikace z nevyřízených položek a odsouhlasí 5 vývojových úkolů pro implementaci v příštím vydání.
Technická rada ve skutečnosti reaguje na požadavky průmyslu a trhu s ohledem na potřeby zaznamenané v aplikacích. Vše, co je málo relevantní, zůstává v nevyřízených záležitostech a nedosáhne rozvoje.
Klasifikace změnových požadavků a financí
Vývoj je drahý. Proto vám okamžitě sdělíme, jaké můžeme mít možnosti, pokud požadavek na změnu přišel od klienta, nikoli od zaměstnance.
Požadavky na změnu jsou klasifikovány takto: specifické potřeby odvětví nebo individuální charakteristiky podniku; významné množství nových funkcí nebo malá oprava. Drobné opravy a individuální požadavky jsou zpracovávány bez jakýchkoli ozdůbek. Jednotlivé požadavky jsou kalkulovány a realizovány pro konkrétního klienta v rámci projektové práce s ním.
Pokud se nejedná o masivní průmyslovou potřebu a množství funkcí je velké, pak lze rozhodnout o vývoji nového samostatného modulu, který bude prodáván jako doplněk k hlavní funkcionalitě. Pokud takový požadavek od klienta obdrží, můžeme uhradit náklady na vývoj modulu, poskytnout klientovi modul zdarma nebo za částečnou úhradu a dát modul do veřejné sféry k prodeji. Klient v takové situaci přebírá část metodické zátěže a v podstatě provádí pilotní implementaci modulu.
Pokud se jedná o masivní potřebu odvětví, lze se rozhodnout zahrnout do základního produktu nové funkce. Náklady v tomto případě neseme zcela my a nová funkcionalita se objevuje v aktuální verzi programů.
Starým zákazníkům je poskytnuta aktualizace.
Může se také stát, že několik zákazníků má podobnou potřebu, ale netáhne to na masový produkt. V takovém případě můžeme těmto zákazníkům zaslat specifikaci a nabídnout jim sdílení nákladů na vývoj. Nakonec vyhrává každý: zákazníci získají implementaci funkcionality za nízkou cenu, my obohatíme produkt, po chvíli mohou funkcionalitu pro své použití získat i další účastníci trhu.
devops
Vývoj připravuje dvě hlavní verze ročně. V každém vydání je vyhrazen čas na realizaci 5 úkolů obdržených od technické rady. Za obratem tedy nikdy nezapomínáme na vývoj produktu.
Každé vydání prochází vhodnou sadou testování a dokumentace. Dále je tato verze nainstalována v testovacím prostředí příslušného zákazníka, který zase vše pečlivě kontroluje a teprve poté je vydání převedeno do výroby.
Kromě systému vydání existuje formát rychlých oprav chyb, aby zákazníci nežili s chybami po dobu šesti měsíců. Tento přechodný formát vám umožní rychle reagovat na incidenty prvních priorit a plnit uvedenou SLA.
Vše výše uvedené platí především pro firemní sektor a on-premise řešení. U cloudových služeb zaměřených na segment SMB nejsou pro zákazníky tak široké možnosti podílet se na vývoji produktu. Formát pronájmu pro SMB tomu ani nenapovídá. Místo požadavku na změnu v podobě jasných požadavků z firemního večírku je tu jen obvyklá zpětná vazba a přání na službu. Snažíme se naslouchat, ale produkt je masivní a touha jednoho klienta přinést něco známého z jeho starého historického systému může odporovat strategii vývoje systému jako celku.
Zdroj: www.habr.com