Paslėptos išlaidos ir tikrasis produktų kūrimo proceso judrumas

"Wu-Tang Clan" buvo teisus

Pinigai valdo viską aplink mane. To negali paneigti net labiausiai turkio spalvos organizacijos. Plėtra projektas valdymo metodai, procesų tobulinimas ir optimizavimas arba darbuotojų motyvacija iš esmės yra nulemta visuotinio pinigų poreikio. Projektavimo judrumas susijęs su tam tikra rizika.

Visi norime būti taupūs ir Agile kad mūsų veiklos rezultatas, matuojamas skaičiais, būtų kuo aukštesnis. Net jei didžiausią dėmesį skiriame nuostoliams mažinti, galiausiai atsižvelgiame į pelną, kuris padidėjo dėl sutaupytų lėšų.

Šios santaupos patenka į tą pačią kišenę kartu su kitais veiksniais ir lieka prieinamos tik patiems smalsiausiems. Taip prarandame dėmesį ir netyčia praleidžiame daug vertingų duomenys ir galiausiai žvalgybą.

Iš nesėkmių išmoktos pamokos

Mokymasis iš savo klaidų yra ypač naudingas (nors ir brangus) įgūdis, tačiau organizacinė kultūra ir į šį gebėjimą integruota diplomatija ne visada padeda. Dažnai neigiamą finansų poveikį slepiame "dūmų uždangos" žodžiais. Kai investuotojas šaukia: "Praradau savo pinigus!", vadovas praneša apie tai komanda sakydami, kad "turėtume būti efektyvesni", ir visi pagal nutylėjimą ieškome naujų sprendimų ir patobulinimų - užuot žvelgę atgal, nuolat ieškome būdų, kaip judėti į priekį.

Tuo tarpu nuostoliai dažnai padeda padaryti teisingas išvadas. Jei tam tikrus proceso srauto žingsnius pereisime tinkamai neįvertinę, kiti sprendimai greičiausiai bus užkrėsti tomis pačiomis klaidomis.

Pavyzdys: 

Nedidelė vyresniųjų specialistų komanda JS kūrėjai nesuteikia funkcijų per numatytą laiką. Investuotojas, norėdamas paspartinti plėtrą, užsako pasamdyti naują programuotoją. Naujo asmens įvedimas į projektą išblaškys komandą, o tai dar labiau sulėtins projekto eigą.

Jei investuotojas geriau suprastų komandos neveiksmingumo priežastis, jis padarytų išvadą, kad ji savo potencialą išnaudoja tik 60-70%. Problemą išspręstų geresnė įranga ir kelios darbo dienos, skirtos darbo automatizavimui.

Deja, dabar jis turi sumokėti už kitą kūrėją, kuris dirbs su ta pačia įranga, o jo našumas taip pat bus 60-70%.

A sprendimas:

• Komanda (2 x vyresnysis JS kūrėjas): $20k / mėn.
• Debesis paslaugos: 200$ / mėn.
• Nauja programuotojams skirta techninė įranga: $10k

Nuo šiol projektas kainuoja $20,200 per mėnesį

Visos išlaidos per 12 mėnesių: 12 * 20 200 + 10 000 = $252 400

Sprendimas B:

• Komanda (2 x vyresnysis JS kūrėjas): $20k / mėn.
• Naujas kūrėjas (1 x vyresnysis JS kūrėjas): $10k / mėn.

Nuo šiol projekto išlaidos: $30 000 / mėn.

Visos išlaidos per 12 mėnesių: 12 * 30 000 = $360 000

Du programuotojai, dirbantys 100%, padaro maždaug tą patį, ką ir trys programuotojai, dirbantys 60-70%. Dėl klaidingo projektinio sprendimo investuotojas už tą patį apdorojimo pajėgumą per metus sumokės daugiau nei $ 100 000 daugiau!

Tobulo gaminio kūrimas - tai tarsi triušio gaudymas

Proceso judrumas nebūtinai reiškia, kad reikia siekti 100% bandymų aprėpties ar sumušti našumo rekordą. Nors šie rodikliai leidžia apžvelgti techninę projekto būklę, galutinio kliento požiūriu jie yra tokie nereikšmingi, kad jų idealios būklės pasiekimas tikrai judriame procese neturi būti pasiektas, nes jie nesuteikia realios rinka vertė.

Tobuliems techniniams sprendimams kurti reikia daug komandinio darbo ir daug platesnio bendravimo. Dėl to pataisos veikia lėčiau, o projektas tampa sunkus dėl perteklinio plėtojimo.

Agile plėtra svarbiausia - sukurti veikiantį kodas su minimaliomis pastangomis. Kodo testavimas neabejotinai yra gera praktika, o testai daug pasako apie kodo veikimą, tačiau jų nereikėtų atlikti vien dėl to, kad juos atliktumėte ir tuo pasigirti - optimali techninė sprendimų kokybė yra kažkur tarp minimumo, kurį nustato kūrėjų komanda ir maksimalią sumą, kurią riboja biudžetas.

