Getting Real - Normaal Doen

• hoofdstuk 1 Inleiding
• hoofdstuk 2 De Start
• hoofdstuk 3 Blijf Slank
• hoofdstuk 4 Prioriteiten
• hoofdstuk 5 Features selecteren
• hoofdstuk 6 Het Proces
• hoofdstuk 7 De Organisatie
• hoofdstuk 8 Het Team
• hoofdstuk 9 Interface ontwerp
• hoofdstuk 10 Code
• hoofdstuk 11 Woorden
• hoofdstuk 12 Prijs en Aanmelding
• hoofdstuk 13 Publiciteit
• hoofdstuk 14 Ondersteuning
• hoofdstuk 15 Na de Lancering
• hoofdstuk 16 Conclusie

---

Inleiding hoofdstuk 1

Wat is Normaal Doen?

Wil je een succesvolle webapplicatie ontwikkelen? Dan is het tijd om Normaal te Doen. Normaal Doen is een kleine, snelle en betere manier om software te ontwikkelen.

• Normaal Doen betekent overslaan van alles wat de werkelijkheid afspiegelt (schema's, diagrammen, grafieken, figuren, pijlen, enzovoorts) en meteen datgene bouwen waarover het gaat.
• Normaal Doen betekent minder. Minder massa, minder software, minder features, minder papier, minder van alles wat niet essentieel is (en het meeste lijkt essentieel, maar is het niet).
• Normaal Doen gaat over klein en wendbaar blijven.
• Normaal Doen begint met de interface, de echte schermen die mensen gaan gebruiken. Het begint met wat de klant daadwerkelijk ervaart en bouwt vanaf daar terug. Zo krijg je de juiste interface voordat de software roet in het eten kan gooien.
• Normaal Doen gaat over herhaalde en goedkope aanpassingen. Normaal Doen gaat over lanceren, bijschaven en constant verbeteren - een perfecte benadering voor software op het web.
• Normaal Doen levert alleen wat klanten willen en verwijdert alles wat ze niet nodig hebben.

De voordelen van Normaal Doen

Normaal Doen geeft betere resultaten omdat het je dwingt om te gaan met de echte problemen die je wilt oplossen in plaats van je ideeën over deze problemen. Het dwingt je om te gaan met de werkelijkheid.

Normaal Doen stopt met functionele specificaties en andere tijdelijke documentatie, maar ontwerpt echte schermen. Een functionele specificatie is slechts schone schijn, een illusie van overeenstemming, terwijl een echte webpagina de werkelijkheid is. Dat krijgen je klanten te zien en gaan ze gebruiken. Dat is wat er toe doet. Normaal Doen brengt je daar sneller. En daardoor maak je software-keuzes op basis van de werkelijkheid in plaats van abstracte aannames.

Tenslotte is Normaal Doen een benadering die uitstekend past bij software op het web. Het oude model, van software verkopen in een doos en dan een of twee jaar wachten met een update, is aan het verdwijnen. In tegenstelling tot geïnstalleerde software kunnen webapplicaties constant verbeteren, van dag tot dag. Normaal Doen buit dit voordeel volledig uit.

Overdaad Schaadt

De oude manier: een traag, bureaucratisch, risicoloos proces. Het typische resultaat: opgeblazen en onduidelijke software die overloopt van middelmatigheid. Bah.

Normaal Doen maakt een einde aan...

• Tijdschema's van maanden of zelfs jaren
• Nutteloze functionele specificaties
• Discussies over schaalbaarheid
• Eindeloze teamvergaderingen
• De "noodzaak" van het inhuren van tientallen medewerkers
• Betekenisloze versienummers
• Schitterende planningen die de perfecte toekomst voorspellen
• Eindeloze voorkeursinstellingen
• Uitbesteden van productondersteuning
• Onrealistische gebruikstesten
• Zinloze papierwinkel
• Dictatoriale hiërarchie

Je hebt geen scheepsladingen geld nodig, of een gigantisch team, of een langdurige ontwikkelingscyclus, om fantastische software te ontwikkelen. Die zaken zijn de ingrediënten voor langzame, stroperige, stilstaande applicaties. Normaal Doen kiest de tegengestelde benadering.

In dit boek tonen we...

• Het belang van het hebben van een filosofie
• Waarom klein blijven een goede zaak is
• Hoe je minder kunt bouwen
• Hoe je snel van een idee naar werkelijkheid kunt komen
• Hoe je team samen te stellen
• Waarom je van binnenuit moet ontwerpen
• Waarom schrijven cruciaal is
• Waarom je voor de concurrentie moet onderdoen
• Hoe je je applicatie kunt promoten en het woord verspreiden
• De geheimen van succesvolle productondersteuning
• Tips voor het vasthouden van het momentum na lancering
• ...en nog veel meer

We richten ons op de grote lijn. We begraven je niet onder gedetailleerde code-fragmenten of CSS-trucs. We houden het bij de belangrijkste ideeën en filosofieën achter het Normaal Doen.

Is dit boek voor jou?

Je bent ondernemer, ontwerper, programmeur, of marketeer en werkt aan een groots plan.

Je begrijpt dat de oude regels niet meer van toepassing zijn. Elk jaar software distribueren op CD-ROM's? Wat 2002. Versienummers? Weg ermee. Je moet ontwikkelen, lanceren, en bijschaven. En dat steeds opnieuw.

Of misschien ben je nog niet overtuigd van wendbare ontwikkeling en bedrijfsstructuur, maar je wilt er graag meer over te weten komen.

Als dit op jou van toepassing is, dan is dit boek voor jou.

Opmerking: Hoewel dit boek de nadruk legt op het bouwen van een webapplicatie zijn veel van deze ideeën ook van toepassing op processen buiten softwareontwikkeling. De suggesties over kleine teams, snelle prototyping, aanpassingen verwachten en vele anderen kunnen gebruikt worden bij het starten van een bedrijf, schrijven van een boek, ontwikkelen van een website, opnemen van een album of allerlei andere avonturen. Zodra je Normaal Doen toepast op een deel van je leven, zul je zien hoe deze concepten gelden voor allerlei andere activiteiten.

---

Over 37signals

Wat we doen

37signals is een klein team dat eenvoudige en doelgerichte software maakt. Onze producten helpen je bij het samenwerken en organiseren. Meer dan 350.000 mensen en kleine ondernemingen gebruiken onze webapplicaties. Jeremy Wagstaff van de Wall Street Journal schreef: "De producten van 37signals zijn verbluffend eenvoudig, elegant en intuïtief. Hierbij vergeleken ziet een scherm in Outlook eruit als het equivalent van een martelkamer." Onze applicaties leggen je nooit op de pijnbank.

Onze manier van werken

Wij vinden software te ingewikkeld. Teveel features, teveel knoppen, teveel te leren. Onze producten doen minder dan de concurrentie - bewust. Wij bouwen producten die slimmer werken, beter aanvoelen, je op je eigen manier laten werken en makkelijker in het gebruik zijn.

Onze producten

Bij publicatie van dit boek hebben we vijf commerciële producten en een opensource webapplicatie raamwerk.

Basecamp zet projectmanagement op zijn kop. In plaats van schema's, grafieken en spreadsheets biedt Basecamp prikborden, to do-lijsten, eenvoudige planning, samen schrijven en delen van bestanden. Tot nu toe honderdduizenden gebruikers vinden dit een betere manier. Farhad Manjoo van Salon.com zei: "Basecamp is de toekomst van software op het web."

Campfire biedt eenvoudige groepschat voor een zakelijke omgeving. Bedrijven met ervaring begrijpen het belang van realtime doorgaande groepschat. Bestaande instant messaging is prima voor snelle een-op-een chats, maar het is ongeschikt bij drie of meer personen tegelijk. Campfire lost dat op en doet nog veel meer.

Backpack is het alternatief voor verwarrende, ingewikkelde, "organiseer je leven in 25 eenvoudige stappen" persoonlijke managers. Backpacks eenvoudige benadering van pagina's, aantekeningen, to do-lijsten en herinneringen via mobiele telefoon of email is verfrissend nieuw binnen een product categorie die lijdt aan status-quo-itis. Thomas Weber van de Wall Street Journal noemde Backpack het beste product in zijn klasse en David Pogue van de New York Times noemde het een "erg coole" organisatie hulp.

Writeboard laat je schrijven, delen, reviseren en teksten vergelijken in je eentje of met anderen. Het is een verfrissend alternatief voor veel te complexe tekstverwerkers die teveel kunnen voor 95% van wat je schrijft. John Gruber van Daring Fireball zei: "Writeboard is zo'n beetje de meest nette en eenvoudige webapplicatie die ik ooit heb gezien. Webgoeroe Jeffrey Zeldman zei: "De briljante breinen van 37signals hebben het weer voor elkaar."

Ta-da List verzamelt en organiseert al je to do-lijsten online. Hou de lijsten voor jezelf of deel ze met anderen voor eenvoudige samenwerking. Er is geen makkelijker manier om zaken afgewerkt te krijgen. Meer dan 100.000 lijsten en bijna 1.000.000 items zijn tot nu toe aangemaakt.

Ruby on Rails, voor ontwikkelaars, is een complete opensource raamwerk in Ruby om snel en eenvoudig echte webapplicaties te schrijven. Rails neemt je veel werk uit handen zodat jij je kan concentreren op je idee. Nathan Torkington van het O'Reilly uitgeversimperium zei: "Ruby on Rails is verbijsterend. Het gebruik ervan lijkt op het kijken naar een kung-fu film, waar een groep slechte raamwerken de kleine nieuwkomer in elkaar willen slaan maar even later hun eigen lichaamsdelen aangeboden krijgen op diverse fantasievolle manieren." Aardige quote, nietwaar?

Meer informatie over onze producten en ons bedrijf kun je vinden op onze website: www.37signals.com.

---

Valkuilen, disclaimers, en andere preventieve maatregelen

Om ze bij voorbaat uit de weg te ruimen, zijn hier onze antwoorden op klachten die we zo nu en dan te horen krijgen:

"Deze technieken werken niet voor mij."

"Getting Real" is een systeem dat voor ons geweldig goed heeft gewerkt. Dit gezegd zijnde zullen de ideeën in dit boek niet van toepassing zijn op ieder project. Als je een wapensysteem, een verwerkingsfabriek voor nucleair afval, een systeem voor internetbankieren met miljoenen gebruikers, of een ander kritisch systeem maakt, dan zul je afhaken op onze "laissez-faire"-houding. Ga je gang en neem extra veiligheidsmaatregelen.

Het is geen alles of niets. Zelfs als je niet volledig op "Getting Real" kunt overstappen, dan zullen er tenminste een paar ideeën zijn die je kan binnensmokkelen.

"Dat idee komt niet van jullie."

We beweren niet dat we deze technieken hebben uitgevonden. Vele van deze concepten zijn er al enige tijd in de ene of andere vorm. Raak niet geïrriteerd als een advies van ons je herinnert aan iets dat je al eens ergens gelezen hebt op blog zus-of-zo, of in een boek van 20 jaar geleden. Dat is absoluut mogelijk. Deze technieken zijn beslist niet exclusief voor 37signals. We vertellen je alleen hoe we werken en wat voor ons succesvol is geweest.

"Je maakt het te zwart-wit."

Vergeef ons als onze toon wat eigenwijs overkomt. We denken dat het beter is om ideeën te presenteren in grove lijnen dan er wollig over te doen. Komt dat over als opgeblazen of arrogant, dan is dat zo. We zijn liever provocatief dan dat we alles laten verwateren met "het hangt ervan af..." Natuurlijk zullen er gelegenheden zijn dat deze regels moeten worden opgerekt of overtreden. En sommmige van deze tactieken hoeven niet van toepassing te zijn op jouw situatie. Gebruik je eigen oordeel en fantasie.

"Dit zal niet werken binnen ons bedrijf."

Vind je jezelf te groot voor "Getting Real"? Zelfs Microsoft is "Getting Real" (en we betwijfelen of jij groter bent dan zij).

Zelfs als je bedrijf gewoonlijk werkt met langetermijn-planning en grote teams, dan zijn er nog steeds domeinen voor "Getting Real". De eerste stap is om alles in kleinere stukken te breken. Wanneer er teveel mensen betrokken zijn komt er niets van de grond. Hoe slanker je bent, des te sneller — en beter — wordt alles gedaan.

Toegegeven, er zal wat overredingskracht aan te pas komen. Verkoop je bedrijf op het "Getting Real"-proces. Laat ze dit boek zien. Toon ze de tastbare resultaten die je kunt bereiken in minder tijd en met een kleiner team.

Leg uit dat "Getting Real" een methode is om nieuwe concepten uit te proberen met weinig risico en lage investeringen. Kijk of je je van het moederschip af kunt splitsen met een kleiner project als bewijs dat het werkt. Demonstreer resultaten.

Of, als je echt stoer wilt zijn, blijf dan in het verborgene. Vlieg onder de radar door en toon echte resultaten. Dat was de benadering van het Start.com-team terwijl ze "Getting Real" werkten bij Microsoft. "Ik heb het Start.com-team aan het werk gezien. Ze vragen geen toestemming," zegt Robert Scoble, Technical Evangelist bij Microsoft. "Ze hebben een baas die luchtdekking geeft. En ze nemen telkens kleine hapjes, voeren het uit en beantwoorden de feedback."

---

De starthoofdstuk 2

Bouw Minder

Doe onder voor je concurrentie

Volgens de gangbare opvatting moet je je concurrenten verslaan door ze te overbieden. Hebben zij vier features, dan doe jij er vijf (of 15, of 25). Geven zij x uit, dan doe jij xx. Hebben zij er 20, dan doe jij er 30.

Dit soort tegen elkaar opbieden, zoals in de tijd van de Koude Oorlog, leidt tot niets. Het is een dure, defensieve, en paranoïde manier van producten maken. Defensieve, paranoïde bedrijven kunnen niet vooruitdenken, ze kunnen alleen achteruitdenken. Ze leiden niet, ze volgen.

Als je een bedrijf wilt opbouwen dat volgt, dan kun je net zo goed dit boek nu neerleggen.

Dus, wat nu? Het antwoord is "minder". Doe minder dan je concurrenten om ze te verslaan. Los de simpele problemen op en laat de monsterlijke, moeilijke, akelige problemen aan de anderen over. In plaats van overbieden, probeer onderbieden. In plaats van overtreffen, probeer onderdoen.

We zullen het concept van "minder" door het hele boek behandelen, maar om te beginnen betekent "minder":

• Minder features
• Minder opties/voorkeuren
• Minder mensen and bedrijfsstructuur
• Minder vergaderingen en abstracties
• Minder beloften

---

Wat is Jouw Probleem?

Maak software voor jezelf

Een geweldige manier om software te maken is door te beginnen je eigen problemen op te lossen. Jij bent de doelgroep en jij weet wat belangrijk is en wat niet. Dat geeft je een geweldige voorsprong bij het leveren van een doorbraakproduct.

De sleutel is te begrijpen dat je niet alleen bent. Heb je dit probleem, dan ligt het voor de hand dat honderdduizenden anderen in hetzelfde schuitje zitten. Daar is je markt. Was dat niet gemakkelijk?

Basecamp ontstond vanuit een probleem: als ontwerpfirma hadden we een eenvoudige manier nodig om met onze cliënten over projecten te communiceren. We begonnen dit te doen via extranets voor klanten die we met de hand konden bijhouden. Maar iedere keer handmatig de HTML aanpassen werkte niet. Deze projectsites leken altijd bedorven te geraken en werden uiteindelijk verlaten. Het was frustrerend omdat het ons gedisorganiseerd maakte, en klanten in het ongewisse liet.

Dus begonnen we naar andere mogelijkheden te kijken. Maar iedere tool die we vonden hetzij 1) deed niet wat we nodig hadden, hetzij 2) was overladen met features die we niet nodig hadden — zoals factureren, stricte toegangsregels, charts, grafieken, etcetera. We wisten dat er een betere manier moest zijn en dus besloten we om zelf iets te maken.

