Solutional
Ärikriitilise süsteemi arenduspartneri valimine ei ole sama mis vahetatava tööjõu ostmine. Partner mõjutab arhitektuuri, tegevusriski, tarnekiirust ja seda, kui lihtsalt saab teie organisatsioon hiljem suunda muuta.
Viimistletud esitlus ja madal hinnakiri räägivad nende tulemuste kohta vähe. Kasulik hindamine keskendub sellele, kuidas võimalik partner mõtleb, suhtleb, tarnib ja reageerib olukorras, kus tegelikkus erineb plaanitust.
Alustage probleemist, mitte tehnoloogiate nimekirjast
Usaldusväärne partner püüab kõigepealt mõista äriprotsessi, kasutajaid, piiranguid, riske ja soovitud tulemust. Olge ettevaatlik, kui pakkuja soovitab platvormi, pilvearhitektuuri või meeskonna ülesehitust enne piisavate küsimuste esitamist.
Paluge kandidaadil selgitada:
- probleemi oma sõnadega;
- milliseid eeldusi ta teeb;
- millised on suurimad teadmatused;
- mida tuleks esimesena valideerida;
- millised osad tekitavad tõenäoliselt tarneriski;
- milline võiks olla esimene kasulik toodangueesmärk.
Nende küsimuste kvaliteet on sageli informatiivsem kui esialgne lahendusettepanek.
Hinnake inimesi, kes tegelikult töö ära teevad
Müügivestlusi juhivad sageli inimesed, kes pärast lepingu sõlmimist kaovad. Keerulise tarkvara puhul kohtuge inseneride ja tarnete eest vastutajatega, kes hakkavad süsteemiga päriselt tegelema.
Selgitage välja:
- kes teeb tehnilisi otsuseid;
- kuidas kogenud insenerid töösse jäävad;
- kas suhtlus läbib mitu juhtimistasandit;
- kuidas jagunevad kliendi ja partneri vastutused;
- mis juhtub võtmeisiku puudumisel;
- kas pakutud inimesed on lahendanud võrreldava keerukusega probleeme.
Asjakohane kogemus ei pea tähendama täpselt sama valdkonda või tehnoloogiat. See võib tähendada sarnase keerukuse kogemust: reguleeritud protsessid, riskantsed migratsioonid, kõrge käideldavus, paljud integratsioonid või pika elueaga süsteemid.
Küsige tõendeid, mitte üldisi väiteid
Väiteid nagu "hindame kvaliteeti" või "töötame agiilselt" ei saa näideteta hinnata.
Küsige juhtumiuuringut, mis näitab:
- algset äriprobleemi;
- piiranguid ja keerulisi otsuseid;
- partneri konkreetset rolli;
- mis tarne käigus muutus;
- kuidas riske juhiti;
- mis jõudis toodangusse;
- kuidas tulemust mõõdeti;
- mida klient koostöö kohta ütleb.
Kõige kasulikumad juhtumiuuringud sisaldavad kompromisse ja õppetunde, mitte ainult edulugu.
Uurige, kuidas kvaliteet tarne sisse ehitatakse
Kvaliteet ei tohiks olla lõpus toimuv testimisetapp. Küsige, kuidas meeskond ennetab nõrku otsuseid ja leiab probleemid varakult.
Olulised teemad on näiteks:
- automaattestide strateegia;
- koodi- ja disainiülevaatus;
- pidev integratsioon ja juurutamine;
- jälgitavus ja intsidentidele reageerimine;
- turvapraktikad;
- sõltuvuste ja uuenduste haldus;
- töö valmimise definitsioon;
- tehnilise võla otsused;
- dokumentatsioon ja teadmiste jagamine.
Partner peab oskama selgitada, kuidas need praktikad muutuvad riski järgi. Maksesüsteem ja sisemine prototüüp ei vaja samu kontrollimehhanisme.
Mõistke ärimudelit
Madalaim tunnihind võib anda kõrgeima kogukulu, kui projekt nõuab liigset koordineerimist, ümbertegemist või järelevalvet.
Võrrelge pakkumisi järgmiste küsimustega:
- Mis on hinnas?
- Kes tegeleb analüüsi, testimise, juurutuse ja koordineerimisega?
- Kuidas arutatakse planeerimata tööd?
- Kui kiiresti saab prioriteete muuta?
- Millist infot saame edenemise ja kulu kohta?
- Mis juhtub, kui algne ulatus osutub valeks?
- Kas saame pärast väikest esimest etappi lõpetada?
Hea partner teeb ärilise ebakindluse nähtavaks ega peida seda optimistlike eelduste taha.
Testige koostööd päris probleemiga
Piiratud tasuline eelanalüüs või piloot annab sageli rohkem infot kui pikk hankeküsimustik. Andke meeskonnale lahendamiseks probleem ja jälgige, kuidas nad töötavad.
Vaadake, kas nad:
- esitavad ebamugavaid, kuid vajalikke küsimusi;
- kaasavad teie valdkonnaeksperte;
- teevad eeldused nähtavaks;
- pakuvad lühimat teed tulemuseni;
- edastavad halbu uudiseid varakult;
- jätavad maha kasulikud artefaktid;
- parandavad teie arusaamist juba enne teostust.
Piloodi tulemus peaks olema otsus, mitte lihtsalt prototüüp. Teil peaks olema selgem arusaam, mida ehitada, miks, kuidas ja milliste riskidega.
Kontrollige omandit ja lahkumistingimusi
Terve partnerlus ei tohiks sõltuda lukustamisest. Enne lepingu sõlmimist täpsustage:
- kellele kuuluvad lähtekood ja intellektuaalne omand;
- kus asuvad koodihoidlad ja taristukontod;
- kuidas hallatakse ligipääse;
- millist dokumentatsiooni hoitakse;
- kuidas teine meeskond saaks töö üle võtta;
- kuidas saab andmeid eksportida;
- millised kolmanda osapoole litsentsid loovad piiranguid;
- millist abi antakse koostöö lõpus.
Oma väärtuses kindel partner ei vaja kliendi hoidmiseks tehnilist vangistust.
Märgake ohumärke
Levinud ohumärgid on:
- lahendus pakutakse enne probleemi mõistmist;
- hindamises osalevad ainult müügiinimesed;
- meeskond koosneb peamiselt inimestest, kes hakkavad teie projekti najal õppima;
- lubatakse fikseeritud ulatust, eelarvet ja tähtaega hoolimata suurest teadmatusest;
- kvaliteet tähendab ainult lõpus tehtavat käsitsi testimist;
- ebaõnnestumistest või rasketest projektidest ei taheta rääkida;
- alltöövõtt on läbipaistmatu;
- sõltutakse ühest nimetatud eksperdist;
- piloodist toodanguni puudub selge plaan;
- üleandmisplaan ei ole usutav.
Üks ohumärk ei välista alati pakkujat, kuid mitu koos viitavad struktuursele riskile.
Valige vajaliku suhte järgi
Mõni tellija vajab ajutist arendusvõimekust. Teine vajab partnerit, kes suudab nõudeid vaidlustada, tehnilise tulemuse eest vastutada ja süsteemiga aastaid kaasas käia. Määratlege enne ettevõtete võrdlemist, millist suhet tegelikult vajate.
Ärikriitilise tarkvara puhul ei ole tugevaim partner tavaliselt see, kes kõige kiiremini nõustub. Tugevaim on see, kes aitab teha paremaid otsuseid, toob riskid vara nähtavale, loob ühise arusaama ja oskab selgitada, kuidas tänased valikud mõjutavad homset kulu.
