Varjatud kulud ja tegelik paindlikkus tootearendusprotsessis

Wu-Tang Clanil oli õigus

Sularaha valitseb kõike minu ümber. Seda ei saa eitada isegi kõige türkisemad organisatsioonid. Arengu projekt juhtimismeetodid, protsesside häälestamine ja optimeerimine või töötajate motiveerimine on põhimõtteliselt tingitud universaalsest rahavajadusest. Disaini agiilsusega kaasnevad teatud riskid.

Me kõik tahame olla lahjad ja agiilne et meie tegevuse tulemus, mõõdetuna arvudes, oleks võimalikult kõrge. Isegi kui me keskendume kõige enam kahjude vähendamisele, võtame lõpuks arvesse tänu saavutatud kokkuhoiule suurenenud kasumit.

Need säästud langevad ülejäänud teguritega samasse taskusse ja jäävad ainult kõige uudishimulikumatele kättesaadavaks. Sel viisil kaotame tähelepanu ja jätame tahtmatult kõrvale palju väärtuslikke andmeid ja lõppkokkuvõttes ka intelligentsust.

Ebaõnnestumistest saadud õppetunnid

Oma vigadest õppimine on eriti kasulik (kuigi kallis) oskus, kuid organisatsioonikultuur ja selle võimega kaasnev diplomaatia ei aita alati. Sageli varjame finantside negatiivset mõju "suitsusõnadega". Kui investor hüüab "Ma kaotasin oma raha!", edastab juht seda meeskond öeldes "me peaksime olema tõhusamad" ja me kõik otsime vaikimisi uusi lahendusi ja parandusi - selle asemel, et vaadata tagasi, otsime pidevalt viise, kuidas edasi liikuda.

Vahepeal on kahjum sageli võti õigete järelduste tegemiseks. Kui me läheme protsessi teatud vooluetappidest üle ilma korraliku kaalutluseta, on järgmised lahendused tõenäoliselt nakatunud samade vigadega.

Näide: 

Väike vanemate JS-arendajate meeskond ei paku funktsionaalsust oodatud aja jooksul. Investor, kes soovib arengut kiirendada, tellib uue programmeerija palkamise. Uue inimese sissetoomine projekti segab meeskonda, mis aeglustab projekti edenemist veelgi.

Kui investor mõistaks paremini meeskonna ebaefektiivsuse põhjuseid, jõuaks ta järeldusele, et see kasutab oma potentsiaali ainult 60-70%. Paremad seadmed ja mõned tööautomaatikale pühendatud tööpäevad lahendaksid probleemi.

Kahjuks peab ta nüüd maksma teise arendaja eest, kes töötab samadel seadmetel ja tema tõhusus on samuti 60-70%.

Lahendus A:

• Meeskond (2 x vanem JS arendaja): $20k / kuu
• Pilv teenused: 200$ / kuu
• Uus riistvara arendajatele: $10k

Nüüdsest alates maksab projekt $20,200 / kuu.

Kulutused kokku 12 kuu jooksul: 12 * 20,200 + 10,000 = $252,400

Lahendus B:

• Meeskond (2 x vanem JS arendaja): $20k / kuu
• Uus arendaja (1 x vanem JS arendaja): $10k / kuu

Nüüdsest alates projekti kulud: $30,000 / kuu

Kulutused kokku 12 kuu jooksul: 12 * 30 000 = $360 000

Kaks arendajat, kes töötavad 100% juures, teevad umbes sama palju kui kolm arendajat, kes töötavad 60-70% juures. Investor maksab sama töötlemisvõimsuse eest aastas üle $ 100 000 võrra rohkem vigase projekteerimisotsuse tõttu!

Täiusliku toote ehitamine on nagu jänese tagaajamine.

Paindlikkus protsessis ei tähenda tingimata 100% testide katvuse saavutamist või jõudlusrekordi purustamist. Kuigi need mõõdikud annavad ülevaate projekti tehnilisest seisundist, on need lõppkliendi seisukohast nii tähtsusetud, et nende viimine ideaalsesse seisundisse tõeliselt agiilses protsessis ei ole vajalik, kuna need ei too tegelikku turg väärtus.

Ideaalsete tehniliste lahenduste väljatöötamine nõuab palju meeskonnatööd ja palju ulatuslikumat suhtlemist. Selle tulemusena töötavad parandused aeglasemalt ja projekt muutub liigse arenduse tõttu raskeks.

Agiilne arendus on kõike seda, et pakkuda töötavat kood minimaalse vaevaga. Koodi testimine on kahtlemata hea tava ja testid ütlevad palju koodi toimimise kohta, kuid neid ei tohiks teha ainult selle pärast, et neid teha ja sellega uhkeldada - lahenduste optimaalne tehniline kvaliteet jääb kuskil selle miinimumi vahele, mis on kindlaks määratud arendusmeeskond ja maksimaalne, mis on piiratud eelarvega.

