Í þessari grein mun ég deila reynslu minni af því að velja hugmyndir til að þróa virkni vara okkar og segja þér hvernig á að viðhalda helstu þróunarvökum.
Við erum að þróa sjálfvirkt uppgjörskerfi (ACP) - innheimtu. Kjörtímabil
Líftími vörunnar okkar er 14 ár. Á þessum tíma hefur kerfið þróast frá fyrstu útgáfum af iðnaðargjaldskrárkerfi í einingasamstæðu sem samanstendur af 18 vörum sem bæta hver aðra upp. Einn mikilvægasti þátturinn í langlífi fyrir forrit er stöðug þróun. Og þróun krefst hugmynda.
Hugmyndir
Heimildir
Það eru 5 heimildir:
- Helsti vinur þróunaraðila upplýsingakerfa fyrirtækja er viðskiptavinur. Og viðskiptavinurinn er sameiginleg ímynd þeirra sem taka ákvarðanir, bakhjarla verkefna, eigenda og framkvæmdastjóra ferla, innri upplýsingatæknisérfræðinga, almennra notenda og fjölda áhugasamra einstaklinga í mismiklum mæli. Það er okkur mikilvægt að hver og einn fulltrúi viðskiptavinarins sé hugsanlega birgir hugmynda. Í versta falli fáum við bara neikvæð viðbrögð um vandamál í kerfinu. Í besta falli er einstaklingur á hlið viðskiptavinarins sem er stöðugur uppspretta hugmynda um úrbætur, sem gefur skipulagðar upplýsingar um þarfir viðskiptavinarins.
- Okkar sölumenn og reikningsstjórar eru önnur mikilvægasta uppspretta hugmynda til úrbóta. Þeir hafa virkan og víðtæk samskipti við fulltrúa iðnaðarins og fá fyrirspurnir frá mögulegum viðskiptavinum um innheimtuvirkni frá fyrstu hendi. Seljendur og reikningar verða að vera meðvitaðir um allar verulegar breytingar á virkni þeirra og nýjustu uppfærslur á hugbúnaði samkeppnisaðila og geta rökstutt kosti og galla mismunandi lausna. Þetta eru starfsmenn okkar sem eru fyrstir til að skynja hvort einhver greiðslugeta verði í raun staðall, án hans getur hugbúnaðurinn ekki talist fullkominn.
- Vörueigandi — einn af æðstu stjórnendum okkar eða mjög reyndur verkefnastjóri. Hefur stefnumótandi markmið fyrirtækisins í huga og lagar vöruþróunaráætlanir í samræmi við þau.
- Arkitekt, einstaklingur sem skilur getu og takmarkanir þeirra tæknilausna sem eru valdar/notaðar og áhrif þeirra á vöruþróun.
Þróunar- og prófunarteymi. Fólk sem kemur beint að vöruþróun.
Flokkun beiðna
Við fáum hrá gögn frá heimildum - bréf, miða, munnlegar beiðnir. Allt
kærur flokkast:
- Samráð með merkingunni "Hvernig á að gera það?", "Hvernig virkar það?", "Af hverju virkar það ekki?", "Ég skil ekki...". Beiðnir af þessu tagi fara til 1. stigs stuðningslínu. Hægt er að endurþjálfa samráðið yfir í aðrar tegundir beiðna.
- Atvik með merkingunni „Virkar ekki“ og „Villa“. Unnið af 2 og 3 stuðningslínum. Ef þörf er á skjótum leiðréttingum og losun plásturs er hægt að flytja þær frá stuðningi beint í þróun. Hægt er að endurflokka hana sem breytingabeiðni og senda í bakdaginn.
- Ósk um breytingar og þróun. Þeir komast inn í vöruafganginn og fara framhjá stuðningslínunum. En það er sérstakt vinnsluferli fyrir þá.
Það eru til tölfræði um beiðnir: strax eftir útgáfu eykst fjöldi beiðna um 10-15% í stuttan tíma. Það er líka aukning í beiðnum þegar nýr viðskiptavinur með mikinn fjölda notenda kemur í skýjaþjónustuna okkar. Fólk er að læra að nota nýja hugbúnaðargetu, það þarf ráðgjöf. Jafnvel lítill viðskiptavinur, þegar hann byrjar að vinna í kerfinu, brennir auðveldlega meira en 100 klukkustundum af samráði á mánuði. Þess vegna, þegar við tengjum nýjan viðskiptavin, áskiljum við okkur alltaf tíma fyrir fyrstu ráðgjöf. Oft veljum við jafnvel sérstakan sérfræðing. Leiguverðið stendur auðvitað ekki undir þessum launakostnaði, en með tímanum jafnast ástandið út. Aðlögunartíminn tekur venjulega frá 1 til 3 mánuði og eftir það minnkar þörfin fyrir ráðgjöf verulega.
Áður notuðum við sjálfskrifaðar lausnir til að geyma beiðnir. En smám saman fórum við yfir í Atlassian vörur. Fyrst fluttum við þróun til að gera það auðveldara að vinna samkvæmt Agile, síðan stuðning. Nú eru öll mikilvæg ferli í Jira SD, auk þess sem þau eru studd af ýmsum viðbótum fyrir Jira, auk Confluence. Sjálfskrifaðar lausnir voru aðeins eftir fyrir ferla sem voru ekki mikilvægir fyrir starfsemi fyrirtækisins. Í ljós kemur að verkefni okkar eru nú þverskurður og hægt er að færa þau á milli stuðnings og þróunar án þess að hoppa úr einu kerfi í annað.
Frá þessum hlekk getum við fengið gögn um öll verkefni, fyrirhugaðan og raunverulegan launakostnað, notað ýmsa verðmöguleika fyrir viðskiptavini og útbúið skjöl fyrir innri þarfir og skýrslugjöf til viðskiptavina.
Afgreiðsla breytingabeiðna
Venjulega koma slíkar beiðnir í formi krafna um virkni. Sérfræðingur okkar rannsakar beiðnina, býr til forskrift og tækniforskriftir á efstu stigi. Flytur forskrift og tækniforskriftir til þess sem sendi þessa beiðni um samþykki - við verðum að vera viss um að við tölum sama tungumál við viðskiptavininn.
Eftir að hafa fengið staðfestingu frá viðskiptavinum um að við skildum hvort annað rétt færir sérfræðingur beiðnina inn í vörusafnið.
Stýring vöruvirkni
Eftirstöðvarnar safna beiðnum um breytingar og þróun. Tækniráð, sem samanstendur af forstjóra, forstöðumönnum stuðnings-, þróunar-, sölu- og kerfisarkitekts, kemur saman á hálfs árs fresti. Í umræðuformi greinir ráðið og forgangsraðar umsóknum úr baklóðinni og kemur sér saman um 5 þróunarverkefni til útfærslu í næstu útgáfu.
Tækniráð bregst í raun við kröfum atvinnulífsins og markaðarins með því að fara yfir þær þarfir sem fram koma í umsóknum. Allt sem litlu máli skiptir situr eftir og nær ekki þróun.
Flokkun breytingabeiðna og fjármál
Þróun er dýr. Þess vegna munum við strax segja þér hvaða valkosti við gætum haft ef beiðni um breytingu kom frá viðskiptavini en ekki starfsmanni.
Við flokkum breytingarbeiðnir sem hér segir: iðnaðarþörf eða einstaklingseinkenni fyrirtækisins; umtalsvert magn af nýrri virkni eða minniháttar lagfæringu. Minniháttar lagfæringar og einstakar beiðnir eru afgreiddar án nokkurra veseni. Einstakar beiðnir eru reiknaðar út og útfærðar fyrir tiltekinn viðskiptavin sem hluti af verkefnavinnu með honum.
Ef þetta er ekki mikil iðnaðarþörf og magn virkni er mikið, þá gæti verið tekin ákvörðun um að þróa nýja sérstaka einingu sem verður seld til viðbótar við aðalvirknina. Ef slík beiðni berst frá viðskiptavinum getum við staðið undir kostnaði við að þróa eininguna, útvegað viðskiptavininum eininguna ókeypis eða með hlutagreiðslu og sett eininguna sjálfa í sölu. Í slíkum aðstæðum tekur viðskiptavinurinn á sig hluta af aðferðafræðilegu álaginu og framkvæmir í rauninni tilraunaútfærslu á einingunni á sjálfum sér.
Ef þetta er gríðarleg iðnaðarþörf, þá gæti verið tekin ákvörðun um að setja nýja virkni inn í grunnvöruna. Kostnaðurinn í þessu tilfelli fellur alfarið á okkur og nýja virknin birtist í núverandi útgáfu af forritunum.
Gamlir viðskiptavinir fá uppfærslu.
Það getur líka verið að nokkrir viðskiptavinir hafi svipaða þörf, en það uppfyllir ekki skilyrði fyrir fjöldavöru. Í þessu tilviki getum við sent forskriftina til þessara viðskiptavina og boðið að skipta þróunarkostnaði á milli þeirra. Að lokum vinna allir: viðskiptavinir fá virkni með litlum tilkostnaði, við auðgum vöruna og eftir nokkurn tíma geta aðrir markaðsaðilar einnig fengið virknina til notkunar.
DevOps
Þróunin undirbýr tvær helstu útgáfur á ári. Í hverri útgáfu er gefinn tími til útfærslu 5 verkefna sem berast frá tækniráði. Þannig, í miðri rútínu, gleymum við aldrei vöruþróun.
Hver útgáfa fer í viðeigandi prófun og skjöl. Næst er þessi útgáfa sett upp í prófunarumhverfi viðkomandi viðskiptavinar, sem aftur á móti skoðar allt nákvæmlega og aðeins eftir það er útgáfan flutt yfir í framleiðslu.
Auk útgáfukerfisins er til snið fyrir skyndivilluleiðréttingar þannig að viðskiptavinir búa ekki við villur í sex mánuði. Þetta millisnið gerir þér kleift að bregðast fljótt við atvikum í fyrsta forgangi og uppfylla tilgreind SLAs.
Allt ofangreint á fyrst og fremst við um fyrirtækjageirann og staðbundnar lausnir. Fyrir skýjaþjónustu sem miðar að SMB-hlutanum eru ekki svo víðtæk tækifæri fyrir viðskiptavini til að taka þátt í vöruþróun. SMB leigusniðið gerir ekki einu sinni ráð fyrir þessu. Í stað breytingabeiðni í formi skýrra krafna frá fyrirtækisaðila er hér einungis um venjuleg endurgjöf og óskir um þjónustuna að ræða. Við reynum að hlusta, en varan er gríðarmikil og löngun eins viðskiptavinar til að koma með eitthvað kunnuglegt úr gamla sögukerfinu sínu gæti stangast á við þróunarstefnu kerfisins í heild.
Heimild: www.habr.com