Šajā rakstā es dalīšos savā pieredzē, izvēloties idejas mūsu produktu funkcionalitātes pilnveidošanai, un pastāstīšu, kā saglabāt galvenos attīstības vektorus.
Mēs izstrādājam automatizēto norēķinu sistēmu (ĀKK) - norēķinu. Jēdziens
Mūsu produkta kalpošanas laiks ir 14 gadi. Šajā laikā sistēma ir attīstījusies no pirmajām industriālo tarifu sistēmas versijām līdz moduļu kompleksam, kas sastāv no 18 produktiem, kas viens otru papildina. Viens no svarīgākajiem programmu ilgmūžības aspektiem ir pastāvīga attīstība. Un attīstībai ir vajadzīgas idejas.
Idejas
avoti
Ir 5 avoti:
- Korporatīvo informācijas sistēmu izstrādātāja galvenais draugs ir klients. Un klients ir lēmumu pieņēmēju, projektu sponsoru, procesu īpašnieku un izpildītāju, iekšējo IT speciālistu, parasto lietotāju un liela skaita ieinteresētu personu kolektīvs tēls dažādās pakāpēs. Mums ir svarīgi, lai katrs klienta pārstāvis būtu potenciāls ideju piegādātājs. Sliktākajā gadījumā mēs saņemam tikai negatīvas atsauksmes par problēmām sistēmā. Labākajā gadījumā klienta pusē ir cilvēks, kurš ir pastāvīgs uzlabojumu ideju avots, sniedzot strukturētu informāciju par klienta vajadzībām.
- Mūsu pārdevēji un kontu vadītāji ir otrs svarīgākais uzlabojumu ideju avots. Viņi aktīvi un plaši sazinās ar nozares pārstāvjiem un saņem tiešus jautājumus par norēķinu funkcionalitāti no potenciālajiem klientiem. Pārdevējiem un kontiem ir jāapzinās visas būtiskās izmaiņas savā funkcionalitātē un jaunākie konkurentu programmatūras atjauninājumi, kā arī jāspēj pamatot dažādu risinājumu plusi un mīnusi. Tie ir mūsu darbinieki, kuri pirmie pamana, vai dažas norēķinu iespējas kļūst par de facto standartu, bez kurām programmatūru nevar uzskatīt par pabeigtu.
- Produkta īpašnieks — kāds no mūsu augstākajiem vadītājiem vai ļoti pieredzējis projektu vadītājs. Patur prātā uzņēmuma stratēģiskos mērķus un atbilstoši tiem koriģē produktu attīstības plānus.
- Arhitekts, persona, kas izprot izvēlēto/izmantoto tehnoloģiju risinājumu iespējas un ierobežojumus un to ietekmi uz produktu attīstību.
Izstrādes un testēšanas komandas. Cilvēki, kuri ir tieši saistīti ar produktu izstrādi.
Pieprasījumu klasifikācija
Mēs saņemam neapstrādātus datus no avotiem - vēstulēm, biļetēm, mutiskiem pieprasījumiem. Visi
apelācijas tiek klasificētas:
- Konsultācijas ar nozīmi "Kā to izdarīt?", "Kā tas darbojas?", "Kāpēc tas nedarbojas?", "Es nesaprotu...". Šāda veida pieprasījumi tiek nosūtīti uz 1. līmeņa atbalsta līniju. Konsultāciju iespējams pārkvalificēt cita veida pieprasījumos.
- Starpgadījumi ar nozīmi “Nedarbojas” un “Kļūda”. Apstrādā 2 un 3 atbalsta līnijas. Ja ir nepieciešamas tūlītējas korekcijas un ielāpa izlaišana, tos var pārsūtīt no atbalsta tieši uz izstrādi. To ir iespējams pārklasificēt kā izmaiņu pieprasījumu un nosūtīt uz nepabeigto.
- Izmaiņu un attīstības pieprasījumi. Viņi nokļūst produktu uzkrājumos, apejot atbalsta līnijas. Bet tiem ir atsevišķa apstrādes procedūra.
Ir statistika par pieprasījumiem: uzreiz pēc izlaišanas pieprasījumu skaits uz īsu brīdi palielinās par 10-15%. Pieprasījumu pieaugums vērojams arī tad, kad mūsu mākoņpakalpojumos ienāk jauns klients ar lielu lietotāju skaitu. Cilvēki mācās izmantot jaunas programmatūras iespējas, viņiem ir nepieciešams padoms. Pat neliels klients, uzsākot darbu sistēmā, mēnesī viegli sadedzina vairāk nekā 100 konsultāciju stundas. Tāpēc, pieslēdzot jaunu klientu, vienmēr rezervējam laiku sākotnējām konsultācijām. Bieži vien mēs pat izvēlamies konkrētu speciālistu. Īres cena, protams, nesedz šīs darbaspēka izmaksas, taču ar laiku situācija izlīdzinās. Adaptācijas periods parasti ilgst no 1 līdz 3 mēnešiem, pēc kura nepieciešamība pēc konsultācijas ievērojami samazinās.
Iepriekš pieprasījumu glabāšanai izmantojām pašrakstītus risinājumus. Bet mēs pamazām pārgājām uz Atlassian produktiem. Pirmkārt, mēs pārnesām attīstību, lai būtu vieglāk strādāt saskaņā ar Agile, pēc tam atbalstu. Tagad visi kritiskie procesi darbojas Jira SD, kā arī tos atbalsta dažādi Jira spraudņi, kā arī Confluence. Pašu rakstītie risinājumi palika tikai tiem procesiem, kas nebija būtiski uzņēmuma darbībai. Izrādās, ka mūsu uzdevumi tagad ir šķērsām un tos var pārnest starp atbalstu un attīstību, nepārlecot no vienas sistēmas uz otru.
No šīs saites mēs varam iegūt datus par visiem uzdevumiem, plānotajām un faktiskajām darbaspēka izmaksām, izmantot dažādas cenu noteikšanas iespējas klientiem un ģenerēt dokumentāciju iekšējām vajadzībām un atskaitēm klientiem.
Izmaiņu pieprasījumu apstrāde
Parasti šādi pieprasījumi tiek iesniegti funkcionalitātes prasību veidā. Mūsu analītiķis pēta pieprasījumu, izveido specifikāciju un augstākā līmeņa tehniskās specifikācijas. Nodod specifikāciju un tehniskās specifikācijas personai, kas iesniedza šo pieprasījumu apstiprināšanai - mums ir jābūt pārliecinātiem, ka mēs runājam vienā valodā ar klientu.
Saņemot no klienta apstiprinājumu, ka esam pareizi viens otru sapratuši, analītiķis ievada pieprasījumu preču rezervē.
Produkta funkcionalitātes vadība
Neizpildītajā uzkrājumā uzkrājas ienākošie izmaiņu un attīstības pieprasījumi. Tehniskā padome, kuras sastāvā ir direktors, atbalsta, attīstības, pārdošanas vadītāji un sistēmas arhitekts, tiekas reizi pusgadā. Diskusiju formātā padome analizē un nosaka prioritārās pieteikumus no nepabeigtā apjoma un vienojas par 5 izstrādes uzdevumiem, kas tiks ieviesti nākamajā laidienā.
Faktiski tehniskā padome reaģē uz nozares un tirgus prasībām, pārskatot pieteikumos izteiktās vajadzības. Viss, kam ir maza nozīme, paliek atpalicībā un nesasniedz attīstību.
Izmaiņu pieprasījumu un finanšu klasifikācija
Attīstība ir dārga. Tāpēc mēs nekavējoties pateiksim, kādas mums var būt iespējas, ja pieprasījums veikt izmaiņas ir no klienta, nevis darbinieka.
Izmaiņu pieprasījumus klasificējam šādi: nozares nepieciešamība vai uzņēmuma individuālais raksturojums; ievērojams daudzums jaunas funkcionalitātes vai neliels labojums. Nelieli labojumi un individuālie pieprasījumi tiek apstrādāti bez jebkādām problēmām. Individuālie pieprasījumi tiek aprēķināti un īstenoti konkrētam klientam kā daļa no projekta darba ar viņu.
Ja tā nav masīva nozares vajadzība un funkcionalitātes apjoms ir liels, tad var tikt pieņemts lēmums izstrādāt jaunu atsevišķu moduli, kas tiks pārdots papildus galvenajai funkcionalitātei. Ja no klienta tiek saņemts šāds pieprasījums, mēs varam segt moduļa izstrādes izmaksas, nodrošināt klientam moduli bez maksas vai ar daļēju samaksu, kā arī pašu moduli izlikt pārdošanā. Šādā situācijā klients uzņemas daļu no metodiskās slodzes un būtībā veic moduļa pilotieviešanu uz sevi.
Ja tā ir milzīga nozares vajadzība, tad var tikt pieņemts lēmums iekļaut jaunu funkcionalitāti bāzes produktā. Izmaksas šajā gadījumā pilnībā gulstas uz mums, un jaunā funkcionalitāte parādās programmu pašreizējā versijā.
Vecajiem klientiem tiek nodrošināts atjauninājums.
Var arī būt, ka vairākiem klientiem ir līdzīga vajadzība, taču tā nekvalificējas masu produktam. Tādā gadījumā šiem klientiem varam nosūtīt specifikāciju un piedāvāt starp viņiem sadalīt izstrādes izmaksas. Galu galā uzvar visi: klienti saņem funkcionalitāti par zemu cenu, mēs bagātinām produktu, un pēc kāda laika arī citi tirgus dalībnieki var iegūt funkcionalitāti savai lietošanai.
DevOps
Izstrāde sagatavo divus galvenos izlaidumus gadā. Katrā laidienā laiks ir rezervēts 5 no tehniskās padomes saņemto uzdevumu izpildei. Tādējādi ikdienas rutīnas vidū mēs nekad neaizmirstam par produktu izstrādi.
Katrai laidienai tiek veikta atbilstoša pārbaude un dokumentācija. Tālāk šis laidiens tiek instalēts attiecīgā klienta testa vidē, kurš savukārt visu rūpīgi pārbauda un tikai pēc tam laidiens tiek pārsūtīts uz ražošanu.
Papildus izlaišanas sistēmai ir arī formāts ātrai kļūdu labošanai, lai klienti sešus mēnešus nedzīvotu ar kļūdām. Šis vidējais formāts ļaus ātri reaģēt uz pirmās prioritātes incidentiem un izpildīt norādītos SLA.
Viss iepriekš minētais galvenokārt attiecas uz korporatīvo sektoru un vietējiem risinājumiem. Mākoņpakalpojumiem, kas vērsti uz MVU segmentu, klientiem nav tik plašas iespējas piedalīties produktu izstrādē. SMB nomas formāts to pat nepieņem. Izmaiņu pieprasījuma vietā skaidru prasību veidā no korporatīvās puses šeit ir tikai parasta atgriezeniskā saite un vēlmes par pakalpojumu. Cenšamies ieklausīties, bet produkts ir masīvs un viena klienta vēlme atnest kaut ko pazīstamu no savas vecās vēsturiskās sistēmas var būt pretrunā ar sistēmas attīstības stratēģiju kopumā.
Avots: www.habr.com
