Piilotetut kustannukset ja todellinen ketteryys tuotekehitysprosessissa

Wu-Tang Clan oli oikeassa

Käteinen hallitsee kaikkea ympärilläni. Edes kaikkein turkoosimmat organisaatiot eivät voi kieltää sitä. Kehitys projekti johtamismenetelmät, prosessien virittäminen ja optimointi tai työntekijöiden motivointi perustuvat pohjimmiltaan yleismaailmalliseen rahan tarpeeseen. Suunnittelun ketteryyteen liittyy tiettyjä riskejä.

Me kaikki haluamme olla laihoja ja ketterä jotta toimintamme tulos olisi lukumäärissä mitattuna mahdollisimman korkea. Vaikka keskitämme suurimman osan energiastamme tappioiden vähentämiseen, otamme lopulta huomioon tuotettujen säästöjen ansiosta kasvaneen voiton.

Nämä säästöt kuuluvat samaan taskuun muiden tekijöiden kanssa ja jäävät vain kaikkein uteliaimpien saataville. Tällä tavoin menetämme fokuksen ja jätämme tahattomasti käyttämättä paljon arvokasta tietoa ja lopulta älykkyyttä.

Epäonnistumisista saadut kokemukset

Omista virheistä oppiminen on erityisen hyödyllinen (joskin kallis) taito, mutta organisaatiokulttuuri ja tähän kykyyn liittyvä diplomatia eivät aina auta. Piilotamme usein talouden kielteisiä vaikutuksia "savuverholla". Kun sijoittaja huutaa "Menetin rahani!", johtaja viestii sen joukkue sanomalla "meidän pitäisi olla tehokkaampia", ja me kaikki etsimme oletusarvoisesti uusia ratkaisuja ja parannuksia - sen sijaan, että katsoisimme taaksepäin, etsimme jatkuvasti tapoja edetä eteenpäin.

Samalla tappiot ovat usein avain oikeiden johtopäätösten tekemiseen. Jos käymme läpi tietyt prosessin virtausvaiheet ilman asianmukaista harkintaa, seuraavat ratkaisut ovat todennäköisesti saastuneet samoista virheistä.

Esimerkki: 

Pieni tiimi, joka koostuu vanhemmista JS-kehittäjistä, ei pysty tarjoamaan toiminnallisuutta odotetussa ajassa. Sijoittaja, joka haluaa nopeuttaa kehitystä, määrää palkata uuden ohjelmoijan. Uuden henkilön tuominen projektiin häiritsee tiimiä, mikä hidastaa projektin etenemistä entisestään.

Jos sijoittaja ymmärtäisi paremmin syyt joukkueen tehottomuuteen, hän päättelisi, että se käyttää potentiaaliaan vain 60-70%:ssä. Paremmat laitteet ja muutama työpäivä työn automatisointiin ratkaisisivat ongelman.

Valitettavasti hänen on nyt maksettava toiselle kehittäjälle, joka työskentelee samalla laitteistolla, ja myös hänen tehokkuutensa on 60-70%.

Ratkaisu A:

• Tiimi (2 x senior JS dev): $20k / kk
• Cloud palvelut: kuukaudessa
• Uusi laitteisto kehittäjille: $10k

Tästä lähtien hankkeen kustannukset ovat $20,200 / kk.

Kokonaismenot 12 kuukauden aikana: 12 * 20 200 + 10 000 = $252 400: 12 * 20 200 + 10 000 = $252 400

Ratkaisu B:

• Tiimi (2 x senior JS dev): $20k / kk
• Uusi kehittäjä (1 x vanhempi JS-kehittäjä): $10k / kk.

Tästä lähtien hankkeen kustannukset: $30,000 / kuukausi

Kokonaismenot 12 kuukauden aikana: = $360,000 EUROA.

Kaksi kehittäjää, jotka työskentelevät 100%:llä, tekevät suunnilleen saman kuin kolme kehittäjää, jotka työskentelevät 60-70%:llä. Sijoittaja maksaa samasta käsittelykapasiteetista yli $ 100 000 euroa enemmän vuodessa virheellisen suunnittelupäätöksen vuoksi!