Galiausiai tobulumas niekur neveda. Įdomu tai, kad ši taisyklė galioja net saugumo srityje - teoriškai į bet kurią sistemą galima įsilaužti. Tačiau minėtas kūrimo minimumas turi būti atitinkamai didesnis ir atitikti galimų kodo nesėkmių pasekmių svorį, mastą ir kainą. Dažnai, užuot nuo nulio rašę prisijungimo modulį, kuris visada apkrautas didele klaidų ir saugumo spragų atsiradimo rizika, geriau naudoti, pavyzdžiui, mygtuką "Prisijungti su "Google", kurio tinkamas įgyvendinimas yra palyginti greitas ir saugus.

Kol tikslas yra trumpas laikas, per kurį reikia patekti į rinką, pernelyg ambicingos prielaidos duoda priešingą rezultatą. Iš pažiūros tobulame procese pernelyg didelis entuziazmas gali būti išteklių švaistymas.

Gera žinoti viską apie kažką ir kažką apie viską

Į naudotoją orientuotas dizainas yra šaunus. Į žmogų orientuotas bendradarbiavimas yra svarbesnis. Kai komanda bendrauja ant tos pačios bangos, ji gali spontaniškai sumažinti tolesnius galimus nuostolius.

A UX dizaineris, kuris yra susipažinęs su frontend technologijomis, nepasiūlys sprendimo MVP etapas, kuris įgyvendinimo etape užims nepagrįstai daug laiko.

Priekinės dalies kūrėjas, išmanantis patogumo euristiką, galės pritaikyti sąsają prie tam tikros ekrano raiškos neįtraukdamas UX dizainerio - greitai pataisyti, peržiūrėti, priimti.

Dirbant su programa reikia sinchronizuoti visiškai skirtingų kompetencijų žmonių veiklą. Kad galėtumėte veiksmingai teikti vertę klientams, turite žinoti, kaip paskirstyti įgūdžius savo komandoje.

Įsitraukusi ir sinchroniškai dirbanti komanda yra pagrindinis taupymo šaltinis. Tokiam judrumui reikia optimalaus produkto kūrimo.

Taip suprastą gerą komandos darbą pasiekti nepaprastai sunku, ypač šiais laikais, kai nuotolinis darbas. Įmonės, kurios jau daugelį metų buvo "draugiškos" nuotoliniam ryšiui, šioje srityje turi didelį pranašumą prieš įmones, kurios buvo priverstos derinti organizaciją užblokavimo metu ir tik dabar mokosi naujų bendravimo metodų ir formų.

Galinga įranga prieš einant

Atsižvelgiant į augančius komunikacijos poreikius, tokių įrankių kaip "Whimsical", "Miro", "Mural", "Figma" ir "Balsamiq" populiarumas įspūdingai auga.

Be abejo, vartotojų skaičiaus didėjimą lėmė užrakinimas ir poreikis dirbti nuotoliniu būdu. Manau, kad įrankio pasirinkimas turėtų atitikti individualius pageidavimus, tačiau pažvelkime į "Miro":

Tokių priemonių populiarėjimas natūraliai skatina ir pačių metodikų populiarėjimą. Žmogus, nusipirkęs "Miro", kad galėtų dirbti su asmenybėmis, gauna prieigą prie dešimčių kitų šablonų, kurie gali būti įdomūs ir teigiamai paveikti kasdienį komandos darbą.

Visada turėtumėte pasirūpinti priemonėmis, kurios supaprastintų informacijos srautą projekte. Atvirumas naujoms priemonėms ir metodams taip pat yra vienas iš veiksmingo produktų kūrimas.

Galite (ir turėtumėte) tinginiauti

Patyrę sąsajos ir programinės įrangos architektūra paprastai bendradarbiavimo pradžioje pastebi keletą galimų sprendimų, kuriuos reikėtų patikrinti, ir efektyviai ieško tinkamų įkvėpimo šaltinių ar net gatavų sprendimų rinkoje. Geras pavyzdys - "Material UI" sistema, kuri paprastai yra saugi prototipo kūrimo etape..

Kartais užtenka "Behance" ar "Dribble" svetainėje peržiūrėti keletą įgyvendinimo pavyzdžių ir, pasinaudojus įkvėpimu, sukurti nuotaikų lentą, o tada perduoti ją kūrėjui. Šis ją panaudos, kad sukurtų spustelėjamą prototipas kuriuos galima pateikti ankstyviesiems naudotojams, kad būtų galima surinkti atsiliepimus. Šis organiškas veiksmingo proceso siekis dizaino srityje mąstantiems ir įsipareigojusiems žmonėms yra natūralus.

Jei norite efektyviai pristatyti skaitmeninius produktus, turite leisti žmonėms atlikti savo darbą. Žinote, kokią vertę ir (arba) paslaugą norite suteikti savo klientams - to pakanka. Kompetentinga ir gerai valdoma projekto komanda geriausiai žinos, kaip šią vertę / paslaugą pateikti kuo greičiau ir su reikiamu ekonominiu efektyvumu.

