Särähdyksiä ja testattavia oletuksia

Kuuntelin eilen ihmisiä Tampere Goes Agile -tapahtumassa ja mietin. Useammassakin kohdassa testaajan korvaani särehteli se mitä luulin kuulevani: pohdintaa siitä miten "perinteisistä testaajista" saataisiin tehtyä testauksen automatisoijia, vaikka sellaisia jotka osaa "copypasteta keywordeja"; miten näistä saataisiin tehtyä määrittelijöitä - yleensäkin jotain mitä he eivät nyt ole.

Toinen särähtelevä viesti oli ajatus siitä että jos testaajat olisivat mukana tekemässä määrittelyä esimerkein, he pystyisivät ennakkoon kertomaan kaikki ne asiat jotka kertoisivat havaintoina testatessaan. Kuunnellessani tämän suunnan viestejä muistin, miksi ensi kertaa koin kykeneväni itse hyväksymään tätä kehitysmallia paremmin kun se sai Gojko Adjicin tekstien lueskelun myötä oikean nimensä: määrittely esimerkein. Ei tämä mitään hyväksymistestiohjattua kehitystä ole, korkeintaan esimerkkiohjattua. Ja esimerkit eivät ole kaikki mitä hyväksyntään vaaditaan. Tämä usko esimerkkien täydellisyyteen henki jotenkin monen toteuttajataustaisen agilistin viesteissä ja onhan se kivan vapauttava ajatus että toteutetaan mitä on määritelty ja muu jää muualle.

Juttelin pitkään erään arvostamani kolleegaan kanssa. Keskustelu muistutti, että osana kokeilujani tehdäksemme hyvää määrittelyä esimerkein, minulla on hypoteesi testattavana. Minä uskon, että ohjelmisto puhuu minulle testaajana, olen oppinut kuuntelemaan sitä tavoilla joita on välillä vaikea eritelläkin. Se vihjaa mihin kiinnittää huomiota, antaa vinkkejä siitä kuinka moneen kertaan asiaa kannattaa eri silmälasein tarkastella. Esitän sille kysymyksiä ja se vastaa. Vastausten perusteella opin jotain mitä en tiennyt ennestään, ja käytän oppimaani rajallisen ajan suuntaamiseen sellaisiin asioihin joilla on merkitystä.

Puhun toki myös ihmisille, ja hekin vastaavat minulle sillä suoralla vastauksella, mutta olen aina testaajana kuunnellut myös vastauksen sivuviestejä: epävarmuuksia, selittämisen vaikeutta, välttelyä, hienojakoisia eroja toisten sanomisiin. Näistäkin opin, ja tarkastelen mitä ne käytännössä tarkoittavat keskustellen jälleen sen ohjelmistoversion kanssa.

Esimerkein määrittelyssä uskon, että inkrementin pienuus auttaa monessa asiassa. Minulla on edelleen se tuotekonteksti, tämänhetkinen ohjelmistoversio. Puhumme esimerkein siitä, mitä siihen lisätään. Mutta oletan, ja tätä aion myös osaltani testata, että avainesimerkit vangitsevat joitain juttuja jotka nostaisin esiin normaalisti testatessani mutta jättävät osan vangitsematta. Määrittely ja mielikuvitus ilman konkreettista herätettä testattavasta ongelmasta ei vain ole yhtä monipuolinen lähde testaajan osaamisten pohjaksi. Uskon toki että se on riittävä. Mutta, korvaani tulee vielä pitkään särähtämään, kun tutkivan testauksen roolia kuviossa ei ymmärretä. Mikään ei estä meitä varaamasta aikaa tutkivalle testaukselle, oppimisille ja reagoinnille - paitsi me itse ja uskomuksemme siitä mitä sprinteissä pitää tapahtua.

Olin muutaman vuoden poissa agilekentältä, kun minusta aiheesta puhujan tulee harjoittaa jotain puhumisensa suuntaista: Ilmarinen ei juurikaan harjoittanut ja käsiteltäväksi jäi lähinnä perinteiseen paluun aikaansaamat opit. Eilinen muistutti, että testausmielessä tällä kentällä on ammattikuntani kannalta tärkeää työtä tehtävänä. On se sääli jos testaajien osaamista ei nimikkeen ja ymmärryksen puutteiden vuoksi osata hyödyntää ja ketterän kentän tarvitsee kantapään kautta oppia monimuotoisen palautteen tekokkaan tuottamisen asiat. Automaatio on osa, mutta se ei ole näin iso fokus. Ja tietystihän on helppoa sanoa että se tuoteomistaja tekee tän tyyppiset jutut, ja harjoittelee ne taidot joita testausihmiset ovat nk. perinteisessä maailmassa hioneet.

Ja muuten, testauskentällä on testaajia, jotka suorittavat muiden suunnittelemia testejä rutiininomaisesti tarkistellen "automaation korvikkeita". Niitä jotka uskovat että vastaukset tulevat spekseistä, ajattelematta, itse oppimatta ja yhdistelemättä. Laitan sen luokan työn samaan laariin sen avainsanojen leikkaa-liimaa -ajatuksen kanssa. Kummastakin voisi kokonaan luopua.

Määrittely esimerkein, ensiaskeleita

Olen pöytälaatikkoprojektinani - muun ollessa vielä korkeampaa prioriteettiä - tutustunut aktiivisesti määrittelyyn esimerkein, SBE - Specification by Example, ja siinä erityisesti Cucumber/Gherkin -tyyliseen määrittelemiseen. Elävän dokumentaation - määrittelyn ja testiautomaation - yhdistämisen konsepti on varsin houkutteleva nykyiseen projektien kuukausirytmiin.

Minulla on tähän tutustumiseen oikeastaan kaksi motivaatiotekijää. Toinen lähtee siitä, että tiimini kehittäjät voivottelevat aika usein tehtävänantojensa epämääräisyyttä, ja tämä voisi olla tapa määrittää tarkemmin mitä muutosta esimerkein tavoiteltiinkaan. Toinen lähtee siitä, että kuukausisyklissä sekoaa, jos ei jotenkin saa sitä testiautomaatiota kuvioon ja mikään "erillinen projekti" ei vielä tälläkään kertaa tule kestämään elossa tiimini kanssa. Niinpä siis mietin aktiivisesti määrittelyn ja testiautomaation yhdistämistä.

Kirjoitin ihan lähiaikoina ensimmäisen kokonaisen esimerkkini ominaisuudesta ja laadin yleensäkin listan ominaisuuksista joita kyseiseen alueeseen voisi liittyä. Ajatukseni on, että sen sijaan että vielä koittaisimme tuotepäälliköiden kanssa alkaa tehdä määrittelyä esimerkein kaikelle uudelle, luotaisiin ensin vähän keskustelun pohjaa nykyisestä toiminnallisuudesta.

Ensiesimerkkini osui ominaisuuteen, jota juuri opiskelin testatessani sitä. Tutkin ja selvittelin miten se käyttäytyy, ja selvitellessäni kyselin toteuttajalta tarkoituksesta. Ja kirjasin esimerkiksi sen mitä opin. Testausheuristiikkoja vasten - yhdenmukaisuus - ominaisuus toimii ilman logiikkaa. Kyseisessä ominaisuudessa seurataan muutoksia kokonaisuuteen, ja nykytoiminnallisuuden mukaan kokonaisuuden muuttamista seurataan, mutta osan muuttaminen ei ole kokonaisuuden muuttamista. Ja muuttaminen muuttamalla on eri asia kuin muuttaminen poistamalla.

Näytin esimerkkiä projektipäällikkö / tuotepäällikkötasolla. Ensireaktio oli kysymys siitä kenen tälläisiä pitäisi laatia ja ajatus siitä, että ei näin tarkkaan tarvitse ainakaan kertoa ominaisuuksista tuotepäälliköiden toimesta. Mutta, mahtaa olla tuskaista jos ei kerrota, ja sitten lopulta minä testatessani speksaan kaikenlaista, mitä speksissä olisi alkujaan pitänyt / voinut ottaa huomioon.Tuotepäälliköt luottavat tiimiin toteutuksen yksityiskohdissa, koska yksityiskohtainen keskustelu vaatisi aikaa jota ei ehkä olekaan varattuna. Joskus luottamus palkitaan hyvällä toteutuksella. Ja joskus saa jotain vähän sinne päin. Mutta onneksi kaikkea voi vähitellen sitten muuttaa ja korjata.

Toisaalta oma ensireaktioni oli, että nämä asiat itse pienemmällä työmäärällä nostaisin bugiraportteina siitä että mitä erilaisia heuristiikkoja sitten emme noudattaneet tai millä tapaa toiminnallisuus vaan on käyttäjän perspektiivistä käsittämätön. Toisaalta pelkään, että en olisi tarpeeksi hyvä osatakseni myöskään ajatella noita asioita ilman toteutettua tuoteversiota, joka inspiroi minua testaamaan ja tutkimaan käyttötilanteen kannalta.

