Hoe werk je samen met een team programmeurs?
Goeiedag, ik ben Tom.
Ik herinner me als de dag van gisteren dat mijn vader thuis kwam met een Commodore 64. Ik was toen een man van 9 jaar. De Commodore 64 was één van de eerste computers die je thuis kon gebruiken, en waar je méér op kon doen dan alleen maar spelletjes spelen. Toegegeven, ik heb er veel spelletjes op gespeeld. Maar het ding trok me ook aan om te kijken wat je er méér mee kon doen — en dat heb ik dan ook gedaan. Eén van de eerste programma's die ik me nog herinner geschreven te hebben, is een beheersprogramma voor een club. Ik hield er alle namen en adressen in bij van de leden van de club. Vandaag zouden ze dat een CRM noemen.
Zo ontdekte ik wat een computer allemaal voor u kan doen. Een computer kan u plezier bezorgen, een computer kan nuttig zijn voor uw werk, en een computer kan u doen huilen. Hoe dikwijls was ik niet gefrustreerd omdat dat ding niet deed wat ik wou doen, en dat enkel omdat ik GOTO 10 had getypt in plaats van GOTO 20.
Later ben ik informatica gaan studeren, en ben ik aan de slag gegaan als programmeur. Ik heb daar goede tijden gekend, ik heb daar slechte tijden gekend. De goede tijden waren vooral wanneer ik goed snapte wat mijn gebruikers wilden, en wanneer ik dat goed kon vertalen naar een goed werkend software programma. De slechte tijden waren wanneer er ergens in die vertaalslag iets mis liep: ofwel snapte ik niet wat mijn gebruikers wilden, ofwel snapte die computer niet wat ik wilde.
Dit probleem is mij blijven intrigeren. Hoe kunnen gebruikers duidelijk maken aan een computer wat ze willen? Weten ze eigenlijk wel wat ze willen? Hoe weten ze wat er mogelijk is met een computer?
Een gebruiker zal zelden zelf beginnen programmeren om hun eigen probleem op te lossen, meestal omdat ze zelf de mogelijkheid of de tijd niet hebben om dat te doen. Zij moeten dat uitleggen aan iemand die daar haar carrière van gemaakt heeft - een programmeur. Maar hoe kan die programmeur er achter komen wat die gebruiker nu echt wil? Het schrijven van een programma vraagt duizenden kleine beslissingen. Als ik op die knop klik, wat gebeurt er dan? Die knop, moet die grijs of rood zijn? Hoe groot moet de tekst erop zijn? En in welk lettertype moet die tekst staan?
Een programmeur die die beslissingen moet nemen, heeft een paar mogelijkheden. Zij kan voor elke beslissing ten rade gaan bij de gebruiker. Dat brengt echter een aantal problemen met zich mee: die gebruiker heeft haar eigen werk. Die gebruiker denkt na verloop van tijd "zeg, weet die dat nu zelf niet?" Die gebruiker denkt na vraag 37: "dat interesseert me eigenlijk niet, los het zelf op." En die gebruiker snapt soms zelfs de vraag niet. Zo hoorde ik een programmeur eens aan een aannemer vragen "Gaan we een NoSQL of een SQL databank gebruiken?"
De programmeur kan dit ook anders benaderen. Zij kan de moeite doen om zich in te leven in de leefwereld van de gebruiker. Ze kan proberen goed te begrijpen wat de gebruiker wil bereiken met haar software, en zo de meest logische beslissingen proberen te nemen. Natuurlijk gaat zij nooit in de schoenen kunnen staan van de gebruiker. Die gebruiker is ook een expert in haar vakgebied — een vakgebied waarin de programmeur een leek is. (Zo was één van mijn klanten een dokter. Die keek vreemd op toen ik vroeg waar ik de milt moest plaatsen op de schets van een lichaam) Daarom is het noodzakelijk dat programmeur en gebruiker dikwijls met elkaar afstemmen, om te kijken of ze nog op de goede weg zijn.
Programmeurs werken zelden alleen. Meestal werken ze in een team. Een team kan meer gedaan krijgen dan iemand alleen. In een team kunnen er ook specialisten zijn - er kan iemand zijn die alles weet van een databank, en er kan iemand zijn die alles weet van hoe een gebruiker anders reageert op een grijze of een rode knop. Maar om een team efficient te laten werken, moet je ervoor zorgen dat ze allemaal in dezelfde richting willen gaan. Elk lid van het team moet zelf elke dag duizenden beslissingen nemen — dus elk lid van het team moet goed begrijpen wat de gebruiker wil. Daar komt nog bij dat wanneer er verschillende opties zijn om een probleem aan te pakken, het team als geheel moet beslissen welke optie ze gaan uitvoeren.
Ook gebruikers zijn zelden alleen. Ik ken heel weinig programma's die voor één gebruiker geschreven zijn. Meestal zijn ze met tientallen, soms zijn ze met duizenden of miljarden. Elk van die gebruikers heeft haar eigen voorkeuren om problemen aan te pakken, heeft haar eigen leefwereld, heeft een eigen manier van denken. Toch kan er maar één programma geschreven worden. Op één of andere manier moeten er dus beslissingen genomen worden van wat er precies moet geprogrammeerd moet worden.
Dit alles is wat mij al jaren intrigeert, sinds die dag dat mijn vader thuiskwam met die Commodore 64. Met dit alles ben ik sindsdien bezig, en ben ik oplossingen aan het uitbouwen en zoeken om te zorgen dat wat er geprogrammeerd wordt, overeenkomt met wat de gebruiker wil. Al de kennis en de ervaring die ik daarin heb opgebouwd, gebruik ik nu elke dag om mijn klanten te helpen. Sommige klanten help ik om goed uit te drukken wat ze willen bereiken. Sommige klanten help ik om goed te communiceren met het software ontwikkelingsteam. Sommige klanten help ik om hun software ontwikkelingsteam intern met elkaar te laten communiceren.
Als jij software aan het bouwen bent, en je hebt het gevoel dat je software team niet oplevert wat je wil — dan kan ik je helpen. Contacteer me voor een eerste vrijblijvend gesprek — ik beloof je dat je na dat gesprek minstens één nieuw inzicht zal hebben. Als we besluiten te gaan samenwerken, maak ik een analyse van de huidige werking van je team, en geef je aanbevelingen waar je kan verbeteren. Als je wil, help ik ook met het uitvoeren van die verbeteringen. Ik beloof je dat je na 6 maanden op een heel andere manier met je software team zal samenwerken.