Lõppkokkuvõttes ei vii täiuslikkus kuhugi. Huvitaval kombel kehtib see reegel isegi turvalisuse kohta - teoreetiliselt võib iga süsteemi häkkida. Kuid eespool nimetatud arendusminimum peab olema vastavalt suurem ja asjakohane koodivigade võimalike tagajärgede kaalu, ulatuse ja maksumuse suhtes. Sageli on parem kasutada näiteks "Logi sisse Google'iga" nuppu, mille korralik rakendamine on suhteliselt kiire ja turvaline, selle asemel, et kirjutada sisselogimise moodul nullist, mis on alati koormatud suure veaohuga ja turvaaukude sissetoomisega.

Kui eesmärgiks on lühike turulejõudmise aeg, on liiga ambitsioonikad eeldused kahjulikud. Näiliselt täiuslikus protsessis võib liigne entusiasm olla ressursside raiskamine.

Hea on teada kõike millestki ja midagi kõigest

Kasutajakeskne disain on lahe. Inimkeskne koostöö on tähtsam. Kui meeskond suhtleb ühel lainel, võib see spontaanselt vähendada edasisi võimalikke kaotusi.

UX-disainer, kes on kursis frontend-tehnoloogiatega, ei paku lahendust, mis on MVP etapp, mis võtab rakendamise etapis ebamõistlikult palju aega.

Kasutatavuse heuristikat tundev frontend-arendaja suudab kasutajaliidese kohandada antud ekraani resolutsioonile ilma UX-disainerit kaasamata - kiire parandamine, eelvaade, vastuvõtmine.

Rakenduse kallal töötamine nõuab täiesti erinevate pädevusprofiilidega inimeste tegevuse sünkroniseerimist. Te peate teadma oskuste jaotust oma meeskonnas, et pakkuda klientidele tõhusalt väärtust.

Pühendunud ja sünkroonitud meeskond on peamine kokkuhoiuallikas. Selline paindlikkus eeldab optimaalset tootearendust.

Selliselt mõistetud head meeskonnatööd on äärmiselt raske saavutada, eriti ajastul, mil kaugtöö. Ettevõtted, kes on juba aastaid olnud "kaugjuhtimissõbralikud", on selles valdkonnas märkimisväärne eelis nende ees, kes on olnud sunnitud organisatsiooni lukustuse ajal häälestama ja alles nüüd õpivad uusi kommunikatsioonimeetodeid ja -vorme.

Võimas varustus, enne kui lähete minema

Seoses kasvavate kommunikatsioonivajadustega on sellised tööriistad nagu Whimsical, Miro, Mural, Figma ja Balsamiq saavutanud muljetavaldava populaarsuse kasvu.

Kindlasti on kasutajate arvu plahvatuslikus suurenemises oma osa mänginud lukustamine ja vajadus töötada eemalt. Ma usun, et tööriista valik peaks vastama individuaalsetele eelistustele, kuid vaatame Miro:

Selliste vahendite populariseerimine suurendab loomulikult ka nende meetodite endi populaarsust. Keegi, kes ostis Miro, et töötada personade kallal, saab juurdepääsu kümnetele teistele mallidele, mis võivad osutuda huvitavaks ja mõjutada positiivselt meeskonna igapäevast tööd.

Te peaksite alati varustama end vahenditega, mis ühtlustavad infovoolu projektis. Avameelsus uute vahendite ja meetodite suhtes on samuti üks tõhusa tootearendus.

Sa võid (ja peaksid) olema laisk

Nii kasutajaliidese kui ka tarkvara arhitektuuri kogenud disainerid märkavad tavaliselt mitmeid võimalikke lahendusi, mida tuleks koostöö alguses kontrollida, ning otsivad tõhusalt sobivaid inspiratsioone või isegi valmislahendusi turul. Hea näide on Material UI raamistik, mis on tavaliselt turvaline valik prototüübi etapis..

Mõnikord piisab sellest, kui vaadata läbi mõned rakendused Behance'is või Dribble'is ja kasutada inspiratsiooni, et koostada meeleoluplaat ning edastada see seejärel arendajale. See inimene paneb selle abil kokku klikitava prototüübi, mida saab tagasiside kogumiseks esitada varajastele kasutajatele. See orgaaniline püüdlus tõhusa protsessi poole on disainiga tegelevatel ja pühendunud inimestel loomulik.

Kui soovite digitaalsete toodete tõhusat tarnimist, peate laskma inimestel teha oma tööd. Te teate, millist väärtust/teenust soovite oma klientidele pakkuda - sellest piisab. Pädev ja hästi juhitud projektimeeskond teab kõige paremini, kuidas seda väärtust/teenust võimalikult kiiresti ja vajaliku kulutõhususega pakkuda.