Täydellisen tuotteen rakentaminen on kuin jäniksen jahtaamista.

Prosessin ketteryys ei välttämättä tarkoita 100%-testien kattavuuden tavoittelua tai suorituskykyennätyksen rikkomista. Vaikka nämä mittarit antavat yleiskuvan projektin teknisestä tilasta, ne ovat loppuasiakkaan näkökulmasta niin merkityksettömiä, että niiden saattaminen ihanteelliseen tilaan aidosti ketterässä prosessissa ei ole välttämätöntä, koska ne eivät tuo todellista hyötyä. markkinat arvo.

Täydellisten teknisten ratkaisujen kehittäminen vaatii paljon tiimin sitoutumista ja paljon laajempaa viestintää. Tämän seurauksena korjaukset toimivat hitaammin ja hankkeesta tulee raskas ylikehittämisen vuoksi.

Ketterässä kehityksessä on kyse toimivan koodi minimaalisella vaivalla. Koodin testaaminen on epäilemättä hyvä käytäntö, ja testit kertovat paljon koodin toiminnasta, mutta niitä ei pitäisi tehdä vain niiden tekemisen ja sillä kehuskelun vuoksi. kehitystiimi ja enimmäismäärä, jota budjetti rajoittaa.

Täydellisyys ei lopulta johda mihinkään. Mielenkiintoista on, että jopa turvallisuuskysymys on tämän säännön alainen - teoriassa mikä tahansa järjestelmä voidaan murtaa. Edellä mainitun kehityksen vähimmäistason on kuitenkin oltava vastaavasti korkeampi, ja sen on vastattava koodin virheiden mahdollisten seurausten painoa, laajuutta ja kustannuksia. Usein sen sijaan, että kirjoitetaan kirjautumismoduuli tyhjästä, jota rasittaa aina suuri virheriski ja tietoturva-aukkojen tuominen, on parempi käyttää esimerkiksi "Kirjaudu sisään Googlen kanssa" -painiketta, jonka asianmukainen toteutus on suhteellisen nopea ja turvallinen.

Niin kauan kuin tavoitteena on lyhyt aika markkinoille saattamiseen, liian kunnianhimoiset oletukset ovat haitallisia. Näennäisen täydellisessä prosessissa liiallinen innostus voi olla resurssien tuhlausta..

On hyvä tietää kaikkea jostakin ja jotain kaikesta...

Käyttäjäkeskeinen suunnittelu on siistiä. Ihmiskeskeinen yhteistyö on tärkeämpää. Kun tiimi kommunikoi samalla aaltopituudella, se voi spontaanisti vähentää mahdollisia tappioita.

UX-suunnittelija, joka on ajan tasalla frontend-teknologioista, ei ehdota ratkaisua, jonka MVP vaihe, joka vie kohtuuttomasti aikaa toteutusvaiheessa.

Käytettävyysheuristiikat tunteva frontend-kehittäjä pystyy mukauttamaan käyttöliittymän tiettyyn näytön resoluutioon ilman UX-suunnittelijan osallistumista - pikakorjaus, esikatselu, hyväksyntä.

Sovelluksen työstäminen edellyttää täysin eri osaamisprofiileja omaavien ihmisten toiminnan synkronointia. Sinun on tiedettävä osaamisen jakautuminen tiimissäsi, jotta voit tuottaa tehokkaasti arvoa asiakkaillesi.

Sitoutunut ja synkronoitu tiimi on keskeinen säästöjen tuottaja. Tällainen ketteryys edellyttää optimaalista tuotekehitystä.

Tällä tavoin ymmärrettyä hyvää tiimityöskentelyä on erittäin vaikea saavuttaa, erityisesti aikakautena, jolloin etätyö. Yrityksillä, jotka ovat olleet "etäyhteysystävällisiä" jo vuosia, on tällä alalla merkittävä etu verrattuna yrityksiin, jotka ovat joutuneet virittämään organisaation lukituksen aikana ja jotka vasta nyt oppivat uusista viestintämenetelmistä ja -muodoista.

