Spaces

We waren vandaag aan het vergaderen op het werk, en het was al lang geleden dat ik zo veel plezier heb gehad in een vergadering.

De situatie: er moet een toepassing gebouwd worden. We hebben voor die toepassing studie gedaan, gesproken met gebruikers, we zijn ze gaan observeren ter plaatse, we hebben een hypothese gemaakt voor hoe we de toepassing zouden bouwen, we hebben dat eerst intern verfijnd en gevalideerd, en dan hebben we een dag workshop gedaan met een hele stapel gebruikers om de concepten samen met hen te bekijken en te valideren.

Daar is veel nuttige feedback uit gekomen, die we nu in een rapport aan het samenvatten zijn, en dan gaan we aan een gedetailleerd design beginnen.

Maar tegelijkertijd moeten er ook ontwikkelaarsresources opzij gezet worden, en moeten we een (zeer ruwe) backog kunnen maken om de volgende drie maand ongeveer te kunnen vullen. En daar zaten we deze namiddag dus voor samen.

Als mijn vorig werk mij iets geleerd heeft, dan is het wel absoluut respect voor ontwikkelaars en hun situatie: niets erger dan een designer die ergens vanuit een ivoren toren komt zeggen “zo moet het”, en dan een tijd later terugkomt met “het werkt niet”. Want ah ja ik bedoelde eigenlijk dit in plaats van wat ge gemaakt hebt. Of, nog erger, want ah ja ik ben van gedacht veranderd.

In dit project proberen we daar enorm hard rekening mee te houden, door bijvoorbeeld de ontwikkelaars om de zoveel tijd uitleg te geven van wat we aan het doen zijn en hoe ver we staan, door de lead developer te betrekken in zowel de interne als de externe validatie, en door ze in het algemeen als evenwaardige partners te beschouwen.

De meeting was zo interessant, omdat we op hoog niveau zowel problem space (wat is er aan de hand?) als solution space (hoe gaan we dat oplossen?) al hadden bekeken, maar dat we nu binnenin de solution space ook weer tussen problem space en solution space zaten. Gewoon een niveau dieper opnieuw in analyse-modus, relatief technologie- en platform-onafhankelijk, aan het focusen om op het wat en het waarom en niet op het hoe.

Het is een algemeen principe dat het beter is om uw problem space niet te vervuilen met de solution space, maar het is niet vaak het zo expliciet gemaakt wordt dat er niet alleen bij analysten en designers een understand>explore>define>build>test-loop is, maar ook bij developers.

Ik kijk hard uit naar het vervolg van het project.