Wanneer je je eigen probleem oplost, creëer je een tool waar je gepassioneerd over bent. En passie is de sleutel. Passie betekent dat je het echt gebruikt en dat je erom geeft. En dat is de beste manier om ook anderen gepassioneerd te doen zijn.

---

Financier jezelf

Geld van buiten is plan B

De hoogste prioriteit voor vele starters is om financiering te verkrijgen van investeerders. Maar onthoud, als je je voor financiering tot buitenstaanders wendt, dan moet je je ook tegenover hen verantwoorden. De lat ligt hoger. Investeerders willen hun geld terug — en snel. Het droevige is dat het incasseren het bouwen van een kwaliteitsproduct vaak in de weg staat.

Vandaag de dag is er niet veel voor nodig om te beginnen. Hardware is goedkoop en een overvloed aan infrastructurele software is open source en gratis. En passie kost niets.

Dus doe wat je kunt met het geld dat je hebt. Denk goed na en bepaal wat echt essentiëel is en waar je zonder kunt. Wat kun je doen met drie mensen in plaats van tien? Wat kun je doen met €20K in plaats van €100K? Wat kun je in drie maanden doen in plaats van zes? Wat kun je doen als je je baan voor overdag houdt en je applicatie ernaast doet?

Beperkingen dwingen creativiteit af

Werk met beperkte middelen en je wordt eerder en intenser gedwongen om rekening te houden met beperkingen. En dat is prima. Beperkingen zorgen voor innovatie.

Beperkingen dwingen je ook om je idee eerder in het wild uit te proberen — nog een goed iets. Een maand of twee na de lancering zou je een goed idee moeten hebben of het ergens toe zal leiden. Als dat zo is, dan zal je snel zelfbedruipend zijn en heb je geen geld van anderen nodig. Als het niks wordt met je idee, dan wordt het tijd om terug te keren naar je tekentafel. Je weet het tenminste nu al, en niet na maanden (of jaren). En je kan er tenminste gemakkelijk mee ophouden. Plannen om te stoppen worden een stuk linker eens er investeerders bij betrokken zijn.

Als je alleen software creëert om snel geld te verdienen, dan is dat eraan te zien. De waarheid is dat snel langs de kassa passeren tamelijk onwaarschijnlijk is. Dus concentreer op het bouwen van een kwaliteitstool waarmee jij en je klanten een lange tijd mee kunnen leven.

---

Leg tijd en budget vast, houdt projectbereik flexibel

Lanceer op tijd en binnen budget

Hier is een gemakkelijke manier om een product op tijd en binnen budget te lanceren: stel ze vast. Besteedt nooit extra tijd of geld aan een probleem, maar schaal in plaats daarvan de omvang terug.

Er bestaat een mythe die zegt dat we kunnen lanceren op tijd, binnen budget, en binnen het projectbereik. Dat gebeurt bijna nooit, en als het gebeurt lijdt de kwaliteit eronder.

Als je niet alles in de beschikbare tijd en budget kunt inpassen, vermeerder dan niet de tijd en het budget. Verklein in plaats daarvan het projectbereik. Er is altijd gelegenheid om later dingen toe te voegen — het later is er voor eeuwig; het nu is vluchtig.

Iets geweldigs lanceren dat wat beperkter is in voorzieningen dan gepland, is beter dan iets middelmatigs vol gaten publiceren omdat je één of ander magische tijd-, budget-, of werkingskader moest halen. Laat de tovenarij maar over aan Houdini. Je hebt een echt bedrijf te leiden en een echt product te leveren.

Dit zijn de voordelen van het vastleggen van tijd en budget, en het flexibel laten van de omvang:

• Prioriteiten

  Je moet uitvinden wat echt belangrijk is. Welke feature brengt het tot de eerste release? Dit dwingt je tot een beperking waarmee je moeilijke beslissingen zal doordrukken in plaats van te palaveren.

• Realiteit

  Verwachtingen zetten is de sleutel. Als je probeert tijd, budget en omvang vast te leggen, dan zul je niet in staat zijn om een hoog kwaliteitsniveau te bereiken. Zeker, je kunt waarschijnlijk wel iets leveren, maar is "iets" datgene wat je werkelijk wilt leveren?

