Slēptās izmaksas un reāla elastība produktu izstrādes procesā

Wu-Tang Clan bija taisnība

Visapkārt valda skaidra nauda. To nevar noliegt pat visturkīzākās organizācijas. Attīstība projekts vadības metodes, procesu uzlabošanu un optimizāciju vai darbinieku motivāciju pamatā izraisa vispārējā vajadzība pēc naudas. Dizaina veiklība ir saistīta ar zināmiem riskiem.

Mēs visi vēlamies būt racionāli un Agile lai mūsu darbības rezultāts, ko mēra skaitļos, būtu pēc iespējas augstāks. Pat ja mēs lielāko daļu savas enerģijas veltām zaudējumu samazināšanai, galu galā mēs ņemam vērā peļņu, kas ir palielinājusies, pateicoties radītajiem ietaupījumiem.

Šie ietaupījumi krīt vienā kabatā ar pārējiem faktoriem un paliek pieejami tikai zinātkārākajiem. Šādā veidā mēs zaudējam koncentrēšanos un netīšām izlaižam daudz vērtīgu lietu. dati un galu galā arī izlūkošanas.

No neveiksmēm gūtā pieredze

Mācīšanās no savām kļūdām ir īpaši noderīga (lai gan dārga) prasme, bet... organizatoriskā kultūra un diplomātija, kas saistīta ar šo spēju, ne vienmēr palīdz. Bieži vien mēs slēpjam finanšu negatīvo ietekmi ar "dūmu aizsegu". Kad ieguldītājs kliedz: "Es zaudēju savu naudu!", vadītājs to dara zināmu komanda sakot "mums vajadzētu būt efektīvākiem", un mēs visi pēc noklusējuma meklējam jaunus risinājumus un uzlabojumus - tā vietā, lai skatītos atpakaļ, mēs pastāvīgi meklējam veidus, kā virzīties uz priekšu.

Savukārt zaudējumi bieži vien ir atslēga, lai izdarītu pareizus secinājumus. Ja mēs pārcilāsim noteiktus procesa plūsmas soļus bez pienācīgas apsvēršanas, nākamie risinājumi, visticamāk, būs inficēti ar tām pašām kļūdām.

Piemērs: 

Neliela vecāko darbinieku komanda JS izstrādātāji nenodrošina funkcionalitāti paredzētajā laikā. Investors, vēloties paātrināt izstrādi, pasūta jaunu programmētāju. Jauna cilvēka iesaistīšana projektā izkliedē komandas uzmanību, kas vēl vairāk palēnina projekta virzību.

Ja investors labāk izprastu komandas neefektivitātes iemeslus, viņš secinātu, ka tā izmanto savu potenciālu tikai 60-70%. Problēmu atrisinātu labākas iekārtas un dažas darba automatizācijai veltītas darba dienas.

Diemžēl tagad viņam ir jāmaksā par citu izstrādātāju, kurš strādās ar to pašu aprīkojumu, un arī viņa efektivitāte būs 60-70%.

Risinājums A:

• Komanda (2 x vecākais JS izstrādātājs): $20k / mēnesī
• Mākonis pakalpojumi: 200$ / mēnesī
• Jauna aparatūra izstrādātājiem: $10k

No šī brīža projekta izmaksas ir $20,200 / mēnesī

Kopējie izdevumi 12 mēnešu laikā: 12 * 20 200 + 10 000 = $252 400

Risinājums B:

• Komanda (2 x vecākais JS izstrādātājs): $20k / mēnesī
• Jaunais izstrādātājs (1 x vecākais JS izstrādātājs): $10k / mēnesī

No šī brīža projekta izmaksas: $30 000 / mēnesī

Kopējie izdevumi 12 mēnešu laikā: 12 * 30 000 = $360 000

