Joel on Software

Joel on Software   Joel over Software

 

Andere "Joel on Software" artikelen in het Nederlands

Andere "Joel on Software" artikels in het Engels

Email de auteur (uitsluitend in het Engels)

 

Pijnloze Functionele Specificaties - Deel 3: Maar... Hoe?


Door Joel Spolsky
Vertaald door Mark Tetrode
4 october 2000

Nu dat je alles gelezen heb over waarom je een spec nodig hebt en wat er in een spec moet zitten, laten we het eens hebben over wie ze moet schrijven.

Wie schrijft specs?

Ik zal je wat Microsoft geschiedenis vertellen. Toen Microsoft serieus ben te groeien in de laat 80-er jaren, had iedereen daar De Mythische Man-Maand (The Mythical Man-Month) gelezen, een klassieker op het gebied van software management. (Als je die niet gelezen hebt beveel ik je die van harte aan.) Het grote punt van dat boek is dat wanner je meer programmeurs aan een al uitlopend project toevoegd, het nog later klaar zal zijn. Dat is omdat waneer je n programmeurs in een team hebt, het aantal communicatie-paden n(n-1)/2 is, en dit groeit met O(n2).

De programmeurs bij Microsoft waren bezorgd hoe nu grotere en grotere programma's te schrijven, als de algemene stelling van die tijd was dat programmeurs toevoegen het alleen maar slechter maakt.

Charles Simonyi, lange tijd "chief architect" bij Microsoft, stelde het meester programmeur concept voor. Het idee was zo ongeveer dat één programmeur verantwoordelijk was om alle code te schrijven, maar dat hij kon terugvallen op een team van junior programmeur als "code slaven". In plaats van zich zorgen te maken over het debuggen van elke fuctie hoefde de meester programmeur slechts de prototype van elke functie te schrijven plus een beschrijving wat deze functie moet doen, en dan kon een van de junior programmeurs deze implementeren. (Simonyi was dan uiteraard de meester meester programmeur.) De term "meester programmeur" was een beetje te middeleeuws, dus Microsoft noemde zoiemand "programma manager".

Dit was dus bedoeld om het mytische man-maand probleem op te lossen, omdat niemand meer met iemand anders moest spreken -- elke junior programmeur sprak alleen met de programma manager, en dus groeide de communicatie met de snelheid O(n) inplaats van O(n2).

Nu, Simonyi kent wellicht de Hongaarse Notatie maar hij kent Peopleware niet. Niemand wil een code slaaf zijn. Het systeem werkte in het geheel niet. Uiteindelijk ontdekte Microsoft dat, ondanks die mytische man-maand, je toch nog slimme mensen aan een team kan toevoegen en sneller kan werken, alhoewel met verminderde marginale waarde. het Excel team had 50 programmeurs toen ik daar werkte, en het was marginaal meer productief dan een team van 25 zou zijn geweest -- maar niet twee keer zo productief.

Het idee van meester/slaaf programmeren werd afgebouwd, maar Microsoft had nu al die mensen rondlopen met de titel "programma manager". Een slimme man met de naam Jabe Blumenthal vond toen de functie van de programma manager opnieuw uit. Vanaf toen zou de programma manager eigenaar zijn van het ontwerp en de spec van het produkt.

Sindsdien verzamelen programma managers bij Microsoft de requirements, zoeken uit wat de code moet gaan dien, en schrijven de specs. Er zijn gewoonlijk ongeveer 5 programmeurs per programma manager; deze zijn verantwoordelijk voor de implementatie die de programma manager als spec heeft uitgeschreven. Een programma manager moet ook de marketing, documentatie, het testen, de localisatie, en alle andere vervelende details coördineren, iets wat een programmeur zich niet mee bezig moet houden. Daarbij moeten programma managers bij Microsoft de "big picture" van de firma in het hoofd heben, terwijl de programmeurs vrij zijn om zich op de bits en de bytes te concentreren.

Programma managers zijn van onschatbare waarde. Als je al eens geklaagd hebt over hoe de programmeurs meer geïnteresseerd zijn in de techniek dan in de marketability, dan heb je een programma manager nodig. Als je al eens geklaagd hebt over het feit dat mensen die goede code kunnen schrijven niet behoorlijke Nederlandse zinnen kunnen bouwen, dan heb je een programma manager nodig. Als je al een geklaagd hebt over hoe je produkt alle kanten opdrijft zonder een klare visie, dan heb je een programma manager nodig.