• Flexibiliteit

  Het vermogen tot verandering is de sleutel. Verandering is lastig als alles vastligt. Het toevoegen van flexibiliteit in omvang geeft mogelijkheden die gebaseerd zijn op je ervaringen met het bouwen van het product. Flexibiliteit is je vriend.

Onze aanbeveling: verklein het bereik. Het is beter om een half product te maken, dan een halfhartig product (meer hierover later).

---

Heb een Vijand

Kies je gevecht

Soms is de beste manier om te weten wat je applicatie zou moeten zijn, te weten wat het niet zou moeten zijn. Vindt je applicatie's vijand en werp een licht op welke richting je uit moet gaan.

Toen we besloten om projectmanagement-software te maken, wisten we dat Microsoft Project de olifant in de kamer was. In plaats van bang zijn voor de olifant gebruikten we hem als motivatie. We besloten dat Basecamp iets compleet anders zou zijn, het anti-Project.

We realiseerden ons dat projectmanagement niet draait charts, grafieken, rapporten en statistieken — maar om communicatie. Het gaat ook niet om een projectmanager die bovenaan zit en een projectplan debiteert. Het gaat erom dat iedereen samen verantwoordelijkheid neemt om het project te laten werken.

Onze vijand waren de Projectmanagement-Dictators en de tools die ze gebruikten om met de zweep te slaan. We wilden projectmanagement democratiseren — en het maken tot iets waar iedereen deel van zou uitmaken (inclusief de klant). Projecten draaien beter uit wanneer iedereen gezamenlijk eigenaar wordt van het proces.

Toen we aan Writeboard begonnen, wisten we dat er concurrenten waren met massa's spectaculaire mogelijkheden. Dus besloten we de "geen gedoe"-invalshoek te benadrukken. We maakten een applicatie die mensen gemakkelijk ideeën liet uitwisselen en liet samenwerken, zonder ze vast te laten lopen op niet-essentiële features. Wanneer het niet essentiëel was, lieten we het weg. En in slechts drie maanden na lancering waren er al 100,000 Writeboards gecreëerd.

Toen we begonnen met Backpack waren structuur en rigide regels onze vijand. Mensen moeten in staat zijn om hun informatie te organiseren op hun eigen manier — niet gebaseerd op een reeks voorgeformatteerde schermen of een formulier met een mer à boire aan verplichte velden.

Een bonus die je krijgt voor het hebben van een vijand is een zeer duidelijke marketingboodschap. Mensen worden geprikkeld door conflict. En ook begrijpen ze een product door de vergelijking met een ander product. Met een gekozen vijand voedt je mensen met een verhaal dat ze willen aanhoren. Niet alleen begrijpen ze je product beter en sneller, ze kiezen ook partij. En dat is een zekere manier om aandacht te krijgen en passie te laten aanwakkeren.

Dit alles gezegd zijnde, is het ook belangrijk om niet te geobsedeerd te raken met de concurrentie. Overanalyseer andere producten en je beperkt je manier van denken. Neem een kijkje en ga vervolgens verder met je eigen visie en je eigen ideeën.

---

Het mag geen hele toer zijn

Je passie — of gebrek daaraan — schijnen erdoorheen

Hoe minder zwaar het karwei, des te beter je applicatie. Houd het kleinschalig en beheersbaar zodat je plezier hebt in het proces.

Als je applicatie je niet enthousiast maakt is er iets niet in orde. Als je er alleen aan werkt om ermee te verdienen, dan is dat te zien. Heb je passie voor je applicatie, dan is ook dat te zien. Mensen zijn heel goed in staat om tussen de regels door te lezen.

---

Blijf slank hoofdstuk 3

Minder massa

Hoe slanker je bent, des te gemakkelijker is verandering

Hoe massiever een object, des te meer energie nodig is om het van richting te doen veranderen. Dit is net zo waar in de zakenwereld als in de fysieke wereld.

Als het gaat om webtechnologie, dan moet verandering eenvoudig en goedkoop zijn. Als je het niet in een handomdraai kunt veranderen, dan verlies je je voorsprong aan iemand die dat wel kan. Daarom moet je je richten op minder massa.

Massa wordt vermeerderd door...

• Langetermijn-contracten
• Overtollige medewerkers
• Permanente beslissingen
• Vergaderingen over andere vergaderingen
• Het denkproces
• Voorraad (fysiek of mentaal)
• Hardware, software, technologie lock-ins
• Proprietaire dataformaten
• Het verleden dat de toekomst beheerst
• Langetermijnplanningen
• Kantoorpolitiek

Massa wordt verminderd door...

• Just-in-time denken
• Teamleden die verscheidene taken doen
• Beperkingen omarmen, en niet proberen opheffen
• Minder software, minder code
• Minder features
• Kleine teamgrootte
• Eenvoud
• Vereenvoudigde interfaces
• Open-source-producten
• Open dataformaten
• An open cultuur die het gemakkelijk maakt om fouten toe te geven

Minder massa laat je snel van richting veranderen. Je kunt reageren en evolueren. Je kunt je concentreren op goede ideeën en de slechte laten vallen. Je kunt luisteren naar klanten en respons geven. Je kunt nieuwe technologieën nu integreren of later. In plaats van een vliegdekschip, bestuur je een speedboat. Geniet van dit feit.

Bijvoorbeeld, laten we ons een slank, lichtgewicht bedrijf voorstellen dat een product heeft met minder software en minder features. Aan de andere kant hebben we een zwaarlijvig bedrijf dat een product heeft met significant meer software en meer features. Dan, laten we zeggen, verschijnt er een nieuwe technologie zoals Ajax of een nieuwe concept zoals tagging. Wie zal in staat zijn om dit eerder in hun product op te nemen? Het team met meer software en meer features en een stappenplan van 12 maanden, of het team met minder software en minder features en een meer organisch proces à la "laten we ons concentreren op waar we ons op moeten concentreren"-proces?

Natuurlijk is het minder-massa-bedrijf in een betere positie om zich aan te passen aan de werkelijke eisen van de markt. Het meer-massa-bedrijf zal waarschijnlijk nog steeds bezig zijn met het discussiëren van verandering of ze door een bureaucratisch proces heen krijgen lang nadat het minder-massa-bedrijf de omschakeling al heeft gemaakt. Het minder-massa-bedrijf zal twee stappen vooruit zijn terwijl het meer-massa-bedrijf nog moet uitvinden hoe het moet lopen.

Vlotte, wendbare, massa-arme bedrijven kunnen snel hun complete bedrijfsmodel, product, pakket features, of marketingboodschap veranderen. Ze kunnen fouten maken en ze snel herstellen. Ze kunnen hun prioriteiten veranderen, hun productmix, en zich concentreren. En vooral, ze kunnen van mening veranderen.

---

Verlaag je Kosten van Verandering

Blijf flexibel door obstakels voor verandering te verkleinen

Verandering is je beste vriend. Hoe duurder het is om een aanpassing te maken, hoe minder waarschijnlijk het is dat je hem maakt. En als je concurrenten sneller kunnen veranderen dan jij, dan ben je enorm in het nadeel. Zodra verandering te duur wordt, ben je er geweest.

Dit is waar slank blijven je uit de brand helpt. De mogelijkheid te veranderen voor een cent is iets dat kleine teams per definitie hebben en dat grote teams nooit hebben. Dit is waar de groten jaloers zijn op de kleintjes. Wat een groot team in een enorme organisatie weken kost, kost een kleine, slanke organisatie misschien een dag. Dat voordeel is onbetaalbaar. Goedkoop en snel aanpassen is het geheime wapen van Klein.

En onthoud: noch met geld, noch met marketing, noch met mensen koop je de wendbaarheid die je hebt door het klein zijn.

Als het gaat om webtechnologie, dan moet verandering eenvoudig en goedkoop zijn. Als je niet in een handomdraai kunt veranderen, verlies je terrein aan iemand die dat wel kan. Daarom moet je gaan voor minder massa.

---

De Drie Musketiers

Een Team van Drie voor versie 1.0

Voor de eerste versie van je applicatie begin je met slechts drie mensen. Dat is het magische getal dat je voldoende mankracht geeft en je toch toestaat om gestroomlijnd en beweeglijk te blijven. Begin met een programmeur, een ontwerper, en iemand die beide werelden kan overbruggen.

Het is een hele uitdaging om een applicatie te bouwen met niet meer dan een paar mensen. Maar als je het juiste team hebt, is het het waard. Getalenteerde mensen hebben geen eindeloze bronnen nodig. Ze teren op de uitdaging om te werken met beperkingen en op het gebruik van hun creativiteit om problemen op te lossen. Je gebrek aan mankracht betekent dat je gedwongen bent om eerder in het proces om te gaan met afwegingen — en dat is prima. Daardoor zul je je prioriteiten in een eerder stadium moeten bepalen. En je zult in staat zijn om te communiceren zonder je voortdurend zorgen te hoeven maken over mensen in de kou laten staan.

Als je je versie één niet met drie mensen kunt realiseren, dan heb je of andere mensen nodig, of je moet je eerste versie afslanken. Onthoud: het is prima om je eerste versie klein en strak te houden. Je zult er snel achterkomen of je idee vleugels heeft, en in dat geval heb je een schone, simpele basis om op verder te bouwen.

---

Omarm beperkingen

Laat begrenzingen je leiden naar creatieve oplossingen

Er is nooit genoeg om verder te komen. Niet genoeg tijd. Niet genoeg geld. Niet genoeg mensen.

Dat is een goed iets.

In plaats van je druk maken over deze beperkingen, omarm ze. Laat ze je leiden. Beperkingen stuwen innovatie en dwingen concentratie af. In plaats van te proberen ze te verwijderen, gebruik ze tot je voordeel.

Toen 37signals Basecamp ontwikkelde, hadden we vele beperkingen. We hadden:

• Een ontwerpfirma te besturen
• Bestaande klantenopdrachten
• 7 uur tijdsverschil (David deed het programmeerwerk in Denemarken, de rest van ons was in de VS)
• Een klein team
• Geen financiering van buitenaf

