Kuus viisi kuidas sinu ettevõte võiks võita kui arendada sinu järgmist projekti, kui startuppi

Ma olen aidanud manageerida, arendada ja kliendini viia lugematu arvu erinevaid veebipõhiseid projekte. Ja olen nüüdseks juba mõnda aega arutlenud selle üle, miks toote arendus ja kliendile andmise protsess on niivõrd vigane. Ja ometi see võiks olla palju-palju parem.

Tavalise veebiarenduse projekti sammud nägid juba 15-20 aastat tagasi umbes sellised välja (ja paraku näevad tihti ka praegu):

• Klient tuleb agentuuri juurde
• Klient selgitab oma vajadused
• Agentuur pakub oma lahenduse
• Klient võtab pakkumise vastu
• Agentuur alustab tööga
• Töö käigus esitab Klient uusi nõudmisi. Mis tihti muudavad seda, kuidas varasemaid asju tegema peab.
• Projekt ei saa tähtajaks valmis
• Agentuur annab tööd üle ja läheb tihti eelarvega lõhki.

Kui startupid niimoodi asju ajavad on nad tihti pankrotis varsti peale esimest investeeringut. Olen seda ise näinud. Siin on mõned viisid, kuidas asju paremini teha.

1. Süvene sellesse, mis probleemi sa tegelikult lahendad oma arenduse tellimisega.

Kui startupid alustavad soovitatakse neil alati väga täpselt defineerida see probleem mida nad lahendavad - enne arenduse algust. Nad räägivad potentsiaalsete klientidega, et aru saada nende valukohti ja kuidas neid lahendada. Nad püüavad leida selleks kõige efektiivsemad viisid ja aru saada, kui palju raha ja resursse nende toote kasutamine kliendile säästab.

Mida sellest õppida võiksid?