Hoe neem je nu een programma manager aan?

De meeste firma's kennen het cocept programma manager niet eens. Ik vind dat jammer. In mijn tijd bij Microsoft hadden de groepen met een sterke programma manager erg succesvolle produkten: Excel, Windows 95 en Access bijvoorbeeld. Maar andere groepen (zoals MSN 1.0 en Windows NT 1.0) werden gedaan door ontwikkelaars die over het geheel genomen hun programma managers negeerden (en die verdienen dat waarschijnlijk wegens het ontbreken van kwaliteit) en hun produkten hadden geen succes.

Hier zijn drie dingen om te vermijden

1. Promoveer een programmeur niet tot programma manager.  De eigenschappen van een goede programma manager (duidelijk Nederlands schrijven, diplomatiek, markt-voeling, medeleven met de gebruiker, goed UI ontwerp), zijn zekel de eigenschappen van een goede programmeur. Natuurlijk, sommige mensen kunnen beide taken aan, maar dit komt niet vaak voor. Goede ontwikkelaars belonen door ze to promoveren naar een andere positie, één waar ze Nederlands moeten schrijven inplaats van C++ is een klassiek voorbeeld van het Peter Principle: mensen worden gepromoveerd tot het niveau van incompetentie.

2. Maak de marketing mensen geen programma managers. Zonder iets slechts te willen zeggen over hen denk ik dat mijn lezers het met me eens zullen zijn dat goede marketing mensen zelden een goed technologisch inzicht hebben om produkten te ontwerpen.

Programma management is gewoon een andere carrière. Alle programma managers moeten erg technisch zijn, maar ze behoeven geen goede programmeurs te zijn. Programma managers moeten de gebruikers-interface bestuderen, klanten ontmoeten, en specs schrijven. Ze moeten goed kunnen omgaan met veel soorten mensen van vervelende klanten tot irriterende programmeurs die naar hun werk komen in Star Trek uniforms, tot opgeblazen verkopers in hun pakken van € 2000. In sommige opzichten zijn de programma managers de lijm van de software teams. Charisma is cruciaal.

3. Ontwikkelaars moeten niet rapporteren aan de programma manager. Dit is een subtiele fout. Als programma manager bij Microsoft ontwierp ik de Visual Basic (VBA) strategie voor Excel, volledig uitgeschreven, tot in het kleinste detail. Mijn spec was ongeveer 500 pagina's. Op het hoogtepunt van de ontwikkeling van Excel 5.0 kwamen er elke morgen ongeveer 250 mensen naar hun werk, en die werkten aan iets wat met deze spec te maken had. Ik wist niet wie al deze mensen waren, maar er waren ongeveer een tiental mensen op het Visual Basic team enkel bezig met het schrijven van documentatie voor dit ding (en daarbij nog het team dat Excel documentatie maakte, en de persoon die full time bezig was met de hyperlinks in de help file.) Het rare was dat ik onderaan de rapportering stond. Echt waar. NIEMAND rapporteerde aan mij. Als ik wilde dat iemand iets deed moest ik hem of haar overtuigen dat dit het beste was. Toen Ben Waldman, de hoofdontwikkelaar iets niet wilde doen wat ik juist had uitgeschreven deed hij het dus niet. Toen de testers klaagden dait ik iets had uitgeschreven dat onmogelijk te testen was, moest ik het vereenvoudigen. Als deze mensen aan mij hadden gerapporteerd was het produkt nooit zo goed geworden. Sommige onder hen hadden dan gedacht dat je je baas nooit voor het hoofd moet stoten. Andere keren had ik met mijn vuist op tafel geslagen en hen  bevolen om het te doen zoals ik zie, uit conceit of kortzichtigheid. Maar zoals het was, had ik geen andere keus dan concensus op te bouwen. Deze vorm van beslissingen maken was de beste manier om het juiste ding te doen.

het laatste artikel in mijn serie over specs gaat over hoe je goede specs kan schrijven die de mensen willen lezen.



De originele versie van dit artikel verscheen in het Engels onder de naam Painless Functional Specifications Part 3  

Joel Spolsky is de oprichter van Fog Creek Software, een klein softwarebedrijf in New York. Hij studeerde af aan de Yale universiteit, en heeft als programmeur en manager gewerkt bij Microsoft, Viacom en Juno.


De inhoud van deze pagina's vertegenwoordigt de mening van één persoon.
Alle inhoud Copyright ©1999-2005 door Joel Spolsky. Alle rechten voorbehouden.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky