Beställare och utförare

Det finns i synnerhet en form av bristande markkontakt som förstör bra och effektiv utveckling av IT-system: abstraktionen i beställare och utförare, att någon beställer IT-utveckling av någon annan på ungefär samma sätt som man beställer tillverkning.

Det är en abstraktion som kan fungera när man är i avtalssituationer, till exempel när man måste teckna ett avtal som fördelar tänkt ansvar mellan två entiteter eller när något har gått snett och vi måste utföra den där ansvarsfördelningen i verkligheten. Men den fungerar inte när man utvecklar. Inte ens om man faktiskt är två olika juridiska entiteter som ska samarbeta om utvecklingen.

För det är samarbete som krävs. Som det agila manifestet formulerar det: We value Customer collaboration over contract negotiation.

Mjukvara är kodifierad kunskap och förståelse. Det behövs såpass mycket förståelse av både problemdomänen och vilka tänkbara lösningar som finns i lösningsdomänen att man till slut kan kodifiera denna kunskap så att också en dum dator förstår. Det är en kunskap man skaffar sig tillsammans: både de som ska använda det färdiga resultatet av utvecklingen och de som är bra på att fånga kunskap och förfina den till kodifierat skick.

Det finns inget sätt att göra en tydlig ansvarsfördelning i en process vars framgång bygger på mycket tät och rik kommunikation. "Beställare" och "utförare" sitter bokstavligen i varandras knä. Om de inblandad är duktiga på det de håller på med så kan de minska riskerna för att den här kommunikationen går fel, men de är i lika mån ansvariga för slutresultatet.

När man, som vi på Squeed, arbetar i en renodlad utförarorganisation som säljer oss som länkar i utvecklingskedjan behöver man ta ut en ekonomisk riskpremie av varje kund. Ibland går det fel i kommunikationen och då behöver man kunna ha lite kapital för att kompensera för denna varians.

Men situationen är långt värre för de som arbetar med IT-utveckling internt i organisationer där de som ska använda resultatet betraktar sig själva som beställare som kan flytta en stor del av ansvaret över på utvecklingsorganisationen, men utan att dessa får lov att ta ut någon riskpremie. I ett flöde kommer problem att uppstå överallt, men de kommer att manifesteras långt ner i kedjan nära leveransen. Det är som ett stopp i avloppet i källaren: problemet har inte uppstått där utan beror på det som kommer längre upp ifrån.

Så oavsett var kommunikationen och kunskapsförfiningen brister är det "utförarna" som kommer att framstå som de skyldiga, om man saknar förmåga att se kommunikationsbristen i samma ögonblick som den uppstod. Det "beställarna" måste förstå är att om de tar ansvar för sin beställning så har de samtidigt ansvar för utförandet.

En ännu mer bisarr avart av detta är organisationer där den delen av utförarorganisationen som beslutar om utvecklingen på strategisk och taktisk nivå betraktar sig själva som beställare i förhållande till de som befinner sig på operativ nivå nära koden. Där har man verkligen lyckats att ge sig själva stora mandat och samtidigt undvika ansvar.

Det må vara en god ordning för de som placerat sig i den positionen, men vad jag inte kan förstå är hur ledningen för sådana organisationer tillåter det att ske. Dessa organisationer brukar ju ha en lång historia av misslyckad IT-utveckling, och med tanke på hur systemet är riggat kan man bara dra slutsatsen att dessa misslyckanden är avsiktliga.