Tehokkaat laitteet ennen kuin lähdet menemään

Kasvavien viestintätarpeiden yhteydessä Whimsicalin, Miron, Muralin, Figman ja Balsamiqin kaltaiset työkalut ovat kasvattaneet suosiotaan merkittävästi.

Lukituksella ja etätyöskentelyn tarpeella on varmasti ollut oma osuutensa käyttäjien määrän kasvuun. Uskon, että työkalun valinnan pitäisi vastata yksilöllisiä mieltymyksiä, mutta katsotaanpa nyt Miroa:

Tällaisten työkalujen yleistyminen johtaa luonnollisesti myös itse menetelmien suosion kasvuun. Joku, joka on ostanut Miron työskentelemään persoonien parissa, saa käyttöönsä kymmeniä muita malleja, jotka voivat osoittautua kiinnostaviksi ja vaikuttaa myönteisesti tiimin päivittäiseen työhön.

Sinun tulisi aina varustaa itsesi työkaluilla, jotka virtaviivaistavat tiedonkulkua projektissa. Avoimuus uusille välineille ja menetelmille on myös yksi tehokkaan työn perusta. tuotekehitys.

Voit (ja sinun pitäisi) olla laiska

Sekä käyttöliittymän että ohjelmistoarkkitehtuurin kokeneet suunnittelijat huomaavat yleensä useita mahdollisia ratkaisuja, jotka olisi tarkistettava yhteistyön alussa, ja etsivät tehokkaasti sopivia inspiraatioita tai jopa valmiita ratkaisuja markkinoilta. Hyvä esimerkki on Material UI -puitteisto, joka on yleensä varma valinta prototyyppivaiheessa..

Joskus riittää, että tarkastelet muutamia toteutuksia Behancessa tai Dribblessä ja käytät inspiraatiota tunnelmataulun laatimiseen ja välität sen sitten kehittäjälle. Tämä kokoaa sen pohjalta klikattavan prototyypin, joka voidaan esitellä varhaisille käyttäjille palautteen keräämiseksi. Tämä orgaaninen pyrkimys tehokkaaseen prosessiin muotoiluhenkisissä ja sitoutuneissa ihmisissä on luonnollista.

Jos haluat toimittaa digitaalisia tuotteita tehokkaasti, sinun on annettava ihmisten tehdä työnsä. Tiedät, mitä arvoa/palvelua haluat tarjota asiakkaillesi - se riittää. Osaava ja hyvin johdettu projektiryhmä tietää parhaiten, miten tämä arvo/palvelu voidaan toimittaa mahdollisimman nopeasti ja kustannustehokkaasti.

Osoita luottamusta, jaa vastuu ja avaudu aidolle kaksisuuntaiselle viestinnälle, jotta sinun tuote on parempi ja taakka siitä, että kaikki on tehtävä itse, on poissa hartioiltasi, mikä usein osoittautuu perustajille ja yrittäjille rasittavaksi ajeluksi! Osoitteessa Codest, toteutamme tätä periaatetta paitsi projekteissa myös sisäisissä prosesseissa - luultavasti siksi meillä on korkea sitoutumisaste sekä asiakkaiden että työntekijöiden keskuudessa (tositarina, molemmat> 90%).

Hemmottele itseäsi hieman laiskuudella, siirrä rohkeasti vastuuta ja päästä irti turhasta työstä, joka ei ole välttämätöntä edistymisen kannalta - toiminnallisuudet, jotka olisivat "kiva saada", voivat aina odottaa.

Keskity oikeiden vastausten löytämiseen

Digitaalisen tuotteen luomisprosessi on erilaisten näkökulmien, kokemusten ja tietolähteiden jatkuva törmäys - jokaisessa tällaisessa törmäyksessä on riski tehdä väärä suunnittelupäätös.