Divi izstrādātāji, kas strādā ar 100%, dara aptuveni to pašu, ko trīs izstrādātāji, kas strādā ar 60-70%. Ieguldītājs maksās vairāk nekā $ 100 000 vairāk par to pašu apstrādes jaudu gadā kļūdaina projekta lēmuma dēļ!

Izstrādāt perfektu produktu ir kā dzīties pakaļ zaķim

Procesa veiklība nebūt nenozīmē tiekties pēc 100% testa pārklājuma vai veiktspējas rekorda sasniegšanas. Lai gan šie rādītāji sniedz pārskatu par projekta tehnisko stāvokli, tie ir tik nenozīmīgi, raugoties no gala klienta perspektīvas, ka to panākšana līdz ideālam stāvoklim patiesi veiklā procesā nav nepieciešama, jo tie nedod reālu rezultātu. tirgus vērtība.

Perfektu tehnisku risinājumu izstrāde prasa lielu komandas iesaistīšanos un daudz plašāku saziņu. Rezultātā ielāpi strādā lēnāk un projekts kļūst smagnējs pārmērīgas izstrādes dēļ.

Agile attīstība galvenais mērķis ir nodrošināt strādājošu kods ar minimālu piepūli. Koda testēšana neapšaubāmi ir laba prakse, un testi daudz ko pasaka par koda darbību, taču tos nevajadzētu veikt tikai tāpēc, lai tos veiktu un ar to lielītos - optimālā risinājumu tehniskā kvalitāte atrodas kaut kur starp minimālo, ko nosaka izstrādes komanda un maksimālo summu, ko ierobežo budžets.

Galu galā, pilnība nekur nevedīs. Interesanti, ka šis noteikums attiecas pat uz drošības jautājumiem - teorētiski jebkuru sistēmu var uzlauzt. Tomēr iepriekš minētajam izstrādes minimumam ir jābūt attiecīgi lielākam un atbilstošākam, ņemot vērā koda kļūdu iespējamo seku svaru, mērogu un izmaksas. Bieži vien tā vietā, lai rakstītu pieteikšanās moduli no nulles, kas vienmēr ir apgrūtināts ar augstu kļūdu un drošības ievainojamību ieviešanas risku, labāk izmantot, piemēram, pogu "Pierakstīties ar Google", kuras pareiza implementācija ir salīdzinoši ātra un droša.

Kamēr mērķis ir īss laiks līdz laišanai tirgū, pārāk ambiciozi pieņēmumi izrādās neproduktīvi. Šķietami perfektā procesā pārmērīgs entuziasms var radīt resursu izšķērdēšanu..

Ir labi zināt visu par kaut ko un kaut ko par visu.

Uz lietotāju orientēts dizains ir forši. Uz cilvēku orientēta sadarbība ir svarīgāka. Ja komanda komunicē uz viena viļņa, tā var spontāni samazināt turpmākos iespējamos zaudējumus.

A UX dizainers, kurš ir lietas kursā par frontend tehnoloģijām, nepiedāvās risinājumu, kad MVP posms, kas īstenošanas posmā patērēs nepamatoti daudz laika.

Frontend izstrādātājs, kurš pārzina lietojamības heiristiku, spēs pielāgot saskarni noteiktai ekrāna izšķirtspējai, neiesaistot UX dizaineri - ātra labošana, priekšskatījums, pieņemšana.

Darbs pie lietojumprogrammas prasa sinhronizēt darbības cilvēkiem ar pilnīgi atšķirīgiem kompetences profiliem. Jums ir jāzina prasmju sadalījums jūsu komandā, lai efektīvi sniegtu vērtību klientiem.

Iesaistīta un sinhronizēta komanda ir galvenais ietaupījumu avots. Šāda veida veiklība prasa optimālu produktu izstrādi.