Meitä on kehitystiimissä vähän ja edestakaisin kirnuaminen syö motivaatiota sekä vähäisiä voimavarojamme. Jatkan siis hetken pöytälaatikkoprojektina ja esimerkein selvittelyä sen osalta miten tätä meillä saadaan oikeasti käyttöön.

Lupaan julkaista lähiaikoina speksit "nykytoiminnallisuudesta" ja "tavoitellusta toiminnallisuudesta". Ja muutenkin pitäisi kirjoittaa enemmän siitä, mitä olen jo tähänkin mennessä oppinut siitä kuinka tälläisiä speksejä yleensäkään kirjoittaisi.

Onko buginen järjestelmä IT-toimittajalle tosiaan rahasampo?

Pääsin eilen juttelemaan puhelimessa Tietoviikon toimittajan kanssa, joka varsin ilahduttavasti poimikin kommenttejani artikkeliinsa:
http://www.tietoviikko.fi/cio/buginen+jarjestelma+on+ittoimittajalle+rahasampo/a831331

Suoranaisista asiavirheistä en suinkaan valita, mutta muutama asia keskustelussamme oli jäänyt vähän erilaiseen lopputulemaan:
1. En suosittelisi "kolmatta osapuolta" tarkoittaen testaukseen erikoistunut firma
2. Suosittelisin sopimusvaiheessa nk. relational contract -mallia, jossa muodostetaan yhteinen rahasumma toimittajan bonuksesta, muutospyyntö ja virherahasta, ei vain virheistä

Halusin kuitenkin hieman pidemmin kirjoittaa kokemuksistani IT-projektien ihmeellisessä maailmassa.

Nykyinen työni on nk. tuotekehitystä. Se tarkoittaa, että testaajana olen sen organisaation palveluksessa, josta löytyy suora asiakas sekä toimittaja samoilta palkkalistoilta. Toiselle testaamistani järjestelmistä on ulkoisia loppukäyttäjiä, joiden näkökulmaa ja sielunelämää sovelluksen käytössä koitan ymmärtää. Suurien käyttäjämäärien myötä lokeistakin näkee, että massa tosiaan tekee kaiken mitä suinkin vain sovelluksella voi tehdä, ei kulje sitä meidän suunnittelemaa polkua eikä meidän suunnittelemaan tahtiin. Toinen testaamistani järjestelmistä on sisäiseen käyttöön, jolloin samalta palkkalistalta löytyvät vielä kaikki käyttäjätkin. Palaute käytävillä on raakaa ja välitöntä, ja kolleegaa halutaan auttaa erityisen vahvasti kun jokaisella käyttäjällä on kasvot.

Aloitin nykyisessä työssäni vasta huhtikuun alusta. Ensin mainitsemani järjestelmä on ollut tuotannossa jo ennen kuin minä työni tiimieni ensimmäisenä ja ainoana testaajana aloitin. Olisi minun silmilläni loukkaavaa väittää, ettei sovellusta ole ennen testattu. Kuitenkin tulokset tekemästäni testauksesta puhuvat täydennyksistä, näkökulmista joita ei testaukseen ole ajallisesti mahtunut ennen lisäpanostusta, tai jota ei ole osattu niillä voimavaroilla tehdä joita tiimin käytössä ennen minun mukaantuloani oli.

