Në këtë artikull, unë do të ndaj përvojën time në zgjedhjen e ideve për zhvillimin e funksionalitetit të produkteve tona dhe do t'ju tregoj se si të ruani vektorët kryesorë të zhvillimit.
Ne po zhvillojmë një sistem të automatizuar shlyerjeje (ACP) - faturim. Afati
Jetëgjatësia e produktit tonë është 14 vjet. Gjatë kësaj kohe, sistemi ka evoluar nga versionet e para të një sistemi tarifor industrial në një kompleks modular të përbërë nga 18 produkte që plotësojnë njëra-tjetrën. Një nga aspektet më të rëndësishme të jetëgjatësisë për programet është zhvillimi i vazhdueshëm. Dhe zhvillimi kërkon ide.
Идеи
burime
Ka 5 burime:
- Miku kryesor i një zhvilluesi të sistemeve të informacionit të korporatës është klient. Dhe klienti është një imazh kolektiv i vendimmarrësve, sponsorëve të projektit, pronarëve dhe ekzekutuesve të proceseve, specialistëve të IT-së në shtëpi, përdoruesve të zakonshëm dhe një numri të madh individësh të interesuar në shkallë të ndryshme. Është e rëndësishme për ne që secili nga përfaqësuesit e klientit të jetë potencialisht një furnizues i ideve. Në rastin më të keq, ne marrim vetëm reagime negative për problemet në sistem. Në rastin më të mirë, ka një person në anën e klientit që është një burim i vazhdueshëm idesh për përmirësim, duke ofruar informacion të strukturuar për nevojat e klientit.
- tonë shitësit dhe menaxherët e llogarive janë burimi i dytë më i rëndësishëm i ideve për përmirësim. Ata komunikojnë në mënyrë aktive dhe të gjerë me përfaqësuesit e industrisë dhe marrin pyetje të dorës së parë në lidhje me funksionalitetin e faturimit nga klientët e mundshëm. Shitësit dhe llogaritë duhet të jenë të vetëdijshëm për të gjitha ndryshimet e rëndësishme në funksionalitetin e tyre dhe përditësimet më të fundit të softuerit të konkurrentëve dhe të jenë në gjendje të justifikojnë të mirat dhe të këqijat e zgjidhjeve të ndryshme. Këta janë punonjësit tanë që janë të parët që kuptojnë nëse disa aftësi faturimi bëhen një standard de facto, pa të cilin softueri nuk mund të konsiderohet i plotë.
- Pronari i produktit — një nga menaxherët tanë të lartë ose një menaxher projekti me shumë përvojë. Mban qëllimet strategjike të kompanisë në mendje dhe përshtat planet e zhvillimit të produktit në përputhje me to.
- arkitekt, një person që kupton aftësitë dhe kufizimet e zgjidhjeve teknologjike të zgjedhura/përdorura dhe ndikimin e tyre në zhvillimin e produktit.
Ekipet e zhvillimit dhe testimit. Njerëzit të cilët janë të përfshirë drejtpërdrejt në zhvillimin e produktit.
Klasifikimi i kërkesave
Ne marrim të dhëna të papërpunuara nga burime - letra, bileta, kërkesa verbale. Të gjitha
ankesat klasifikohen:
- konsultime me kuptimin "Si ta bëj?", "Si funksionon?", "Pse nuk funksionon?", "Nuk e kuptoj...". Kërkesat e këtij lloji shkojnë në Linjën Mbështetëse të Nivelit 1. Është e mundur të rikualifikohet konsultimi në lloje të tjera kërkesash.
- Incidentet me kuptimin “Nuk funksionon” dhe “Gabim”. Përpunuar nga 2 dhe 3 Linja mbështetëse. Nëse korrigjimet e menjëhershme dhe lëshimi i një patch janë të nevojshme, ato mund të transferohen nga mbështetja direkt në zhvillim. Është e mundur që të riklasifikohet si një kërkesë ndryshimi dhe ta dërgoni atë në dosjen e mbetur.
- Kërkesat për ndryshime dhe zhvillim. Ata futen në ngarkesën e produkteve, duke anashkaluar linjat mbështetëse. Por ekziston një procedurë e veçantë përpunimi për to.
Ka statistika për kërkesat: menjëherë pas lëshimit, numri i kërkesave rritet me 10-15% për një kohë të shkurtër. Ka gjithashtu rritje të kërkesave kur një klient i ri me një numër të madh përdoruesish vjen në shërbimet tona cloud. Njerëzit po mësojnë të përdorin aftësitë e reja të softuerit, ata kanë nevojë për këshilla. Edhe një klient i vogël, kur fillon të punojë në sistem, djeg lehtësisht më shumë se 100 orë konsultime në muaj. Prandaj, kur lidhim një klient të ri, ne gjithmonë rezervojmë kohë për konsultimet fillestare. Shpesh ne zgjedhim edhe një specialist specifik. Çmimi i qirasë, natyrisht, nuk i mbulon këto kosto pune, por me kalimin e kohës situata rregullohet. Periudha e përshtatjes zakonisht zgjat nga 1 deri në 3 muaj, pas së cilës nevoja për këshillim zvogëlohet ndjeshëm.
Më parë, ne përdornim zgjidhje të vetë-shkruara për të ruajtur kërkesat. Por gradualisht kaluam në produktet Atlassian. Së pari, ne transferuam zhvillimin për ta bërë më të lehtë punën sipas Agile, më pas mbështetjen. Tani të gjitha proceset kritike jetojnë në Jira SD, plus ato mbështeten nga shtojca të ndryshme për Jira, plus Confluence. Zgjidhjet e shkruara vetë mbetën vetëm për proceset që nuk ishin kritike për aktivitetet e kompanisë. Rezulton se detyrat tona tani janë ndërsektoriale dhe mund të transferohen midis mbështetjes dhe zhvillimit pa u hedhur nga një sistem në tjetrin.
Nga kjo lidhje mund të marrim të dhëna për të gjitha detyrat, kostot e planifikuara dhe aktuale të punës, të përdorim opsione të ndryshme çmimesh për klientët dhe të gjenerojmë dokumentacion për nevojat e brendshme dhe raportimin tek klientët.
Përpunimi i kërkesave për ndryshim
Në mënyrë tipike, kërkesa të tilla vijnë në formën e kërkesave të funksionalitetit. Analisti ynë studion kërkesën, krijon një specifikim dhe specifikime teknike të nivelit të lartë. Transferon specifikimet dhe specifikimet teknike personit që ka paraqitur këtë kërkesë për miratim - duhet të jemi të sigurt që flasim të njëjtën gjuhë me klientin.
Pasi ka marrë konfirmimin nga klienti se e kemi kuptuar mirë njëri-tjetrin, analisti e fut kërkesën në listën e produkteve të mbetura.
Menaxhimi i funksionalitetit të produktit
Numri i prapambetur akumulon kërkesat hyrëse për ndryshim dhe zhvillim. Këshilli teknik, i përbërë nga drejtori, drejtuesit e mbështetjes, zhvillimit, shitjeve dhe arkitekti i sistemit, mblidhet çdo gjashtë muaj. Në një format diskutimi, këshilli analizon dhe prioritizon aplikacionet nga diferenca e mbetur dhe bie dakord për 5 detyra zhvillimi për zbatim në versionin e ardhshëm.
Në fakt, këshilli teknik i përgjigjet kërkesave të industrisë dhe tregut duke rishikuar nevojat e shprehura në aplikacione. Gjithçka që ka pak rëndësi mbetet në prapambetje dhe nuk arrin zhvillim.
Klasifikimi i Kërkesave për Ndryshimin dhe Financat
Zhvillimi është i shtrenjtë. Prandaj, ne do t'ju tregojmë menjëherë se çfarë opsionesh mund të kemi nëse kërkesa për ndryshim ka ardhur nga një klient dhe jo nga një punonjës.
Kërkesat për ndryshim i klasifikojmë si më poshtë: nevoja e industrisë ose karakteristikë individuale e ndërmarrjes; një sasi e konsiderueshme funksionaliteti të ri ose një rregullim i vogël. Rregullime të vogla dhe kërkesat individuale përpunohen pa asnjë frill. Kërkesat individuale llogariten dhe zbatohen për një klient specifik si pjesë e punës së projektit me të.
Nëse kjo nuk është një nevojë masive e industrisë dhe vëllimi i funksionalitetit është i madh, atëherë mund të merret një vendim për të zhvilluar një modul të ri të veçantë që do të shitet përveç funksionalitetit kryesor. Nëse një kërkesë e tillë merret nga një klient, ne mund të mbulojmë kostot e zhvillimit të modulit, t'i ofrojmë klientit modulin falas ose me pagesë të pjesshme dhe ta nxjerrim vetë modulin në shitje. Në një situatë të tillë, klienti merr përsipër një pjesë të ngarkesës metodologjike dhe në thelb kryen një implementim pilot të modulit mbi vete.
Nëse kjo është një nevojë masive e industrisë, atëherë mund të merret një vendim për të përfshirë funksionalitete të reja në produktin bazë. Kostot në këtë rast bien tërësisht mbi ne, dhe funksionaliteti i ri shfaqet në versionin aktual të programeve.
Klientëve të vjetër u sigurohet një përditësim.
Mund të ndodhë gjithashtu që disa klientë të kenë një nevojë të ngjashme, por ajo nuk kualifikohet për një produkt masiv. Në këtë rast, ne mund t'ua dërgojmë specifikimin këtyre klientëve dhe të ofrojmë ndarjen e kostove të zhvillimit midis tyre. Në fund, të gjithë fitojnë: klientët marrin funksionalitetin me një kosto të ulët, ne e pasurojmë produktin dhe pas njëfarë kohe, edhe pjesëmarrësit e tjerë të tregut mund të marrin funksionalitetin për përdorimin e tyre.
DevOps
Zhvillimi përgatit dy lëshime kryesore në vit. Në çdo dalje është rezervuar koha për zbatimin e 5 detyrave të marra nga këshilli teknik. Kështu, në mes të rutinës, nuk harrojmë kurrë zhvillimin e produktit.
Çdo lëshim i nënshtrohet një grupi të përshtatshëm testimi dhe dokumentacioni. Më pas, ky lëshim instalohet në mjedisin e testimit të klientit përkatës, i cili, nga ana tjetër, kontrollon me përpikëri gjithçka dhe vetëm pas kësaj lëshimi transferohet në prodhim.
Përveç sistemit të lëshimit, ekziston një format për rregullime të shpejta të gabimeve në mënyrë që klientët të mos jetojnë me gabime për gjashtë muaj. Ky format i ndërmjetëm do t'ju lejojë t'i përgjigjeni shpejt incidenteve të prioritetit të parë dhe të përmbushni SLA-të e deklaruara.
Të gjitha sa më sipër janë të vërteta kryesisht për sektorin e korporatave dhe zgjidhjet e brendshme. Për shërbimet cloud që synojnë segmentin SMB, nuk ka mundësi kaq të gjera që klientët të marrin pjesë në zhvillimin e produktit. Formati i qirasë SMB as që e supozon këtë. Në vend të një kërkese ndryshimi në formën e kërkesave të qarta nga pala e korporatës, këtu ka vetëm reagime dhe dëshira të zakonshme për shërbimin. Ne përpiqemi të dëgjojmë, por produkti është masiv dhe dëshira e një klienti për të sjellë diçka të njohur nga sistemi i tyre i vjetër historik mund të kundërshtojë strategjinë e zhvillimit të sistemit në tërësi.
Burimi: www.habr.com