Šādi saprasts labs komandas sniegums ir ārkārtīgi grūti sasniedzams, jo īpaši laikmetā, kad attālinātais darbs. Uzņēmumiem, kas jau gadiem ilgi ir bijuši "attālināti draudzīgi", šajā jomā ir ievērojamas priekšrocības salīdzinājumā ar tiem, kas bloķēšanas laikā ir bijuši spiesti pielāgot organizāciju un tikai tagad apgūst jaunas saziņas metodes un veidus.

Jaudīgs aprīkojums pirms došanās

Ņemot vērā pieaugošās komunikācijas vajadzības, tādi rīki kā Whimsical, Miro, Mural, Figma un Balsamiq uzrāda iespaidīgu popularitātes pieaugumu.

Protams, bloķēšana un nepieciešamība strādāt attālināti ir veicinājušas lietotāju skaita pieaugumu. Es uzskatu, ka rīka izvēlei ir jāatbilst individuālajām vēlmēm, bet aplūkosim Miro:

Šādu rīku popularizēšana dabiski veicina pašu metodoloģiju popularitātes pieaugumu. Cilvēks, kurš iegādājies Miro, lai strādātu ar personībām, iegūst piekļuvi desmitiem citu veidņu, kas var izrādīties interesantas un pozitīvi ietekmēt komandas ikdienas darbu.

Jums vienmēr ir jāaprīko sevi ar rīkiem, kas racionalizēs informācijas plūsmu projektā. Atvērtība jauniem rīkiem un metodēm ir arī viens no efektīvas darbības pamatiem. produktu izstrāde.

Jūs varat (un jums vajadzētu) būt slinks

Pieredzējuši dizaineri gan saskarnes, gan programmatūras arhitektūra parasti pamana vairākus potenciālos risinājumus, kas būtu jāpārbauda sadarbības sākumā, un efektīvi meklē atbilstošus iedvesmas avotus vai pat gatavus risinājumus tirgū. Labs piemērs ir Material UI ietvars, kas prototipa izstrādes posmā parasti ir droša izvēle..

Dažkārt pietiek ar dažu Behance vai Dribble aplikāciju apskati un iedvesmu, lai izveidotu noskaņu dēli un pēc tam nodotu to izstrādātājam. Šis cilvēks to izmantos, lai izveidotu klikšķināmu prototips ko var piedāvāt pirmajiem lietotājiem, lai apkopotu atsauksmes. Šī organiskā tiekšanās pēc efektīva procesa dizaina domājošiem un apņēmīgiem cilvēkiem ir dabiska.

Ja vēlaties efektīvi piegādāt digitālos produktus, ļaujiet cilvēkiem darīt savu darbu. Jūs zināt, kādu vērtību/pakalpojumu vēlaties sniegt saviem klientiem - ar to pietiek. Kompetenta un labi vadīta projektu komanda vislabāk zinās, kā šo vērtību/pakalpojumu nodrošināt pēc iespējas ātrāk un ar nepieciešamo izmaksu efektivitāti.

Izrādiet uzticību, dalieties atbildībā un sāciet patiesu abpusēju komunikāciju, lai jūsu produkts būs labāk, un no jūsu pleciem tiks noņemts slogs, kas bieži vien izrādās nogurdinošs brauciens dibinātājiem un uzņēmējiem! Uz The Codest, mēs šo principu īstenojam ne tikai projektos, bet arī iekšējos procesos - iespējams, tāpēc mums ir augsts gan klientu, gan darbinieku noturības rādītājs (patiess stāsts, abiem> 90%).

Palutiniet sevi ar nelielu slinkumu, drosmīgi nododiet atbildību un atmetiet lieku darbu, kas nav nepieciešams, lai virzītos uz priekšu - funkcionalitātes, kas būtu "jauki", vienmēr var pagaidīt.

Koncentrējieties uz pareizo atbilžu meklēšanu

Digitālā produkta radīšanas process ir nepārtraukta dažādu perspektīvu, pieredzes un informācijas avotu sadursme - katra šāda sadursme ir saistīta ar risku pieņemt nepareizu dizaina lēmumu.