Arkipäiviini kuuluu ongelmien löytämistä - bugeja, niinkuin ammattikielellä sanotaan. Bugi on mitä tahansa mikä käyttäjää ärsyttää, haittaa, estää tai hidastaa. Bugit voivat olla puuttuvia keskeisiä toiminnallisuuksia. Ne voivat olla koodivirheitä. Ne voivat olla virheitä siinä miten meidän koodi ja muilta hankkimamme koodi yrittävät ratkoa yhdessä käyttötilannetta. Ne voivat olla virheitä siinä miten käyttäjä ohjelmaa tulkitsee käyttävänsä, missä järjestyksessä tai kuinka nopeasti. Olemme ihastuttavan yksimielisiä tiimini toteuttajien ja projektipäällikön kanssa siitä että olisi ajan tuhlausta jäädä pohtimaan koska bugi on syntynyt (onko se jo nyt asiakkaiden riesana tuotannossa), onko bugi virhe vai muutospyyntö jos samalla rajallisella ajalla sen korjaamme, tai onko kukaan osannut juuri oikeaan aikaan oppia ja tajuta että tämäkin asia oikeasti haittaa käyttäjiä merkittävästi. Tosiasia kuitenkin on, että jos emme saa ongelmasta käsitystä  jonka pohjalta myös toteuttaja ihan käytännön tasolla ymmärtää mikä ei toimi ja millä tapaa, korjaus vähintään menee jollain tapaa metsään. Ja testaajana tuotan lisäarvoa tiimissäni auttaen kehittäjäkolleegoitani löytämään virheitä ajoissa, ennen kuin sekin asiakassekmentti ilmaantuu jolle tämä asia on maailman pysäyttävä, ennen kuin meidän uutta asiaa tarvitsee ensi kertaa käyttäjille näyttää tai ennen kuin löytyy se asiakas, jolla tämä ongelma ylittää ärsyyntymiskynnyksen tuotteen laadun kanssa.

Elämä tuotekehityksessä ei ole helppoa, kun meillä kaikilla on yhtälailla haasteena ajan rajallisuus ja toiveiden monimuotoisuus, ja yritys ymmärtää sitä käyttäjien massaa ja monipuolisuutta sekä usein arvattuja tarpeita. Mutta verraten siihen mitä tein aiemmin, elämä on suorastaan ruusuilla tanssimista.

Olin välissä nelisen vuoden jakson koittamassa ymmärtää asiakas-toimittaja -projekteja ja niihin liittyvää testausta. Tein keikkaa toimittajaorganisaatioiden projekteissa, kunnes siirryin päivätöihin asiakasorganisaatioon tukemaan hyväksymistestausta sekä toimittajilta tilattavan testauksen määrittelyä. Näissä projekteissa on kummallisia ilmiöitä, joista todella monia tunnistan varsin kärjistetysti kirjoitetussa artikkelissa http://ohjelmistotestaus.fi/2012/08/tarinoita-it-hankkeiden-ihmemaasta/.