Näidake oma usaldust, jagage vastutust ja avanege tõelisele kahepoolsele suhtlusele, nii et teie toode on parem ja koormus, et kõik ise teha, on teie õlgadelt maha võetud, mis sageli osutub asutajatele ja ettevõtjatele kurnavaks! Veebilehel The Codest, me rakendame seda põhimõtet mitte ainult projektides, vaid ka sisemistes protsessides - ilmselt seetõttu on meil nii klientide kui ka töötajate (tõsi lugu, mõlemad> 90%) seas kõrge püsivusmäärad (tõsi lugu, mõlemad> 90%).

Ravige ennast pisut laiskusega, andke julgelt vastutust üle ja laske lahti kõigist üleliigsetest töödest, mis ei ole edasiliikumiseks vajalikud - funktsionaalsused, mis oleksid "nice to have", võivad alati oodata.

Keskendu õigete vastuste leidmisele

Digitaalse toote loomise protsess on erinevate vaatenurkade, kogemuste ja teabeallikate pidev kokkupõrge - iga selline kokkupõrge kätkeb endas riski teha vale disainiotsus.

Hea sisekommunikatsioon vähendab seda riski, kuid see on ainult mündi üks külg. Küsimus, kuidas hoida turuga kontakti, on veel vastamata.

Business Intelligence, klienditoe, UX-uuringute osakonnad ja paljud teised - nagu ka arendusmeeskond, peaksid nad püüdlema minimaalse vajaliku taseme poole, et anda konkreetseid vastuseid tooteomaniku või UX-meeskonna esitatud küsimustele.

Oluline on ka brändi enda ja brändi kommunikatsioonistrateegia. Need aitavad luua klientidega kvalitatiivset suhet, mis omakorda väljendub nende pühendumuses. Kui soovite esitada klientidele küsimusi, siis peaksite veenduma, et nad on valmis nendele küsimustele vastama. Teie hääletoon on oluline.

On kindel, et pidev kokkupuude turuga võimaldab teil määratleda projekti jaoks õiged trajektoorid, et see lendaks. Vähem ilmne on asjaolu, et selle kontakti vajadust tuleks kaaluda juba projekti alguses, umbes ette näha õige pädevus meeskonnas (et küsida õigeid küsimusi ja neile vastata) ning koostada tootestrateegia, mis kaasab sihtrühmad.

Järeldused

Võttes arvesse kõiki eespool nimetatud küsimusi, võime täheldada mitmeid probleeme, mis ilmnevad regulaarselt projekteerimisprotsessis:

- liigselt kasumile orienteeritud ja vältida ebaõnnestumiste vaatlemist,

- ebatäpsus ja mitte röntgeni enda vigade läbivalgustamine,

- jahtida täiuslikku toodet, mis on teil peas, kuid mida turg ei vaja,

- õpikuprotsesside liigselt innukas rakendamine - liigne arendamine ja liigne projekteerimine,

- meeskonnatöö paindumatus ja töötajate sundimine jääma ainult oma erialale,

- ebaefektiivne suhtlemine,

- kalduvus leiutada ratas uuesti.

Protsessi optimeerimine makromajanduslikul tasandil hõlmab kokkuhoiu summat. Et eespool nimetatud väljakutsetega korralikult toime tulla, peate kaasama oma kolleegid, et nad esitaksid avalikult ideid protsessi parandamiseks.

Mõnikord piisab edu saavutamiseks sellest, kui rääkida vähem ja kuulata tähelepanelikumalt alluvaid, kliente, partnereid - vastavalt igaühe rollile ja vastutusele.

Kui te ei ole päris piisavalt, siis tõenäoliselt investeerite liiga palju.. Kas teil on liiga palju raha?

Ole vait ja võta oma raha! Oh, ja pealegi:

1. Ärge võtke kasutusele Scrumi ainult selleks, et harjutada Scrumi.
2. Pöörake rohkem tähelepanu protsessis esinevatele puudustele.
3. Seadke väiksemaid eesmärke, mis on lühikese aja jooksul saavutatavad ja mõõdetavad - üldiselt jääge minimaalsele tasemele.
4. Mõnikord on hea teekaart on piisav, et anda meeskonnale ühise eesmärgi tunnetus ja kaasata nad tõhusasse töösse siin ja praegu.
5. Luua hea meeskond, et anda talle vajalik vabadus.
6. Seadke alati praegused tööriistad kahtluse alla - otsige oma töökojas võimalikke täiustusi.
7. Kujundage protsess laisa inimese vaatenurgast - justkui tahaksite teha võimalikult vähe.

Loe edasi:

CTO väljakutsed - tarkvaratoodete laiendamine ja arendamine

Milline andmebaas valida oma tarkvaraprojekti konkreetse andmetüübi jaoks