We voelden de "niet genoeg"-blues. Dus hielden we de menukaart klein. Zo konden de inbreng beperkt houden. We kozen grotere taken en braken ze in kleinere stukjes die we één voor één te lijf gingen. We gingen stap voor stap en bepaalden onze prioriteiten onderweg.

Dat dwong ons tot creatieve oplossingen. We verlaagden onze kosten van verandering door altijd minder software te maken. We gaven mensen juist genoeg features om hun eigen problemen op hun eigen manier op te lossen — en gingen dan uit de weg staan. Het tijdverschil en de afstand tussen ons maakten ons efficiënter in onze communicatie. In plaats van elkaar persoonlijk te ontmoeten, communiceerden we bijna uitsluitend via IM en e-mail, hetgeen ons dwong om snel tot de essentie te komen.

Beperkingen zijn vaak vermomde voordelen. Vergeet venture captical, lange uitgavecycli, en snelle aanwervingen. Werk in plaats daarvan met wat je hebt.

---

Wees Jezelf

Differentiëer jezelf van grote ondernemingen door persoonlijk en vriendelijk te zijn

Veel kleine bedrijven maken de fout van het proberen zich groot te gedragen. Het is alsof ze het hun grootte als een zwakheid zien die verborgen moet worden. Jammer. Kleinschaligheid kan feitelijk een groot voordeel zijn, vooral als het gaat om communicatie.

Kleine bedrijven genieten minder formaliteit, minder bureaucratie, en meer vrijheid. Kleinere bedrijven zijn dichter bij de klant, per definitie. Dat betekent dat ze kunnen communiceren in een directere en meer persoonlijke manier met hun klanten. Als je klein bent, kun je familiaire taal gebruiken in plaats van jargon. Je website en je product kunnen een menselijke stem hebben in plaats van te klinken als een bedrijfsmatig deuntje. Klein zijn betekent dat je mét je klanten kunt praten, in plaats van op ze in praten.

Er zijn ook voordelen van interne communicatie bij kleine bedrijven. Je kunt de formaliteiten laten vervallen. Er is geen nood aan lastig processen en meervoudige ondertekeningen voor vanalles. Iedereen in het proces kan open en eerlijk spreken. Deze ongeremde stroom ideeën is één van de grote voordelen van klein blijven.

---

Prioriteiten hoofdstuk 4

Wat is het Grote Idee?

Onderscheid jezelf van grotere bedrijven door persoonlijk en vriendelijk te zijn

Definiëer expliciet die ene visie voor je applicaite. Waar staat zij voor? Waar draait het allemaal om? Voordat je begint iets te ontwerpen of programmeren, moet je het doel van je product weten — de visie. Denk groot. Waarom bestaat het? Wat onderscheidt het van andere, vergelijkbare producten?

Deze visie gidst je beslissingen en houdt je op een consistente weg. Wanneer er een knelpunt is, vraag dan: "Blijven we trouw aan de visie?"

Je visie moet ook kort zijn. Eén zin moet genoeg zijn om het idee over te brengen. Hier is de visie voor elk van onze producten:

• Basecamp: Projectmanagement is communicatie
• Backpack: Breng de losse eindjes in het leven samen
• Campfire: Groepchat via IM slaat nergens op
• Ta-da List: Concureer met de Post-It!-note
• Writeboard: Word is overkill

Bij Basecamp bijvoorbeeld was de visie "Projectmanagement is communicatie". We waren er sterk van overtuigd dat effectieve projectcommunicatie leidt tot collectief eigendom, betrokkenheid, investering, en momentum. Je krijgt alle neuzen dezelfde kant op voor hetzelfde gezamenlijke doel. We wisten dat als Basecamp dit voor elkaar zou brengen, de rest vanzelf zou gaan.

Deze visie hielp ons Basecamp zo open en transparant mogelijk te maken. In plaats van de communicatie te beperken tot binnen de firma, gaven we de klanten ook toegang. We dachten minder over permissies en meer over het aanmoedigen van alle deelnemers om deel te nemen. Deze visie maakte dat we charts, gafieken, tabellen, rapportages, statistieken en spreadsheets weglieten en ons in plaats daarvan concentreerden op communicatieprioriteiten zoals berichten, commentaar, taaklijsten, en bestanden delen. Maak de grote beslissing over je visie aan het begin, en al je toekomstige kleine beslissingen worden veel gemakkelijker.

---

Negeer details in het begin

Werk van groot naar klein

We're zijn gek op details.

• De ruimte tussen objecten
• De perfecte regelhoogte
• The perfect kleur
• The perfect woorden
• Vier regels code in plaats van zeven
• 90% vs 89%
• 760px vs 750px
• $39/maand vs. $49/maand

Succes en voldoening zitten in de details.

Echter, succes is niet het enige dat je vindt in de details. Je vindt er ook stagnatie, verschil van mening, vergaderingen, en vertraging. Deze zaken kunnen het moraal vernietigen en je kansen op succes verminderen.

Hoe vaak ben je al een hele dag blijven steken op één enkel design- of code-element? Hoe vaak heb je je gerealiseerd dat de vooruitgang die je vandaag geboekt had geen echte vooruitgang was? Dit gebeurt als je je te vroeg in het proces op details concentreert. Er is meer dan genoeg tijd voor perfectionisme. Doe het gewoon later.

Maak je geen zorgen over de lettergrootte van de koptekst in de eerste week. Je hoeft niet die perfecte tint groen te vinden in week twee. Je hoeft die "submit"-knop drie pixels naar rechts te verschuiven in week drie. Zet, voor nu, gewoon alles op de pagina, en gebruik het. Zorg ervoor dat het werkt. Later kun je aanpassen en perfectioneren.

Details onthullen zichzelf wanneer je gebruikt wat je aan het maken bent. Je ziet vanzelf waar je meer aandacht aan moet besteden. Je voelt vanzelf wat er ontbreekt. Je weet welke gaten gedicht moeten worden omdat je er zelf tegenaan loopt. Dat is het moment dat je er aandacht aan moet besteden, en niet eerder.

---

Het is pas een Probleem wanneer het een Probleem is

Verspil geen tijd aan problemen die je nog niet hebt

Is het echt noodzakelijk om je zorgen te maken over schalen naar 100.000 gebruikers vandaag, als het je twee jaar kost om zover te komen?

Moet je werkelijk acht programmeurs huren als je er vandaag maar drie nodig hebt?

Heb je werkelijk 12 van de allerduurste servers nodig als je dit jaar ook met twee vooruit kunt?

Smijt het eruit

Mensen besteden vaak bij voorbaat teveel tijd aan het oplossen van problemen die ze nog niet hebben. Doe het niet. Man, we begonnen met Basecamp nog zonder de mogelijkheid om klanten te factureren! Omdat het product in maandelijkse termijnen werd gefactureerd, wisten we dat we 30 dagen de tijd hadden om het uit te zoeken. We gebruikten die tijd om urgentere problemen op te lossen en pas toen, na de lancering, gingen we de facturering te lijf. Het liep goed af (en het dwong ons tot een eenvoudige oplossing zonder overbodige toeters en bellen).

Werk je nergens voor in het zweet totdat het echt moet. Overdrijf niet. Voeg hardware en software toe wanneer het nodig is. Eén of twee weken traagheid is niet het einde van de wereld. Wees gewoon eerlijk: leg je klanten uit dat je last hebt van wat groeipijnen. Ze zullen niet dolenthousiast zijn, maar wel de eerlijkheid op prijs stellen.

Kortom: neem beslissingen op precies het juiste moment, wanneer je toegang hebt tot de echte informatie die je nodig hebt. In de tussentijd kun je voldoende aandacht geven aan de dingen die onmiddellijke aandacht vragen.

---

Neem de Juiste Klanten aan

Vind de kernmarkt voor je applicatie en concentreer je uitsluitend daarop

De klant heeft niet altijd gelijk. De waarheid is dat je moet uitklaren wie gelijk heeft en wie niet voor jou applicatie. Het goede nieuws is dat het internet het gemakkelijker dan ooit maakt om de juiste mensen te vinden.

Wie iedereen wil plezieren, doet niemand een plezier

Toen we Basecamp maakten concentreerden we onze marketing op de ontwerpbureaus. Door onze markt op deze manier te beperken, zouden we aannemelijkerwijs gepassioneerde klanten aantrekken die op hun beurt, het product zouden uitdragen. Weet voor wie je applicatie werkelijk bedoeld is en richt je erop om hen een plezier te doen.

---

Later schalen

Je hebt geen schaalprobleem - nog niet

"Gaat mijn applicatie schalen als miljoenen gebruikers het gaan gebruiken?"

Weet je wat? Wacht tot het echt gebeurt. Als een groot aantal mensen je systeem overlaadt dan hoera! Dat is een zalig probleem om te hebben. De waarheid is dat de overweldigende meerderheid van webaplicaties nooit dat stadium bereikt. En zelfs als je begint in de overload-problemen te komen is het nog geen kwestie van alles of niets. Je zult tijd hebben om aanpassingen te doen en een antwoord op het probleem te vinden. Plus, je zult na de lancering meer echte gegevens en benchmarks hebben die je kunt gebruiken om uit te vinden op welke gebieden verbetering nodig is.

Zo liep Basecamp in het eerste jaar op een enkele server. Omdat we begonnen met zo'n simpele opzet kostte het niet meer dan een week om te implementeren. We begonnen niet met een cluster van 15 machines, noch maakten we ons maandenlang zorgen over schaalbaarheid.

Werden we geconfronteerd met problemen? Een paar. Maar we realiseerden ons ook dat de meeste problemen waar we bang voor waren, zoals een korte vertraging, niet echt een groot probleem waren voor onze klanten. Zolang je mensen op de hoogte houdt, en je eerlijk bent over de situatie, zullen ze het begrijpen. Achteraf gezien zijn we heel blij dat we niet maanden later zijn begonnen met een "perfecte set-up".

Maak in het begin het bouwen van een solide kernproduct je prioriteit, in plaats van geobsedeerd te zijn over schaalbaarheid en serverfarms. Creëer een geweldige applicatie en maak je dan pas zorgen over wat te doen bij geweldig succes. Anders zou je energie, tijd en geld kunnen verspillen aan het vastleggen iets dat nooit voorkomt.