Parodykite pasitikėjimą, pasidalykite atsakomybe ir pradėkite abipusį bendravimą, kad jūsų produktas bus geriau ir nuo jūsų pečių nusimesite naštą, kuri dažnai būna labai sunki įkūrėjams ir verslininkams! Svetainėje The Codest, šį principą taikome ne tik projektuose, bet ir vidiniuose procesuose - tikriausiai todėl turime aukštus klientų ir darbuotojų išlaikymo rodiklius (tikra istorija, abu> 90%).

Tinginiaukite, drąsiai perkelkite atsakomybę ir atsisakykite nereikalingų darbų, kurie nėra būtini norint judėti į priekį - funkcijos, kurios būtų "gražu turėti", visada gali palaukti.

Sutelkite dėmesį į teisingų atsakymų paiešką

Skaitmeninio produkto kūrimo procesas - tai nuolatinis skirtingų požiūrių, patirčių ir informacijos šaltinių susidūrimas, o kiekvienas toks susidūrimas susijęs su rizika priimti neteisingą dizaino sprendimą.

Gera vidinė komunikacija sumažina šią riziką, tačiau tai tik viena medalio pusė. Į klausimą, kaip palaikyti ryšį su rinka, dar reikia atsakyti.

verslo žvalgybos, klientų aptarnavimo, UX tyrimų skyriai ir daugelis kitų - kaip ir kūrimo komanda, jie turėtų stengtis pateikti kuo mažiau konkrečių atsakymų į produkto savininko arba UX komandos užduotus klausimus.

Taip pat svarbus pats prekės ženklo kūrimas ir komunikacijos strategija. Jie padeda užmegzti kokybiškus santykius su klientais, kurie vėliau virsta jų įsipareigojimais. Jei norite klientams užduoti klausimų, turėtumėte įsitikinti, kad jie noriai į juos atsako. Svarbu ir jūsų balso tonas.

Neabejotina, kad nuolatinis ryšys su rinka leidžia nustatyti teisingas projekto trajektorijas, kad jis būtų sėkmingas. Mažiau akivaizdu tai, kad apie tokio kontakto poreikį reikėtų pagalvoti pačioje projekto pradžioje, numatant tinkamas komandos kompetencijas (kad būtų galima užduoti tinkamus klausimus ir į juos atsakyti) ir kuriant produkto strategiją, kuri įtrauktų tikslines grupes.

Išvados

Atsižvelgdami į visus pirmiau minėtus klausimus, galime pastebėti keletą problemų, kurios nuolat iškyla projektavimo procese:

- pernelyg didelis dėmesys pelnui ir vengimas vertinti nesėkmes,

- netikslumas ir savo klaidų nerodymas rentgenu,

- persekioti tobulą gaminį, kurį turite galvoje, bet kuris nėra toks, kokio reikia rinkai,

- pernelyg uolus vadovėlinių procesų įgyvendinimas - perteklinis kūrimas ir perteklinis projektavimas,

- komandinio darbo nelankstumas ir darbuotojų vertimas likti tik savo specializacijos srityje,

- neveiksmingas bendravimas,

- tendencija išradinėti dviratį iš naujo.

Proceso optimizavimas makro mastu apima sutaupytų lėšų sumą. Norėdami tinkamai įveikti minėtus iššūkius, turite įtraukti savo kolegas, kad jie atvirai pateiktų idėjų, kaip pagerinti procesą.

Kartais užtenka mažiau kalbėti ir atidžiau klausytis pavaldinių, klientų, partnerių - pagal kiekvieno vaidmenį ir atsakomybę - kad pasiektumėte sėkmės.

Kai jums nepakanka, greičiausiai per daug investuojate. Ar turite per daug pinigų?

Užsičiaupk ir pasiimk pinigus! Be to:

1. Neįveskite "Scrum" tik tam, kad praktikuotumėte "Scrum".
2. Daugiau dėmesio skirkite proceso trūkumams.
3. Išsikelkite mažesnius tikslus, kuriuos būtų galima pasiekti ir išmatuoti trumpuoju laikotarpiu - apskritai, laikykitės minimalių tikslų.
4. Kartais geras kelių žemėlapis pakanka, kad komanda pajustų bendrą tikslą ir įsitrauktų į veiksmingą darbą čia ir dabar.
5. Suburkite gerą komandą, kad galėtumėte suteikti jai reikiamą laisvę.
6. Visada abejokite esamais įrankiais - ieškokite galimų patobulinimų savo dirbtuvėse.
7. Kurkite procesą iš tinginio perspektyvos - tarsi norėtumėte padaryti kuo mažiau.

Skaityti daugiau:

CTO iššūkiai - programinės įrangos produktų masto didinimas ir augimas

Kurią DB pasirinkti konkrečiam duomenų tipui programinės įrangos projekte