In hierdie artikel sal ek my ervaring deel met die keuse van idees vir die ontwikkeling van die funksionaliteit van ons produkte en jou vertel hoe om die belangrikste vektore van ontwikkeling te handhaaf.
Ons ontwikkel 'n outomatiese vereffeningstelsel (ACP) - faktuur. Termyn
Die lewensduur van ons produk is 14 jaar. In hierdie tyd het die stelsel ontwikkel van die eerste weergawes van 'n industriële tariefstelsel tot 'n modulêre kompleks wat uit 18 produkte bestaan wat mekaar aanvul. Een van die belangrikste aspekte van lang lewe vir programme is konstante ontwikkeling. En ontwikkeling vereis idees.
idees
bronne
Daar is 5 bronne:
- Die hoofvriend van 'n korporatiewe inligtingstelselontwikkelaar is kliënt. En die kliënt is 'n kollektiewe beeld van besluitnemers, projekborge, eienaars en uitvoerders van prosesse, interne IT-spesialiste, gewone gebruikers en 'n groot aantal belangstellende individue in verskillende mate. Dit is vir ons belangrik dat elkeen van die kliënt se verteenwoordigers potensieel 'n verskaffer van idees is. In die ergste geval ontvang ons net negatiewe terugvoer oor probleme in die stelsel. In die beste geval is daar 'n persoon aan die kliënt se kant wat 'n konstante bron van idees vir verbetering is, wat gestruktureerde inligting oor die kliënt se behoeftes verskaf.
- ons verkoopspersoneel en rekeningbestuurders is die tweede belangrikste bron van idees vir verbetering. Hulle kommunikeer aktief en omvattend met bedryfsverteenwoordigers en ontvang eerstehandse navrae oor faktureringfunksionaliteit van potensiële kliënte. Verkopers en rekeninge moet bewus wees van alle beduidende veranderinge in hul funksionaliteit en die jongste opdaterings aan mededingers se sagteware, en in staat wees om die voor- en nadele van verskillende oplossings te regverdig. Dit is ons werknemers wat die eerste is om te sien of sommige faktureringsvermoëns 'n de facto standaard word, waarsonder die sagteware nie as volledig beskou kan word nie.
- Produk Eienaar — een van ons topbestuurders of 'n baie ervare projekbestuurder. Hou die maatskappy se strategiese doelwitte in gedagte en pas produkontwikkelingsplanne daarvolgens aan.
- argitek, 'n persoon wat die vermoëns en beperkings van die tegnologie-oplossings wat gekies/gebruik word en hul impak op produkontwikkeling verstaan.
Ontwikkeling en toetsspanne. Mense wat direk by produkontwikkeling betrokke is.
Klassifikasie van versoeke
Ons ontvang rou data van bronne – briewe, kaartjies, mondelinge versoeke. Almal
appèlle word geklassifiseer:
- Konsultasie met die betekenis “Hoe om dit te doen?”, “Hoe werk dit?”, “Hoekom werk dit nie?”, “Ek verstaan nie...”. Versoeke van hierdie tipe gaan na Vlak 1 Ondersteuningslyn. Dit is moontlik om die konsultasie te herlei in ander soorte versoeke.
- Voorvalle met die betekenis “Werk nie” en “Fout”. Verwerk deur 2 en 3 ondersteuningslyne. As vinnige regstellings en vrystelling van 'n pleister nodig is, kan dit van ondersteuning direk na ontwikkeling oorgedra word. Dit is moontlik om dit as 'n veranderingsversoek te herklassifiseer en na die agterstand te stuur.
- Versoeke vir veranderinge en ontwikkeling. Hulle kom in die produkagterstand en omseil die ondersteuningslyne. Maar daar is 'n aparte verwerkingsprosedure vir hulle.
Daar is statistieke oor versoeke: onmiddellik na die vrystelling neem die aantal versoeke toe met 10-15% vir 'n kort tydjie. Daar is ook toenames in versoeke wanneer 'n nuwe kliënt met 'n groot aantal gebruikers na ons wolkdienste kom. Mense leer om nuwe sagteware-vermoëns te gebruik, hulle het raad nodig. Selfs 'n klein kliënt, wanneer hy in die stelsel begin werk, verbrand maklik meer as 100 ure se konsultasies per maand. Daarom, wanneer ons 'n nuwe kliënt koppel, bespreek ons altyd tyd vir aanvanklike konsultasies. Dikwels kies ons selfs 'n spesifieke spesialis. Die huurprys dek natuurlik nie hierdie arbeidskoste nie, maar mettertyd word die situasie gelyk. Die aanpassingstydperk neem gewoonlik van 1 tot 3 maande, waarna die behoefte aan berading aansienlik verminder word.
Voorheen het ons selfgeskrewe oplossings gebruik om versoeke te stoor. Maar ons het geleidelik oorgeskakel na Atlassian-produkte. Eerstens het ons ontwikkeling oorgedra om dit makliker te maak om volgens Agile te werk, dan ondersteuning. Nou leef alle kritieke prosesse in Jira SD, plus hulle word ondersteun deur verskeie plugins vir Jira, plus Confluence. Selfgeskrewe oplossings het slegs gebly vir prosesse wat nie krities was vir die maatskappy se aktiwiteite nie. Dit blyk dat ons take nou deurmekaar is en tussen ondersteuning en ontwikkeling oorgedra kan word sonder om van een stelsel na 'n ander te spring.
Vanaf hierdie skakel kan ons data verkry oor alle take, beplande en werklike arbeidskoste, verskeie prysopsies vir kliënte gebruik en dokumentasie vir interne behoeftes en verslagdoening aan kliënte genereer.
Verwerking van veranderingsversoeke
Tipies kom sulke versoeke in die vorm van funksionaliteitvereistes. Ons ontleder bestudeer die versoek, skep 'n spesifikasie en topvlak tegniese spesifikasies. Dra die spesifikasie en tegniese spesifikasies oor aan die persoon wat hierdie versoek vir goedkeuring ingedien het – ons moet seker wees dat ons dieselfde taal met die kliënt praat.
Nadat die kliënt bevestiging ontvang het dat ons mekaar reg verstaan het, voer die ontleder die versoek in die produkagterstand in.
Produk funksionaliteit bestuur
Die agterstand versamel inkomende versoeke vir verandering en ontwikkeling. Die tegniese raad, bestaande uit die direkteur, hoofde van ondersteuning, ontwikkeling, verkope en die stelselargitek, vergader elke ses maande. In 'n besprekingsformaat ontleed en prioritiseer die raad aansoeke uit die agterstand en kom ooreen oor 5 ontwikkelingstake vir implementering in die volgende vrystelling.
In werklikheid reageer die tegniese raad op industrie- en markvereistes deur die behoeftes wat in aansoeke uitgedruk word, te hersien. Alles wat min ter sake is, bly in die agterstand en bereik nie ontwikkeling nie.
Klassifikasie van Veranderingsversoeke en Finansies
Ontwikkeling is duur. Daarom sal ons jou dadelik vertel watter opsies ons kan hê as die versoek om verandering van 'n kliënt en nie 'n werknemer kom nie.
Ons klassifiseer veranderingsversoeke soos volg: industriebehoefte of individuele kenmerk van die onderneming; 'n aansienlike hoeveelheid nuwe funksionaliteit of 'n geringe oplossing. Geringe regstellings en individuele versoeke word sonder enige fieterjasies verwerk. Individuele versoeke word vir 'n spesifieke kliënt bereken en geïmplementeer as deel van projekwerk met hom.
As dit nie 'n massiewe industriebehoefte is nie en die volume van funksionaliteit is groot, kan 'n besluit geneem word om 'n nuwe aparte module te ontwikkel wat bykomend tot die hooffunksionaliteit verkoop sal word. Indien so 'n versoek van 'n kliënt ontvang word, kan ons die koste van die ontwikkeling van die module dek, die kliënt gratis of met gedeeltelike betaling van die module voorsien en die module self te koop aanbied. In so 'n situasie neem die kliënt 'n deel van die metodologiese las op en voer in wese 'n loodsimplementering van die module op homself uit.
As dit 'n massiewe industriebehoefte is, kan 'n besluit geneem word om nuwe funksionaliteit in die basisproduk in te sluit. Die koste in hierdie geval val geheel en al op ons, en die nuwe funksionaliteit verskyn in die huidige weergawe van die programme.
Ou kliënte word van 'n opdatering voorsien.
Dit kan ook wees dat verskeie klante 'n soortgelyke behoefte het, maar dit kwalifiseer nie vir 'n massaproduk nie. In hierdie geval kan ons die spesifikasie aan hierdie kliënte stuur en aanbied om die ontwikkelingskoste tussen hulle te verdeel. Op die ou end wen almal: kliënte ontvang funksionaliteit teen 'n lae koste, ons verryk die produk, en na 'n geruime tyd kan ander markdeelnemers ook die funksionaliteit vir hul gebruik kry.
DevOps
Die ontwikkeling berei twee groot vrystellings per jaar voor. In elke vrystelling word tyd gereserveer vir die implementering van 5 take wat van die tegniese raad ontvang is. Dus, te midde van roetine, vergeet ons nooit van produkontwikkeling nie.
Elke vrystelling ondergaan 'n toepaslike stel toetsing en dokumentasie. Vervolgens word hierdie vrystelling in die toetsomgewing van die ooreenstemmende kliënt geïnstalleer, wat op sy beurt alles noukeurig nagaan en eers daarna word die vrystelling na produksie oorgedra.
Benewens die vrystellingstelsel is daar 'n formaat vir vinnige foutoplossings sodat kliënte nie vir ses maande met foute saamleef nie. Hierdie intermediêre formaat sal jou toelaat om vinnig op eerste-prioriteit voorvalle te reageer en die gestelde SLA's na te kom.
Al die bogenoemde geld hoofsaaklik vir die korporatiewe sektor en oplossings op die perseel. Vir wolkdienste wat op die SMB-segment gerig is, is daar nie sulke breë geleenthede vir kliënte om aan produkontwikkeling deel te neem nie. Die SMB-huurformaat neem dit nie eens aan nie. In plaas van 'n veranderingsversoek in die vorm van duidelike vereistes van die korporatiewe party, is hier net gewone terugvoer en wense vir die diens. Ons probeer luister, maar die produk is massief en die begeerte van een kliënt om iets bekend uit hul ou historiese stelsel te bring, kan die ontwikkelingstrategie van die stelsel as geheel weerspreek.
Bron: will.com