• Paljon aikaa ja energiaa menee 'hukkaan' kun  asiakas- ja toimittajaorganisaatio kilpaa todistelevat että ehdottomasti korjattava ongelma on virhe eikä muutospyyntö. Virheet sopimusteknisesti kuuluvat usein toimittajan vastuulle, kun taas muutospyynnöt asiakas maksaa erillisestä rahapussista. Tuntuu varsin uskomattomalta, että voidaan rakentaa tilauksesta eläkkeen laskentajärjestelmä, joka ei osaa laskea eläkettä, mutta toimii "määrittelyjensä mukaan". Toimivuudesta tarkoitukseensa maksetaan erikseen, koska vastuu asiantuntijuudesta on sovittu asiakasorganisaatiolle eikä siitä ole siis toimittajalle maksettukaan. Myös riskin otto nostaa projektin hintalappua. 
• Asiakkaan testausvaihe, "hyväksymistestaus", on usein ensimmäinen tuloksellinen testaus ja tapahtuu hyväksymisnäkökulman vuoksi jo alkuperäisessä viivästymisten vuoksi tiukennetusta aikataulusta irrallaankin liian lyhyessä aikavälissä liian pitkän heikkolaatuisen palautteen jälkeen. Hyväksymistestauksen pitäisi olla testaus-, ei korjausvaihe. Jotta tämä olisi mahdollista, on oltava samanlaatuista ja sisältöistä testausta, tai laajempaakin, aikataulussa ennen tätä. Jos aiempien testausvaiheiden sisältöä vielä rytmittää edellisessä pointissani mainitsemani määrittelyjen ylipalvonta, huomaamme lopuksi ennen lakimuutoksen pakottamaa tuotantoonsiirtopäivämäärää, ettei koko järjestelmä tee mitä sen tarvitsee, vaikka tekeekin mitä on määritelty. Ohjelmistokehityksessä monet asiat konkretisoituvat vasta kun järjestelmää pääsee käyttämään - testaamaan. 
• Vaikka virheet kuuluvat ehkä sopimuksen mukaan perushintaan, sopimukset harvoin huomioivat että testaaminen tavalla jolla virheet raportoidaan selkeästi ja korjaukset mahdollistavasti, ei välttämättä kuulukaan. Testauksen vaatiminen / tilaaminen on taitolaji. On täysi myytti, että testaamaton tarkoittaisi toimimatonta. On todistettavasti järjestelmiä, joilla ei ole erillisiä testaajia, joiden laatu on näitä "ammattitestaajien" testaamia parempi - yleensä taustalta löytyy ammattiylpeyttä ja yrittäjähenkeä. Testaus - kenen tahansa aikaa ja osaamista käyttävän toimesta - kuitenkin opettaa yllättävistä reunaehdoista, joista kaikkia ei parhaimpiinkaan suunnitelmiin saada mukaan. Ei siis riitä, että vaaditaan toimittajaa testaamaan. Pitää pystyä kertomaan ja sopimaan mitä ja miten, ja missä laajuudessa ja laadussa. Testausta se on huonolaatuinenkin testaus, ja jotkut kutsuvat sitäkin testaukseksi että painelee samoja nappeja käsin samassa järjestyksessä kymmeniä kertoja ilmaan mitään perustetta epäillä että juuri tätä asiaa nyt tarvitsisi tarkkailla. Samalla ajankäytöllä voisi tehdä edes pieniä muutoksia tekemiseensä, ja sitä kautta merkittävästi lisätä tehdyn testauksen laatua. Lisäksi todella monet asiakkaat tietoisesti ja tarkoituksella tilaavat projektinsa ilman testausta laskien hintalappua tyypillisesti 20-30 %. Tällöin sovitaan että asiakas hoitaa testauksen ja "hyväksymistestaukseen" kuuluukin yllättäen mahdollisesti täysin toimimattomalla ja aiemmin tarkastelemattomalla ohjelmistokokonaisuudella testaaminen. 
• Hintakilpailu toimittajien välillä tuo erikoisia sivuilmiöitä. Tarjouksista on todella vaikeaa saada vertailukelpoiset sisältyvältä laajuudeltaan, ja toimittajat omien malliensa nimissä tarjoavat selkeästi alihintaan projekteja, joissa varsinainen lypsylehmä on virheiden ja muutosten toteutus ensitoimituksen jälkeen. Ensitoimituksen kokoa projektin kuluessa aktiivisesti minimoidaan tiedostaen, että seuraavan täydentävän toimituksen kanssa on haastavaa siirtää kehitystä seuraavalle, ja vaikka tuntihintaa ei ehkä voi ylös hilatakaan (moni asiakas pyytää tarjouksessaan alkuun jo sitovat ylläpitohinnatkin), mikään ei aseta rajoja sille kuinka monta tuntia asian tekemiseen toimittajaorganisaatiossa menee. Ja tuntimäärää saadaan helposti nostettua, kun on erikseen henkilö joka juttelee asiakkaan kanssa (vaatimukset), joka keksii miten asiakkaan tarve ratkaistaan (määrittelyt), joka miettii tekniset rakenteet ratkaisuille (arkkitehtuuri), joka mietii mitä osia koodista viime kädessä muutetaan (tekninen suunnittelu), joka toteuttaa muutokset (koodaaja), joka testaa teknisesti (integraatiotestaaja), joka testaa osana järjestelmää (järjestelmätestaaja) ja joka juttelee aikatauluista asiakkaan kanssa (projektipäällikkö). Ja jos tehdään isompia asioita, joka ryhmällähän pitää tietysti olla vielä erillinen vetäjä. Välillä tulee mielikuva että ei voi ajatellakaan, että yksi kaveri tekisi näitä kaikkia, sehän laskisi laskutettujen tuntien määrää.
• Pelon ja epäluottamuksen ilmapiiri maksaa asiakkaalle moninkertaisesti. Ei suinkaan kelpaa, että toimittajaorganisaatio valvoisi itse omaa tekemistään ja esimerkiksi vastaisi siitä, että toimitukseen sisältyy tulevaa tukeva testiautomaatio (sen ohittamisella ensiprojektissa saadaan muuten upea määrä ylläpitotunteja laskutettavaksi!) vaan kyllä tilaajan pitää ehdottomasti laittaa omat edustajansa asialle vahtimaan. Ja testausfirmat vielä propagandamaisesti mielellään nostavat ammattimaisen edunvalvojan näkökulman esiin. Tehdessäni töitä testausfirmalle testauskonsulttina silloinen myyntiorganisaatio myi edelliselle työnantajalleni useita kavereita täysipäiväisesti tekemään testiautomaatiota hyväksymistestauksen tueksi. Testiautomaatio ei koskaan tuottanut muuta kuin lämpimän tunteen, sen ylläpitäminen maksoi maltaita sillä se hajosi jatkuvasti. Se ei myöskään elänyt kovin kauaa. Ja tässä asiakasorganisaatiossa työtä tehneenä tiedän melkoisen varmasti, että suurin tekijä epäonnistumiselle on etäisyys. Samasta asiasta samalla rahalla samalle toimittajalle kuin joka teki hyväksyttävää järjestelmää olisi saanut merkittävästi enemmän onnistumisen eväitä. En todellakaan ymmärrä että miksi pitäisi maksaa kahdesta "samansisältöisestä" testauskerroksesta vain epäluottamuksen nimissä. Luottamusta voi rakentaa ja sitä tukevia rakenteita tuoda sopimuksiin. Viime kädessä kahdenkin organisaation välisissä projekteissa ihmiset ja yhteistyö ovat ne avainsanat. Organisaatioiden etäisyys vain vaatii sopimusta tueksi tiukkoihin tilanteisiin, joissa liiketoimintojen reunaehdot eivät ehkä olekaan synkassa.
• Ulkoiset testausorganisaatiot usein pahentavat tilannetta. Jos kahdella organisaatiolla on jo erilaisia tavoitteita, kolmas testaukseen keskittyvä organisaatio ei välttämättä mitenkään helpota tilannetta. Kun testaajalle maksetaan testaustuloksista ja järjestelmätoimittaja menettää rahaa korjatessaan ilman lisämaksua ja molemmat toimittajat koittavat optimoida itselleen mahdollisimman suuren ja merkittävän osuuden kokonaisuudesta, saadaan aikaan lähinnä kaaosta ja taistelua.

