ProHoster > Blogs > Administrācija > Kā mēs izvēlamies idejas mÅ«su produktu attÄ«stÄ«bai: pārdevējam ir jāspēj dzirdētā€¦

Kā mēs izvēlamies idejas mÅ«su produktu attÄ«stÄ«bai: pārdevējam ir jāspēj dzirdētā€¦

Å 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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

Pievieno komentāru