Uuri probleemi ettevõtte sees, Leia probleemi algpõhjus. Kasuta põhjuste tuvastamisel näiteks "Viie miksi" tehnikat. Guugelda seda (5 why's) või küsi minu käest selle kohta. Tihti ei ole parim lahendus mitte uue toote arendus vaid hoopis midagi muud - näiteks protsessi muutus. Mul on selle koha pealt häid lugusid, mida jagada. Ettevõtte sisese inimesena võib nende probleemide ja lahenduste märkamine olla samas keeruline ("Sest kogu aeg on nii tehtud"). Seepärast ongi hea kaasata keegi väljastpoolt ettevõtet.

2. Testi potentsiaalset lahendust enne arendust.

Oletame, et sul on nüüd leitud võimalik lahendus oma probleemile. Mõnikord on sellisel hetkel vaja alustada oma MVP ( Minimaalne sobiv/elujõuline projekt) arendamist. Aga mitte alati. Kuigi olen tehniline inimene, siis meeldib mulle leida probleemidele "low-tech", ehk mitte nii väga tehinilisi lahendusi. Mulle meeldib väga, kui startupid leiavad low-tech lahendusi oma idee testimiseks. Eric Reis räägib mõne sellise loo oma raamatus "The lean startup". Üks lugu on sellest, kuidas tiim testis oma äriideed kõigepealt kõike käsitsi tehes.

Mida sinu ettevõtte siit õppida võiks?

Kas päriselt on ka vaja uut toodet arendada? Juba mõnda aega olen oma äri alustavatel sõpradel soovitanud ettevõttele veebilehe arendamise asemel mõni veebi ehitamise teenus kasutusele võtta. Sellised teenused teevad oma äriidee rahvani viimise ja testimise lihtsaks.

Samuti võiksid ka sina raha kulutada vaid siis, kui see raha tagasi majja toob. Ära torma uut rakendust arendama vaatamata, kas mõni lahendus juba turul ei eksisteeri või kas lahendust ei ole võimalik muul viisil testida.

3. Tee selgeks, mida sinu vajaduste puhul tähendab Minimaalne sobiv/elujõuline toode.

Kui on selge mis probleemi sa lahendad ja mida sul vaja on algab päriselt arendustegevus. Aga enne seda süvenevad tiimid sellesse, mis on absoluutne miinimum, mis käesoleva probleemi lahendab. Erinevad ettevõtted ja messkonnad on selleks välja töötanud erinevaid metoodikaid. Üks rohkem tuntum on Google disaini sprint.

Selliste harjutuste käigus kirjutab meeskond üles projekti funktsionaalsuse kirjeldades neid kasutajalugudena. Neid lugusid saab lahendada, testida, kustutada või ümber kirjutada - kõike selleks, et paremini aru saada, mis teile sobib. Mõnikord on seda tööd tegevates meeskondades kaastatud ka disainerid et prototüüpida kasutaliideseid. Disainerid aitavad paremini visualiseerida seda, mis toimib ja mis mitte.

Tulemuseks on nimekiri kasutajaludest, millest kõik ühtmoodi aru saavad.

Mida sellest õppida?

Sellised töökojad ei aita ainult paremini aru saada, mida vaja on arendada vaid genereerivad ka dokumentatsiooni, mis võib olla projekti dokumentatsiooni alge või sisend hinnapakkumiste küsimiseks. Enamik arendusettevõtteid saab kasutajalugudest väga hästi aru ja oskab nende põhjal sulle anda hinnapakkumise, mis on võrreldav teiste sarnastega. Üks suurimaid probleeme, mis agentuuridel on, on see, et kuidas saab klient omavahel võrrelda hinnapakkumisi, mis ei ole tehtnud sama info pealt. See probleem tekib, sest tavaliselt teeb iga agentuur kliendiga läbi oma küsimuste protsessi ja genereerib selle pealt hinnapakkumise - mis tegelikult ei ole teise agentuuri omaga võrreldav.

Selline protsess ei ole hea ei kliendi ega agentuuri jaoks. Sest kõigi agentuuride esitatud küsimuste tulemusena tekib kliendil mingi pilt, mida ta saab. Tegelikkuses ei pruugi see nii aga olla, sest kliendi ettekujutus ei ole sama, mis agentuuri ettekujutus. Sellest tulevad probleemid, kus klient mingi hetk küsib või ütleb, et " Ma arvasin, et te selle ka teete ".

Seetõttu on parem investeering teha projektile korralik analüüs kas maja siseselt või kasutades välist konsultanti ja teha korralik kasutajalugusid sisaldav dokument. Selline investeering toob sulle kohe raha tagasi mitmel viisil:

• Sul on ees arenduse "roadmap". Sa saad selle abil kenasti jälgida, mis on töös ja mis veel ei ole. Saad paremini aru, kui palju projekti lõpuni veel on vaja teha.
• Sul on olemas ka nimekiri asjadest, mida testida. Kirja pandud kasutajalugude põhjal on väga lihtne arendajal teste kirjutada aga ka sinul testida ja proovida, kuidas süsteem töötab.
• Sul on viis, kuidas jälgida mõtteid või ideid, mis tekivad arenduse käigus. Kogu aeg on olemas ülevaade uutest vajadustest ja nendest, mis olid juba hinnapakkumises.

4. Arenda faaside kaupa.

Erinevus alustava startupi ja tegutseva ettevõtte vahel on tihti selles, et startupi säilima jäämine ja edukus on märksa ebakindlamad. Seetõttu on startupil mõistlik iga üles kerkiv eeldus testida. Oletame, et nad eeldavad, et mingi arendus või muudatus annab neile rohkem käivet või pikendab kliendi "eluiga". Sellisel puhul võtab startup tihti selle oletuse endale testimiseks seades eesmärgi ja selle eelduse ära testida nii hästi, kui võimalik. Eesmärk kas täitub või ei aga ettevõte õpib sellest kinldasti alati. Igal juhul tähendab see ettevõtte jaoks seda, et nad säästsid aega või raha läbi selle, et nad ei arendanud midagi, mis ei oleks tööle hakanud.

Mida ettevõtted sellest õppida võiks?

Ehita MVP. Ära alusta suurarendusega, kui seda vaja pole. Faaside kaupa arendamine aitab sul arenduspartnerit tundma õppida aga peamiselt säästab sulle aega ja raha. Mõtle, kumb oleks hullem:

• Varakult teada saada, et sinu projekt ei too sulle loodetud edu ning seetõttu varakult projektile lõpu tegemine. Või
• Suure projekti lõpuni arendamine saamaks teada, et kulutasid palju raha ja aega millegi peale, mis ei toimi.

Faaside kaupa arendamise juures on palju kasulikku:

• Sul on võimalik projekti progressi paremini hinnata
• Sa tuvastad probleeme kiiremini ja jõuad neile kiiremini reageerida
• Sul on võimalik vajaduse korral arenduspartnerit vahetada aga endiselt edasi minna toimiva projektiga
• Sul on võimalik kiiremini hallata ja muuta prioriteete arendusprotsessi käigus.

5. Vali õiged tehnoloogiad

Üks olulisemaid otsuseid startupi jaoks on valida õiged tehnoloogiad. Nii mõnigi startup on saanud hiljem oma tehnoloogilisi valikuid kahetsema.

Probleeme, mis tehnoloogiavalikust tekkida võivad on palju. Startupi jaoks on neist olulisemad see, et arendus on aeglane, keeruline või on vaja kaasata arendajaid, keda on turult keeruline leida.

Mida siit õppida?

Vali agentuurid, kes kasutavad tehnoloogiaid, mis on laialdaselt kasutusel. Sellised keeled ja tööriistad teevad arenduse lihtsamaks ja kiiremaks aga teevad ka sulle vajadusel partneri vahetuse lihtsamaks. Kui tööriistad on laialdaselt kasutusel, siis võid kindel olla, et neil on hea tugi, mis teeb nende kasutamisel arenduse kiiremaks ja efektiivsemaks.

6. Investeeri kvaliteeti

Mida startupid tihti teevad on see, et nad püüavad arendada võimalikult kiiresti ja jätavad kasutamata koodi kvaliteedi tööriistad ja testimise. Miks see juhtub on tihti seepärast, et arendusmeeskonnal ei ole piisavalt kogemust vastu panna juhtkonna ja müügi poolt tulevale survele kiirelt turule jõuda ja turgu haarata. Mida arendajad ei räägi sellisel puhul on see, et kiirustamise tulemusel tekib järjest suurenev vajadus asju ringi kirjutada või vigu parandada. Lõpuks hakkab nende tööde tegemine väga oluliselt mõjutama seda, kui kiiresti jõuab ettevõte uusi featuure välja arendada. Kui äripool küsib, et "miks see nii kaua aega võtab", siis vastuseks on alati see, et koodi kvaliteeti ja selle hoidmiseks vajalikke metoodikaid eirati projekti alguses.

Mida tellijad sellest õppima peaks

Aktsepteeri, et projekti koodi kvaliteet on projekti eluea vaatevinklist esmatähtis. Kui algne projekt oli edukas, siis on tõenäoliselt mingi hetk vaja juurde arendada uusi võimalusi. Projekti alguses koodi kvaliteedi ja tehnilise võla eiramine tähendab hiljem sedasi, et uued arendused on ajakulukamad. Täpselt nagu läheb labidas vihma käes rooste ja teeb kaevamise tüütumaks, hakkab ka kood koguma "tehnilist võlga".

Seega kui algne hinnapakkumine võib mõnel ettevõttel olla odavam võib see tähendada sinu jaoks seda, et tulevased arendused on keerulised ja projekt on täis vigu.

Kokkuvõtteks

Rohkem teadmisi on alati kasuks. Üks takistusi, mida tehnilised inimesed tihti kohtavad on ülalkirjeldatu kommunikeerimine oma klientidele. Mõned agentuurid on selles väga head. Tööta koos nendega. Usalda neid. Kui sa kahtled, millisega edasi minna, siis räägi kõigepealt minuga.