Pitkän vuodatuksen jälkeen haluan vielä kertoa, että olen kokenut myös jotain hyvää. Edellisen työnantajani palveluksessa yhdessä projektissa (ehdin tehdä 2,5 vuoteen viittä projektia tuotantoon saakka) teimme erittäin ammattimaisen 30 päivän hyväksymistestauksen ja teimme kaikkemme löytääksemme virheitä ja muutospyyntöjä. Emme onnistuneet. Järjestelmä meni tuotantoon edellä aikataulustaan ja alle sovitun budjettinsa. Avain onnistumiseen, väittäisin, oli erinomainen yhteistyö asiakkaan eri roolien sekä toimittajan eri roolien välillä. Testauksen yhteisissä viikkopalavereissa käytettiin 30 minuuttia viikossa erittäin avoimeen vuorovaikutukseen ja pieleen menevien asioiden veikkailuun, joilla asiakkaan tukemana toimittajan toteuttajat tekivät erinomaisen järjestelmämuutoksen, toimittajan testaajat testasivat ja korjauttivat rajoitteet suhteessa tarpeeseen ja viestivät erinomaisesti toteuttajien kanssa teknisellä tasolla. Taustalla onnistumisessa oli mielestäni puitteet: projekti myytiin meille hinnalla, joka ei ollut toimittajalle kuristuspanta. Rinnakkaisprojekti, joka oli laajuudeltaan karkeasti kaksinkertainen myytiin 2/3 tämän onnistuneen projektin hinnasta. Tarinasta lienee selvää, että tämä alihinnoiteltu projekti oli molemmin puolin paljon työllistävämpi ja työilmapiiri ei koskaan saavuttanut samaa hyvää tasoa. Testaustaidoissa ja neuvottelutaidoissa oli toimittajaorganisaation nimetyissä henkilöissä myös suuri ero.

Buginen järjestelmä voi olla toimittajalle rahasampo, ja minun silmiini monet suurien toimittajien menetelmistöistä optimoivat tätä. Mutta vikaa on myös asiakkaissa. Mitä jos asiakkaat tyytyisivät time-and-material -sopimukseen, siihen että riskiä ei lopulta voikaan siirtää ilman merkittävää omaa lisäkustannusta toimittajalle ja laittaisivat tarkistuspisteitä kalenteriin useammin. Ja se ei silti estä sopimasta tavoitehintaa ja palkkio/riskisummaa, jolla projektin joustot hoidetaan. Niin, kuulostaa uhkaavasti suositukselta ketterien menetelmien suuntaan - etenkin yhdistettynä tuohon roolipohjaisen siiloutumisen naurettavuuteen jossa kahden töihin tarvitaan kymmenen spesialistia välttelemään vastuita.