Geloof het of niet, het grotere probleem is niet schalen, het probleem is het bereiken van het punt waarop je moet schalen. Zonder het eerste probleem zul je het tweede nooit hebben.

---

Maak geopiniëerde software

Je applicatie moet partij kiezen

Sommige mensen beweren dat software agnostisch moet zijn. Ze zeggen dat het arrogant is als ontwikkelaars features beperken of verzoeken om features negeren. Ze zeggen dat software altijd zo flexibel als mogelijk moet zijn.

Wij denken dat dat gelul is. De beste software heeft een visie. De beste software kies partij. Als iemand software gebruikt, zijn ze niet allen op zoek naar features, maar ook naar een benadering. Ze zijn op zoek naar een visie. Bepaal wat de visie is en ga ervoor.

En onthoud, voor wie het niet met je visie eens is, zijn er vele andere visies te vinden. Ga geen mensen achterna die je toch niet gelukkig kunt maken.

Een geweldig voorbeeld is het originele wiki-ontwerp. Ward Cunningham en vrienden ontdeden de wiki opzettelijk van vele features die vroeger als integraal onderdeel van documentsamenwerking werden beschouwd. In plaats van iedere verandering van het document aan een bepaalde persoon toe te wijzen, verwijderden ze veel van de visuele representatie van eigendom. Ze maakten de inhoud ego- en tijdloos. Ze besloten dat niet belangrijk was wie de content had geschreven of wanneer het was geschreven. En dat maakte alle verschil. Deze beslissing bevordert een gedeeld gevoel van gemeenschap en was een sleutelingrediënt in het succes van Wikipedia.

Onze applicaties volgen een vergelijkbaar pad. Ze proberen niet alles tegelijk te zijn voor iedereen. Ze hebben een attitude. Ze zoeken naar klanten die ook partners zijn. Ze spreken mensen aan die onze visie delen. Je bent aan boord of niet.

---

Features selecteren hoofdstuk 5

Half, niet halfslachtig

Maak een half product, geen halfslachtig product

Kijk uit voor de alles-behalve-een-lavabo-benadering voor webapplicatie-ontwikkeling. Gooi ieder bruikbaar idee dat voorbij komt erin, en je eindigt met alleen een halfslachtige versie van je product. Wat je werkelijk wilt is een half product bouwen dat imponeert.

Blijf bij wat werkelijk essentiëel is. Goede ideeën kunnen op tafel gelegd worden. Neem wat je denkt dat je product zou moeten zijn en snijd het in tweeën. Verminder het aantal features totdat je overblijft met alleen de meest essentiële. Do het dan nog een keer.

Voor Basecamp begonnen we met alleen het "messages"-gedeelte. We wisten dat dat het hart van de applicatie zou worden dus negeerden we "milestones", "to-do lists", en andere dingen voorlopig. Daardoor konden we de toekomstige beslissingen nemen op grond van "real-world"-gebruik in plaats van instinct.

Begin met een slanke, slimme applicatie en laat het snelheid maken. Daarna kun je beginnen met toevoegingen maken aan de fundering die je gebouwd hebt.

---

Het Doet Er Niet Toe

Alleen de Essentie

Ons favourite antwoord op "waarom niet zus of zo?" is altijd: "Omdat het er niet toe doet." Deze verklaring belichaamt wat een product groot maakt. Je moet uitvinden wat ertoe doet, en de rest weglaten.

Toen we Campfire lanceerden hoorden van de eerste gebruikers bijvoorbeeld dit soort vragen:

"Waarom tijdsmarkeringen per 5 minuten? Waarom geen tijdsmarkeringen op iedere chatregel? Antwoord: Het doet er niet toe. Hoe vaak hoef je werkelijk een conversatie per seconde of zelfs maar per minuut te kunnen volgen? Minstens 95% van de tijd hoeft dat niet. Tijdsmarkeringen per 5 minuten zijn voldoende omdat alles specifieker er gewoon niet toe doet.

"Waarom laten jullie geen formattering in vet, cursief of kleur toe in de chats?" Antwoord: Het doet er niet toe. Als je iets wilt benadrukken, gebruik de vertrouwde 'caps lock'-toets, of zet een paar asterisken rond het woord of de frase. Deze oplossingen vereisen geen extra software, tech support, processing-kracht, of leercurve. Bovendien: zware formattering in een simpele, tekstgebaseerde chat doet er gewoon niet toe.

"Waarom tonen jullie niet het totaal aantal mensen in de chatroom op een bepaald moment?" Antwoord: Het doet er niet toe. Ieders naam staat in de lijst dus je weet wie er is, en wat voor verschil maakt het of we met zijn twaalven of met zijn zestienen zijn? Als niets met dat soort informatie doet, doet het er ook niet toe.

Is dit soort features leuk om te hebben? Zeker. Maar zijn ze essentiëel? Doen ze er echt toe? Njet. En daarom hebben we ze weggelaten. De beste designers en de beste programmeurs zijn niet degenen met de beste vaardigheden, of de vlugste vingers, of degenen die kunnen rock-and-rollen met Photoshop of hun eigen ontwikkelomgeving, nee, het zijn degenen die kunnen bepalen wat er gewoon niet toe doet. Dat is waar de echte verbeteringen worden bereikt.

De meeste tijd wordt verspild aan dingen die er niet toe doen. Als je het werk en het denkwerk dat er niet toe doet kan uitsluiten, bereik je productiviteit die je je nooit hebt kunnen voorstellen.

---

Begin met Nee

Maak features moeilijk implementeerbaar

Het geheim van het maken van een half product in plaats van een halfslachtig product, is nee zeggen.

Iedere keer dat je "ja" zegt tegen een feature, adopteer je een kind. Je moet je kindje meenemen door een hele keten van schakels (t.w. ontwerp, implementatie, testen, etc). En zodra die feature er is, dan zit je eraan vast. Probeer maar eens een gereleasde feature weg te nemen van klanten en kijk hoe woest ze worden.

Wees geen ja-knikker

Maak iedere feature moeilijk te implementeren. Maak dat iedere feature zichzelf bewijst en aantoont dat het een overlever is. Net zoals "Fight Club". Je moet enkel features overwegen die bereid zijn om drie dagen op de stoep te wachten om binnengelaten te worden.

Daarom begin je met nee. Ieder nieuw verzoek om een feature dat ons bereikt — of van onszelf — wordt geconfronteerd met een "nee". We luisteren maar doen niets. Het eerste antwoord is "niet nu". Als een verzoek om een feature terug blijft komen, dan weten we dat het tijd wordt om verder te kijken. Dan, en alleen dan, beginnen we een feature werkelijk te overwegen.

En wat zeg je tegen mensen die klagen wanneer je hun idee voor een feature niet opneemt? Herinner ze eraan waarom ze ook al weer van de applicatie houden. "Je houdt ervan omdat we nee zeggen. Je houdt ervan omdat het 100 andere dingen niet doet. Je houdt ervan omdat het niet iedereen tegelijk probeert te plezieren."

---

Verborgen Kosten

Achterhaal de prijs van nieuwe features

Zelfs wanneer een feature de "nee"-fase voorbij komt, moet je nog steeds haar verborgen kosten kwantificeren.

Wees bijvoorbeeld bedacht op "feature loops" (d.w.z. features die leiden tot meer features). We kregen verzoeken om een "meetings"-tabblad aan Basecamp toe te voegen. Dat lijkt eenvoudig genoeg totdat je er goed naar kijkt. Denk aan alle onderdelen die zo'n tabblad met zich meebrengt: locatie, tijd, kamer, mensen, uitnodigingen e-mailen, kalender-integratie, documentatie voor productondersteuning, etcetera. Om nog maar te zwijgen van het aanpassen van promotie-screenshots, rondleiding-pagina's, FAQ/hulppagina's, de gebruiksvoorwaarden, en meer. Voordat je het weet leidt zo'n eenvoudig idee tot een lawine, en een flinke hoofdpijn.

Voor iedere nieuwe feature moet je...

• 1. Nee zeggen.
• 2. De feature dwingen haar waarde te bewijzen.
• 3. Indien weer "nee", stop hier. Zo "ja", ga door...
• 4. Schets de schermen/gebruikersinterface.
• 5. Ontwerp de schermen/gebruikersinterface.
• 6. Schrijf de code.
• 7-15. Testen, aanpassen, testen, aanpassen, testen, aanpassen...
• 16. Controleer of de hulpteksten moeten worden aangepast.
• 17. Werk de productrondleiding bij (indien nodig).
• 18. Werk de marketingteksetn bij (indien nodig).
• 19. Werk de gebruiksvoorwaarden bij (indien nodig.).
• 20. Controleer of beloften gebroken zijn.
• 21. Controleer of de prijsstructuur is beïnvloed.
• 22. Lanceer.
• 23. Houd je adem in.

---

Kun je het aan?

Maak iets dat je kunt beheersen

Wanneer je een partnerprogramma lanceert, heb je de systemen beschikbaar om de boekhouding en de betalingen te regelen? Misschien zou je mensen alleen een crediet op hun lidmaatschapsgelden moeten geven in plaats van iedere maand een overboeking te moeten doen.

Kun je het je veroorloven om 1GB schijfruimte web te geven alleen maar omdat Google dat doet? Misschien moet je klein beginnen met 100MB, en alleen meer ruimte bieden op betaalde accounts.

Slotsom: bouw producten en bied diensten die je kunt beheersen. Het is gemakkelijk om beloften te maken. Het is veel moeilijker om je eraan te houden. Verzeker je ervan dat wat je doet beheersbaar is — organisatorisch, strategisch, en financiëel.

---

Menselijke Oplossingen

Maak software voor algemene concepten en moedig mensen aan om hun eigen oplossingen te creëren

Smeer mensen geen conventies aan. Maak in plaats daarvan je software algemeen zo dat iedereen zijn eigen oplossing kan vinden. Geef mensen juist genoeg om hun eigen problemen op hun eigen manier op te lossen. Ga dan uit de weg staan.

