En ĉi tiu artikolo, mi dividos mian sperton pri elekto de ideoj por disvolvi la funkciecon de niaj produktoj kaj diros al vi kiel konservi la ĉefajn vektorojn de disvolviĝo.
Ni disvolvas aŭtomatigitan setlsistemon (ACP) - fakturadon. Terminon
La vivo de nia produkto estas 14 jaroj. Dum ĉi tiu tempo, la sistemo evoluis de la unuaj versioj de industria tarifsistemo al modula komplekso konsistanta el 18 produktoj, kiuj kompletigas unu la alian. Unu el la plej gravaj aspektoj de longviveco por programoj estas konstanta evoluo. Kaj evoluo postulas ideojn.
Идеи
Fontoj
Estas 5 fontoj:
- La ĉefa amiko de kompania informsistemo-programisto estas kliento. Kaj la kliento estas kolektiva bildo de deciduloj, projektsponsoroj, posedantoj kaj ekzekutistoj de procezoj, internaj IT-specialistoj, ordinaraj uzantoj kaj granda nombro da interesitaj individuoj en diversaj gradoj. Gravas por ni, ke ĉiu el la reprezentantoj de la kliento eble estas provizanto de ideoj. En la plej malbona kazo, ni ricevas nur negativajn rimarkojn pri problemoj en la sistemo. En la plej bona kazo, estas persono flanke de la kliento, kiu estas konstanta fonto de ideoj por plibonigo, provizante strukturitajn informojn pri la bezonoj de la kliento.
- Nia vendistoj kaj konto-administrantoj estas la dua plej grava fonto de ideoj por plibonigo. Ili aktive kaj vaste komunikas kun industriaj reprezentantoj kaj ricevas unuamanajn enketojn pri faktura funkcieco de eblaj klientoj. Vendistoj kaj kontoj devas esti konsciaj pri ĉiuj signifaj ŝanĝoj en sia funkcieco kaj la plej novaj ĝisdatigoj al programaro de konkurantoj, kaj povi pravigi la avantaĝojn kaj malavantaĝojn de malsamaj solvoj. Ĉi tiuj estas niaj dungitoj, kiuj la unuaj sentas, ĉu iuj fakturaj kapabloj fariĝas fakta normo, sen kiu la programaro ne povas esti konsiderata kompleta.
- Produktposedanto — unu el niaj ĉefmanaĝeroj aŭ tre sperta projektestro. Tenas en menso la strategiajn celojn de la firmao kaj ĝustigas produktajn evoluplanojn laŭ ili.
- Arkitekto, homo, kiu komprenas la kapablojn kaj limojn de la teknologiaj solvoj elektitaj/uzataj kaj ilian efikon al produkta evoluo.
Disvolvaj kaj testaj teamoj. Homoj, kiuj rekte okupiĝas pri produkta disvolviĝo.
Klasifiko de petoj
Ni ricevas krudajn datumojn de fontoj - leteroj, biletoj, vortaj petoj. Ĉiuj
apelacioj estas klasifikitaj:
- Konsultado kun la signifo "Kiel fari ĝin?", "Kiel ĝi funkcias?", "Kial ĝi ne funkcias?", "Mi ne komprenas...". Petoj de ĉi tiu tipo iras al Nivelo 1 Subtena Linio. Eblas retrejni la konsulton en alispecajn petojn.
- Okazaĵoj kun la signifo "Ne funkcias" kaj "Eraro". Prilaborita de 2 kaj 3 Subtenaj Linioj. Se rapidaj korektoj kaj liberigo de flikaĵo estas necesaj, ili povas esti transdonitaj de subteno rekte al evoluo. Eblas reklasifiki ĝin kiel ŝanĝpeton kaj sendi ĝin al la restaro.
- Petoj pri ŝanĝoj kaj disvolviĝo. Ili eniras la produktan restaron, preterirante la subtenajn liniojn. Sed estas aparta prilabora proceduro por ili.
Estas statistiko pri petoj: tuj post la liberigo, la nombro de petoj pliiĝas je 10-15% dum mallonga tempo. Ankaŭ estas plialtiĝo de petoj kiam nova kliento kun granda nombro da uzantoj venas al niaj nubaj servoj. Homoj lernas uzi novajn programajn kapablojn, ili bezonas konsilojn. Eĉ malgranda kliento, kiam komencas labori en la sistemo, facile bruligas pli ol 100 horojn da konsultoj monate. Tial, kiam li konektas novan klienton, ni ĉiam rezervas tempon por komencaj konsultoj. Ofte ni eĉ elektas specifan specialiston. La luprezo, kompreneble, ne kovras ĉi tiujn laborkostojn, sed kun la tempo la situacio egaliĝas. La adapta periodo kutime daŭras de 1 ĝis 3 monatoj, post kiu la bezono de konsilado estas signife reduktita.
Antaŭe, ni uzis memskribitajn solvojn por konservi petojn. Sed ni iom post iom ŝanĝis al Atlassian-produktoj. Unue, ni translokigis disvolviĝon por faciligi labori laŭ Agile, poste subteno. Nun ĉiuj kritikaj procezoj vivas en Jira SD, krome ili estas subtenataj de diversaj kromprogramoj por Jira, plus Confluence. Mem-skribitaj solvoj restis nur por procezoj, kiuj ne estis kritikaj por la agadoj de la firmao. Montriĝas, ke niaj taskoj nun estas transversaj kaj povas esti translokigitaj inter subteno kaj evoluo sen salti de unu sistemo al alia.
De ĉi tiu ligo ni povas akiri datumojn pri ĉiuj taskoj, planitaj kaj realaj laborkostoj, uzi diversajn prezojn por klientoj kaj generi dokumentadon por internaj bezonoj kaj raportado al klientoj.
Prilaborado de ŝanĝpetoj
Tipe, tiaj petoj venas en la formo de funkciecpostuloj. Nia analizisto studas la peton, kreas specifon kaj altnivelajn teknikajn specifojn. Transdonas la specifon kaj teknikajn specifojn al la persono, kiu prezentis ĉi tiun peton por aprobo - ni devas certigi, ke ni parolas la saman lingvon kun la kliento.
Ricevinte konfirmon de la kliento, ke ni ĝuste komprenis unu la alian, la analizisto enmetas la peton en la produktan restaron.
Produkta funkcieca administrado
La restaro amasigas alvenantajn petojn por ŝanĝo kaj evoluo. La teknika konsilio, konsistanta el la direktoro, estroj de subteno, evoluo, vendo kaj la sistemarkitekto, kunvenas ĉiujn ses monatojn. En diskutformato, la konsilio analizas kaj prioritatas aplikojn el la restaro kaj konsentas pri 5 evoluaj taskoj por efektivigo en la venonta eldono.
Efektive, la teknika konsilio respondas al industrio kaj merkatpostuloj reviziante la bezonojn esprimitajn en aplikoj. Ĉio, kio estas malmulte grava, restas en la restaro kaj ne atingas evoluon.
Klasifiko de Ŝanĝaj Petoj kaj Financo
Evoluo estas multekosta. Tial ni tuj diros al vi, kiajn eblojn ni povas havi, se la peto por ŝanĝo venis de kliento kaj ne de dungito.
Ni klasifikas ŝanĝpetojn jene: industria bezono aŭ individua karakterizaĵo de la entrepreno; signifa kvanto de nova funkcieco aŭ negrava solvo. Malgrandaj korektoj kaj individuaj petoj estas traktataj sen ekstraĵoj. Individuaj petoj estas kalkulitaj kaj efektivigitaj por specifa kliento kiel parto de projekta laboro kun li.
Se ĉi tio ne estas amasa industria bezono kaj la volumeno de funkcieco estas granda, tiam decido povas esti farita por evoluigi novan apartan modulon, kiu estos vendita aldone al la ĉefa funkcieco. Se tia peto estas ricevita de kliento, ni povas kovri la kostojn de evoluigado de la modulo, provizi la klienton per la modulo senpage aŭ kun parta pago, kaj meti la modulon mem por vendo. En tia situacio, la kliento prenas parton de la metodika ŝarĝo kaj esence faras pilotan efektivigon de la modulo sur si mem.
Se ĉi tio estas amasa industribezono, tiam decido povas esti farita por inkluzivi novan funkciecon en la baza produkto. La kostoj ĉi-kaze tute dependas de ni, kaj la nova funkcio aperas en la nuna versio de la programoj.
Malnovaj klientoj ricevas ĝisdatigon.
Povas ankaŭ esti, ke pluraj klientoj havas similan bezonon, sed ĝi ne kvalifikas por amasa produkto. En ĉi tiu kazo, ni povas sendi la specifon al ĉi tiuj klientoj kaj oferti dividi la disvolvajn kostojn inter ili. Al la fino, ĉiuj gajnas: klientoj ricevas funkciecon je malalta kosto, ni riĉigas la produkton, kaj post iom da tempo, aliaj merkatpartoprenantoj ankaŭ povas akiri la funkciecon por sia uzo.
DevOps
La evoluo preparas du gravajn eldonojn jare. En ĉiu eldono, tempo estas rezervita por la efektivigo de 5 taskoj ricevitaj de la teknika konsilio. Tiel, meze de rutino, ni neniam forgesas pri produkta disvolviĝo.
Ĉiu eldono spertas taŭgan aron de testado kaj dokumentado. Poste, ĉi tiu eldono estas instalita en la prova medio de la responda kliento, kiu, siavice, zorge kontrolas ĉion kaj nur post tio la eldono estas transdonita al produktado.
Krom la eldonsistemo, ekzistas formato por rapidaj korektoj por ke klientoj ne vivu kun eraroj dum ses monatoj. Ĉi tiu meza formato permesos al vi rapide respondi al unuaprioritataj okazaĵoj kaj plenumi la deklaritajn SLA-ojn.
Ĉio ĉi-supra validas ĉefe por la kompania sektoro kaj surlokaj solvoj. Por nubaj servoj celitaj al la SMB-segmento, ne ekzistas tiaj larĝaj ŝancoj por klientoj partopreni en produkta evoluo. La luformato SMB eĉ ne supozas tion. Anstataŭ ŝanĝpeto en formo de klaraj postuloj de la kompania partio, ĉi tie estas nur ordinaraj reagoj kaj deziroj por la servo. Ni provas aŭskulti, sed la produkto estas amasa kaj la deziro de unu kliento alporti ion konatan el sia malnova historia sistemo povas kontraŭdiri la disvolvan strategion de la sistemo entute.
fonto: www.habr.com