Apperium - Waarom we geen projectmanager hebben (en wat dat voor jouw app betekent)
Tech
Waarom we geen projectmanager hebben (en wat dat voor jouw app betekent)
Geschreven door Herbert Megens-Kreté, Apperium
De meeste app-bureaus zetten een projectmanager tussen jou en de mensen die je app bouwen.
Dat klinkt logisch. Iemand die de boel coördineert, jou op de hoogte houdt, intern de neuzen dezelfde kant op krijgt. Dat is het werk waar je voor betaalt.
Bij ons werkt het anders. Wij hebben geen projectmanagers. Niet omdat we ze niet kunnen betalen, maar omdat we 90% van het werk dat ze doen niet meer nodig hebben.
In deze blog leg ik uit wat dat betekent voor de manier waarop we apps bouwen, waarom het sneller en beter is, en wat het voor jou anders maakt als je met ons werkt.
Wat een projectmanager bij een app-bureau eigenlijk doet
Voordat ik uitleg waarom wij ze niet hebben, moeten we eerst eerlijk zijn over wat een projectmanager bij een softwarebureau de hele dag doet.
Het is grofweg dit:
Status doorgeven. Voortgang bewaken. Inschatten of iets uit budget gaat lopen. Vergaderingen plannen. Notuleren. Tickets verschuiven in Jira. Mailtjes vertalen tussen jou en het developmentteam. Risico's signaleren. Scope-discussies voeren. Verslagen maken.
Dat zijn allemaal nuttige dingen. Maar het is ook werk dat een computer kan doen. Beter zelfs, want een computer vergeet niks en is altijd op tijd.
Het probleem is alleen dat je voor dat hele pakket bij de meeste bureaus alsnog een mens betaalt. Vaak een dure mens. En wat je daarmee koopt is niet sneller werk, het is een tussenpersoon die het werk vertraagt.
Waarom een tussenpersoon vertraagt
Elk overdrachtmoment is een verliespunt. Jij vertelt iets aan de projectmanager, die noteert het, die brengt het in de stand-up, die geeft het door aan de developer, die heeft een vraag terug, die gaat via de projectmanager naar jou, en zo gaat het twee dagen heen en weer over iets dat in een gesprek van vijf minuten klaar was geweest.
Dat is geen kritiek op projectmanagers. Het is wiskunde. Hoe meer schakels in een keten, hoe meer informatie er onderweg verdwijnt of vervormt. Iedereen die wel eens fluisterspelletje heeft gedaan op een verjaardag weet hoe dat afloopt.
Bij software ontwikkelen is dat verlies duur. Een misverstand over hoe een knop moet werken kost geen tijd in de meeting, het kost twee dagen herwerk een week later, als de developer iets blijkt te hebben gebouwd wat jij niet bedoelde.
Wat we wél automatiseren
We hebben de afgelopen jaren stap voor stap weggehaald wat een projectmanager handmatig doet. Niet in één klap, niet als marketingstunt, maar gewoon omdat het kan en het werk er beter van wordt.
Voortgang bewaken doet onze tooling. Insights over scope, budget en planning rollen automatisch uit het systeem. Als iets uit de bocht dreigt te lopen, ziet het team dat eerder dan een mens dat ooit zou kunnen signaleren. Status-updates komen direct uit het werk dat de developers doen, niet uit een aparte ronde langs alle stoelen op donderdagmiddag.
Wat overblijft is het deel dat je niet kunt automatiseren: het gesprek tussen mensen. De vraag of een idee klopt. De afweging tussen twee opties. Het moment waarop iemand "ja maar" zegt en je goed moet luisteren waarom.
Dat doe je rechtstreeks met de mensen die het bouwen. Niet met een tussenlaag.
Hoe zo'n project er dan uitziet
We werken in vier fases: Discover, Design, Develop en Doorontwikkeling. Niks bijzonders aan de namen, dat doen meer bureaus zo. Het verschil zit in wie er aan tafel zit en hoe de communicatie loopt.
Discover is waar we scherp krijgen wat we gaan bouwen en, net zo belangrijk, wat we niet gaan bouwen. Geen dikke rapporten, geen workshops van drie dagen die eindigen met een PDF die niemand meer opent. Wel: harde keuzes over wat MVP is en wat later komt, technische haalbaarheid vroeg op tafel, en duidelijkheid over hoe succes eruitziet.
Design gaat bij ons over hoe iets werkt, niet alleen over hoe het eruitziet. Designers en developers zitten letterlijk naast elkaar, dus een ontwerp dat technisch onmogelijk is haalt het einde van de week niet. Itereren is goedkoop in deze fase, daarna wordt het duur.
Develop is waar tempo gemaakt wordt, omdat we eerder hebben opgeruimd. Korte sprints, releases die je echt kunt gebruiken, en directe lijnen met de developers. Geen weken radiostilte gevolgd door een grote onthulling.
Doorontwikkeling is wat we doen na livegang, en eerlijk gezegd is dat waar de meeste waarde ontstaat. Een app is bij oplevering geen eindproduct, maar een eerste versie. Wat gebruikers ermee doen is wat 'm beter maakt, als je tenminste meet en bijstuurt.
Wat je hier in de praktijk van merkt
Een paar dingen die anders voelen dan bij een klassiek bureau.
Je krijgt geen wekelijks statusrapport in een keurig sjabloon. Je krijgt iemand die je belt als er iets is, en anders praten we elkaar gewoon bij in de standup waar je bij mag aanschuiven.
Beslissingen vallen sneller. Als je vrijdagmiddag iets bedenkt over hoe een feature zou moeten werken, hoeft dat niet te wachten op een meeting volgende week. Je belt de developer die het bouwt en je bespreekt het.
Je hoort eerder als iets niet klopt. Niet bij oplevering, maar in de week dat het gebouwd wordt. Bijsturen is dan goedkoop. Bijsturen aan het einde is duur, en dat is waar veel projecten misgaan.
En je betaalt niet voor een rol die voor jou geen werk verzet. Wat we niet uitgeven aan management-overhead, gaat naar de mensen die je app daadwerkelijk maken.
Voor wie werkt dit niet
Eerlijk verhaal: deze manier van werken is niet voor iedereen.
Als jij een opdrachtgever bent die liever maandelijks een dik rapport ontvangt en pas aan het einde van het traject het resultaat wil zien, dan past het niet. Wij verwachten betrokkenheid. Niet veel, een uur per week is vaak genoeg, maar wel echte betrokkenheid van iemand die kan beslissen.
Als jouw organisatie een traject alleen kan goedkeuren als er vooraf een vastgespijkerd plan ligt voor de komende negen maanden, dan ook niet. Software ontwikkelen werkt niet zo, en doen alsof het wel zo is, is waar de duurste fouten ontstaan.
Wij werken het beste met opdrachtgevers die snappen dat een app bouwen een proces is van leren onderweg. Die scherp zijn op wat ze willen bereiken, maar flexibel in hoe ze er komen.
Veelgestelde vragen
Wie is mijn aanspreekpunt als er geen projectmanager is? Een van de developers of designers die op je project werkt. Niet iemand die het project voor je bewaakt vanaf de zijlijn, maar iemand die er met de handen in zit.
Hoe weet ik dan hoe het project ervoor staat? Via dezelfde tooling die wij intern gebruiken. Voortgang, scope, planning, dat is geen geheim dat een projectmanager voor je vertaalt, dat zie je gewoon.
Wat als er iets misgaat? Dan hoor je het zo snel mogelijk, van iemand die weet wat er aan de hand is en wat eraan te doen valt. Niet een week later via een tussenpersoon die het ook van horen-zeggen heeft.
Werkt dit ook bij grotere projecten? Ja. We hebben apps gebouwd waar honderdduizenden mensen op zitten. De manier van werken schaalt mee, juist omdat de overhead laag blijft. Hoe meer schakels je toevoegt aan een project, hoe trager het wordt. Dat geldt voor projecten van vijf weken én van twee jaar.
Is dit goedkoper? Vaak wel, maar dat is niet het hoofdpunt. Het hoofdpunt is dat je betere apps bouwt als de mensen die ze maken context hebben en kunnen meedenken, in plaats van orders uitvoeren via een tussenlaag.
Wil je weten hoe dit voor jouw project zou werken? Dan plannen we een gesprek. Geen verkooppraatje, geen offerteformulier, gewoon een uur waarin we kijken of het idee klopt en of we een goede match zijn.