Arendust sisse ostes väldi alatuid trikke

Arenduse sisseostmine on igati mõistlik, ent seda uisa-päisa tehes võib sattuda suuremate probleemide otsa. Miks IT-teenuseid üldse sisse osta (inglisekeelse nimega outsource)? Peamised põhjused on kulude kokkuhoid võrreldes endale uute töötajate palkamisega, võimalus anda vastutus keerukate ülesannete täitmise eest teisele osapoolele või uute kompetentside leidmine.

Laias laastus on tarkvaraarenduse sisseostuks kolm lahendust. Esimene neist on valida riiulitoode ning see enda ettevõtte vajadustega kohandada. Teine tee on osta uue tarkvara loomine sisse selle teenuse pakkumisele keskendunud ettevõttelt (inglise keeles managed service). Kolmas võimalus on kasutada vabakutselisi tarkvaraarendajaid.

Erinevad on ka koostöömudelid: kas lepitakse kokku tunnitasu ja makstakse ülesande täitmiseks kulunud aja järgi, pannakse kohe paika fikseeritud hind või pikaajalise koostöö korral antakse kliendi käsutusse terve tarkvarainseneride meeskond (dedicated team), kes teeb kõik vajalikud arendustööd.

Kui esimese mudeli järgi on kulud raskesti planeeritavad, siis teisel juhul on see üheselt selge ning ka kolmandal juhul samuti kergesti eelarvestatav, kuna tasu moodustab tavaliselt inseneride palgafond ning teenusepakkuja haldustasu.

Järgmisena tuleb selgeks teha, kas teenusepakkuja arendajad peavad asuma tellija kontoris, lähipiirkonnas (näiteks samas linnas või riigis) või võivad paikneda hoopis kaugemal. Näiteks mõnel teisel mandril asuvate programmeerijate kasutamine võib tunduda hinnalt soodsam, kuid projekti elluviimist võivad segada ajavahe, kultuurilised erinevused, mõningane keelebarjäär ning pikemad lennud, sest sageli tuleb ka tellija esindajatel käia arendusmeeskonna juures.

Konkreetse partneri valikul tasub mõelda, kas olulisem on arendajate tehniline kompetents või kogemus teie ärivaldkonnas tarkvaralahenduste loomisel. Vahel võivad ülesande täitmiseks olla vajalikud tehnilised sertifikaadid, mõnel juhul on aga olulisem valdkondlik kogemus.

Kui tellijal on enda ettevõttes olemas arendusprojektide juhtimise kogemus, võib projektijuhiks olla ka tellija esindaja, vastasel juhul peaks kogu protsessi juhtima arendaja. Kindlasti tuleb kontrollida ka teenusepakkuja seniseid kogemusi ja hinnata, kui hästi sujub suhtlus partnerettevõtte esindajatega.

Millest alustada, kui partner on leitud? Esimene samm peaks olema alati paberimajandus ehk koostöölepingu, teenustasemelepingu, konfidentsiaalsuslepingu ja muude vajalike kokkulepete sõlmimine. Võimalusel võiks aluseks võtta tellija koostatud lepinguprojektid.

Vastasel juhul võib juhtuda, et lepingu ülesütlemine või vaidluste lahendamine tehakse võimalikult keerukaks. Näiteks soovis üks Euroopa arendaja vaidluste lahendamist vastavalt Austraalia seadusandlusele sealses kohtus, mis kindlasti ei ole tellijasõbralik lahendus.

Kui dokumendid korras, siis järgmine samm peaks olema mõlemapoolselt protsessi ja selles osalejate defineerimine. Lisaks peamistele kontaktisikutele tuleb kindlasti määrata ka asendajad ning paika panna, kuidas liigub info tellijalt programmeerijateni ning vastupidi. Hea on küsida ka konkreetsete arendajate ja teiste tiimiliikmete CVsid, kontrollida nende referentse ning võimalusel teha nende kõigiga üks telefonikõne.

Enne projekti kallale asumist võib paluda partnerilt proovitööd, mis on tegeliku ülesande mikroversioon. Selleks võiks kasutada pigem väikest arendajate tiimi, kes teevad oma töö kliendi juures kohapeal. Proovitööle peab paari nädala jooksul kindlasti järgnema ülevaade mõlemalt poolelt, mis läks hästi, mis halvasti ja mida konkreetselt tulevikus parandada.

Alati tõstatub küsimus, kes maksab proovitöö eest? Vahel pakuvad arendusettevõtted tasuta proovitöid. Teiseks levinud mudeliks on maksmine siis, kui tellija on proovitööga rahul. Neid võimalusi saab iga tellija kasutada.

Väldi alatu arendaja trikke

Isegi kui proovitöö läks hästi, tuleb olla tähelepanelik, et arenduspartner ei prooviks kasutada mõnda alatut trikki. Esimene neist on varitöötajad, näiteks makstakse viieliikmelise tiimi eest, ehkki töö teeb ära üks kutt. Loomulikult on kõigil varitöötajatel CVd koos referentsidega, nad on Skype´is ja vastavad küsimustele.

Teiseks võidakse töö saamiseks lisada hinnapakkumusse väga hea kogemusega insenere, kes küll töötavad arendusettevõttes, kuid konkreetse projektiga mitte. Sellega on mõneti sarnane olukord, kui esimesed paar nädalat teevad tipud projekti kallal tööd, kuid seejärel asendab neid B- või koguni C-tiim, kes on staaride toimetamist töövarjuna kõrvalt jälginud ning püüdnud selle aja jooksul targaks saada. Paraku aastatepikkust kogemust see siiski kuidagi ei asenda.

Kolmas riugas on väga loominguline juurdemüük ja arveldamine. Näiteks küsitakse lisaraha arendajate internetiühenduse eest või näidatakse arvel, et kõva koodikirjutamine käis ka 31. aprillil, kuigi aprillikuus on 30 päeva. Kui tellija laest võetud lisaarveid maksma ei nõustu, võivad eriti alatud tegelased ähvardada valminud koodi kaaperdamise või taristule ligipääsu piiramisega.

Viimasena tuleb ette ka ülesandepüstituse vaikset muutmist ning loomulikult arendajale soodsas suunas.

Kokkuvõtteks võib öelda, et tarkvaaraarenduse sisseost on mõistlik, kuid peab algama ülesande püstitamisest ning seejärel sobivaima koostöömudeli ja partneri leidmisest. Ohtude vältimiseks tuleb pidevalt koostööd hallata ja tööprotsessi parandada isegi siis, kui projektijuht asub partnerettevõtte poolel.