Eerste hulp bij het organiseren van je werk.

Of je nu midden in een project zit, of er net mee begint. Of je expert bent of iets voor de eerste keer doet, alle werkzaamheden zijn in te plannen. Hier vind je mijn eerstehulpkoffertje met tips

Mijn team bij Microsoft HoloLens werkte altijd onder zeer grote druk. Het was geen uitzondering om in twee weken een app te bouwen die op een HoloLens bij de klant moest draaien.

Hoe ontwerp, bouw en test je een app die over een paar weken op de grootste beurs van duitsland de show moet stelen? Dat is niet makkelijk. Naast het maken van holografische magie, leerde ik bij de Mixed Reality Studio in Berlijn ook hoe je projecten met vele onbekende factoren en nieuwe technologie kunt organiseren.

Organiseren voor de ongeorganiseerden

Dit artikel is voor mensen die –net als ik– niet zo goed zijn in het organiseren van hun werk. Het zijn ervaringen die ik opgedaan heb in mijn tijd bij HoloLens.

Break it down

Klinkt als een cliché en toch doen mensen dit niet. Misschien breken ze het probleem wel op in hun hoofd, maar leggen dit niet vast. Deel je probleem altijd op in delen en maak een sticky note van elk deelprobleem. Dit geeft overzicht en een goed gevoel als je een deelprobleem hebt opgelost.

Het gevaar van break it down

Het is verleidelijk om je tasks zo klein mogelijk te maken. Het ziet er overzichtelijk uit en je kunt vaak sticky notes verplaatsen. Toch zijn er ook gevaren bij te kleine taken:

• Er is geen duidelijke relatie meer tussen taken en user stories/acceptance criteria
• Te veel overhead door teveel taken. Hiervoor is een mooie analogie: De engelse Kustlijnparadox. Volgens deze paradox heeft een kustlijn van een bepaald stuk land geen eenduidig te definiëren lengte. Dit komt door de fractal-achtige eigenschap van kustlijnen. Bij vele kleine taken stijgt de administratieve overhead waardoor het juist moeilijker wordt om te plannen.
• Jezelf klem plannen door in een te vroeg stadium taken onder te verdelen.

Milestones

Heb je een deel van het werk af en kun je iets laten zien? Maak screenshots of video’s van je overwinningen en deel ze met je collega’s. Werk je alleen? Stuur ze dan gewoon aan je moeder. Maak een plek waar de milestones bewaard blijven. Zit je even vast in je project? Bekijk de behaalde milestones en krijg nieuwe energie!

Proof of concept, MVP, Implementeren

Zelfs in korte projecten is het goed om de volgende fases te doorlopen:

• Proof of concept: bewijzen dat het mogelijk is
• MVP: een minimale werkende (bruikbare) versie (0.x)
• Implementeren: de volle versie (1.0)

Timeboxing

Niets is erger dan je blind staren op een probleem. Het is frustrerend en kost tijd.

Neem voor elk deelprobleem een vaste tijd om het uit te voeren.

• Voorbeeld 1: Ik neem 4 uur om te proberen of ik een connectie kan maken van een HoloLens naar een online test socket
• Voorbeeld 2: Ik neem 25 minuten om een item in de lijst klikbaar te maken

Lukt het niet? Dan komt het volgende belangrijke punt:

Kill your darlings

Admit defeat. Het moeilijkste wat er is. Als iets te veel tijd kost, heeft het geen zin om ermee door te gaan. Meer daarover in de volgende punten.

Evolution over increment

Door het opbreken van een probleem in kleine stukjes, kun je beginnen met iets heel kleins. Iets dat misschien totaal niet lijkt op wat je uiteindelijk wil bereiken. Het spreekwoordelijke skateboard terwijl je een auto wil bouwen. Maar het skateboard werkt. Terwijl een wiel van een auto (zonder de rest van de auto) waardeloos is.

De eerste keer is moeilijk

Nog zo’n mooie cliché. Maar daardoor niet minder waar.

Iets maken terwijl je alles nog moet uitzoeken is moeilijk en kan frustrerend zijn! Voor uitzoekwerk kun je geen resultaat beloven. En toch vraagt je baas: “Hoe lang gaat het duren?”. Wat je dan kan doen is de taak opsplitsen in:

• Een bepaalde tijd nemen om uit te zoeken (Timeboxed)
• Daarna beslissen
• Inplannen en bouwen