Hyvä sisäinen viestintä vähentää tätä riskiä, mutta se on vain kolikon toinen puoli. Kysymys siitä, miten pidetään yhteyttä markkinoihin, on vielä ratkaisematta.

Business Intelligence, asiakastuki, UX-tutkimusosastot ja monet muut - aivan kuten myös kehitystiimi, niiden olisi pyrittävä siihen, että ne tarjoavat mahdollisimman vähän vastauksia tuoteomistajan tai UX-tiimin esittämiin kysymyksiin.

Myös itse brändin luominen ja brändiviestintästrategia ovat tärkeitä. Niiden avulla rakennetaan laadullinen suhde asiakkaisiin, mikä puolestaan johtaa heidän sitoutumiseensa. Jos haluat esittää asiakkaille kysymyksiä, sinun on varmistettava, että he ovat halukkaita vastaamaan näihin kysymyksiin. Äänensävylläsi on merkitystä.

On varmaa, että kun olet jatkuvasti yhteydessä markkinoihin, voit määritellä hankkeelle oikeat reitit, jotta se lentää. Vähemmän ilmeistä on se, että tämän yhteydenpidon tarve olisi otettava huomioon heti hankkeen alussa, jotta voidaan ennakoida tiimin oikeanlaista osaamista (oikeiden kysymysten esittäminen ja niihin vastaaminen) ja laatia tuotestrategia, joka ottaa kohderyhmät mukaan.

Päätelmät

Kun otetaan huomioon kaikki edellä mainitut seikat, voidaan havaita useita ongelmia, joita esiintyy säännöllisesti suunnitteluprosessissa:

- liiallinen voittokeskeisyys ja epäonnistumisten välttäminen,

- epätarkkuus ja se, ettei omia virheitä röntgenöidä,

- jahdata täydellistä tuotetta, joka on mielessäsi, mutta jota markkinat eivät tarvitse,

- oppikirjaprosessien liian innokas toteuttaminen - liiallinen kehittäminen ja suunnittelu,

- tiimityön joustamattomuus ja työntekijöiden pakottaminen pysymään vain omalla erikoisalallaan,

- tehoton viestintä,

- taipumus keksiä pyörä uudelleen.

Prosessien optimointi makrotasolla sisältää säästöjen summan. Jotta voit kohdata edellä mainitut haasteet asianmukaisesti, sinun on otettava kollegasi mukaan, jotta he esittävät avoimesti ideoita prosessin parantamiseksi.

Joskus riittää, että puhut vähemmän ja kuuntelet tarkemmin alaisia, asiakkaita ja yhteistyökumppaneita - kunkin roolin ja vastuun mukaan - jotta saavutat menestystä.

Kun et ole aivan tarpeeksi, olet todennäköisesti yli-investoinut.. Onko sinulla liikaa rahaa?

Ole hiljaa ja ota rahasi! Ja sitä paitsi:

1. Älä ota Scrumia käyttöön vain harjoitellaksesi Scrumia.
2. Kiinnitä enemmän huomiota prosessissa tapahtuviin virheisiin.
3. Aseta pienempiä tavoitteita, jotka ovat saavutettavissa ja mitattavissa lyhyellä aikavälillä - yleisesti ottaen pidä kiinni vähimmäistavoitteista.
4. Joskus hyvä tiekartta riittää antamaan ryhmälle tunteen yhteisestä tavoitteesta ja sitouttamaan heidät tehokkaaseen työhön tässä ja nyt.
5. Rakenna hyvä tiimi, jotta voit antaa sille sen tarvitseman vapauden.
6. Kyseenalaista aina nykyiset työkalut - etsi työpajassasi mahdollisia parannuksia.
7. Suunnittele prosessi laiskan ihmisen näkökulmasta - ikään kuin haluaisit tehdä mahdollisimman vähän.

Lue lisää:

CTO:n haasteet - ohjelmistotuotteiden skaalautuminen ja kasvu

Minkä tietokannan valitset ohjelmistoprojektisi tietyntyyppistä dataa varten?