Kõige kallim kood on kood, mis lahendab vale probleemi.
Oleme näinud seda liiga palju kordi juhtumas: klient tuleb meie juurde pärast kuude ja märkimisväärse eelarve kulutamist teise agentuuriga ning toode ei vasta sellele, mida nad tegelikult vajasid. Funktsioonid on tehniliselt korrektsed, kuid jäävad ilma äririaalsusest. Arhitektuur töötab, kuid ei suuda skaleeruda viisil, mida äri vajab. Ajakava eeldas nõudeid, mis muutusid teisel nädalal.
Algpõhjus on peaaegu alati sama: meeskond alustas koodi kirjutamist enne, kui nad mõistsid probleemi.
Seetõttu algab iga Codelive’i kaasamine avastustöötoaga. Ilma eranditeta.
Mis on avastustöötuba (ja mis see ei ole)
Avastustöötuba ei ole koosolek, kus me noogutame kaasa, kui sa kirjeldad oma rakenduse ideed. See ei ole nõuete kogumise seanss, kus täidame spetsifikatsioonimalli. Ning see ei ole kindlasti müügipitch, mis on riietatud koostööna.
Avastustöötuba on struktureeritud töönädal, kus süveneme su äriprobleemi, su kasutajatesse, su piirangutesse ning su eesmärkidesse — ning väljume ühise arusaamaga sellest, mida me ehitame, miks ning kuidas.
Siin on see, mis tavaliselt juhtub:
Päev 1-2: äri mõistmine
Alustame ärist, mitte tehnoloogiast. Millist probleemi lahendad? Kes on su kasutajad? Milline näeb edu välja kuue kuu pärast? Kahe aasta pärast? Millised on piirangud — regulatiivsed, eelarvelised, ajakavalised?
FinTech klientide jaoks on see faas eriti kriitiline. Peame mõistma, millistes jurisdiktsioonides tegutsed, millised vastavusnõuded kehtivad ning kuidas regulatsioon võib su toote teekaarti muuta. Oleme ehitanud FinTech lahendusi kuues riigis ning igaühel neist olid vastavusnõuded, mida asutajad algselt alahindasid.
Päev 3: kasutajateekonna kaardistamine
Kaardistame iga kasutajatüübi ja tema teekonna läbi su toote. Mitte ainult õnneliku raja — vaid erandjuhtumid, veaolekud, “mis siis, kui kasutaja teeb midagi ootamatut” stsenaariumid.
Siin ilmub peidetud keerukus. Turuplatvorm, mis tundub lihtne, osutub vajavaks depoo makseid, vaidluste lahendamist ja müüja kontrolli. Laenuplatvorm vajab mitte ainult laenu väljastamist, vaid ka sissenõudmist, aruandlust ja regulatiivseid teavitusi.
Oleme leidnud, et see üksainus kaardistamise päev ennetab nädalaid hilisemat ümbertegemist.
Päev 4: arhitektuur ja tehnilised otsused
Nüüd räägime tehnoloogiast. Selge pildiga sellest, mida me ehitame ja kelle jaoks me seda ehitame, saame teha informeeritud arhitektuuriotsuseid.
Kas see peaks olema monoliit või mikroteenused? Milline andmebaas sobib su andmemudeli ja skaleerimisnõuetega? Kas vajame reaalaja funktsioone? Milliseid kolmandate osapoolte integratsioone on vaja? Kus on jõudluskriitilised rajad?
Neid otsuseid on hiljem raske muuta. Nende tegemine täieliku konteksti — mitte oletustega — on investeeringut väärt.
Päev 5: teekaart ja prioriteedid
Lõpetame nädala prioritiseeritud teekaardiga. Mitte funktsioonide soovinimekirjaga, vaid realistliku plaaniga, mis tasakaalustab seda, mida sa soovid, sellega, mida su eelarve ja ajakava lubavad.
Kasutame lihtsat raamistikku: iga funktsiooni puhul hindame ärilist väärtust versus rakendamise pingutust. Kõrge väärtus, madal pingutus tuleb esimesena. Kõrge väärtus, kõrge pingutus planeeritakse hoolikalt. Madal väärtus, kõrge pingutus seatakse kahtluse alla — kas me tõesti vajame seda?
Väljund on dokument, mille saad viia oma juhatuse, investorite või meeskonna ette. See näitab, mida ehitatakse, millises järjekorras ja miks.
Miks see nädal loeb rohkem kui ükski teine
Avastustöötuba maksab tavaliselt 5-10% kogu projekti eelarvest. Kuid see ennetab kaht kõige kallimat ebaõnnestumise viisi tarkvaraarenduses:
Vale asja ehitamine. Ilma avastuseta ehitavad meeskonnad sageli seda, mis oli spetsifitseeritud, mitte seda, mida vajati. Enne sügavat mõistmist kirjutatud spetsifikatsioonid on peaaegu alati puudulikud või valed.
Ümberarhitekteerimine keset projekti. Kui tehnilised otsused tehakse ilma täieliku kontekstita, vajavad need sageli hiljem muutmist. Relatsioonilisest andmebaasist dokumendipõhisele üleminek keset projekti ei ole refaktoreerimine — see on ümberehitus.
Oleme viinud läbi avastustöötubasid projektidele alates kahekuulistest MVP-dest kuni aastapikkuste ettevõttetasandi ehitisteni. Igal juhul ütles klient meile hiljem, et töötuba muutis nende arusaama omaenda tootest.
Mida kliendid tavaliselt avastavad
Kõige väärtuslikumad hetked avastustöötoas on üllatused. Siin on mustrid, mida näeme kõige sagedamini:
Ulatus on suurem kui oodatud. Mitte funktsioonide leviku tõttu, vaid sellepärast, et päris maailma keerukus oli peidetud. “Lihtne” maksete integratsioon osutub vajavaks pettuse tuvastamist, korduskatse loogikat, sobitamist ja mitme valuuta tuge.
Esimene versioon peaks olema väiksem. Vastupidiselt intuitsioonile aitab täieliku ulatuse mõistmine klientidel MVP-d enesekindlamalt kärpida. Kui näed tervikpilti, tead, millised funktsioonid võivad oodata ja millised mitte.
Kasutaja ei ole see, keda eeldati. Asutajad ehitavad sageli endale, mitte oma tegelikule sihtkasutajale. Avastusprotsess toob selle lõhe varakult esile, enne kui see on arhitektuuri sisse kodeeritud.
Vastavus ei ole valikuline. Eriti FinTechis ja tervisetehnoloogias ei ole regulatiivsed nõuded funktsioonid, mida lisad hiljem. Need kujundavad arhitektuuri esimesest päevast peale.
Alternatiiv
Mõnikord saame vastuseisu: “Kas saame avastuse vahele jätta ja lihtsalt hakata ehitama?” Mõistame kiireloomulisust. Kuid meie kogemuses kulutavad meeskonnad, kes jätavad avastuse vahele, rohkem aega kokku, mitte vähem.
Nad kulutavad seda ümbertegemisele. Keset-projekti pöördumistele. Koosolekutele, mis oleks pidanud toimuma enne koodi kirjutamist. Funktsioonide ehitamisele, mis visatakse minema.
Avastustöötuba ei ole viivitus. See on investeering õige asja ehitamisse esimesel korral.
Valmis oma projekti õigesti alustama? Meie avastustöötoad annavad sulle selguse enne, kui eelarvele pühendud. Võta ühendust.