Laba iekšējā komunikācija samazina šo risku, taču tā ir tikai viena medaļas puse. Jautājums par to, kā uzturēt saikni ar tirgu, vēl nav atbildēts.

Biznesa izlūkošanas, Klientu atbalsta, UX izpētes nodaļas un daudzi citi - tāpat kā... izstrādes komanda, tiem būtu jācenšas nodrošināt minimumu, kas nepieciešams, lai sniegtu konkrētas atbildes uz produkta īpašnieka vai UX komandas uzdotajiem jautājumiem.

Svarīgs ir arī pats zīmola zīmols un zīmola komunikācijas stratēģija. Tās kalpo kvalitatīvu attiecību veidošanai ar klientiem, kas pēc tam izpaužas kā viņu uzticība. Ja vēlaties uzdot jautājumus klientiem, pārliecinieties, ka viņi ir gatavi uz tiem atbildēt. Jūsu balss tonis ir svarīgs.

Ir skaidrs, ka pastāvīgs kontakts ar tirgu ļauj jums noteikt pareizās projekta trajektorijas, lai tas varētu lidot. Mazāk acīmredzams ir fakts, ka par šāda kontakta nepieciešamību ir jādomā jau projekta sākumā, paredzot pareizās kompetences komandā (lai uzdotu pareizos jautājumus un atbildētu uz tiem) un izstrādājot produkta stratēģiju, kas iesaistīs mērķa grupas.

Secinājumi

Ņemot vērā visus iepriekš minētos jautājumus, var novērot vairākas problēmas, kas regulāri parādās projektēšanas procesā:

- pārmērīga orientēšanās uz peļņu un izvairīšanās no neveiksmju izvērtēšanas,

- neprecizitāte un savu kļūdu neredzēšana ar rentgena stariem,

- vajātu perfektu produktu, kas ir jūsu prātā, bet kas nav tas, kas ir vajadzīgs tirgum,

- pārmērīga mācību grāmatu procesu ieviešana - pārmērīga attīstība un pārmērīga projektēšana,

- komandas darba neelastība un darbinieku piespiešana palikt tikai savā specializācijas jomā,

- neefektīva saziņa,

- tendence izgudrot jaunu ratu.

Procesa optimizācija makro mērogā ietver ietaupījumu summu. Lai pienācīgi risinātu iepriekš minētos uzdevumus, ir jāiesaista kolēģi, lai viņi atklāti piedāvātu idejas procesa uzlabošanai.

Dažkārt pietiek mazāk runāt un uzmanīgāk uzklausīt padotos, klientus, partnerus - atbilstoši katra lomai un atbildībai -, lai gūtu panākumus.

Ja jums nav pietiekami daudz, visticamāk, jūs pārāk daudz investējat.. Vai jums ir pārāk daudz naudas?

Aizklājiet un paņemiet savu naudu! Turklāt:

1. Neievietojiet Scrum tikai tāpēc, lai praktizētu Scrum.
2. Pievērsiet lielāku uzmanību procesa nepilnībām.
3. Izvirziet mazākus mērķus, kas ir sasniedzami un izmērāmi īstermiņā, - kopumā ievērojiet minimumu.
4. Dažreiz labs ceļa karte ir pietiekami, lai komandai radītu kopīga mērķa sajūtu un iesaistītu viņus efektīvā darbā šeit un tagad.
5. Izveidojiet labu komandu, lai varētu tai dot nepieciešamo brīvību.
6. Vienmēr apšaubiet pašreizējo rīku komplektu - meklējiet iespējamos uzlabojumus savā darbnīcā.
7. Izstrādājiet procesu no slinka cilvēka perspektīvas - it kā jūs vēlētos darīt pēc iespējas mazāk.

Lasīt vairāk:

CTO izaicinājumi - programmatūras produktu paplašināšana un izaugsme

Kura DB jāizvēlas konkrētam datu tipam jūsu programmatūras projektā