Selles artiklis jagan oma kogemusi ideede valimisel meie toodete funktsionaalsuse arendamiseks ja räägin teile, kuidas hoida peamisi arenguvektoreid.
Arendame välja automatiseeritud arveldussüsteemi (ACS) – arveldamist. Tähtaeg
Meie toote eluiga on 14 aastat. Selle aja jooksul on süsteem muutunud tööstusliku hindaja esimestest versioonidest modulaarseks kompleksiks, mis koosneb 18 üksteist täiendavast tootest. Programmide pikaealisuse üks olulisemaid aspekte on pidev areng. Ja arendamiseks on ideid vaja.
Ideed
allikatest
Seal on 5 allikat:
- Ettevõtte infosüsteemide arendaja peamine sõber on klient. Ja klient on kollektiivne kuvand otsustajatest, projekti sponsoritest, protsesside omanikest ja teostajatest, ettevõttesisestest IT-spetsialistidest, tavakasutajatest ja suurest hulgast erineval määral huvilistest. Meie jaoks on oluline, et iga kliendi esindaja oleks potentsiaalselt ideede pakkuja. Halvimal juhul saame süsteemi probleemide kohta ainult negatiivset tagasisidet. Parimal juhul on kliendi poolel inimene, kes on pidevaks parendusidee allikaks, pakkudes struktureeritud infot kliendi vajaduste kohta.
- Наши müüjad ja kontohaldurid on tähtsuselt teine parendusideede allikas. Nad suhtlevad palju ja aktiivselt valdkonna esindajatega, saavad potentsiaalsetelt klientidelt otsekohe arveldusfunktsiooni taotlusi. Kaupmehed ja kontod peavad olema teadlikud kõigist olulistest muudatustest oma funktsionaalsuses ja konkurentide viimastest tarkvarauuendustest, suutma põhjendada erinevate lahenduste plusse ja miinuseid. Just need meie töötajad tunnevad esimesena, kui mõnest arveldusfunktsioonist saab de facto standard, ilma milleta ei saa tarkvara terviklikuks pidada.
- Toote omanik on üks meie tippjuhtidest või väga kogenud projektijuht. Peab silmas ettevõtte strateegilisi eesmärke ja kohandab tootearendusplaane nende järgi.
- Arhitekt, inimene, kes mõistab valitud/kasutatud tehnoloogiliste lahenduste võimalusi ja piiranguid ning nende mõju tootearendusele.
Arendus- ja testimismeeskonnad. Inimesed, kes on otseselt seotud tootearendusega.
Tabamuste klassifikatsioon
Toorandmeid saame allikatest – kirjadest, piletitest, suulistest päringutest. Kõik
apellatsioonid on klassifitseeritud:
- Konsultatsioonid tähendusega "Kuidas seda teha?", "Kuidas see töötab?", "Miks see ei tööta?", "Ma ei saa aru...". Seda tüüpi kõned lähevad 1. taseme tugiliinile. Konsultatsiooni on võimalik ümber õpetada teist tüüpi apellatsioonideks.
- Juhtumid tähendusega "Ei tööta" ja "Viga". Käsitsetakse 2 ja 3 tugiliiniga. Kui on vaja plaastrit kiiresti parandada ja vabastada, saab selle toelt otse arendusse üle kanda. Seda on võimalik ümber liigitada muudatustaotluseks ja saata see mahajäämusse.
- Taotlused muudatusteks ja arendamiseks. Saage toote mahajäämusse, mööda tugiliinidest. Kuid nende jaoks on eraldi töötlemisprotseduur.
Tabamuste kohta on selline statistika olemas – kohe peale ilmumist kasvab tabamuste arv lühiajaliselt 10-15%. Kõnepuhanguid tuleb ette ka siis, kui meie pilveteenustesse tuleb uus, suure kasutajate arvuga klient. Inimesed õpivad kasutama uusi tarkvaravõimalusi, nad vajavad nõu. Ka väike klient põletab süsteemis tööd alustades kergesti üle 100 tunni konsultatsioone kuus. Seetõttu jätame uue kliendi ühendamisel alati aega esmaseks konsultatsiooniks. Sageli tõstame välja isegi konkreetse spetsialisti. Üürikulu muidugi neid tööjõukulusid ära ei tasu, kuid aja jooksul olukord tasaneb. Kohanemisperiood kestab reeglina 1 kuni 3 kuud, pärast mida väheneb oluliselt vajadus nõustamise järele.
Varem kasutasime kõnede salvestamiseks isekirjutatud lahendusi. Kuid järk-järgult läks üle Atlassiani toodetele. Esmalt viidi üle arendus, et oleks lihtsam Agile’il töötada, seejärel tugi. Nüüd on kõik kriitilised protsessid Jira SD-s, lisaks on need varustatud erinevate Jira pistikprogrammidega ja Confluence'iga. Isekirjutatud lahendused jäid vaid ettevõtte tegevuse jaoks mittekriitilistele protsessidele. Selgus, et meie ülesanded on nüüd otsast lõpuni, neid saab tugi- ja arendustegevuse vahel üle kanda ilma ühest süsteemist teise hüppamata.
Sellest komplektist saame andmeid kõigi tööülesannete, planeeritud ja tegelike tööjõukulude kohta, kasutada klientidele erinevaid arveldusvõimalusi ning koostada dokumentatsiooni sisemiste vajaduste jaoks ja aruannet klientidele.
Muudatustaotluste töötlemine
Tavaliselt esitatakse need taotlused funktsiooninõuete vormis. Meie analüütik uurib taotlust, genereerib spetsifikatsiooni ja tipptasemel TOR-i. Edastab spetsifikatsiooni ja TOR-i isikule, kes selle kooskõlastustaotluse esitas – peame olema kindlad, et räägime kliendiga sama keelt.
Saanud kliendilt kinnituse, et oleme teineteisest õigesti aru saanud, kannab analüütik päringu tootemahusse.
Toote funktsioonide haldamine
Mahajäämus koguneb laekunud muudatus- ja arendustaotlusi. Kord poole aasta jooksul tuleb kokku tehniline nõukogu, kuhu kuuluvad direktor, hooldus-, arendus-, müügijuhid ja süsteemiarhitekt. Arutelu formaadis analüüsib ja prioritiseerib nõukogu mahajäänud taotlusi ning lepib kokku 5 arendusülesannet järgmises väljaandes rakendamiseks.
Tegelikult vastab tehniline nõukogu tööstuse ja turu nõuetele, võttes arvesse taotlustes kajastatud vajadusi. Kõik väheoluline jääb mahajäämusse ega jõua arendusse.
Muudatustaotluste ja rahanduse klassifikatsioon
Arendus on kallis. Seetõttu anname kohe teada, millised võimalused meil võivad olla, kui muutmistaotlus tuleb kliendilt, mitte töötajalt.
Muudatustaotlused liigitatakse järgmiselt: valdkonnapõhised vajadused või ettevõtte individuaalsed omadused; märkimisväärne hulk uusi funktsioone või väike parandus. Väikseid parandusi ja individuaalseid taotlusi töödeldakse ilma probleemideta. Individuaalsed taotlused arvutatakse välja ja viiakse ellu konkreetse kliendi jaoks temaga tehtava projektitöö raames.
Kui tegemist ei ole massilise tööstuse vajadusega ja funktsionaalsuse hulk on suur, siis võib otsustada uue eraldi mooduli väljatöötamise kohta, mis müüakse lisaks põhifunktsionaalsusele. Kui kliendilt selline soov laekub, saame katta mooduli arendamise kulud, anda kliendile mooduli tasuta või osalise tasuga ning panna mooduli avalikku kasutusse müüki. Klient võtab sellises olukorras osa metoodilisest koormusest enda peale ja viib tegelikult läbi mooduli pilootrakenduse.
Kui see on tööstusharu tohutu vajadus, võib teha otsuse lisada baastootesse uusi funktsioone. Kulud kanname sel juhul täielikult meie ning uus funktsionaalsus ilmub programmide praegusesse versiooni.
Vanadele klientidele pakutakse värskendust.
Võib ka juhtuda, et mitmel kliendil on sarnane vajadus, kuid see ei tõmba masstoote külge. Sel juhul saame nendele klientidele spetsifikatsiooni saata ja pakkuda arenduskulude omavahelist jagamist. Lõppkokkuvõttes võidavad kõik: kliendid saavad madala kuluga funktsionaalsuse juurutuse, meie rikastame toodet, mõne aja pärast saavad funktsionaalsuse enda kasutusse ka teised turuosalised.
DevOps
Arendus valmistab ette kaks suuremat väljaannet aastas. Igas versioonis on reserveeritud aega 5 tehniliselt nõukogult saadud ülesande täitmiseks. Seega käibe taga ei unusta me kunagi toote arengut.
Iga väljalase läbib asjakohase testimise ja dokumentatsiooni. Edasi paigaldatakse see väljalase vastava kliendi testkeskkonda, kes omakorda kõik hoolikalt üle kontrollib ja alles pärast seda viiakse väljalase tootmisse.
Lisaks väljalaskesüsteemile on olemas kiirete veaparanduste formaat, et kliendid kuus kuud vigadega ei elaks. See vahepealne vorming võimaldab teil kiiresti reageerida esmatähtsatele juhtumitele ja täita märgitud SLA-d.
Kõik eelnev kehtib eelkõige ärisektori ja kohapealsete lahenduste kohta. SMB segmendile keskendunud pilveteenuste puhul ei ole klientidel nii laialdasi võimalusi tootearenduses osaleda. SMB rendivorming seda isegi ei soovita. Korporatiivse osapoole selgete nõuete vormis muudatustaotluse asemel on teenusele vaid tavapärane tagasiside ja soovid. Püüame kuulata, aga toode on massiivne ja ühe kliendi soov tuua midagi tuttavat oma vanast ajaloolisest süsteemist võib minna vastuollu süsteemi kui terviku arengustrateegiaga.
Allikas: www.habr.com