Want je kunt wel beloven dat je na de timebox-periode genoeg weet om verder te gaan of meer tijd nodig hebt. Mijn baas zei wel eens: Ik zeg je niet waartoe je je moet committen, maar ik wil commitment.

Definition of done

Definieer alle voorwaarden die voldaan moeten zijn om iets af te noemen. Zeg nooit dat iets af is als het niet af is! Met zoiets kom je maar éen keer weg! Gebruik ook niet het excuus dat je achteraf nog input nodig hebt van anderen.

Hoe schat je de hoeveelheid werk?

Hier zijn wat strategieën die je kunnen helpen om een hoeveelheid werk in te schatten:

• Terwijl je je werk inschat, stel je jezelf voor die het werk aan het doen is.
• Als taken veranderen, weersta dan het verlangen om direct een getal te noemen. Denk er nog eens over na.
• Stel je voor hoe lang iemand die je kent zou doen over deze taak. Houdt hierbij rekening met zijn of haar ervaring niveau.
• Heb je het werk al eens gedaan? Hoe lang duurde het toen? Is het al eens gedaan? Hoe lang duurde het toen?
• Nee? Kun je het vergelijken met dingen die wel al eens gedaan zijn?

Leer de echte termen

Dit is iets wat ik in duitsland ben gaan waarderen. Wij nederlanders zijn sterren in het maken van verkleiningswoordjes en het niet zo nauw nemen met definities. De duitsers zijn strikter en ik ben gaan leren om dingen bij de naam te noemen.

Door dingen juist te benoemen:

• Is het makkelijker om documentatie te vinden
• Kom je veel makkelijker op de juiste naam die je in je code kunt gebruiken. Het voelt ook goed om dingen in je code juist te benoemen.

Info verzamelen

Een van de beste tips die ik kreeg en nog dagelijks gebruik is:

Skip opinions. Find links to papers or blog posts

Developers die dagelijks StackOverflow gebruiken kennen dit fenomeen. Je zoekt een oplossing voor je probleem en alles wat je leest zijn de meningen van beterweters. Scan in zo’n geval de pagina op links naar de documentatie of blog posts.

Hoe ontwerp je een systeem?

Hiervoor is veel discipline vereist. De een zal het graag op kantoor doen, de ander tijdens een boswandeling. Maar voor je begint met ontwerpen of plannen, kun je deze mentale oefening doen:

Ga dan in je hoofd eens na wat je allemaal moet doen. Maak een lijstje en beeld je in dat je de klus aan het uitvoeren bent. Waar begin je mee? Wat is de volgende stap? Zijn er afhankelijkheden? Wat is het einddoel?

Maak desnoods een Flow Chart en teken het pad van executie. Wat heb je allemaal nodig en hoe grijpt het in elkaar?

$$$

Als een ander voor jou gaat betalen, wil deze antwoord op de volgende vragen:

• Wat krijg ik er voor terug? (= Purpose, Mogelijkheden, Visie)
• Wanneer krijg ik het? (= Go to market roadmap)
• Hoeveel en wat heb je nodig? (= Investering, Inzet)

Agile

Hier de kortste en goedkoopste agile-training die je ooit zult zien:

• Iedereen met een boerenverstand begrijpt dat je kleine stapjes moet nemen en vaak moet kijken of je nog in de juiste richting gaat.
• Agile verhindert niet dat je vooraf je huiswerk moet doen!

Punt.

Fouten maken

Leer van de gemaakte fouten. Release de gemaakte fouten niet.

Metawoorden

Gebruik in je communicatie op papier of met je team geen metawoorden zoals: zou, willen, hopen. Dit geeft twijfel en verwarring en draagt zeker niet bij tot het belangrijke laatste punt:

Het probleem van de de andere zijde benaderen

Zit je vast? Als je niet direkt de oplossing ziet voor de taak, moet je het probleem van de andere kant aanvliegen!

The strategy is delivering

Ik eindig met de belangrijkste les die ik geleerd heb.

Shipping is the bottom line

De duitsers zeggen heel mooi: “In Schönheit sterben”.

Je kunt nog zo mooi spelen, als je niet wint is het niets waard. Je kunt nog zo’n mooie oplossing bouwen, als je de deadline niet haalt, heeft niemand er iets aan.