Verwijderd schreef op zondag 14 augustus 2005 @ 04:51:
In je verhaal over stakeholders zeg je onder andere:
[Ontwikkelaars, testers en beheerders kunnen ook stakeholders zijn]
Mijns inziens is de aannemer (zoals een interne afdeling danwel extern bedrijf) wel een stakeholder, maar die zou interne organisatie moeten afschermen, waardoor ontwikkelaars of testers nooit en te nimmer een stakeholder worden in de eisen van een softwareproject.
Om even een vergelijking te maken: als ik bijvoorbeeld een keuken bestel en laat plaatsen, zijn de monteurs die de keuken moeten monteren geen stake holders. Ik verwacht dat de leverancier de keuken plaatst op de manier als overeengekomen voor de prijs waarvoor het overeen gekomen is en op het moment dat het overeen gekomen is. Als 1 van de monteurs bijvoorbeeld maar een halve dag kan werken, verwacht ik dat er een andere monteur geregeld wordt zodat de plaatsing geen vertraging oplevert. De organisatie van de realisatie is een verantwoordelijkheid voor de aannemer en moet nooit invloed hebben op de overeenkomst met de opdrachtgever.
Je zou inderdaad voor de interne projectorganisatie een gedelegeerd opdrachtgever aan kunnen wijzen die als één partner met de echte opdrachtgever overlegd. Dat is een opzet die je wel vaker ziet en ook in sommige methodieken wordt aangedragen. Hoe je het uiteindelijk regelt maakt volgens mij niet zo heel veel uit, zolang je maar expliciet omgaat met requirements voor architectuur, opleiding, testen, beheer, enz. moet je phantom requirements kunnen voorkomen.
Om jouw voorbeeld te gebruiken: de installateur zal in zijn schema kijken en een dag met jou afspreken die uitkomt in zijn rooster, eventueel in combinatie met een monteur-in-opleiding en vakantietijden. Jij mag alleen kiezen uit een aantal standaard keukens met een aantal standaard opties. De installateur zal een bepaald bedrag vooraf vragen en als de keuken voltooid is. Jij hebt de garantie dat eventuele gebreken binnen 6 weken kosteloos worden gerepareerd, maar je moet die gebreken wel zelf kenbaar maken. In dit voorbeeld zijn monteurs, keukenleveranciers, de opdrachtgever en de opdrachtnemer specifieke stakeholders met elk een eigen belang. Een gedeelte van de afwegingen wordt gemaskeerd voor de opdrachtgever, maar ze worden wel expliciet meegenomen in de gemaakte afspraken.
Helaas is een gemiddeld software-ontwikkelproject iets ingewikkelder als het installeren van een keuken, en zijn er vaak complicaties omdat de gebruikersbehoefte nog niet duidelijk is, weinig ervaring met een bepaalde techniek, enz. enz. Als jij een installateur belt met de vraag of ze een keuken willen leveren, maar je weet nog niet of ie wit of zwart moet zijn, of je wilt een type wat de installateur niet kent, dan zal het verhaal voor hem (en ook voor jou) ook een stuk ingewikkelder worden.
Een installateur zal dan waarschijnlijk zeggen: "bel maar terug als je weet welke kleur het moet worden", in een ontwikkelproject is de kleur bepalen juist een onderdeel van de activiteiten. Software-ontwikkeling wordt wel vaker vergeleken met garages en keukens maar die vergelijking gaat maar voor een gedeelte op.
Mbt het beheer is het een andere zaak, aangezien de verantwoordelijkheid en kosten uiteindelijk (in ten minste de meeste gevallen) bij de opdrachtgever zelf komen te liggen. Daarom moeten de beheersaspecten van een systeem zeker onderdeel zijn het eisenpakket en zijn de beheerders zeker stake holders, hoewel ze vaak te weinig als zodanig erkent worden.
Moet beheer de applicatie kunnen onderhouden en kunnen uitbreiden met nieuwe functionaliteit? Het testen van de applicatie voor de oplevering (de acceptatietest) gebeurt vaak door mensen van de opdrachtgever. Dit zijn meestal gebruikers, maar die hebben dan wel de rol van testers. Ik hoor regelmatig: "dat kunnen we niet testen, want dat is veel te moeilijk". Als tester, maar ook als opdrachtgever zou ik het erg belangrijk vinden dat je zo veel mogelijk testbaar maakt. Beheerders zijn voor de meesten een duidelijke stakeholder (die vaak alsnog vergeten wordt), maar voor mij niet een partij die significant belangrijker is dan andere (interne) stakeholders.
[...]
Eigenlijk lijk je te zeggen dat de klant tegen zijn eigen beperkingen in bescherming genomen moet worden, en dat daarom phantom requirements ontstaan. De kosten die voortvloeien uit het realiseren van dergelijke eisen stromen alsnog door naar de klant, want als besluit of onbewust worden deze dus alsnog gerealiseerd, met als verklaring dat de klant er uiteindelijk wel beter mee af is.
Nee ik zeg dat de situatie nu is dat de klant/opdrachtgever het vaak zelf niet kan of niet wil beslissen. Ik ben het niet eens met die situatie. Het gaat er mij alleen om dat als je discussieert over phantom requirements je de totale dynamiek moet zien van het requirementsproces, en hierin speelt de (on)kunde van de opdrachtgever een zeer grote rol.
Eerlijk gezegd klinkt dat een beetje als een garagehouder die tijdens een grote beurt aan je auto meer werk doet dan afgesproken en je met een stevige rekening opzadelt, met als argument: "Ja meneertje, je kunt maar beter voorkomen dat het kapot gaat." Wellicht heeft hij gelijk, maar ik wil als klant zelf een dergelijke beslissing nemen, eventueel op advies van een garagehouder.
De garagehouder beslist zelf of hij een brug installeert in zijn garage (duur) of een put (goedkoop), welk gereedschap hij gebruikt, enz. Op dat soort strategische beslissingen heb je als klant geen invloed. Ik stel dat de opdrachtgever niet overal in hoeft worden betrokken, mits belangen van stakeholders niet worden geschaad (bijvoorbeeld doordat het duurder wordt of langer duurt), én als het duidelijk is dat het significant veel moeite zou kosten om de opdrachtgever wél te betrekken. Als ik bij een garage een maand moet wachten voor mijn auto omdat ze speciaal voor mijn reparatie een brug aanschaffen, en ik moet de volle meerprijs voor de brug betalen, dan wil ik ook graag hier van te voren over beslissen.
Ik ben een groot voorstander van een heel goed en degelijk voortraject waarin je het beslissingstraject van de klant ondersteunt, maar als de klant bewust beslist weinig tot geen beheersfunctionaliteit in te bouwen, dan is hij zelf verantwoordelijk voor de gevolgen. Vaak zal de foute beslissing dan alsnog met meerwerk worden rechtgezet. Juist als je dingen gaat verzwijgen voor je klant ben je bezeig hem te vervreemden van jou en je product / dienst.
Ik noem het verzwijgen ook symptoombestrijding, ik vind het ook geen gezonde situatie. Het verband wat ik leg is puur om de oorzaak aan te geven, niet om de situatie goed te praten. Het punt wat ik wilde maken dat het niet _alleen_ techies zijn die aan het over-engineeren zijn (alhoewel dat absoluut wel regelmatig voorkomt). Phantom requirements zijn een veel breder probleem en hebben een diepere oorsprong. Over-engineerende technies zou ik zien als een gevolg voor een phantom-requirements probleem, niet als oorzaak.
Het probleem in de ICT sector is dat we juist te vaak de klant een hand boven hun hoofd houden en uiteindelijk de budgetoverschrijdingen die voortvloeien uit slechte beslissingen delen of zelfs volledig op ons nemen, omdat er ook nooit duidelijke afspraken zijn geweest over wat we wel danwel niet leveren. Daarmee snijden we onszelf in de hand en ontnemen we de klant een leermoment.
Juist, alhoewel opdrachtnemers zelf vaak ook niet vies zijn van vage planningen en budgetten. Wat ik erg frappant vind is dat de huidige markt een tegenovergestelde beweging maakt. De gemiddelde klant lijkt liever te horen dat er voor 1 miljoen "iets" wordt gemaakt, dan dat er voor 4 miljoen een duidelijk gedefinieerd product wordt opgeleverd. Ik heb zelf aan dergelijke offertetrajecten met klanten aan tafel gezeten en het is echt lastig om hiermee te concurreren. Als je uiteindelijk dan mensen kunt overtuigen waarom dat je vindt dat iets 4 miljoen gaat kosten dan zijn er bijvoorbeeld nog allerlei bizare Europese aanbestedingsregels, accountants en directeuren, die voornamelijk op de hoogte van de offerte beslissen, niet op inhoud.
Ik ben het met je eens dat begrip van ICT nog steeds beschamend laag is bij de gemiddelde manager, maar dat is niet omdat het zo super complex is, maar omdat ze niet voldoende aandacht eraan besteden, veel ICTers niet management taal spreken of zelfs weigeren dat te doen, omdat er vanuit managementkant te weinig wordt vertrouwd op ICT functionarissen en omdat de meeste managers van interne ICT afdelingen vaak onkundige eikels zijn die zich met glad maar onbegrijpelijk technisch gebrabbel op hebben gewerkt naar die positie en natuurlijk nooit meer weggaan aangezien hun salaris schandalig afsteekt bij hun werkelijke kennisnivo. Dit zijn allemaal problemen die verholpen kunnen worden, maar dat zal pas gebeuren bij de nodige prikkels, zoals een mislukt project.
Het één werkt het ander in de hand, en er valt inderdaad nog genoeg te verbeteren op het gebied van kennis en kunde in de ICT. Ik ben zelf een gelover van Scott Adams's Dilbert Principle. De stelling die in de Dilbert Principle wordt verdedigd luidt: "All people are idots". Als je er vanuit gaat dat iedereen een idioot is dan is het niet voldoende om vast te stellen dat het huidige systeem niet werkt omdat er te veel idioten zijn. Je zult dan op een andere manier moeten werken die wel functioneert ondanks dat het idioten zijn. In de Dilbert Principle wordt dit toegelicht met grappige en heldere voorbeelden die laten zien dat je het inherent idioot zijn van mensen ook kunt gebruiken voor positieve doeleinden.
Een bedrijf moet zijn eigen bedrijfsmiddelen goed bergijpen en beheersen en er is geen excuus voor als ze dat niet doen. Bedrijven zijn ontzettend afhankelijk geworden van ICT, en totdat ze dat realiseren en integreren in hun beslissingsproces, zullen ze fouten maken. En juist daardoor zullen ze gaan begrijpen hoe de vork in de steel steekt. Een Britse vriend van mij en een enorme topper op management consultancy zei ooit tegen mij: "The customer gets what he pays for: if he pays shit, he gets shit, and he'll think twice the next time around."
Daar ben ik het absoluut mee eens. Gelukkig worden de strategische voordelen van goede ICT steeds belangrijker voor de marktposities van bedrijven, waardoor de aandacht en noodzaak van goede ICT voorzieningen steeds verder stijgt. Zolang het voor de klant maar duidelijk blijft dat hij niet alleen geld moet pay-en, maar ook moet investeren in kennis en aandacht voor zijn ICT projecten. Genoeg geld alleen garandeert geen shit-vrij project.
:strip_exif()/u/31626/eend.gif?f=community)
:strip_icc():strip_exif()/u/59957/got-icon.jpg?f=community){kind=icon}
:strip_icc():strip_exif()/u/64562/crop578ced1600c94_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/6988/greg.jpg?f=community)
:strip_exif()/u/80759/monstermania_small.gif?f=community)
Moppelt verder over Gestalt-theorie, perceptie, de eye movement hypothese.