Geschreven door Frodo Larik op 27-6-2018
Vanaf het begin dat je een samenwerking met een klant aangaat – waarbij jij de opdrachtnemer bent en de klant de opdrachtgever – ontstaan er reeds verwachtingen aan beide kanten.
Vaak zien verwachtingen er als volgt uit:
De opdrachtgever verwacht dat er voor hem iets gemaakt wordt, zoals hij het bedacht heeft.
én
De opdrachtnemer verwacht dat hij betaald wordt voor het werk waarvoor hij een offerte heeft gestuurd.
Bovenstaande klinkt logisch vanuit een zakelijk perspectief. Maar kijk je verder, dan zie je dat deze eigenlijk niet in lijn zijn met elkaar.
Want eigenlijk wil je:
De opdrachtgever verwacht dat er voor hem gemaakt wordt, zoals het samen met opdrachtnemer bedacht is.
én
De opdrachtnemer verwacht betaald te worden voor het werk wat hij samen met opdrachtgever uitgedacht heeft.
Zou dit niet een beter gevoel geven?
Het grote verschil tussen beide “verwachtingen” is dat de tweede omschrijving meer uitgaat van samenwerken in een win/win situatie. Het behalen van synergie.
Binnen Kabisa hechten we veel waarde aan co-creatie"
In de praktijk komen verwachtingen op vele niveaus voor. Voorbeelden van vragen waarvan de verwachtingen gemanaged dienen te worden zijn:
- Wat is de opleverdatum? Jij denkt volgende maand, klant denkt morgen.
- Hoe lang gaat het duren om een bepaald onderdeel te ontwikkelen? Klant denkt morgen, jij begint er over een paar dagen aan.
- Wanneer kunnen wij aan de payment provider gekoppeld worden? Klant denk nu, jij wacht nog op wachtwoorden.
- Wanneer kunnen wij de App in de App Store / Google Play Store verwachten? Klant denkt nu. Jij kunt niet verder, want je hebt eerst een licentie nodig om te kunnen uploaden.
- Wanneer staat de software op de server? Klant heeft morgen een demo, jij wacht nog op toegang tot de server.
- Waarom loopt het niet volgens planning? Klant werkt via z’n spreadsheet. Jij werkt met software waarin alle stories en planning zichtbaar is.
- Waarom zijn we over budget? Jij hebt geen idee van het budget.
In eerst instantie, lijken deze vragen redelijk eenvoudig te beantwoorden. Maar toch, als je deze vragen analyseert, ontdek dat er meer achter zit.
Neem als voorbeeld de vraag: “Wat is de opleverdatum?”, dan zien we zonder de context te kennen, dat daar nog allerlei informatie in verborgen ligt in de vorm van vragen die ook weer allerlei vragen oproepen.
- Wat is de definitie van wat er er opgeleverd worden (Definition of Done)?
- Wie definieert wat er opgeleverd moet moet worden?
- Hoe/waar wordt er vastgelegd wat er opgeleverd moet worden?
- Wie controleert wat er opgeleverd moet worden?
- Hoe wordt deze controle afgestemd?
- Wie accordeert wat er opgeleverd moet worden?
- Wat gebeurd er als je niet kunt opleveren binnen een bepaalde termijn? Is de impact bekend?
- Is de ontwikkelen tijd een doorlooptijd of een absolute tijd?
- etc.
Dit soort vragen komen in meer of mindere mate terug tijdens het samenwerkingsproces. Soms zijn de antwoorden hierop evident, maar niet altijd. En de vraag is, als het voor jou evident is, is dat voor de ander ook zo? Hoe kun je er nu voor zorgen dat het voor iedereen evident is, of dat het inzichtelijk wordt dat het niet voor iedereen even duidelijk is. Het eenvoudige antwoord is, dat het nooit voor iedereen even duidelijk is, en dat het een constant proces is wat gemonitord en gemanaged moet worden. Je moet elkaar challengen om er achter ter komen of je elkaar wel goed genoeg begrijpt, want aannames zijn bronnen van mislukking.
"Assumption is the mother of all fuckups…" — Travis Dane
Om zo veel mogelijk duidelijkheid tussen partijen te hebben, gebruiken we binnen Kabisa een aantal methodieken om verwachtingen tussen partijen te managen.
Goede en duidelijke afspraken omtrent de samenwerking
Een inkoppertje natuurlijk, maar het maken van duidelijke afspraken als het gaat om hoe je met elkaar communiceert en wil communiceren tijdens het samenwerkingsproces is essentieel in onderlinge afstemming. Voor de een is het belangrijk dat hij telefonisch op vaste tijden benaderd wordt, terwijl de andere het liefst via mail op de hoogte gesteld. De preferentie van hoe te communiceren en wanneer én wat te doen als het mis gaat, leggen bij bij Kabisa vast in een Designed Partnership Alliance (DPA). Deze wordt opgesteld door een aantal vragen te stellen aan de betrokkenen, zoals de key stakeholders, Product Owner en Development Team. De antwoorden op deze vragen geven een beeld hoe de betrokkenen willen samen werken en wat zij samen willen bereiken.
Helder en duidelijk werkproces
Als er een werkproces is met vaste onderdelen, zoals stand-ups, backlog refinement en retrospectives, zoals geboden wordt door Scrum, het Agile framework wat Kabisa gebruikt voor software ontwikkeling. Dan schept dit automatisch allerlei momenten en mogelijkheden om verwachtingen uit te kunnen spreken. In de praktijk is Agile Scrum heel prettig om software mee te ontwikkelen. Maar om een project tot een success te maken, zijn er nog meer zaken die spelen. Denk hierbij aan Product Owner training, de samenstelling van een team, afspraken die gemaakt worden omtrent de samenwerking, co-preparation, co-creation, release management, hosting, monitoring, advisering etc.
Al deze onderdelen hebben wij ondergebracht in het Kabisa Success Process. Dit process omschrijft hoe wij samen met de klant door middel van co-creation tot een succesvol resultaat kunnen komen. Het success process is gebaseerd op onze jarenlange ervaring met het lanceren en opleveren van succesvolle projecten.
Duidelijke omschrijving van wat er gemaakt dient te worden
Binnen Kabisa werken we met User Stories om software functionaliteiten te omschrijven. Een user story omschrijft een functioneel doel vanuit het perspectief van de eindgebruiker. Eigenlijk komt het er op neer “Wie wil wat doen met het product en waarom?”. Een user story dient een duidelijk verhaal te vertellen en duidelijke acceptatiecriteria te hebben, gedefinieerd door een Definition of Done. Een user Story is een belangrijk vehikel om verwachtingen te managen over wat er ontwikkeld gaat worden binnen deze user story. Als user stories niet goed beschreven zijn, is het resultaat meestal dat de klant niet krijgt wat hij wil. M.a.w. hij is ontevreden. Dit kan te maken hebben met het feit dat er aannames worden gedaan over wat er in de user story omschreven staat door beide kanten, de developers en de Product Owner. Het is belangrijk dat voordat user stories opgepakt gaan worden dat deze duidelijk zijn en der een duidelijk Definition of Done is. Tijdens het schrijven van user stories kun je je vragen stellen als “Wanneer…?”, “Waarom?”, “Waar…?”, “Op welke Wijze…?”, “Wat als…?” Om tot betere omschrijvingen te komen.
Tijdig feedback geven
Het is belangrijk om snel en eerlijk feedback te geven tijdens een samenwerking. Dit zorgt ervoor dat er ten alle tijden duidelijkheid is van de stand van zaken binnen project.
- Als je het idee hebt dat er iets onduidelijk is in de definitie van features omschreven in stories, geeft dat aan en ga geen aannames doen.
- Als je tijdens het ontwikkelen erachter komt dat iets veel meer tijd gaat kosten, geef dat direct aan binnen je team, dan kan een Product Owner deze verwachting terug managen naar de stakeholders.
- Als er communicatieproblemen binnen het team zijn, geeft dat aan tijdens een retrospective
Heeft u ook zo’n zin om een mooi product te ontwikkelen, neem dan snel contact met ons op ;-)
Vragen?
Heb je vragen naar aanleiding van dit artikel? Neem gerust contact met ons op!
(of stuur een bericht)+31 495 430 798
Frodo Larikstuur bericht