Toen we "Ta-da List" maakten lieten we er opzettelijk een heleboel dingen uit. Er is geen manier om een "to-do" aan iemand toe te wijzen, er is geen manier om een datum te markeren, geen manier om items te categoriseren, etcetera.

We hielden de tool schoon en netjes door mensen creatief te laten zijn. Mensen vonden vanzelf manieren om met die zaken om te gaan. Als ze een datum aan een to-do wilden toevoegen konden ze gewoon (tegen 7 april 2006) erbij schrijven. Als ze een categorie wilden toevoegen, konden ze gewoon [Boeken] aan het begin van een item toevoegen. Ideeal? Nee. Oneindig flexibel? Ja.

Hadden we geprobeerd om software te schrijven om specifiek met deze scenario's om te gaan, dan was het minder bruikbaar geweest voor alle gevallen waarin deze zaken niet van toepassing zijn.

Werk zo goed als je kunt aan de kern van het probleem en ga dan opzij. Mensen vinden hun eigen oplossingen en gewoontes binnen het algemene concept.

---

Vergeet feature-aanvragen

Laat je klanten je eraan herinneren wat belangrijk is

Klanten willen het beste onder de zon. Ze zullen je bedelven onder feature aanvragen. Kijk maar in onze productforums; de "feature request"-categorie verslaat de andere met grote afstand.

We horen van "deze kleine extra feature" of "dit kan niet moeilijk zijn" of "zou het niet gemakkelijk zijn om dit erbij te doen" of "het zou maar een paar seconden kosten om dit erin te doen" enzovoorts.

Natuurlijk verwijten we niemand het doen van aanvragen. We moedigen het aan en we willen horen wat men te zeggen heeft. Bijna alles wat we aan onze producten toevoegen begint met een vraag van een klant. Maar, zoals we al eerder noemden, je eerste antwoord moet "nee" zijn. Dus wat doe je met al die binnenstromende verzoeken? Waar sla je ze op? Hoe ga je met ze om? Gewoon, niet. Je leest ze en gooit ze weg.

Inderdaad, lezen, weggooien en vergeten. Het klinkt blasfemisch, maar de belangrijke blijft steeds weer opborrelen. Die je moet onthouden. Dat zijn de werkelijk essentiële. Maak geen punt van het bijhouden en opslaan van ieder verzoek dat binnenkomt. Laat je klanten je geheugen zijn. Als het echt de moeite van het onthouden waard is, dan zullen ze je eraan blijven herinneren tot je het niet meer kunt vergeten.

Hoe kwamen we tot deze conclusie? Toen we Basecamp voor het eerst lanceerden hielden we alle grote feature-aanvragen bij in Basecamp met een to-do-lijst. Wanneer een verzoek door een ander herhaald werd, turfden we een extra teken in de lijst (II of III of IIII, etc). We dachten ooit de lijst te bekijken en te beginnen met de meest verzochte vraag en zo verder.

Maar in werkelijkheid keken we er nooit meer naar om. We wisten al wat we het eerst moesten doen omdat onze klanten ons er voortdurend aan herinnerden, door steeds dezelfde verzoeken te doen. Er was geen noodzaak voor een lijst of uitgebreide analyse omdat het allemaal al in real-time gebeurde. Je kunt helemaal niet vergeten wat belangrijk is als je er iedere dag aan herinnerd wordt.

En nog iets: dat een x aantal mensen iets vraagt, betekent niet dat je het ook hoeft te doen. Soms is het beter om nee te zeggen en je visie voor het product in stand te houden.

---

Zonder mayonaise

Vraag mensen wat ze niet willen

De meeste software enquêtes en onderzoeksvragen gaan over wat mensen willen in een product. "Welke feature denk je dat eraan ontbreekt?" "Als je er één ding aan mocht toevoegen, wat zou het zijn?" "Wat zou dit product beter bruikbaar voor je maken?"

Wat dacht je van andersom? Waarom niet vragen wat men niet wil? "Als je één feature zou kunnen verwijderen, wat zou het zijn?" "Wat gebruik je niet?" "Wat loopt je het meest in de weg?"

Meer is het antwoord niet. Soms bewijs je je klanten de grootste dienst door iets weg te laten.

---

Het Proces hoofdstuk 6

Race naar werkende software

Maak iets werkends — en vlug

Werkende software is de beste manier om momentum te bouwen, je team te laten racen, en ideeën die niet werken weg te spoelen. Dat moet vanaf de eerste dag je hoogste prioriteit zijn.

Het is prima om minder te doen, details over te slaan, of een kortere weg te nemen in je proces als het leidt naar sneller iets werkend krijgen. Zodra je daar bent, word je beloond met aanzienlijk meer accuraat perspectief op hoe je verder moet. Verhalen, draadgrafieken, zelfs HTML voorontwerpen zijn slechts benaderingen. Werkende software is echt.

Met echte, werkende software komt iedereen dichterbij werkelijk begrip en overeenstemming. Je vermijdt verhitte ruzies over schetsen en paragrafen die er uiteindelijk niet toe blijken te doen. Je realiseert je dat onderdelen die triviaal leken in feite cruciaal zijn.

Echte dingen leiden tot echte reacties. En zo moet je de waarheid bereiken.

---

Spoel terug en herhaal

Werk in iteraties

Verwacht niet om het de eerste keer goed te krijgen. Laat de applicatie groeien en tot je spreken. Laat het vervormen en evolueren. Met web-based software is er geen noodzaak om perfectie te leveren. Ontwerp schermen, gebruik ze, analyseer ze, en begin dan opnieuw.

In plaats van te wagen dat je alles direct goed gaat, laat het iteratieve proces je doorgaan met het nemen van geïnformeerde beslissingen. Bovendien krijg je je applicatie sneller in werking omdat je niet onmiddellijk streeft naar perfectie. Het resultaat is echte feedback en echte gids voor wat je aandacht nodig heeft.

Iteraties leiden tot bevrijding

Je hoeft je niet al met de eerste poging op perfectie te richten als je weet dat het later toch weer over wordt gedaan. Weten dat je dingen opnieuw gaat bekijken is een grote motivatie om ideeën uit te brengen om te zien of ze het halen.

---

Van Idee naar Implementatie

Ga van brainstorms naar schetsen naar HTML naar programmeren

Dit is het proces dat we gebruiken "to Get Real":

Brainstorm

Kom met ideeën. Wat gaat dit product doen? Voor Basecamp keken we naar onze eigen noden. We wilden project-updates posten. We wilden klanten laten participeren. We wisten dat projecten "milestones" hadden. We wilden centrale opslag zodat men eenvoudig oud materiaal kon terugzien. We wilden een "big picture", een overzicht in vogelvlucht van wat er allemaal in onze projecten omging. Samen dienden deze aannames, en een paar andere, als onze fundering.

Dit stadium gaat niet over de pietluttige-details. Dit gaat over de grote vraagstukken. Wat moet de applicatie kunnen doen? Hoe weten we wanneer het zinvol is? Wat precies gaan we maken? Dit gaat over ideeën op hoog niveau, geen discussie op pixel-niveau. In dit stadium zijn dit soort details eenvoudig van geen betekenis.

Schetsen op papier

Schetsen zijn gemakkelijk en goedkoop en dat is precies hoe je wilt beginnen. Teken. Krabbel. Vierkanten, circels, lijnen. Haal je ideeën uit je hoofd en zet ze op papier. Het doel voor nu is om concepten om te zetten in ruwe interface-ontwerpen. Deze step heeft alles te maken met experimenteren. Er zijn geen verkeerde antwoorden.

Creëer HTML-schermen

Maak een HTML-versie van die feature (of sectie of flow, als dat van toepassing is). Breng iets echts uit zodat iedereen kan zien hoe het er op het scherm uitziet.

Voor Basecamp deden we eerst het "post a message"-scherm, toen het "edit a message"-scherm, en daarvandan verder.

Schrijf nog geen programmacode. Bouw gewoon een model in HTML en CSS. Implementatie komt later.

Coderen maar

Als de model er goed uitziet en voldoende van de noodzakelijke functionaliteit laat zien, ga dan verder en stop de programmacode erin.

Onthoud tijdens dit hele proces om flexibel te blijven en meerdere iteraties te verwachten. Je moet de vrijheid voelen om het onderdeel weg te gooien en opnieuw te beginnen als het niks blijkt te zijn. Het is normaal om meermalen door deze cyclus heen te gaan.

---

Vermijd Voorkeuren

Beslis over de kleine details zodat de klanten niet hoeven

Je wordt geconfronteerd met een moeilijke beslisingen: hoeveel berichten doen we op een pagina? Je eerste neiging zou kunnen zijn om te zegen, "Laten we er een voorkeurinstelling van maken waar mensen kunnen kiezen tussen 25, 50, of 100". Dat is de gemakkelijke uitweg niettemin. Neem gewoon een beslissing.

Voorkeuren zijn een manier om moeilijke beslissingen te vermijden

In plaats van je expertise te gebruiken om de beste weg te kiezen, draag je het probleem over aan je klanten. Het lijkt alsof je ze een plezier doet maar feitelijk laat je het zware werk aan hen over (en waarschijnlijk hebben ze het al druk genoeg). Voor klanten zijn voorkeurschermen met een eindeloze hoeveelheid opties pure hoofdpijn, geen zegening. Klanten zouden niet hoeven nadenken over ieder pietluttig detail — plaats die last niet op hun schouders wanneer dat jouw verantwoordelijkheid zou moeten zijn.

Voorkeuren zijn ook een kwaad omdat ze meer software creëren. Meer opties vereisen meer code. En dan zijn er alle extra testen en ontwerpen die je moet doen. Je eindigt ook met voorkeur-permutaties en interface-schermen die je zelf nooit ziet. Dat betekent weer bugs waar je niet van af weet: gebroken lay-outs, zwakke tabellen, rare pagineerfouten, etcetera.

Jij beslist

