Ketterän ohjelmistokehityksen julistuksessa (Manifesto for Agile Software Development) arvostetaan yhteistyötä enemmän kuin sopimusneuvotteluita. Ohjelmistokehityshankkeissa hankitaan usein kalliita järjestelmiä. Tällöin asiakas törmää usein tilanteeseen, jossa yhteistyön sujuvuus on hyvä varmistaa myös tarjouskilpailun jälkeen ja osa näistäkin asioista kannattaa kirjata osaksi sopimusta.
Asiakkaalla tulisi olla aina mahdollisuus ostaa palvelunsa siltä toimittajalta ja/tai tiimiltä, joka työhön parhaiten soveltuu. Asiakkaalla tulisi olla kaikki avaimet kädessään ja täysi riippumattomuus toimittajista.
Usein asiakas on toimittajan armoilla ja pelaa toimittajan pelisääntöjen mukaan – tilanne tulisi olla päinvastoin! Ohessa listaan muutaman asian mikä helpottaa asiakkaiden elämää toimittajien kanssa.
- Säilytä kaikki tekijänoikeudet itselläsi
Säilytä kaikki oikeudet koodiin, konseptiin, suunnitelmiin, dokumentaatioon ja sisältöön itselläsi. Tämä on elinehto sille, että voit ottaa sovelluksen ja viedä kehityksen haluamallesi taholle. - Tarjoa avoimia rajapintoja
Älä keksi pyörää uudelleen vaan tarjoa järjestelmääsi järkevät rajapinnat, jotta sovellukseesi voidaan helposti kytkeytyä. Sovelluksesi arvo kasvaa kun voit lähtökohtaisesti mainostaa, että “meidän sovellus toimii hyvin yhteen myös näiden sovellusten kanssa”. Avoin rajapinta tarkoittaa myös sitä, että parhaassa tapauksessa joku toinen hoitaa kytkeytymistyön puolestasi. - Hanki toinen mielipide
Ohjelmistoprojektit ovat usein hyvin haastavia ja monimutkaisia. Toinen mielipide toiselta toimittajalta varmistaa, että ensimmäinen “diagnoosi” on oikea tapa edetä eikä toimittajasi naruta sinua. Voit kysyä mielipiteitä esimerkiksi arkkitehtuuriin, tietoturvaan ja jatkokehitysmahdollisuuksiin. Toinen mielipide selkeyttää nykytilannetta ja auttaa hahmottamaan tulevaisuuden kehityssuuntia. - Vältä design-velkaa
Design-velka (tai tekninen velka) tarkoittaa velkaa, jota otetaan kun tehdään huonoja arkkitehtuurillisia ratkaisuja. Design-velka, kuten mikä tahansa muukin velka, tulee maksettavaksi vasta tulevissa kehityskustannuksissa. Design-velan arviomiseen on olemassa myös työkaluja ja metriikkaa. Hyvä ohjelmistokehitystiimi ymmärtää design-velan ja tietää keinot sen välttämiseen. Halutessasi voit hankkia myös toisen mielipideen design-velan määrästä. - Dokumentoi prosessit
Huolimatta siitä, että toimiva ohjelmisto on paljon tärkeämpi kuin massiivinen määrä dokumentaatiota, tiettyjen asioiden dokumentointi on järkevää. Vaadi asiakkaana seuraavien asioiden dokumentointia:- Mitä tietoa järjestelmä pitää sisällään ja kuinka tieto tallennetaan. Yleensä arvokkain asia mitä sovellukset sisältävät on niiden sisältämä tieto ja tietokanta. Asiakasrekisterin päätyminen kilpailijoille tai käyttäjätietojen vuotaminen voi tarkoittaa isoja taloudellisia vahinkoja. Ymmärrä aina vakavuus pahimman tilanteen varalta
- Ohjeet käyttöönotosta ja uuden version käyttöönotosta (deployment). Toimittajalta kannattaa vaatia myös käyttöönoton automatisointia (kehityssyklin nopeuttamisen vuoksi)
- Kuinka järjestelmää päivitetään ja tieto kuinka iso päivitystyö on
- Tiedot käytetyistä ulkoisista moduuleista ja/tai komponenteista.
