Reading time: 3 minutes
Author:
In een interview met Winy Maas van het Rotterdams architectenbureau MVRDV komt het ontwerp van het Nederlandse paviljoen op de Expo-2000 aan de orde. De interviewer zit duidelijk met een vraag: ’Er was één ding dat ik niet begreep in Hannover: het was een heel open gebouw, zonder gevel, maar toch kon het publiek niet vrij in en uit lopen. Iedereen moest met de lift naar boven en dan afdalen, er stond een enorme rij. Dat is toch in tegenspraak met de openheid van het ontwerp?‘ Winy Maas antwoordt: ’In het pakket van eisen stond: hoe langer de wachtrij, hoe beter, want daaraan wordt het succes van het paviljoen afgemeten. Dus dat was een eis. Ze wilden per se een rij. En wij hadden uiteindelijk de langste.‘
Hier heeft een architect een informeel geventileerde wens wel erg letterlijk als een belangrijke eis genomen. En toch leidde dit bij de opdrachtgever niet tot ontevredenheid. Integendeel, het Nederlandse paviljoen werd algemeen beschouwd als een van de succesvolste op deze wereldtentoonstelling. Bij elke andere opdracht zou de architect zware kritiek te verduren hebben, maar hier had Winy Maas precies de juiste oplossing geleverd om het succes van het paviljoen aanschouwelijk te maken.
Het lijkt erop dat om succesvol te zijn een architect niet zomaar letterlijk kan uitgaan van een eisenpakket. Voor een optimaal eindresultaat speelt meer mee dan alleen de opdrachtgever met zijn formele lijstje. Sommige eisen moeten letterlijk worden genomen, andere geïnterpreteerd of zelfs volkomen genegeerd. Dit geldt niet alleen in de bouwkunde, maar ook in technische productontwikkeling.
Hoe werkt dan in productontwikkeling het proces van eisen verzamelen? In het geval van business-to-business gaat een verkoopteam naar een klant. Dat neemt de eerste wensen en eisen op en geeft de eerste commitments. Hier is slechts zelden een architect bij betrokken; in het beste geval zit er een requirementsengineer bij het team. In vervolggesprekken krijgen wensen, eisen en beperkingen van de klant verdere uitwerking. Het verkoopteam gaat terug naar huis met de lijst. Negen van de tien keer krijgt de architect dit opgedrongen als een absolute lijst, oftewel: hij kan er in principe niet meer met de klant over spreken.
Het gevolg hiervan is dat de klant wel krijgt wat hij vraagt, maar vaak niet wat hij wilde. De verschillende partijen in ontwikkeling vinden dit eigenlijk allemaal wel oké. Projectleiders en productmanagers erkennen dat de architect technisch goed is onderlegd, maar daardoor kun je ook moeilijker met hem praten en je kunt al helemaal niet regisseren wat hij te berde brengt in een gesprek met een klant. De architect aan de andere kant heeft een broertje dood aan bijeenkomsten met een klant. Hij ziet altijd de nuance en laat zich daarom niet graag een zwart-witte uitspraak ontlokken.
Wat betekent dit voor het geleverde product? Dit zal uiteindelijk altijd naar behoren werken, want iedereen heeft daar belang bij. De gekozen oplossingen zullen echter middelmatig zijn, want risico‘s worden niet genomen. Dit geldt voor zaken als eenvoud van gebruik, maar ook voor kwaliteitsaspecten als performance en betrouwbaarheid.
Als je een product wilt leveren dat uitstijgt boven de massa, dan zul je als architect de klant moeten leren kennen. Kruip in zijn huid en probeer te ontdekken waarom bepaalde vragen worden gesteld en richt je ontwerp op die zaken die belangrijk zijn voor de klant. En vooral: sta erop dat je als architect onderdeel uitmaakt van het team dat naar de klant gaat. Durf zo nu en dan een zwart-witte uitspraak te plaatsen, en het zou zomaar kunnen dat je het contact met de klant leuk gaat vinden en dat klant, projectleider en productmanager voor het eerst de echte toegevoegde waarde van een architect ondervinden. Architecten eropuit!
