Yn dit artikel sil ik myn ûnderfining diele by it selektearjen fan ideeën foar it ûntwikkeljen fan 'e funksjonaliteit fan ús produkten en jo fertelle hoe't jo de wichtichste vectoren fan ûntwikkeling kinne behâlde.
Wy ûntwikkelje in automatisearre delsettingssysteem (ACP) - fakturearring. Term
It libben fan ús produkt is 14 jier. Yn dizze tiid is it systeem evoluearre fan 'e earste ferzjes fan in yndustrieel tarifsysteem nei in modulêr kompleks besteande út 18 produkten dy't elkoar oanfolje. Ien fan 'e wichtichste aspekten fan longevity foar programma's is konstante ûntwikkeling. En ûntwikkeling fereasket ideeën.
Ideeën
Boarnen
Der binne 5 boarnen:
- De wichtichste freon fan in ûntwikkelder fan bedriuwsynformaasjesystemen is klant. En de klant is in kollektyf byld fan besluters, projektsponsors, eigners en útfierers fan prosessen, yn-house IT-spesjalisten, gewoane brûkers en in grut oantal ynteressearre yndividuen yn ferskate mjitte. It is wichtich foar ús dat elk fan 'e fertsjintwurdigers fan' e kliïnt potinsjeel in leveransier fan ideeën is. Yn it slimste gefal krije wy allinich negative feedback oer problemen yn it systeem. Yn it bêste gefal is d'r in persoan oan 'e kant fan' e kliïnt dy't in konstante boarne is fan ideeën foar ferbettering, it jaan fan struktureare ynformaasje oer de behoeften fan 'e kliïnt.
- Ús ferkeapers en account managers binne de twadde wichtichste boarne fan ideeën foar ferbettering. Se kommunisearje aktyf en wiidweidich mei fertsjintwurdigers fan 'e yndustry en ûntfange earste-handfragen oer fakturearringsfunksjonaliteit fan potensjele kliïnten. Ferkeapers en akkounts moatte bewust wêze fan alle wichtige feroaringen yn har funksjonaliteit en de lêste updates foar software fan konkurrinten, en kinne de foar- en neidielen fan ferskate oplossingen rjochtfeardigje. Dit binne ús meiwurkers dy't de earste binne om te fielen as guon fakturearringsmooglikheden in de facto standert wurde, sûnder hokker de software net as kompleet beskôge wurde kin.
- Produkt Eigner - ien fan ús topmanagers of in tige betûfte projektmanager. Hâldt de strategyske doelen fan it bedriuw yn gedachten en past produktûntwikkelingsplannen oan yn oerienstimming mei har.
- Arsjitekt, In persoan dy't de mooglikheden en beheiningen fan 'e keazen / brûkte technologyske oplossingen begrypt en har ynfloed op produktûntwikkeling.
Untwikkelings- en testteams. Minsken dy't direkt belutsen binne by produktûntwikkeling.
Klassifikaasje fan oanfragen
Wy ûntfange rauwe gegevens út boarnen - brieven, kaartsjes, mûnlinge oanfragen. Alle
beswierskriften wurde klassifisearre:
- Rieplachtsje mei de betsjutting "Hoe te dwaan?", "Hoe wurket it?", "Wêrom wurket it net?", "Ik begryp it net ...". Fersiken fan dit type geane nei Level 1 Support Line. It is mooglik om it oerlis om te learen yn oare soarten oanfragen.
- Ynsidinten mei de betsjutting "Wurkt net" en "Flater". Ferwurke troch 2 en 3 Support Lines. As prompt korreksjes en frijlitting fan in patch nedich binne, kinne se wurde oerdroegen fan stipe direkt nei ûntwikkeling. It is mooglik om it opnij te klassifisearjen as in feroaringsoanfraach en stjoer it nei de efterstân.
- Fersiken foar feroarings en ûntwikkeling. Se komme yn 'e produktefterstân, troch de stipelinen om te gean. Mar der is in aparte ferwurkingsproseduere foar har.
D'r binne statistiken oer oanfragen: fuort nei de frijlitting nimt it oantal oanfragen foar in koarte tiid mei 10-15% ta. D'r binne ek tanimmingen yn oanfragen as in nije klant mei in grut oantal brûkers nei ús wolktsjinsten komt. Minsken leare nije softwaremooglikheden te brûken, se hawwe advys nedich. Sels in lytse klant, as hy begjint te wurkjen yn it systeem, baarnt maklik mear as 100 oeren konsultaasjes per moanne. Dêrom reservearje wy by it ferbinen fan in nije klant altyd tiid foar earste oerlis. Faak selektearje wy sels in spesifike spesjalist. De hierpriis dekt dizze arbeidskosten fansels net, mar yn 'e rin fan' e tiid wurdt de situaasje gelyk. De oanpassingsperioade duorret meastentiids fan 1 oant 3 moannen, wêrnei't de needsaak foar begelieding signifikant fermindere wurdt.
Earder brûkten wy sels skreaune oplossingen om oanfragen op te slaan. Mar wy stapten stadichoan oer op Atlassian produkten. Earst hawwe wy ûntwikkeling oerdroegen om it makliker te meitsjen neffens Agile te wurkjen, dan stipe. No libje alle krityske prosessen yn Jira SD, plus se wurde stipe troch ferskate plugins foar Jira, plus Confluence. Sels skreaune oplossingen bleaunen allinich foar prosessen dy't net kritysk wiene foar de aktiviteiten fan it bedriuw. It docht bliken dat ús taken no cross-cutting binne en kinne wurde oerbrocht tusken stipe en ûntwikkeling sûnder te springen fan it iene systeem nei it oare.
Fan dizze keppeling kinne wy gegevens krije oer alle taken, plande en werklike arbeidskosten, ferskate prizenopsjes brûke foar kliïnten en dokumintaasje generearje foar ynterne behoeften en rapportaazje oan kliïnten.
Ferwurkjen fan feroaringsoanfragen
Typysk komme sokke oanfragen yn 'e foarm fan funksjonaliteitseasken. Us analist ûndersiket it fersyk, makket in spesifikaasje en technyske spesifikaasjes op topnivo. Ferpleatst de spesifikaasje en technyske spesifikaasjes nei de persoan dy't dit fersyk foar goedkarring yntsjinne - wy moatte der wis fan wêze dat wy deselde taal prate mei de klant.
Nei befêstiging fan 'e klant dat wy inoar goed begrepen hawwe, fiert de analist it fersyk yn' e produktefterstân.
Produkt funksjonaliteit behear
De efterstân sammelet ynkommende oanfragen foar feroaring en ûntwikkeling. De technyske ried, besteande út de direkteur, haaden fan stipe, ûntwikkeling, ferkeap en de systeemarsjitekt, komt elk healjier byinoar. Yn in diskusjeformaat analysearret en prioritearret de ried oanfragen út de efterstân en wurdt it iens oer 5 ûntwikkelingstaken foar útfiering yn de folgjende útjefte.
Yn feite reagearret de technyske ried op 'e easken fan' e yndustry en merken troch de behoeften útdrukt yn oanfragen te besjen. Alles wat net fan relevânsje is, bliuwt yn de efterstân en berikt net ta ûntwikkeling.
Klassifikaasje fan feroaringsoanfragen en finânsjes
Untwikkeling is djoer. Dêrom sille wy jo fuortendaliks fertelle hokker mooglikheden wy hawwe as it fersyk foar feroaring kaam fan in kliïnt en net in meiwurker.
Wy klassifisearje feroaringsoanfragen as folget: yndustry need of yndividuele skaaimerk fan 'e ûndernimming; in wichtige hoemannichte nije funksjonaliteit as in lytse fix. Lytse reparaasjes en yndividuele oanfragen wurde ferwurke sûnder franje. Yndividuele oanfragen wurde berekkene en útfierd foar in spesifike klant as ûnderdiel fan projektwurk mei him.
As dit net in massive yndustry need is en it folume fan funksjonaliteit is grut, dan kin in beslút makke wurde om in nije aparte module te ûntwikkeljen dy't neist de haadfunksjonaliteit ferkocht wurdt. As sa'n fersyk fan in klant ûntfongen is, kinne wy de kosten fan it ûntwikkeljen fan de module dekke, de klant de module fergees of mei in dielbetelling leverje en de module sels te keap sette. Yn sa'n situaasje nimt de kliïnt in diel fan 'e metodologyske lading op en fiert yn essinsje in pilot-ymplemintaasje fan' e module op himsels.
As dit in massale yndustryferlet is, dan kin in beslút wurde makke om nije funksjonaliteit op te nimmen yn it basisprodukt. De kosten yn dit gefal falle folslein op ús, en de nije funksjonaliteit ferskynt yn 'e aktuele ferzje fan' e programma's.
Alde klanten wurde foarsjoen fan in update.
It kin ek wêze dat ferskate klanten in ferlykber ferlet hawwe, mar it komt net yn oanmerking foar in massaprodukt. Yn dit gefal kinne wy de spesifikaasje nei dizze klanten stjoere en oanbiede om de ûntwikkelingskosten tusken har te dielen. Oan 'e ein wint elkenien: klanten krije de funksjonaliteit ymplementearre tsjin in lege kosten, wy ferrykje it produkt, en nei in skoft kinne oare merkdielnimmers ek de funksjonaliteit krije foar har gebrûk.
DevOps
De ûntwikkeling taret twa grutte releases yn 't jier op. Yn elke release wurdt tiid reservearre foar de útfiering fan 5 taken dy't ûntfongen binne fan de technyske ried. Sa, yn 'e midden fan routine, ferjitte wy noait oer produktûntwikkeling.
Elke release ûndergiet in passende set fan testen en dokumintaasje. Dêrnei wurdt dizze release ynstalleare yn 'e testomjouwing fan' e korrespondearjende klant, dy't op syn beurt alles sekuer kontrolearret en pas dêrnei wurdt de release oerbrocht nei produksje.
Neist it releasesysteem is d'r in opmaak foar rappe bugfixes, sadat kliïnten seis moannen net mei flaters libje. Dit tuskenformaat lit jo fluch reagearje op ynsidinten mei earste prioriteit en de oantsjutte SLA's folbringe.
Al it boppesteande is foaral wier foar de bedriuwssektor en oplossingen op it terrein. Foar wolktsjinsten rjochte op it SMB-segment binne d'r gjin sokke brede kânsen foar kliïnten om diel te nimmen oan produktûntwikkeling. It SMB-ferhierformaat giet dit net iens oan. Yn stee fan in wizigingsoanfraach yn de foarm fan dúdlike easken fan de bedriuwspartij is hjir allinnich gewoane feedback en winsken foar de tsjinst. Wy besykje te harkjen, mar it produkt is massaal en de winsk fan ien klant om wat fertroud te bringen fan har âlde histoaryske systeem kin de ûntwikkelingstrategy fan it systeem as gehiel tsjinsprekke.
Boarne: www.habr.com