Neem simpele beslissingen in naam van je klanten. Dat is wat we deden in Basecamp. Het aantal berichten per pagina is 25. Op de overzichtspagina zie je de laatste 25 items. Berichten worden gesorteerd in omgekeerd chronologische volgorde. De vijf meest recente projectn worden getoond in de dashboard. Er zijn geen opties. Dat is gewoon zoals het is.

Ja, je zou een verkeerde beslissing kunnen nemen. Nou en? Als het gebeurt komen ze wel bij je klagen. Als altijd, kun je aanpassen. "Getting Real" gaat helemaal om de mogelijkheid om "on-the-fly" aan te passen.

---

"Klaar!"

Beslissingen zijn tijdelijk dus neem een beslissing en ga door

Klaar. Begin erover te denken als een magische term. Als je iets klaar hebt betekent het dat er iets bereikt is. Een beslissing is gemaakt en je kunt verder. Klaar betekent dat je momentum opbouwt.

Maar wacht eens, wat dan als je het verknoeit en de verkeerde beslissing neemt? Dat is prima. Het gaat niet over hersenchirurgie, het is een webapplicatie. Zoals we blijven zeggen, je zult tijdens het proces waarschijnlijk sowieso features en ideeën meerdere keren moeten bekijken. Hoeveel je ook plant, je hebt waarschijnlijk toch de helft verkeerd. Doe niet aan "paralyse door analyse". Dat vertraagt alleen de voortgang en zuigt de moraal weg.

Waardeer in plaats daarvan het belang van doorgaan en verdergaan. Kom in het ritme van beslissingen nemen. Maak een snelle, eenvoudige beslissing en kom terug op die beslissing als zij niet werkt.

Accepteer dat beslissingen tijdelijk zijn. Accepteer dat fouten zullen plaatsvinden en realiseer je dat het geen punt is zolang je weet dat je ze snel kunt herstellen. Voer uit, bouw momentum, en ga verder.

---

Test in het Wild

Test je applicatie via "real-world"-gebruik

Er is geen substituut voor echte mensen die je applicatie op echte manieren gebruiken. Echte data. Echte feedback. Dan, verbeter op basis van die informatie.

Formeel testen van gebruiksvriendelijkheid is te stijf. Een laboratoriumomgeving heeft niets met de werkelijkheid te maken. Als je van achter iemand's schouder kijkt, krijg je een idee wat werkt en wat niet, maar over het algemeen presteren mensen niet goed voor een camera. Als er iemand kijkt, worden mensen vooral voorzichtig om geen fouten te maken — alleen zijn die fouten nu juist waar je naar op zoek bent.

Lanceer in plaats daarvan beta-features voor een paar insiders. Laat ze de beta-features samen met de bestaande features gebruiken. Dit brengt deze features naar de echte gegevens en de echte werkomstandigheden van mensen. En daar krijg je de echte resultaten.

Verder, doe niet aan een release-versie en een bèta-versie. Die moeten altijd hetzelfde zijn. Een afzonderlijke bèta krijgt alleen een kunstmatige doorloop. De echte versie, met een paar bèta-features ertussendoor, maken een volledig pakket

---

Krimp je Tijd

Breek in stukjes

Schattingen van weken of maanden zijn fantasie. De waarheid is dat je zo lang van tevoren gewoon niet weet wat er gaat gebeuren.

Dus krimp je tijd. Blijf tijdsvensters in kleine stukjes breken. Denk in plaats van aan een project van 12 weken, aan 12 projecten van een week. In plaats van een wilde slag slaan naar taken van 30 en meer uren, breek ze in realistischer stukken van 6-10 uur. Ga dan stap voor stap verder.

Dezelfde theorie geldt ook voor andere problemen. Word je geconfronteerd met een probleem dat te groot is om te bevatten? Breek het in stukken. Blijf problemen in kleinere en kleinere stukjes onderverdelen totdat je in staat bent om ze te verteren.

---

De Organisatie hoofdstuk 7

Eenheid

Splits niet op in silo's

Teveel bedrijven scheiden ontwerp, ontwikkeling, tekstschrijven, ondersteuning, en marketing in verschillende silo's. Hoewel specialisatie haar voordelen heeft, creëert ze ook een situatie waarin werknemers alleen hun eigen kleine wereld zien in plaats van de gehele contekst van de webapplicatie.

Integreer je team zoveel mogelijk zodat er een gezonde heen-en-weer-dialoog is tijdens het proces. Zet een proces op van controles en afwegingen. Laat niets verloren gaan bij de vertaling. Laat copywriters samenwerken met ontwerpers. Verzeker je ervan dat support-vragen worden gezien door programmeurs.

Beter zelfs, huur mensen in met meerdere talenten die verschillende petten kunnen dragen tijdens de ontwikkeling. Het eindresultaat zal een harmonieuzer product zijn.

---

Tijd alleen

Mensen hebben ononderbroken tijd nodig om dingen af te krijgen

37signals is verspreid over vier steden en acht tijdzones. Onze vijf mensen van Provo, Utah tot Kopenhagen, Denemarken, zitten acht uur uit elkaar. Eén positief bij-effect hiervan is tijd alleen.

Slechts gedurende 4-5 uur per dag zijn we allemaal tegelijk aan het werk. Op andere momenten slaapt het US team terwijl David, die in Denemarken zit, aan het werk is. De rest van de tijd zijn wij aan het werk terwijl David slaapt. Dit geeft ons ongeveer een halve dag samen en de andere helft alleen.

Raad eens in welk deel van de dag we het meeste werk gedaan krijgen? Het deel dat we alleen zijn. Dat is eigenlijk niet zo verbazend. Veel mensen werken graag of heel vroeg in de ochtend of laat in de avond — tijden waarop ze niet worden lastig gevallen.

Wanneer je een lang uitgestrekte tijd hebt waarin je niet wordt gestoord, dan kun je in de "zone" terechtkomen. De zone is waar je het meest productief bent. Dat is wanneer je je aandacht niet hoeft te verdelen over verschillende taken. Dat is wanneer je niet onderbroken wordt om een vraag te beantwoorden, iets op te zoeken, een e-mail te sturen of een IM te beantwoorden. De "alleen-zone" is waar de echte vooruitgang wordt geboekt.

In de "zone" terechtkomen kost tijd. En daarom is onderbreking je vijand. Het is net zoals REM-slaap — je komt niet zomaar in je REM-slaap, je valt eerst in slaap en komt daarna terecht in REM. Na iedere onderbreking moet je opnieuw beginnen. REM is waar de echte slaapmagie plaatsvindt. De alleen-tijdzone is waar de echte ontwikkelingsmagie plaatsvindt.

Stel een regel in bij het werk: Reserveer de helft van de dag voor tijd alleen. Van tien tot twee praat niemand met elkaar (behalve tijdens de lunch). Of maak de eerste of de laatste helft van de dag de periode voor tijd alleen. Zorg dat deze periode aaneengesloten is om productiviteitsdodende onderbrekingen te vermijden.

Een succesvolle tijdsperiode alleen betekent dat je je communicatieverslaving laat gaan. Stop tijdens tijd alleen met IM, telefoon, en vergaderingen. Vermijd iedere e-mail-discussie die een onmiddellijk antwoord vereist. Gewoon, kop dicht en aan het werk.

---

Vergaderingen zijn Giftig

Geen vergaderingen

Is een vergadering echt noodzakelijk? Vergaderingen ontstaan gewoonlijk wanneer het concept onvoldoende duidelijk is. In plaats van te vluchten in een vergadering, probeer het concept te vereenvoudigen zodat je er snel via e-mail of IM of Campfire over kunt discussiëren. Het doel is vergaderingen vermijden. Iedere minuut die je niet in vergaderingen doorbrengt is een minuut waarin je echt werk kunt doen.

Er is niets giftiger voor productiviteit dan een vergadering. Een paar redenen:

• Ze breken je werkdag in kleine, incoherente stukjes die je natuurlijke werkritme verstoren
• Ze gaan meestal over woorden en abstracte concepten, geen echte dingen (zoals een stukje code of een interface-ontwerp)
• De hoeveelheid informatie per minuut is vaak rampzalig klein
• Vaak is er minstens één klojo aanwezig die onontkoombaar een beurt krijgt waarin hij ieders tijd verknoeit met onzin
• Je raakt er sneller van het onderwerp af dan "a Chicago cab in heavy snow"
• De agenda is meestal zo vaag dat niemand precies weet waar het over gaat
• Ze vereisen een grondige voorbereiding waartoe nauwelijks iemand bereid is

Voor de gevallen waarin je absoluut een vergadering moet hebben (dit mag nauwelijks voorkomen), houd je dan aan deze simpele regels:

• Stel een alarmklok in op 30 minuten. Rinkelt die, dan is de vergadering voorbij. Punt uit.
• Nodig zo min mogelijk mensen uit.
• Vergader nooit zonder een duidelijke agenda.

---

Zoek en Vier Kleine Overwinningen

Breng vandaag iets uit

Het belangrijkste in software-ontwikkeling is motivatie. Motivatie is lokaal — als je niet gemotiveerd bent door waar je nu aan werkt, dan is de kans groot dat het niet zo goed wordt als zou moeten. Waarschijnlijk gaat het resultaat zelfs als een tang op een varken slaan.

Langdurige, uitgerekte uitgavecycli doden de motivatie. Ze laten teveel tijd tussen de festiviteiten. Aan de andere kant zijn kleine overwinningen die je kunt vieren grote motivatoren. Zodra je langdurige uitgavecycli de snelle overwinningen laat verijdelen, dan dood je motivatie. En dat kan weer je product doden.

Dus, als je in het midden van een maandenlange uitgavecyclus zit, besteedt dan een dag per week (of iedere twee weken) aan een paar kleine overwinningen. Vraag jezelf "Wat kunnen we doen en uitbrengen in 4 uur tijd?" En doe het dan. Het zou kunnen zijn...

• Een nieuwe simpele feature
• Een kleine verbetering voor een bestaande feature
• Een paar hulpteksten herschrijven om de support-last te verlichten
• Een paar formuliervelden verwijderen die je toch niet nodig hebt

Met deze snelle 4-uurs overwinningen heb je een reden om te vieren. Dat versterkt het moraal, verhoogt de motivatie, en herbevestigt dat het team in de juiste richting gaat.

