Sisäinen vs. ulkoistaminen: Ohjelmistokehityksen vertailu
Tutustu sisäisen ja ulkoistetun ohjelmistokehityksen lopulliseen vertailuun, jossa korostuvat kustannustehokkuus, kykyjen saatavuus ja Codestin poikkeukselliset kumppanuusedut.
Yksisarvisten jahtaaminen on pirun kallis harrastus. Joka vuosi startupit syövät miljardeja, jotta vain yksi kymmenistä tai sadoista voi saada miljoonatuloja. Perustajat ja tuotteiden omistajat keräävät rahaa sijoittajilta ja uhraavat itsenäisyytensä valloittaakseen markkinat nopeammin. Loppujen lopuksi he eivät kuitenkaan useimmiten saa kerättyä tarpeeksi varoja. Ehkä oli oikein sanoa "turpa kiinni ja ota rahasi" oikealla hetkellä?
Käteinen hallitsee kaikkea ympärilläni. Edes turkoosimmat organisaatiot eivät voi kieltää sitä. Projektinhallintamenetelmien kehittäminen, prosessien hienosäätö ja optimointi tai työntekijöiden motivointi käynnistyy pohjimmiltaan universaalista rahan tarpeesta. Suunnittelun ketteryyteen liittyy tiettyjä riskejä.
Me kaikki haluamme olla kevyitä ja ketteriä, jotta toimintamme tulos olisi numeroin 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ä.
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 siitä tiimille 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:
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:
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!
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 tarpeen, koska ne eivät tuo todellista markkina-arvoa.
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 koodin tuottamisesta mahdollisimman pienellä 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 - ratkaisujen optimaalinen tekninen laatu on jossain kehitysryhmän määrittelemän vähimmäistason ja budjetin rajoittaman enimmäistason välissä.
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..
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 MVP-vaiheessa ratkaisua, 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.
Tällä tavoin ymmärrettyä hyvää tiimityöskentelyä on erittäin vaikea saavuttaa, erityisesti etätyön aikakaudella. Yrityksillä, jotka ovat olleet "etätyöystävällisiä" jo vuosia, on tällä alalla merkittävä etu verrattuna yrityksiin, jotka ovat joutuneet virittämään organisaation lukituksen aikana ja vasta nyt oppivat uusista viestintämenetelmistä ja -muodoista.
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 työkaluille ja menetelmille on myös yksi tehokkaan tuotekehityksen perusta.
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 kommunikaatiolle, jotta tuotteestasi tulee parempi ja jotta taakka siitä, että sinun on tehtävä kaikki yksin, putoaa hartioiltasi, mikä usein osoittautuu perustajien ja yrittäjien kannalta 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.
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 kehitystiimin, niidenkin pitäisi pyrkiä siihen, että ne pystyvät antamaan 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.
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?
Lue lisää:
CTO:n haasteet - ohjelmistotuotteiden skaalautuminen ja kasvu
Minkä tietokannan valitset ohjelmistoprojektisi tietyntyyppistä dataa varten?