Šiame straipsnyje pasidalinsiu savo patirtimi atrenkant idėjas, kaip tobulinti mūsų produktų funkcionalumą, ir papasakosiu, kaip išlaikyti pagrindinius plėtros vektorius.
Kuriame automatizuotą atsiskaitymų sistemą (ACP) – atsiskaitymą. Terminas
Mūsų gaminio tarnavimo laikas yra 14 metų. Per šį laiką sistema iš pirmųjų pramoninės tarifų sistemos versijų išsivystė į modulinį kompleksą, susidedantį iš 18 vienas kitą papildančių produktų. Vienas iš svarbiausių programų ilgaamžiškumo aspektų yra nuolatinis tobulėjimas. O vystymuisi reikia idėjų.
Idėjos
Informacijos šaltiniai
Yra 5 šaltiniai:
- Pagrindinis įmonės informacinių sistemų kūrėjo draugas yra klientas. O klientas – tai kolektyvinis sprendimų priėmėjų, projektų rėmėjų, procesų savininkų ir vykdytojų, vidinių IT specialistų, paprastų vartotojų ir daugybės įvairaus laipsnio suinteresuotų asmenų įvaizdis. Mums svarbu, kad kiekvienas kliento atstovas būtų potencialus idėjų tiekėjas. Blogiausiu atveju sulaukiame tik neigiamų atsiliepimų apie problemas sistemoje. Geriausiu atveju kliento pusėje yra žmogus, kuris yra nuolatinis tobulėjimo idėjų šaltinis, teikiantis struktūrizuotą informaciją apie kliento poreikius.
- Mūsų pardavėjai ir sąskaitų vadybininkai yra antras pagal svarbą tobulinimo idėjų šaltinis. Jie aktyviai ir plačiai bendrauja su pramonės atstovais ir gauna tiesioginių užklausų apie atsiskaitymo funkcijas iš potencialių klientų. Pardavėjai ir paskyros turi žinoti apie visus reikšmingus savo funkcionalumo pokyčius ir naujausius konkurentų programinės įrangos atnaujinimus bei sugebėti pagrįsti skirtingų sprendimų privalumus ir trūkumus. Tai mūsų darbuotojai, kurie pirmieji pajunta, ar kai kurios atsiskaitymo galimybės tampa de facto standartu, be kurių programinė įranga negali būti laikoma užbaigta.
- Produkto savininkas — vienas iš mūsų aukščiausių vadovų arba labai patyręs projektų vadovas. Nepamiršta įmonės strateginių tikslų ir pagal juos koreguoja produktų kūrimo planus.
- Architektas, asmuo, suvokiantis pasirinktų/naudojamų technologijų sprendimų galimybes ir apribojimus bei jų įtaką produkto kūrimui.
Kūrimo ir testavimo komandos. Žmonės, kurie tiesiogiai dalyvauja gaminių kūrime.
Prašymų klasifikavimas
Neapdorotus duomenis gauname iš šaltinių – laiškų, bilietų, žodinių prašymų. Visi
apeliacijos klasifikuojamos:
- konsultacijos su reikšme „Kaip tai padaryti?“, „Kaip tai veikia?“, „Kodėl neveikia?“, „Aš nesuprantu...“. Tokio tipo užklausos siunčiamos į 1 lygio palaikymo liniją. Konsultaciją galima perkvalifikuoti į kitų rūšių užklausas.
- Incidentai su reikšmėmis „Neveikia“ ir „Klaida“. Apdoroja 2 ir 3 palaikymo linijos. Jei reikia nedelsiant atlikti pataisymus ir išleisti pleistrą, jie gali būti perkelti iš palaikymo tiesiai į plėtrą. Jį galima perklasifikuoti į pakeitimo užklausą ir išsiųsti į atsilikimą.
- Prašymai dėl pakeitimų ir plėtros. Jie patenka į produktų atsilikimą, aplenkdami palaikymo linijas. Tačiau jiems yra atskira apdorojimo procedūra.
Yra užklausų statistika: iškart po išleidimo užklausų skaičius trumpam padidėja 10-15%. Taip pat užklausų padaugėja, kai į debesijos paslaugas ateina naujas klientas, turintis daug vartotojų. Žmonės mokosi naudotis naujomis programinės įrangos galimybėmis, jiems reikia patarimo. Net mažas klientas, pradėdamas dirbti sistemoje, per mėnesį nesunkiai išdegina daugiau nei 100 valandų konsultacijų. Todėl prijungdami naują klientą visada pasiliekame laiko pirminėms konsultacijoms. Dažnai net pasirenkame konkretų specialistą. Nuomos kaina, žinoma, nepadengia šių darbo sąnaudų, tačiau laikui bėgant situacija išsilygina. Adaptacijos laikotarpis paprastai trunka nuo 1 iki 3 mėnesių, po kurio konsultacijos poreikis gerokai sumažėja.
Anksčiau užklausoms saugoti naudojome pačių parašytus sprendimus. Tačiau palaipsniui perėjome prie „Atlassian“ gaminių. Pirmiausia perkėlėme plėtrą, kad būtų lengviau dirbti pagal Agile, tada palaikymą. Dabar visi svarbūs procesai veikia „Jira SD“, be to, juos palaiko įvairūs „Jira“ papildiniai, taip pat „Confluence“. Savarankiškai parašyti sprendimai liko tik tiems procesams, kurie nebuvo svarbūs įmonės veiklai. Pasirodo, mūsų užduotys dabar yra kryžminės ir gali būti perkeltos tarp paramos ir plėtros, neperšokant iš vienos sistemos į kitą.
Iš šios nuorodos galime gauti duomenis apie visas užduotis, planuojamas ir faktines darbo sąnaudas, pasinaudoti įvairiais kainodaros variantais klientams bei generuoti dokumentaciją vidiniams poreikiams ir ataskaitoms klientams.
Pakeitimų užklausų apdorojimas
Paprastai tokie prašymai pateikiami funkcionalumo reikalavimų forma. Mūsų analitikas išnagrinėja užklausą, sukuria specifikaciją ir aukščiausio lygio technines specifikacijas. Perduoda specifikaciją ir technines specifikacijas asmeniui, kuris pateikė šį prašymą patvirtinti – turime būti tikri, kad su klientu kalbame ta pačia kalba.
Gavęs kliento patvirtinimą, kad vienas kitą supratome teisingai, analitikas įveda užklausą į prekių užsakymus.
Produkto funkcionalumo valdymas
Atsilikimas kaupia gaunamas pakeitimų ir plėtros užklausas. Techninė taryba, kurią sudaro direktorius, palaikymo, plėtros, pardavimų vadovai ir sistemos architektas, renkasi kas pusmetį. Diskusijų formatu taryba analizuoja ir nustato prioritetines programas iš atsilikimo ir susitaria dėl 5 kūrimo užduočių, kurios bus įgyvendinamos kitoje laidoje.
Tiesą sakant, techninė taryba reaguoja į pramonės ir rinkos poreikius peržiūrėdama paraiškose išreikštus poreikius. Viskas, kas mažai aktualu, lieka atsilikime ir nepasiekia plėtros.
Pakeitimų prašymų ir finansų klasifikacija
Plėtra yra brangi. Todėl mes iš karto pasakysime, kokias galimybes galime turėti, jei pakeitimų prašymas gautas iš kliento, o ne iš darbuotojo.
Pakeitimų prašymus klasifikuojame taip: pramonės poreikis arba individuali įmonės savybė; daug naujų funkcijų arba nedidelis pataisymas. Smulkūs pataisymai ir individualūs prašymai apdorojami be jokių smulkmenų. Konkrečiam klientui, vykdant projektinį darbą su juo, apskaičiuojami ir įgyvendinami individualūs prašymai.
Jei tai nėra didžiulis pramonės poreikis, o funkcionalumo apimtis yra didelė, tuomet gali būti priimtas sprendimas sukurti naują atskirą modulį, kuris bus parduodamas be pagrindinių funkcijų. Gavus tokį kliento prašymą, galime padengti modulio kūrimo išlaidas, suteikti klientui modulį nemokamai arba už dalinį apmokėjimą, o patį modulį pateikti pardavimui. Esant tokiai situacijai, klientas prisiima dalį metodinio krūvio ir iš esmės pats atlieka bandomąjį modulio įgyvendinimą.
Jei tai didžiulis pramonės poreikis, gali būti priimtas sprendimas įtraukti naujas funkcijas į pagrindinį produktą. Išlaidos šiuo atveju visiškai tenka mums, o naujos funkcijos atsiranda dabartinėje programų versijoje.
Seniems klientams suteikiamas atnaujinimas.
Taip pat gali būti, kad keli klientai turi panašų poreikį, tačiau jis neatitinka masinio produkto reikalavimų. Tokiu atveju šiems klientams galime nusiųsti specifikaciją ir pasiūlyti jiems padalinti kūrimo išlaidas. Galų gale laimi visi: klientai gauna funkcionalumą už mažą kainą, mes praturtiname produktą, o po kurio laiko funkcionalumą savo naudojimui gali gauti ir kiti rinkos dalyviai.
DevOps
Plėtra parengia du pagrindinius leidimus per metus. Kiekvienoje laidoje laikas yra skirtas 5 iš techninės tarybos gautoms užduotims įgyvendinti. Taigi kasdienybės įkarštyje niekada nepamirštame apie produktų kūrimą.
Kiekvienam leidimui atliekamas atitinkamas bandymų ir dokumentų rinkinys. Toliau šis leidimas įdiegiamas atitinkamo kliento testinėje aplinkoje, kuris savo ruožtu viską kruopščiai patikrina ir tik po to leidimas perkeliamas į gamybą.
Be išleidimo sistemos, yra greito klaidų taisymo formatas, kad klientai šešis mėnesius negyventų su klaidomis. Šis tarpinis formatas leis greitai reaguoti į pirmojo prioriteto incidentus ir įvykdyti nurodytas SLA.
Visa tai, kas išdėstyta pirmiau, visų pirma galioja verslo sektoriui ir vietiniams sprendimams. Debesijos paslaugoms, skirtoms SMB segmentui, nėra tokių plačių galimybių klientams dalyvauti produktų kūrime. SMB nuomos formatas to net neprisiima. Vietoj pakeitimo prašymo aiškių įmonės šalies reikalavimų forma čia yra tik įprasti atsiliepimai ir pageidavimai dėl paslaugos. Stengiamės įsiklausyti, bet produktas yra didžiulis ir vieno kliento noras atsinešti ką nors pažįstamo iš savo senos istorinės sistemos gali prieštarauti visos sistemos plėtros strategijai.
Šaltinis: www.habr.com