---

Het team hoofdstuk 8

Werf minder aan, werf later aan

Wees langzaam en ga sneller

Het is niet nodig om in een vroeg stadium groot te groeien — of zelfs in een later stadium. Zelfs al heb je toegang tot 100 van de allerbeste mensen, dan is het nog steeds een slecht idee om ze allemaal tegelijk in te huren. Je kunt onmogelijk zoveel mensen tegelijk in een coherente cultuur assimileren. Je krijgt hoofdpijnproblemen met opleiding, botsingen van persoonlijkheid, communcatiestoornissen, mensen die verschillende richtingen kiezen, en meer.

Werf dus niemand aan. Echt waar. Werf geen mensen aan. Zoek naar een andere manier. Is het werk waaronder je bezwijkt echt noodzakelijk? Wat als je het gewoon niet doet? Kun je het probleem anders oplossen met een stukje software of een praktische verandering?

Wanneer Jack Welch, voormalig CEO van General Electric, iemand moest ontslaan, wierf hij niet onmiddellijk een vervanger aan. Hij wilde zien hoe lang GE vooruit kon zonder die persoon en die positie. We verkondigen beslist niet dat je mensen moet ontslaan om de theorie uit te proberen, maar we denken wel dat Jack hier een punt heeft: Je hebt niet zoveel mensen nodig als je denkt.

Als er geen andere manier is, overweeg dan om iemand in te huren. Maar je moet precies weten wie je wilt vinden, hoe ze in het werk te introduceren, en de precieze pijn die je wilt dat ze je helpen oplossen.

---

Maak een proefrit

Laat kandidaat-werknemers eerst op proef werken

Kijken naar een portfolio, cv, codevoorbeeld of eerder werk is één zaak. Daadwerkelijk met iemand samenwerken is een andere. Neem, indien mogelijk, kandidaat-teamleden altijd mee op een proefrit.

Alvorens wij mensen aanwerven, laten we ze eerst kauwen op een klein project. We bekijken hoe ze het project aanpakken, hoe ze communiceren, hoe ze werken, enz. Iemand enkele schermen laten ontwerpen of coderen, geeft je een hoop inzicht. Je zal erg snel merken of de juiste sfeer er is.

Iets dergelijks plannen kan moeilijk zijn, maar zelfs als het maar voor 20 of 40 uur is, is het beter dan niets. Als het wel of niet klikt, zal duidelijk zijn. En indien niet, voorkomen beide partijen veel problemen door de situatie eerst uit te testen.

---

Geen Woorden maar Daden

Beoordeel kandidaten voor technische functies op open source bijdragen

De typische aanwervingsmethodes voor technische posities — gebaseerd op diploma’s, cv’s, etc. — zijn op verschillende vlakken dwaas. Maakt het wat uit waar iemand zijn diploma haalde en met hoeveel onderscheidingen? Kan je een cv of een referentie echt vertrouwen?

Open source is een geschenk voor wie technische mensen moet aanwerven. Met open source kan je iemands werk en bijdragen — goede en slechte — over een lange tijdspanne nagaan.

Dat betekent dat je mensen kan beoordelen op hun daden en niet enkel op hun woorden. Je kan een beslissing nemen gebaseerd op de zaken die er echt toe doen:

• Kwaliteit van het werk
  Veel programmeurs kunnen het goed uitleggen, maar vallen door de mand als het op daden aankomt. Met open source krijg je een zeer specifiek zicht op de praktijk en de kwaliteit van hun programmeerwerk.
• Cultureel perspectief
  Programmeren gaat over beslissingen. Een heleboel beslissingen. Beslissingen worden bepaald door je culturele standpunt, waarden en idealen. Kijk naar de specifieke beslissingen die de kandidaat maakte bij het coderen, testen en onderlinge discussies om te bepalen of jullie een culturele overeenkomst hebben. Als het hier niet klikt, zal elke beslissing een gevecht zijn.
• Dosis passie
  Betrokkenheid in open source vereist per definitie op zijn minst enige passie. Waarom zou deze persoon anders zijn vrije tijd zittend voor een scherm besteden? Hoe betrokken een kandidaat is in open source, bewijst vaak hoeveel hij werkelijk geeft om programmeren.
• Voltooiingspercentage
  Iemand kan slim zijn, over de geschikte cultuur beschikken en passie hebben, maar dat draagt niets bij tot waardevolle software als deze persoon niets kan afwerken. Jammer genoeg kunnen veel programmeurs dit niet. Kijk dus naar die ijver om iets uit te brengen. Neem iemand aan die het de deur uit wil en die bereid is de pragmatische afwegingen te maken die daarvoor nodig zouden zijn.
• Sociale overeenkomst
  Met iemand samenwerken gedurende een lange periode, gedurende zowel stress/ontspanning als hoogtes/laagstes, zal je zijn echte persoonlijkheid tonen. Als iemand tekortschiet in manieren of sociale vaardigheden, filter hem dan uit.

Als het over programmeurs gaat, nemen we enkel mensen aan die we kennen via open source. We vinden dat iets anders doen onverantwoord is. We namen Jamis aan omdat we zijn bijdragen en deelname aan de Ruby gemeenschap volgden. Hij blonk uit op alle hierboven vermelde gebieden. We waren niet ahankelijk van secundaire factoren, omdat we hem konden beoordelen op wat er echt toe doet: de kwaliteit van zijn werk.

En wees niet bezorgd dat nevenactiviteiten de focus en de passie zullen wegnemen van de werknemer zijn dagtaak. Zoals het oude cliché zegt: als je iets gedaan wilt krijgen, vraag het aan de drukstbezette persoon die je kent. Jamis en David zijn twee van de grootste bijdragers aan Rails en ze slagen er toch in om 37signals technisch aan de gang te houden. Mensen die van programmeren houden en dingen gedaan krijgen zijn exact het soort mensen die je in je team wil.

---

Neem veelzijdige individuen

Ga voor snel lerende generalisten in plaats van verstokte specialisten

We zullen nooit iemand aanwerven die inforatie architect is. Dat is gewoon overdreven specifiek. Met een klein team als het onze, is het onzinnig mensen aan te nemen met zo'n eng gedefinieerde vaardigheid.

Kleine teams hebben mensen nodig die verschillende petjes kunnen dragen. Je hebt ontwerpers nodig die kunnen schrijven. Je hebt programmeurs nodig die kunnen ontwerpen. Iedereen zou een idee moeten hebben over de architectuur van informatie (wat dat ook moge betekenen). Iedereen heeft een georganiseerde geest nodig. Iedereen moet in staat zijn om te commmuniceren met klanten.

En iedereen moet bereid en in staat zijn om onderweg van gereedschap te veranderen. Denk eraan dat kleine teams vaak van richting moeten veranderen en dat snel moeten doen. Je wil iemand hebben die zich kan aanpassen en leren en meegaan in plaats van een koppigaard die maar één ding kan.

---

Enthousiasme kan je niet nabootsen

Liever gelukkig en middelmatig dan gefrustreerd en uitmuntend

Enthousiasme. Het is een eigenschap die je niet veinzen. Wanneer de tijd gekomen is om iemand aan te werven, denk dan niet dat je een goeroe of een technische beroemdheid nodig hebt. Meestal zijn dat toch maar primadonna's. Een gelukkige maar gemiddelde werknemer is beter dan een misnoegde expert.

Zoek iemand die enthousiast is. Iemand waarvan je kan vertrouwen dat hij zaken afwerkt als hij alleen gelaten wordt. Iemand die afgezien heeft bij een groter, trager bedrijf en hunkert naar een nieuwe omgeving. Iemand die geprikkeld is om te bouwen wat jij bouwt. Iemand die dezelfde dingen haat die jij haat. Iemand die verrukt is om aan boord te springen van jouw trein.

---

Woordkunstenaars

Neem goede schrijvers aan

Als je probeert te beslissen tussen een aantal mensen om een positie in te vullen, neem dan altijd de beste schrijver aan. Het maakt niet uit of die persoon een ontwerper, programmeur, marketeer, verkoper, of wat dan ook is, de schrijfvaardigheden zullen zichzelf terugbetalen. Effectieve en bondige schrijfsels en redactie leiden tot effectieve en bondige code, ontwerp, e-mails, instant messages en meer.

Dat komt omdat een goede schrijver zijn over meer dan woorden gaat. Goede schrijvers weten hoe ze moeten communiceren. Zij maken zaken gemakkelijk verstaanbaar. Zij kunnen zichzelf in andermans schoenen plaatsen. Zij weten wat ze moeten weglaten. Zij denken helder. En dat zijn de kwaliteiten die je nodig hebt.

---

Interface Ontwerphoofdstuk 9

Eerst de interface

Ontwerp de interface voordat je begint te programmeren

Te veel toepassingen beginnen met een "eerst-het-programma"-mentaliteit. Dat is een slecht idee. Programmatie is de zwaarste component van het bouwen van een toepassing, wat betekent dat het het duurste en moeilijkste is om te veranderen. Begin in plaats daarvan met het ontwerp.

Ontwerp is relatief licht. Een schets op papier is goedkoop en gemakkelijk te veranderen. Html-ontwerpen zijn nog steeds relatief eenvoudig aan te passen (of weg te gooien). Dat geldt niet voor programmeren. Eerst ontwerpen houdt je flexibel. Eerst programmeren sluit je op en zadelt je op met bijkomende kosten.

Een andere reden om eerst te ontwerpen is dat de interface je product is. Wat de mensen zien is wat je verkoopt. Als je er gewoon een interface tegenaan gooit op het eind, dan zullen de gaten te zien zijn.

Wij beginnen met de interface zodat we van in het begin kunnen zien hoe de toepassing eruit ziet en aanvoelt. Hij wordt constant herzien doorheen het proces. Is hij zinnig? Is hij gemakkelijk te gebruiken? Lost hij het bewuste probleem op? Dit zijn vragen die je enkel naar waarheid kan beantwoorden wanneer je werkt met echte schermen. Eerst ontwerpen houdt je flexibel en brengt je bij deze antwoorden in het begin van het proces in plaats van op het einde.