37signals logo Getting Real Overview

Buy the book

Buy Getting Real in PDF or paperback.

Job Board

Gig Board

Looking for design, copywriting, or programming help with your project? Check the Gig Board.

Getting Real - Normaal Doen



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.

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.

Hoe kan je krachtige software schrijven

Krachtig schrijven komt precies. Een zin hoort geen onnodige woorden te bevatten, een paragraaf geen onnodige zinnen, om dezelfde reden dat een tekening geen onnodige lijnen hoort te hebben, en een machine geen onnodige onderdelen. Dit betekent niet dat de schrijver alle zinnen moet inkorten of details moet vermijden en alleen hoofdzaken mag beschrijven, maar dat elk woord er toe doet.

—Uit "The Elements of Style" door William Strunk Jr.


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...

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...

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 lancering van Microsoft's Start.com

In grote bedrijven zijn processen en vergaderingen de norm. Maanden worden besteed aan het plannen van features en het discussiëren van details met als doel het bereiken van overeenstemming over wat "goed" is voor de klant.

Dat zou de juiste benadering kunnen zijn voor software in cellofaanverpakking, maar met het web hebben we een ongelooflijk voordeel. Lanceer het gewoon! Laat de gebruiker maar vertellen of het goed is of niet, wat maakt het uit: je kunt repareren en dezelfde dag weer publiceren als je wilt! Geen woord is sterker dan dat van de klant — verzet je tegen de neiging om in langdradige vergaderingen en discussies te verzeilen. Lanceer het gewoon en bewijs je standpunt.

Dit is gemakkelijker gezegd dan gedaan, en impliceert:

Maandenlang plannen is niet nodig.
Maandelang specificaties schrijven is niet nodig — in de specificaties moeten de essenties benoemd zijn, en details moeten worden uitgezocht tijdens de ontwikkelingsfase. Probeer niet alle openstaande vragen en ieder detail op te lossen nog voordat de ontwikkeling begint.

Lever minder features, maar kwaliteitsfeatures.
Je hebt geen Big Bang-benadering nodig met een hele nieuwe release en een hoop features. Geef de gebruikers hapklare brokken te verteren.

Als er wat kleine bugs zijn, lanceer het zodra je de belangrijkste scenario's op orde hebt en geef de herstellingen van de bugs geleidelijk aan. Hoe sneller je reacties van gebruikers krijgt, hoe beter. Ideeën kunnen er op papier prachtig uitzien maar in de praktijk minder dan ideaal blijken te zijn. Hoe eerder je achter fundamentele kwesties komt die in strijd zijn met het idee, hoe beter.

Zodra je snel itereert en reageert op klantenreacties heb je een klantenrelatie gelegd. Onthoud: het doel is om de klant voor je te winnen door te bouwen wat ze willen.

—Sanaz Ahari, Program Manager van Start.com, Microsoft


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":



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.

Krab waar je zelf jeuk hebt

De Open Source-wereld omarmde dit mantra lange tijd geleden — ze noemen het "scratching your own itch" - krabben waar je zelf jeuk hebt. Voor de Open Source-ontwikkelaars betekent het dat ze de tools krijgen die ze nodig hebben, op de manier waarop ze die willen. Maar het voordeel gaat veel verder.

Als de ontwerper of ontwikkelaar van een nieuwe applicatie wordt je iedere dag geconfronteerd met honderden micro-besluiten: blauw of groen? Eén tabel of twee? Statisch of dynamisch? Afbreken of herstellen? Hoe nemen we deze beslissingen? Als het iets is dat we herkennen als belangrijk, zouden we het kunnen vragen. De rest gokken we. En al dat gokken bouwt een soort schuld op in onze applicaties — een samengesteld web van aannames.

Als ontwikkelaar haat ik dat. Het werkt stressverhogend als je weet van al deze kleinschalige tijdbommen verspreid door je applicatie. Open Source-ontwikkelaars, die zichzelf krabben, hebben hier geen last van. Omdat ze hun eigen gebruikers zijn, weten ze de correcte antwoorden op 90% van de besluiten die ze moeten maken. Ik denk dat dit één van de redenen is dat mensen na een dag van hard werken verdergaan met werken aan Open Source: het is ontspannend.

—Dave Thomas, The Pragmatic Programmers

Geboren uit noodzaak

Campaign Monitor werd geboren uit pure noodzaak. Jarenlang waren we gefrustreerd door de kwaliteit van de bestaande e-mail-marketingproducten. De ene tool deed x en y maar nooit z, de andere had y en z voor elkaar maar x niet. We konden niet winnen.

We besloten om wat tijd vrij te maken in onze planning en een gooi te doen naar het bouwen van onze droom-marketingtool. We besloten bewust om niet te kijken naar wat de rest deed, en in plaats daarvan iets te maken dat ons leven en dat van onze klanten iets gemakkelijker zou maken.

Zoals duidelijk werd waren we niet de enigen die ontevreden waren met de bestaande mogelijkheden. We maakten een paar modificaties in de software zodat iedere ontwerpfirma ze kon gebruiken en begonnen het woord te verspreiden. In minder dan zes maanden, duizenden ontwerpers gebruikten Campaign Monitor om e-mail-nieuwsbrieven te versturen voor zichzelf en hun clienten.

—David Greiner, oprichter, Campaign Monitor

Je moet erom geven

Wanneer je een boek schrijft heb je meer nodig dan een interessant verhaal. Je moet gedreven zijn om het verhaal te vertellen. Je moet er op de één of andere manier persoonlijk in geïnvesteerd hebben. Als je er twee, drie jaar, de rest van je leven mee moet leven, dan moet je erom geven.

—Malcolm Gladwell, auteur (from A Few Thin Slices of Malcolm Gladwell)


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.

Twee routes

[Jake Walker begon één bedrijf met investeerdersgeld (Disclive) en één zonder (The Show). Hier vertelt hij over de verschillen tussen de twee paden.]

De wortel van alle problemen was niet het verzamelen van het geld zelf, maar alles dat daarbij hoorde. De verwachtingen zijn gewoon hoger. Mensen beginnen salaris te nemen, en de motivatie is om het te bouwen en te verkopen, of een andere manier te vinden voor de initële investeerders om hun geld terug te verdienen. In het geval van het eerste bedrijf begonnen we ons groter te gedragen dan we waren — uit noodzaak...

[Met The Show] We realizeerden ons dat we een veel beter product konden leveren met minder kosten, alleen met meer tijd. En we gokten met wat van ons eigen geld dat mensen bereid zouden zijn te wachten op kwaliteit in plaats van snelheid. Maar het bedrijf is en waarschijnlijk blijft een kleine organisatie. En sinds dat eerste project zijn we volledig zelfbedruipend geweest. Met juist een beetje creatieve voorwaarden van onze leveranciers, zijn we nooit genoodzaakt geweest om veel van ons geld in de organisatie te steken. En de verwachting is niet om te groeien en te verkopen, maar om te groeien omwille van het groeien en er financieel van te blijven profiteren.

—A comment from Signal vs. Noise


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:

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

Eén, twee, drie...

Hoe raakt een project een jaar achter op schema? Dag voor dag.

—Fred Brooks, software engineer en computer scientist


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.

Volg nooit de leider

Marketeers (en alle mensen) zijn goed getrained om de leider te volgen. Het natuurlijk instinct is om uit te vinden wat werkt voor de concurrentie, en ze dan te verslaan — door goedkoper te zijn dan je concurrent die op prijs concurreert, of sneller dan de concurrent die concurreert op snelheid. Het probleem is dat zodra een consument het verhaal van een ander geslikt heeft en in die leugen gelooft, hem overtuigen om over te stappen hetzelfde is als hem doen toegeven dat hij zich vergist had. En mensen geven niet graag toe dat ze zich vergissen.

In plaats daarvan moet je een ander verhaal vertellen en luisteraars overtuigen dat jouw verhaal belangrijker is dan het verhaal waar ze nu in geloven. Is de concurrentie sneller, dan moet je goedkoper zijn. Verkopen ze een verhaal over gezondheid, dan moet je een verhaal verkopen over gemak. Niet alleen de x/y-as-positionering van "Wij zijn goedkoper", maar een echt verhaal dat compleet anders is dan het verhaal dat al verteld wordt.

Seth Godin, auteur/ondernemer (van Be a Better Liar) ("Wees een Betere Leugenaar")

Wat is het sleutelprobleem?

Eén van de snelste manieren om in de problemen te raken is kijken naar wat je concurrentie doet. Dit was vooral van toepassing op ons bij BlinkList. Sinds de lancering zijn er ongeveer tien andere social bookmarking-services gelanceerd. Sommige mensen zijn zelfs spreadsheets gaan genereren met een gedetailleerde feature-voor-feature-vergelijking.

Zoiets leidt echter snel af. In plaats daarvan blijven we geconcentreerd op de het algemene plaatje en blijven we onszelf afvragen, wat is het sleutelprobleem dat we proberen op te lossen en hoe kunnen we het oplossen?

—Michael Reining, mede-oprichter, MindValley & Blinklist


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.

De aanwezigheid van passie

In ontwerp, waar betekenis vaak controversiëel subjectief of pijnlijk ondoorgrondelijk is, zijn weinig zaken duidelijker en klaarder dan de aanwezigheid van passie. Of het ontwerp van een product je nu meesleept of koud laat, in beide gevallen is het moeilijk om de emotionele investering door de handen van de maker niet op te merken.

Enthousiasme manifesteert zichzelf natuurlijk al gauw, maar onverschilligheid is al net zo onuitwisbaar. Als er geen sprake is van passie van binnenuit voor het werk dat je doet, dan is dat bijna onmogelijk te verbergen, hoe uitgewerkt of aantrekkelijk ontworpen het ook is.

—Khoi Vinh, Subtraction.com

De bakkerij

Amerikaans zakendoen gaat vandaag de dag om het ontwikkelen van een idee, het idee winstgevend maken, het verkopen wanneer het nog winstgevend is, en dan weglopen of diversiferen. Het is gewoon nemen wat er te nemen valt. Mijn idee was: geniet van het bakken, verkoop je brood, mensen vinden het lekker, verkoop nog meer. Houdt de bakkerij gaande omdat je lekker eten maakt en mensen er blij mee zijn.

—Ian MacKaye, lid van Fugazi en mede-eigenaar van Dischord Records
(from Salon.com People | Ian MacKaye)


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...

Massa wordt verminderd door...

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.

Emergentie (totstandkoming)

Emergentie is één van de basisprincipes van wendbaarheid, en ligt het dichtste bij pure magie. Emergente eigenschappen worden niet ontworpen of ingebouwd, ze gebeuren gewoon als dynamisch resultaat van de rest van het systeem. "Emergentie" komt uit het 17e-eeuws Latijn in de betekenis van "onvoorziene gebeurtenis". Je kunt het niet ontwerpen of plannen, maar je kunt een omgeving cultiveren waarin je het kunt laten gebeuren en je ervan kunt profiteren.

Een klassiek voorbeeld van emergentie ligt in het groepsgedrag van vogels. Een computersimulatie kan met niet meer dan drie simpele regels (in de trant van "loop niet tegen elkaar op") en plotseling krijg je zeer complex gedrag als de groep zich wendt en gracieus door de lucht glijdt, zich aanpast aan obstakels, enzovoorts. Niets van dit geavanceerde gedrag (zoals dezelfde aanpassen aan een obstakel) wordt gespecificeerd door de regels; het ontstaat vanuit de dynamiek van het systeem.

Simpele regels, zoals in de vogelsimulatie, leiden tot complex gedrag. Complexe regels, zoals in het belastingrecht in de meeste landen, leidt tot stompzinnig gedrag.

Vele gangbare praktijken in software-ontwikkeling hebben het ongelukkige bij-effect van het elimineren van iedere kans op emergent gedrag. De meeste pogingen tot optimalisatie — iets zeer expliciet afbakenen — reduceren de breedte en werkingsgebied van interacties en relaties, die de bron zelf vormen van emergentie. In het voorbeeld van de vlucht vogels zijn het, net als in een goed ontworpen systeem, de interacties en relaties die het interessante gedrag doen ontstaan.

Hoe steviger we alles dichttimmeren, hoe minder ruimte er is voor een creatieve, emergente oplossing. Of het nu gaat om het definitief vastleggen van vereisten voordat ze goed begrepen zijn, of om het prematuur optimaliseren van code, of het uitvinden van complexe navigatie- en workflowscenario's voordat de eindgebruikers gelegenheid hebben gehad om met het systeem te spelen, het resultaat is hetzelfde: een overdreven gecompliceerd, stompzinnig systeem in plaats van een schoon, elegant systeem dat emergentie ondersteunt.

Hou het klein. Houdt het simpel. Laat het op je af komen.

—Andrew Hunt, The Pragmatic Programmers


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.

De Wet van Metcalfe en projectteams

Houd het team zo klein mogelijk. De Wet van Metcalfe, dat "de waarde van een communicatiesysteem groeit met ongeveer het kwadraat van het aantal gebruikers in het systeem", heeft een effect op projectteams: De efficiëntie van het team is ongeveer de inverse van het kwadraat van het aantal deelnemers in een team. Ik begin te denken dat drie mensen optimaal is voor een 1.0-productrelease... Begin met het aantal mensen te verminderen dat je van plan bent aan het team toe te voegen, en verminder dat aantal daarna nog wat verder.

—Marc Hedlund, entrepreneur-in-residence at O'Reilly Media

Communicatiestromen

Communicatie verloopt eenvoudiger bij kleine dan bij grote teams. Als je de enige persoon in een project bent, dan is de communicatie eenvoudig. De enige communicatie is tussen jou en de klant. Zodra het aantal mensen op een project toeneemt, dan neemt ook het aantal communicatiekanalen toe. Dat gaat niet proportioneel, maar exponentieel, proportioneel aan het kwadraat van het aantal mensen.

—Steve McConnell, Chief Software Engineer at Construx Software Builders Inc.
(from Less is More: Jumpstarting Productivity with Small Teams)


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:

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.

Vecht tegen verrotting

Wat wordt bescheven als "sluipende elegantie" wordt wellicht beter omschreven als "feature verrotting", als een schimmel op een plant die zich geleidelijk uitbreidt en het echte doel van het product doet vervagen terwijl het zijn sap uitzuigt. Het tegengif tegen feature verrotting is, natuurlijk, de "krappe deadline". Dit resulteert in het schrappen van features in proportie met de tijd die het inneemt om ze te implementeren. Het is vaak zo dat de nuttigste features het meeste tijd in beslag nemen om te implementeren. Bijgevolg resulteert de combinatie van de verrotting en de deadline in software zoals we die kennen en waar we van houden, samengesteld uit rijkelijke hoeveelheden nutteloze eigenschappen.

—Jef Raskin, author (from "Why Software Is the Way It Is") ("Waarom Software Is zoals het Is")


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.

Wees trots en onverzettelijk eerlijk

Hoewel je zou kunnen denken dat een klant voor de gek kan worden gehouden met het aantal medewerkers in je bedrijf of de groote van je productaanbod, de slimmeriken, degenen die je echt wilt hebben, komen altijd achter de waarheid — hetzij intuïtief, hetzij door deductie. Tot mijn schande heb ik deel uitgemaakt van dit soort lichte leugens in het verleden, en geen van die situaties resulteerde ooit in wat er voor een onderneming echt toe doet: betekenisvolle, langdurige en tot wederzijds voordeel strekkende relaties met mensen die het gebodene echt nodig hadden. De betere weg zou zijn geweest om trots en koppig eerlijk te zijn over de exacte grootte van de onderneming.

—Khoi Vinh, Subtraction.com

Wanneer U Maar Wilt

Wat voor onderneming je ook hebt, goede klantenservice is het belangrijkste verzoek dat een klant ooit zal maken. We eisen hetzelfde voor de diensten die we zelf gebruiken en waarom zouden onze klanten anders zijn? Vanaf het allereerste begin hebben we het gemakkelijk en transparant voor klanten gemaakt om voor alle mogelijke vragen met ons in contact te komen. Op onze website staat een gratis nummer dat doorgeschakeld staat naar onze mobiele telefoons, en op onze visitekaartjes staan al deze nummers vermeld. We benadrukken tegenover onze klanten dat ze altijd met ons in contact kunnen komen, wat het probleem ook moge zijn. Onze klanten stellen het vertrouwen op prijs en niemand heeft ooit misbruik gemaakt van deze service.

—Edward Knittel, Director of Sales and Marketing, KennelSource


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:

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.

Whiteboard-filosofie

Andy Hunt en ik schreven eens een transactieswitch voor debetkaarten . Een belangrijke vereiste was dat de gebruiker van de debetkaart nooit twee keer dezelfde transactie zou aangerekend krijgen. Met andere woorden, wat voor fout er ook zou kunnen optreden, de fout zou alleen mogen uitdraaien op het niet verwerken van de transactie, nooit het twee keer verwerken van de transactie.

Dus schreven we op ons gedeelde whiteboard in grote letters: Vergis je ten gunste van Gebruikers.

Deze stelregel, samen met een handvol andere, gidsten al de moeilijke beslissingen die je neemt wanneer je iets complex moet maken. Samen gaven deze wetten onze applicatie een sterke samenhang en grote uiterlijke consistentie.

—Dave Thomas, The Pragmatic Programmers

Maak Mantra

Organisaties hebben wegwijzers nodig. Ze hebben een overzicht nodig; werknemers moeten weten, wanneer ze 's ochtends wakker worden, waarom ze naar hun werk gaan. Dit overzicht moet kort en krachtig zijn, en allesomvattend: Waarom besta je? Wat motiveert je? Ik noem dit een mantra — een omschrijving van waarom je bestaat in drie of vier woorden.

Guy Kawasaki, auteur (van Make Mantra)


Negeer details in het begin

Werk van groot naar klein

We're zijn gek op details.

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.

The Duivel is in de Details

Ik kwam al snel over mijn houding om direct in de details te duiken heen nadat ik een paar tekenlessen had genomen... Als je meteen de details begint te tekenen kun je er zeker van zijn dat het niets wordt. In feite mis je gewoon het hele punt.

Je moet beginnen met de proporties voor de hele scène goed te krijgen. Daarna schets je de grootste objecten op de scène, tot aan de kleinste. De schets moet tot hier toe heel los zijn. Daarna kun je doorgaan met inkleuren om de vorm tot leven te brengen. Je begint met slechts drie schakeringen (licht, halfdonker, donker). Dit geeft je een schets van schakeringen. Vervolgens herevalueer je voor elk gedeelte van je tekening de drie schakeringen en pas je ze toe. Doe dit tot de vormen er zijn (vereist meervoudige iteratie)...

Werk van groot naar klein. Altijd.

—Patrick Lafleur, Creation Objet Inc. (from Signal vs. Noise)


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.

De Beste Beslissing Ooit Gemaakt

De beslissing om Campaign Monitor strict op de webdesign-markt te richten was onze beste beslissing ooit. Het hielp ons gemakkelijk identificeren welke features werkelijk zinvol waren en, belangrijker, welke features we weg konden laten. Niet alleen hebben we meer klanten getrokken door op een kleinere groep mensen te mikken, deze klanten hebben vergelijkbare noden wat ons werk een stuk makkelijker maakt. Er zijn bakken met functionaliteit in Campaign Monitor die zinloos zijn voor iedereen behalve webdesigners.

Je concentreren op een kernmarkt maakt het ook gemakkelijker om het woord te verspreiden over je software. Nu we een strak gedefiniëerd publiek hebben, kunnen we adverteren waar zij elkaar tegenkomen, artikelen publiceren die ze interessant kunnen vinden, en een gemeenschap rondom het product bouwen.

—David Greiner, founder, Campaign Monitor


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.

Je moet sowieso alles opnieuw bekijken

Feit is dat iedereen schaalbaarheidsproblemen heeft; niemand kan rekening houden met een service die van nul naar een paar miljoen bezoekers gaat zonder bijna ieder aspect van hun design en architectuur opnieuw te bekijken.

—Dare Obasanjo, Microsoft (from Scaling Up and Startups)


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."

"We Willen Geen Duizend Features"

Steve Jobs gaf een kleine privé-presentatie over de iTunes Music Store aan enkele mensen van een onafhankelijk platenlabel. Mijn favoriete moment van de dag was toen mensen hun hand bleven opsteken om te vragen, "Doet het [x]?" en "Plan je [y] toe te voegen?". Uiteindelijk zei Jobs: "Wacht wacht — doe je handen naar beneden. Luister: ik weet dat jullie duizend ideeën hebben voor alle coole features die iTunes zou kunnen hebben. Wij ook. Maar we willen geen duizend features. Dat zou lelijk worden. Innovatie gaat niet over ja zeggen tegen alles. Het gaat over NEE zeggen tegen alles behalve de meest cruciale features."

—-Derek Sivers, voorzitter en programmeur, CD Baby and HostBaby
(uit Say NO by default)


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...



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.

Innovatie komt van Nee zeggen

[Innovatie] komt van nee zeggen tegen 1.000 dingen om zeker te zijn dat we niet op het verkeerde spoor belanden of proberen teveel te doen. We denken altijd aan nieuwe markten die we zouden kunnen betreden, maar alleen met nee zeggen kun je je concentreren op de dingen die echt belangrijk zijn.

—Steve Jobs, CEO, Apple (from The Seed of Apple's Innovation)


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.

De "Real Thing" leidt tot overeenstemming

Wanneer een groep mensen op zoek gaan naar harmonie... zullen hun meningen ertoe neigen meer overeen te stemmen als ze echt spul of werkelijke schaal opmaken. Natuurlijk zullen ze wanneer je schetsen maakt of ideeën rondstrooit het niet met elkaar eens zijn. Maar als je "the real thing" begint te maken, dan neigt men naar overeenstemming.

—Christopher Alexander, Hoogleraar Architectuur
(from Contrasting Concepts of Harmony in Architecture) ("Contrasterende Concepten van Harmonie in de Architectuur")

Zorg dat het ZSM werkt

Ik geloof niet dat ik ooit betrokken ben geweest in een softwareproject — groot of klein — dat succesvol was in termen van planning, kosten, of functionaliteit, als we begonnen met een lange periode van planning en discussie, zonder gelijktijdige ontwikkeling. Het is gewoon te makkelijk, en soms leuk, om kostbare tijd te verspillen met het uitvinden van features die onnodig of niet implementeerbaar blijken.

Dit geldt voor alle niveaus van ontwikkeling, en "maak iets werkends" is een "fractal-mantra". Het geldt niet alleen voor het project als geheel, het is minstens net zo van toepassing op de kleinschalige ontwikkeling van de deelcomponenten waaruit de applicatie is opgebouwd.

Zodra er een werkende implementatie van een sleutelcomponent beschikbaar is, willen ontwikkelaars begrijpen hoe het (niet) gaa werken met hun deel van de applicatie, en zullen het over het algemeen gaan gebruiken zo snel ze kunnen. Zelfs als de implementatie niet perfect of compleet is, leidt deze vroege samenwerking tot goed gedefiniëerde interfaces en features die precies doen wat ze moeten doen.

—Matt Hamer, programmeur en productmanager, Kinja


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.

Misschien ben je wel slimmer dan ik

Misschien ben je wel VEEL slimmer dan ik.

Het is heel goed mogelijk. In feite is het zelfs waarschijnlijk. Echter, als je bent zoals de meeste mensen, en in dat geval zoals ik, dan vind je het lastig om je iets voor te stellen wat je niet kunt zien en voelen en aanraken.

Mensen zijn extreem goed in reageren op hun omgeving. We weten hoe we in paniek moeten raken als er een tijger binnenkomt, en hoe we moeten opruimen na een verwoestende overstroming. Helaas zijn we verschrikkelijk slecht in vooruitplannen, in de gevolgen van onze daden te begrijpen en in het stellen van prioriteiten van wat er echt toe doet.

Misschien ben je één van die weinige individuen die het allemaal in hun hoofd kunnen bewaren. Het doet er niet echt doe.

Web 2.0, de wereld waar we beginnen met aan te nemen dat iedereen webgebruiker is, laat slimme ontwikkelaars toe om deze menselijke tekortkoming voor zich te laten werken. Hoe? Door hun gebruikers toe staan om je te vertellen wat ze denken, terwijl er nog tijd is om er iets aan te doen.

En die laatste zin maakt duidelijk waarom je op deze manier moet ontwikkelen en hoe je zou willen promoten/lanceren.

Heb je verhaal voor elkaar. Zorg ervoor dat de stukjes op hun plek vallen. Breng uit en reviseer. Niemand is net zo slim als wij allemaal samen.

Seth Godin, auteur/ondernemer


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.

Voorkeuren hebben een Prijs

Voorkeuren blijken een prijs te hebben. Natuurlijk hebben sommige voorkeuren ook belangrijke voordelen — en ze kunnen cruciale interface-features zijn. Maar elk heeft een prijs, en je moet aandachtig zijn waarde overwegen. Veel gebruikers en ontwikkelaars begrijpen dit niet, en eindigen met een hoop kosten en weinig waarde per voorkeur-dollar.... Ik vind dat als je supergedisciplineerd bent om goede standaardwaarden te hebben die gewoonweg werken in plaats van domweg voorkeuren toe te voegen, de gebruikersinterface natuurlijkerwijs in de juiste richting geleid wordt.

—Havoc Pennington, tech lead, Red Hat (uit Free software and good user interfaces) ("Gratis software en goede gebruikersinterfaces")


"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.

Wees een Uitvoerder

Het is zo grappig als ik mensen hoor die zo hun ideeën zo beschermen. (Mensen die willen dat ik een vertrouwelijkheidsverklaring teken om me een allereenvoudigst idee te kunnen vertellen.)

Voor mij zijn ideeën niets waard tenzij ze worden uitgevoerd. Ideeën zijn slechts een vermenigvuldigingsfactor. Uitvoering is miljoenen waard.

Uitleg:

  • Waardeloos idee = -1
  • Zwak idee = 1
  • Aardig idee = 5
  • Goed idee = 10
  • Geweldig idee = 15
  • Briljant idee = 20
  • Geen uitvoering = $1
  • Zwakke uitvoering = $1000
  • Aardige uitvoering = $10,000
  • Goede uitvoering = $100,000
  • Geweldige uitvoering = $1,000,000
  • Briljante uitvoering = $10,000,000

Om een onderneming op te bouwen moet je de twee vermigvuldigen.

Het allerbriljantste idee, zonder uitvoering, is $20 waard. Het allerbriljanste idee heeft geweldige uitvoering nodig om $20.000.000 waard te zijn.

Daarom wil ik andermans ideeën niet horen. Ik ben niet geïnteresseerd totdat ik ze uitgevoerd zie.

—Derek Sivers, president and programmeur, CD Baby and HostBaby


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

Het Bèta-Boek

Zijn programmeurs nerveus over het vrijgeven van code, zo zijn uitgevers en auteurs als de dood voor het uitgeven van boeken. Zodra een boek op papier staat, dan wordt dat gezien als een kwelling om nog iets te veranderen. (Dat klopt echt niet, maar perceptie en herinneringen van problemen met ouderwetse technologie waren nog steeds rond in de industrie.) En zo doen uitgevers een hoop moeite (en maken een hoop kosten) om boeken "juist" te krijgen voordat ze worden uitgegeven.

Toen ik het boek "Agile Web Development With Rails" schreef, was er nogal wat opgehoopte vraag onder programmeurs: geef ons het boek nu — we willen iets leren over Rails. Maar ik was ten prooi gevallen aan de ingesteldheid van een uitgever. "Het is nog niet klaar," zei ik dan. Maar door de druk van de gemeenschap en wat aanmoediging van David Heinemeier Hansson veranderde ik van mening. We publiceerden het boek in PDF ongeveer 2 maanden voordat het compleet was. De resultaten waren spectaulair. Niet alleen verkochten we heel wat boeken, maar we kregen ook feedback — een heleboel feedback. Ik zette een geautomatiseerd systeem op om lezerscommentaar in te verwerken, en kreeg aan het eind zo'n 850 meldingen van typefouten, technische vergissingen, en suggesties voor nieuwe inhoud. Bijna alles hiervan kwam terecht in het uiteindelijke boek.

Het was een win-win: ik kwam met een enorm verbeterd gedrukt boek, en de gemeenschap kreeg eerder toegang tot iets dat ze wilden hebben. En als je in een competitieve race bent, dan leidt vroeg publiceren tot trouw aan jou in plaats van aan de concurrentie.

—Dave Thomas, The Pragmatic Programmers

Doe het snel

  • 1. Beslis of het de moeite waard is, en zo ja:
  • 2. Doe het snel — niet perfect. doe het gewoon.
  • 3. Sla het op. upload het maar. geef het vrij.
  • 4. Kijk wat mensen ervan vinden
    • Hoewel ik altijd huiverig ben om ergens nieuwe features aan toe te voegen, zodra ik dat "yeah!"-moment heb van besluiten dat iets de moeite van het doen waard is, dan is het gewoonlijk een paar uur later op de site, met fouten maar daar, en dan laten we de feedback de verdere verfijning bepalen.

      —Derek Sivers, president en programmeur, CD Baby and HostBaby


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.

Kleinere oprachten en kleinere tijdlijnen

Software ontwikkelaars zijn optimisten van een speciaal ras: als ze een programmeeropdracht voorgeschoteld krijgen, denken ze, "Dat is een makkie! Zal helemaal niet veel tijd kosten."

Geef je een programmeur dus drie weken om een grote opdracht te voltooien, dan zal ze twee en halve week bezig zijn met uitstellen, en dan één week met programmeren. Het laattijdige resultaat zal waarschijnlijk aan foute vereisten voldoen, omdat de opdracht ingewikkelder bleek dan ze leek. Bovendien, wie kan zich herinneren wat het team drie weken geleden overeenkwam?

Geef een programmeur een namiddag om een kleine specifieke module te coderen en ze zal dit vlot afwerken, klaar om over te gaan naar de volgende taak.

Kleinere opdrachten en kleinere tijdlijnen zijn beter beheersbaar, verbergen minder mogelijke misverstanden rond de vereisten, en kosten minder om over van mening te veranderen of opnieuw te doen. Kortere tijdlijnen houden ontwikkelaars bij de les en geven hen meer gelegenheid om een gevoel van voldoening te beleven, en minder reden om te denken "Oh, ik heb meer dan genoeg tijd om dat te doen. Laat me nu eerst maar even mijn liedjes een beoordeling geven in mijn iTunes-bibliotheek."

—Gina Trapani, webprogrammeur en uitgever of Lifehacker, de productiviteits- en softwaregids

Echte Factoren

De volgende keer dat iemand je probeert vast te pinnen op een niet te kennen vraag — of het nu is voor de datum van een deadline, de uiteindelijke kosten van een project, of de hoeveelheid melk die in de Grand Canyon past — begin met de druk weg te nemen: zeg "Ik weet het niet."

Dit beschadigt je geloofwaardigheid allerminst, integendeel, het demonstreert de zorg die je besteedt aan het nemen van beslissingen. Je roept niet zomaar wat om slim over te komen. Het plaats je ook op gelijke voet door de vraag te herdefiniëren als een collaboratieve conversatie. Door te leren hoe precies je schatting zou moeten zijn (en waarom) kun je samen een gedeeld begrip ontwikkelen over de werkelijke factoren achter de cijfers.

—Merlin Mann, schepper en uitgever van 43folders.com

Los het ene probleem op dat je in de ogen staart

Mijn absoluut favoriete recente gebeurtenis op het web is het uitbrengen en de adoptie van het "nofollow"-attribuut. Niemand praatte er op voorhand over. Er waren geen conferenties of comités waar een hoop yahoos over het semantische of grammaticale karakter konden debatteren. Geen rfc dat een eenvoudig idee kon omvormen in een xml-fragment van 20 regels dat ik zou moeten lezen om gewoon te weten hoe het te gebruiken, en het dan niet gebruiken omdat ik niet zeker was het ik het moest formatteren naar versie .3 of 3.3b.

Het is eenvoudig, het is effectief, het gaf een mogelijkheid aan mensen die een mogelijkheid wilden — en dat is veel belangrijker wanneer je omgaat met een bevolking van het web die geen boodschap heeft aan specificaties of goede manieren.

De volgende twintig problemen oplossen is soms minder nuttig of verstandig dan het ene probleem oplossen dat je recht in het gezicht kijkt. Het was niet zomaar een kleine overwinning op spam (alle overwinningen op spam zijn klein), maar een overwinning voor diegenen onder ons die houden van simpele en snelle resultaten waar het werk van een webontwikkelaar om draait.

—Andre Torrez, programmeur en VP of Engineering bij Federated Media Publishing


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.

Kom in de Groove

We weten allemaal dat kenniswerkers werken het best in hun "flow", ook bekend als het "in de zone" zijn, waar ze volledig geconcentreerd zijn op hun werk en compleet afgesloten van hun omgeving. Ze verliezen hun besef van tijd en produceren fantastische dingen door absolute concentratie... het probleem is dat het zo gemakkelijk is om uit de zone te raken. Lawaai, telefoon, gaan lunchen, 5 minuten naar Starbucks rijden voor koffie, en onderbrekingen door collega's — vooral onderbrekingen door collega's — slaan je allemaal uit de zone. Wanneer je een onderbreking van een minuut neemt voor een collega met een vraag, die je zo uit je concentratie haalt dat het je een half uur kost om weer productief te worden, dan is je algehele productiviteit in grote problemen.

—Joel Spolsky, software-ontwikkelaar, Fog Creek Software
(uit Where do These People Get Their (Unoriginal) Ideas?) ("Waar halen deze mensen hun (onoriginele) ideeën vandaan?")


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:

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

Minder vergaderen

Er zijn teveel vergaderingen. Vermijd vergaderingen die geen zin hebben of onproductief zijn. Boek een vergadering alleen dan wanneer je een belangrijke bedrijfskwestie te bespreken hebt en je ideeën, goedkeuring, of overeenstemming wilt of nodig hebt. Weersta zelfs dan de drang om iedereen en hun broer uit te nodigen — verspil niet nodeloos andermans tijd.

—Lisa Haneberg, auteur (van Laa!)

Breek in stukjes

Groeit het project, dan wordt het effect van mensen toevoegen steeds kleiner. Eén van de belangrijkste redenen is het verhoogde aantal communicatiekanalen. Twee mensen kunnen alleen met elkaar praten; er is maar één communicatiekanaal. Drie medewerkers hebben drie communicatiekanalen; 4 hebben er 6. In feite is de groei aan het aantal kanalen exponentiëel. Voor je het weet eten memo's en vergaderingen de hele werkdag op.

De oplossing is helder: breek teams op in kleinere, autonome en onafhankelijke eenheden om het aantal communicatiekanalen te verminderen.

Op dezelfde manier, hak programma's in kleinere eenheden. Aangezien een groot deel van het probleem afkomstig is van afhankelijkheden (globale variabelen, data doorgegeven via functies, gedeelde hardware, etc), vind een manier om het programma te partitioneren om afhankelijkheden tussen eenheden te elimineren of minimaliseren.

The Ganssle Group (from Keep It Small) ("Houdt Het Klein")


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...

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.

De Wet van Brooks

Meer mensen voor een software-project over tijd maakt het later.

—Fred Brooks

Programmeren en Mozart's Requiem

Eén enkele goede programmeur werkend aan één enkele taak heeft geen coordinatie- of communicatie-overhead. Vijf programmeurs werkend aan dezelfde taak moeten coördineren en communiceren. Dat kost een hoop tijd... Het echte probleem met de inzet van een grote hoeveelheid middelmatige programmeurs in plaats van een paar goede is dat hoe lang ze ook werken, ze nooit iets kunnen produceren dat zo goed is als wat uitmuntende programmeurs kunnen produceren. Vijf Antonio Salieri's produceren geen Mozart Requiem. Ooit. Al werken ze 100 jaar.

—Joel Spolsky, software developer, Fog Creek Software (uit Hitting the High Notes) ("De Hoge Noten Halen")


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.

Klein beginnen

Probeer te beginnen een kleine proefopdracht. Spring niet met al je werk tegelijk binnen. Laat je nieuwe [virtuele assistent] werken aan een tweetal testprojecten, en kijk hoe de chemie zich ontwikkelt. In het begin is het al te gemakkelijk om mogelijke problemen te verbergen achter roze brilglazen. Maak het duidelijk dat dit een testrit is.

—Suzanne Falter-Barns, auteur / creativiteitsexpert
(uit How To Find And Keep The Perfect VA)


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:

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.

Open Source passie

Wat je het meest wil van een nieuwe werknemer is passie voor wat hij doet, en er is geen betere manier om dat te tonen dan een spoor van engagementen in open source projecten.

—Jarkko Laine, software ontwikkelaar
(uit Reduce the risk, hire from open source)


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.

Extra punten voor het stellen van vragen

Observeer of een kandidaat-werknemer veel vragen stelt over jouw project. Gepassioneerde programmeurs willen een probleem zo goed mogelijk begrijpen en zullen snel mogelijke oplossingen en verbeteringen voorstellen, wat tot veel vragen leidt. Vragen om verduidelijking leggen ook een begrip bloot dat jouw project op duizend verschillende manieren kan geimplementeerd worden en het is essentieel om zo expliciet mogelijk te specifiëren hoe jij precies je webtoepassing in gedachten hebt. Terwijl je tot de details overgaat, zal je het gevoel krijgen of de persoon een goede culturele partij is.

—Eric Stephens, BuildV1.com


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.

Een geordende geest

Goede schrijfvaardigheden zijn een aanwijzing van een georganiseerde geest die bekwaam is om informatie te ordenen en te argumenteren op een systematische manier en ook om andere mensen dingen te helpen begrijpen. Het loopt door in code, persoonlijke communicatie, instant messaging (voor die samenwerkingen op lange afstand), en zelfs in zulke esoterische concepten als professionalisme en betrouwbaarheid.

—Dustin J. Mitchell, ontwikkelaar (uit Signal vs. Noise)

Helder schrijven leidt tot helder denken

Helder schrijven leidt tot helder denken. Je weet niet wat je weet tot je het probeert uit te drukken. Goed schrijven is deels een kwestie van karakter. In plaats van te doen wat gemakkelijk is voor jezelf, doe je wat gemakkelijk is voor je lezer.

—Michael A. Covington, Professor Computerwetenschappen aan de University of Georgia
(uit How to Write More Clearly, Think More Clearly, and Learn Complex Material More Easily (Hoe helderder schrijven, helderder denken en gemakkelijker ingewikkeld materiaal leren))


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.

De oranje pen die Blinksale startte

Van zodra ik mij bewust werd van mijn frustratie met de bestaande facturatiesoftware, besliste ik uit te tekenen hoe ik wilde dat mijn facturatieoplossing zou werken. Ik haalde een oranje pen boven, omdat dit het enige geschikte ding was die avond, en ik had ongeveer 75 procent van de gebruikersinterface uitgetekend binnen enkele uren. Ik toonde het aan mijn vrouw Rachel, die aan het strijken was op dat moment, en vroeg, "Wat denk je?" En ze antwoordde met een glimlach, "Je moet dit doen. Echt waar."

Tijdens de volgende twee weken verfijnde ik de ontwerpen, en modelleerde volledige statische html pagina's voor bijna de volledige eerste versie van wat Blinksale zou worden. We hebben nooit draadmodellen gemaakt na die schetsen met de oranje pen, en meteen overgaan op het html-ontwerp hielp ons opgewonden te blijven over hoe "echt" het project aan het worden was, zelfs al wisten we in die tijd echt niet tot waar dit zou leiden.

Eens de html-modellen afgewerkt waren, benaderden we onze ontwikkelaar, Scott, met het idee voor Blinksale. Dat we het grootste deel van de gebruikersinterface op voorhand ontworpen hadden was een enorm voordeel op verschillende niveaus. Ten eerste gaf het Scott het echte zicht en de opwinding van waar we naar toe gingen. Het was veel meer dan een idee, het was echt. Ten tweede hielp het ons nauwkeurig in te schatten hoeveel moeite en tijd het Scott zou kosten om het ontwerp om te zetten in een werkende toepassing. Wanneer je een project financieel opstart, geldt dat hoe eerder je budgetvereisten kan voorspellen, hoe beter. Het ontwerp van de interface werd onze toetssteen voor het initiële bereik van het project. Tenslotte diende het ontwerp van de interface om ons eraan te herinneren waarover de toepassing ging terwijl we evolueerden. Wanneer we in de verleiding kwamen om nieuwe mogelijkheden toe te voegen, konden we niet zomaar zeggen, "Tuurlijk, laten we dat toevoegen!" We moesten teruggaan naar het ontwerp en onszelf afvragen waar die mogelijkheid zou terechtkomen, en als ze geen plaats had, dan werd ze niet toegevoegd.

—Josh Williams, stichter, Blinksale


Epicentrum-ontwerp

Begin bij de kern van de pagina en werk naar buiten

Epicentrum-ontwerp concentreert zich op de ware essentie van de pagina — het epicentrum — en dan naar buiten werken. Dit betekent dat, aan het begin, je de buitenkant negeert: de navigatie/tabs, voet, kleuren, zijkolom, logo, etc. In plaats daarvan begin je bij het epicentrum en ontwerp je het belangrijkste stukje inhoud eerst.

Een pagina is dat waar een pagina absoluut niet zonder kan. Bijvoorbeeld, wanneer je een pagina ontwerpt die een blogpost weergeeft, dan is de post zelf het epicentrum. Niet de categorieën in de zijkolom, niet de topbalk, niet het commentaar onderaan, maar de eigenlijke post-eenheid. Zonder de post-eenheid is de pagina geen blogpost.

Alleen wanneer die eenheid compleet is begin je te denken aan het eerstvolgende meest kritische element op die pagina. Daarna het op twee na meest kritische element, daarna het derde, enzovoorts. Dat is epicentrum-ontwerp.

Epicentrum-ontwerp passeert het traditionele model à la "we bouwen het raamwerk eerst en gooien de inhoud er wel in". In dat laatste proces wordt eerst de pagina vormgegeven, dan de navigatie aangebracht, dan de marketingrommel ingevoegd, en dan wordt eindelijk pas de kernfunctionaliteit gegoten in wat er toevallig aan ruimte overblijft. Het traditionele model is een achterwaarts proces dat de hoogste prioriteit voor het laatst bewaard.

Epicentrum-ontwerp draait dat proces om en stelt je in staat om je te concentreren op waar het werkelijk om gaat. Essenties eerst, extra's daarna. Het resultaat is een vriendelijker, geconcentreerder, bruikbaar scherm voor klanten. Bovendien helpt het je de dialoog tussen ontwerper en software-ontwikkelaar meteen op gang te brengen, en hoef je niet te wachten tot alle aspecten van de pagina op hun plaats vallen.



Drie toestanden

Ontwerp voor normale, lege en fouttoestanden

Voor elk scherm moet je rekening houden met drie mogelijke toestanden:

De normale toestand is een makkie. Aan dit scherm zal je het meeste tijd besteden. Maar vergeet niet om ook tijd te steken in de andere toestanden (meer hierover in de volgende paragrafen).



De propere lei

Vestig verwachtingen met een doordachte eerste indruk

De lege toestand negeren is een van de grootste fouten die je kan maken. De propere lei is de eerste indruk van je applicatie en je krijgt er nooit een tweede... je weet wel.

Het probleem is dat de interface bij het ontwerp meestal vol zit met data. Ontwerpers vullen templates altijd met data. Elke lijst, elke post, elk veld, elke hoekje en kantje bevat dingen. En dat betekent dat het scherm er geweldig uitziet en werkt.

Toch is de natuurlijke toestand van de toepassing er een zonder data. Wanneer iemand inschrijft, begint die met een propere lei. Net als een weblog, is het aan hen om het op te vullen — de totale look and feel krijgt pas vorm als mensen hun gegevens invullen: posts, links, commentaren, uren, sidebar informatie, wat dan ook.

Helaas beslist een klant of een toepassing waardevol is in deze lege toestand — de fase waarin er het minste informatie, design en inhoud is waarop de algemene bruikbaarheid van de toepassing kan beoordeeld worden. Als je er niet in slaagt om een behoorlijke propere lei te ontwerpen, dan weten mensen niet wat ze missen omdat alles ontbreekt.

Toch beschouwen de meeste ontwerpers en ontwikkelaars deze fase als vanzelfsprekend. Ze slagen er niet in om veel tijd te besteden aan de propere lei omdat de applicatie, terwijl ze hem ontwerpen/gebruiken, vol zit met gegevens die ze hebben ingevuld om te testen. Ze komen de propere lei zelfs niet tegen. Jazeker, misschien zullen ze enkele keren inloggen als nieuwe persoon, maar het grootste deel van hun tijd zwemmen ze rond in een toepassing die vol zit met gegevens.

Wat moet je invoegen in een hulpvaardige lege toestand?

Eerste indrukken zijn cruciaal. Als je er niet in slaagt een doordachte propere lei te ontwerpen, creëer je een negatieve (en foute) indruk van je applicatie of dienst.

Je krijgt nooit een tweede kans...

Een ander aspect van de Mac OS x interface dat volgens mij enorm beïnvloed is door [Steve] Jobs is de ervaring bij de setup en het eerste gebruik. Ik denk dat Jobs uitermate bewust is van het belang van eerste indrukken... Ik denk dat Jobs naar de eerste gebruikerservaring kijkt en denkt, het is misschien maar een duizendste van de totale gebruikerservaring met de machine, maar het is het belangrijkste duizendste, omdat het het eerste duizendste is, en het vestigt hun verwachtingen en initiële indruk.

John Gruber, auteur en webontwikkelaar (uit Interview with John Gruber)


Wees Defensief

Ontwerp voor wanneer er iets fout gaat

Laten we het toegeven: er gaan dingen mis online. Hoe zorgvuldig je je applicatie ook ontwerpt, hoeveel testen je ook uitvoert, klanten zullen nog altijd problemen tegenkomen. Dus hoe ga je om met deze onontkoombare breuken? Met defensief ontwerp.

Defensief ontwerpen is als defensief rijden. Op dezelfde manier waarop bestuurders altijd moeten uitkijken voor gladde wegen, roekeloze bestuurders, en andere gevaarlijke scenario's, zo moeten sitebouwers voortdurend op zoek gaan naar probleemgebieden die bezoekers verwarring en frustratie opleveren. Goede site-defensie kan de gebruikerservaring maken of breken.

We zouden een boek kunnen vullen over alles wat we te zeggen hebben over defensief ontwerp. In feite hebben we dat al gedaan. "Defensive Design for the Web" is de titel en het is een geweldige bron voor iedereen die wil leren hoe je foutmelding-schermen en andere crisispunten kunt verbeteren.

Onthoud: je applicatie mag 90% van de tijd geweldig werken. Maar als je klanten in de steek laat wanneer ze je nodig hebben, dan zullen ze dat niet gauw vergeten.



Contekst gaat voor Consistentie

Wat hier steek houdt, houdt daar niet noodzakelijk steek

Moeten acties knoppen of links zijn? Dat hangt af van de actie. Moet een kalenderweergave in lijstvorm of in gridvorm? Het hangt ervan af waar hij staat en hoe lang de tijdsperiode is. Moet iedere globale navigatielink op iedere pagina aanwezig zijn? Heb je overal een globaal zoekveld nodig? Heb je exact dezelfde voet nodig op iedere pagina? Het antwoord: "Het hangt ervan af."

Daarom is contekst belangrijker dan consistentie. Het is prima om inconsistent te zijn als je ontwerp op die manier meer betekenis krijgt. Geef mensen alleen wat ertoe doet. Geef ze wat ze nodig hebben en haal weg wat ze niet nodig hebben. Het is beter om juist te zijn dan consistent.

Intelligente Inconsistentie

Consistentie is niet nodig. Jarenlang werd studenten van gebruikersinterfaces en gebruikerservaring verteld dat consistentie is één van de kardinale regels in interface-ontwerp. Misschien werkt dat in software, maar op het web is het gewoon niet waar. Wat ertoe doet op het Web is of, op iedere individuele pagina, de gebruiker snel en gemakkelijk naar de volgende stap in het proces kan gaan.

Bij Creative Good noemen we dit "intelligent inconsistency": er zeker van zijn dat iedere pagina de gebruiker exact geeft wat ze op dat punt in het proces nodig hebben. Overbodige navigatie-elementen toevoegen, alleen maar omdat ze consistent zijn met de rest van de site, is gewoon stom.

—Mark Hurst, oprichter van Creative Good en maker van Goovite.com
(uit The Page Paradigm)


Tekstschrijven is interface-ontwerp

Iedere letter telt

Copywriting is interface design. De beste interfaces worden geschreven. Als je denkt dat iedere pixel, ieder icoon, ieder lettertype ertoe doet, dan moet je ook geloven dat iedere letter ertoe doet. Wanneer je je interface schrijft, plaats jezelf in de schoenen van de persoon die je interface leest. Wat moeten ze weten? Hoe kun je het gecondenseerd en duidelijk uitleggen?

Noem je een knop "Submit" of "Save" of "Update" of "New" of "Create"? Dat is copywriting. Schrijf je drie zinnen of vijf? Leg je uit met algemene voorbeelden of met details? Noem je inhoud "New" of "Updated" of "Recently Updated" of "Modified"? Is het, "Er zijn nieuwe berichten: 5" of "Er zijn 5 nieuwe berichten" of is het 5 of vijf, of berichten of "posts"? Dit telt allemaal.

Je moet bovendien dezelfde taal spreken als je publiek. Alleen omdat je een webapplicatie schrijft betekent nog niet dat je wegkomt met technisch jargon. Denk aan je klanten en denk aan wat deze knoppen en woorden voor ze betekenen. Gebruik geen acronymen of woorden die de meeste mensen niet begrijpen. Gebruik geen intern jargon. Klink niet als een programmeur die tot een andere programmeur spreekt. Houd het kort en duidelijk. Zeg wat je moet zeggen maar niet meer.

Goed schrijven is goed ontwerp. Alleen bij hoge uitzonderingen begeleiden woorden het ontwerp niet. Iconen met namen, formuliervelden met voorbeelden, knoppen met labels, stapsgewijze instructies in een proces, een heldere uitleg van je terugbetaalpolitiek. Dit is allemaal interface-ontwerp.



Eén interface

Incorporeer beheerfuncties in de publieke interface

Administratieschermen — de schermen om voorkeuren, mensen, enz. te beheren — hebben de neiging om eruit te zien als rommel. Dat komt omdat het grootste deel van de ontwikkelingstijd besteed wordt aan de publieke interface.

Om het rommel-admin-scherm-syndroom te vermijden, bouw je beter geen aparte schermen voor de beheerfuncties. Bouw deze functies (bv. aanpassen, toevoegen, verwijderen) juist mee in de normale interface van de toepassing.

Als je twee aparte interfaces moet onderhouden (nl. één voor de gewone mensen en één voor de admins), dan zullen beide eronder lijden. Daarnaast zal je dezelfde inspanning twee keer moeten doen. Je bent verplicht jezelf te herhalen en dat betekent dat je kansen op slordigheid verhogen. Hoe minder schermen waarover je je zorgen moet maken, hoe beter ze er zullen uitzien.

Geen aparte interface

De toepassing is alles. Alles dat kan veranderd, toegevoegd of aangepast worden, kan rechtstreeks gedaan worden in het beheergedeelte van de toepassing. Dit laat ons toe om exact hetzelfde te zien als onze klanten en hen te helpen met alle problemen en vragen die zij hebben. En onze klanten hoeven zich geen zorgen te maken over inloggen in een aparte interface om andere taken te doen. De ene minuut kunnen ze bezig zijn met afspraken voor hun klanten en de volgende minuut moeten ze misschien een nieuwe werknemer toevoegen. Ze hebben geen zin om heen en weer te springen tussen verschillende toepassingen en door een consistente interface te hanteren kunnen ze de applicatie nog sneller onder de knie krijgen.

—Edward Knittel, Directeur Sales en Marketing, KennelSource


Code hoofdstuk 10

Minder Software

Hou je code zo eenvoudig mogelijk

Je zou denken dat dubbel zoveel code je software maar dubbel zo complex maakt. Maar in werkelijkheid is het zo dat elke keer dat je de hoeveelheid code vergroot, je software exponentieel complexer wordt. Elke kleine toevoeging, elke verandering, elke afhankelijkheid, en elke instelling heeft een watervaleffect. Blijf je roekeloos code toevoegen, dan zal je voor je het weet de verschrikkelijke Grote Modderbal gecreëerd hebben.

De manier waarop je deze complexiteit tegengaat is met minder software. Minder software betekent minder features, minder code, minder afval.

De sleutel is om elk moeilijk probleem dat veel software vereist, te herformuleren naar een eenvoudig probleem dat veel minder vereist. Misschien los je niet exact hetzelfde probleem op, maar dat geeft niks. 80% van het oorspronkelijke probleem oplossen met 20% van de inspanningen is een grote winst. Het oorspronkelijke probleem is bijna nooit zo erg dat het een vijfvoud aan inspanningen waard is om het op te lossen.

Minder software betekent dat je de kristallen bol weglegt. In plaats van toekomstige problemen te proberen voorspellen, werk je enkel met de problemen van vandaag. Waarom? Je vrees voor morgen komt vaak niet uit. Rijd jezelf niet vast met het oplossen van spookproblemen.

Vanaf de start hebben wij onze producten ontworpen rond het concept van 'minder software'. Wanneer mogelijk breken we moeilijke problemen op in eenvoudige. We hebben gemerkt dat oplossingen voor gemakkelijkere problemen niet alleen gemakkelijker te implementeren en te ondersteunen zijn, maar ook gemakkelijker te begrijpen en gemakkelijker te gebruiken. Het maakt allemaal deel uit van hoe we onszelf differtentieren van concurrenten; in plaats van producten te proberen bouwen die meer doen, bouwen we producten die minder doen.

Welke features je kiest om in te voegen of weg te laten heeft ook veel te maken met minder software. Wees niet bang om neen te zeggen teggen vragen naar features die moeilijk te doen zijn. Tenzij ze absoluut essentieel zijn, bespaar tijd/moeite/verwarring door ze eruit te laten.

Vertraag bovendien. Onderneem een week lang geen actie en kijk of het nog steeds een geweldig idee blijkt nadat het eerste enthousiasme gaan liggen is. De extra marineertijd zal je brein vaak helpen met een betere oplossing te komen.

Moedig programmeurs aan om een tegenbod te doen.
Wat je wil horen is: "De manier die jij voorstelt zal 12 uur vragen. Maar er is een manier waarop het maar één uur zal kosten. Het zal niet x doen maar het zal y doen." Laat de software terugduwen. Vertel programmeurs dat ze moeten vechten voor wat zijn denken dat de beste manier is.

Zoek voorts naar omwegen rond meer software schrijven. Kan je de tekst op het scherm veranderen zodat het een alternatieve route voorstelt aan de klanten zonder dat het een verandering in het softwaremodel vraagt? Kan je bijvoorbeeld voorstellen dat mensen afbeeldingen uploaden van een specifieke grootte in plaats van de beeldmanipulatie aan de serverkant te doen?

Stel jezelf, voor elke feature die het je toepassing haalt, de vraag: is er een manier waarop dit kan toegevoegd worden die niet zoveel software vereist? Schrijf enkel de code die je nodig hebt en meer niet. Je toepassing zal hierdoor slanker en gezonder zijn.

Er is geen CODE die flexibeler is dan GEEN code!

Het "geheim" van goed sotwareontwerp lag niet in weten wat er in de code moest komen, maar in weten wat eruit moest blijven! Het lag in de erkenning waar de harde stukken en de zachte stukken lagen, en weten waar ruimte te laten in plaats van meer in het ontwerp te proppen.

—Brad Appleton, software-ingenieur
(uit There is No CODE that is more flexible than NO Code!)

Complexiteit schaalt niet linair met grootte

De belangrijkste regel van software-ontwerp is tegelijk de minst bekende: Complexiteit schaalt niet linair met grootte... Een programma van 2000 lijnen vereist meer dan het dubbel van de ontwikkelingstijd dan één van de helft van die grootte.

The Ganssle Group (uit Keep It Small)


Optimaliseer de werkvreugde

Kies werkmiddelen dat je team enthousiast en gemotiveerd houdt

Een gelukkige programmeur is een productieve programmeur. Dat is de reden waarom wij de werkvreugde optimaliseren, en jij dat ook zou moeten. Kies niet zomaar werkmiddelen en praktijken volgens de standaarden van de industrie of prestatiestatistieken. Kijk naar het ontastbare: is er passie, fierheid, en vakmanschap? Zou je echt graag acht uur per dag werken in deze omgeving?

Dit is met name belangrijk bij het kiezen van een programmeertaal. Tegen de algemene opvatting in, zijn deze niet allemaal gelijkwaardig. Ook al kan zowat elke taal zowat iedere applicatie maken, zullen de beste de inspanning niet zomaar mogelijk of draaglijk maken, maar leuk en stimulerend. Het gaat erom de kleine details van het dagelijkse werk prettig te maken.

Vreugde heeft een watervaleffect. Blije programmeurs doen de juiste dingen. Ze schrijven eenvoudige, leesbare code. Ze hebben een propere, expressieve, leesbare en elegante benadering. Ze hebben plezier.

Wij vonden programmeergeluk in de taal Ruby en gaven het door aan andere ontwikkelaars met ons framework Rails. Beide hebben dezelfde missie om te optimaliseren voor mensen en hun vreugde. We moedigen je aan om die combinatie uit te proberen.

Samengevat, je team moet werken met gereedschappen waar ze van houden. We hebben het hier gehad over programeertalen, maar het concept geldt ook voor applicaties, platformen, en al de rest. Kies een lont die mensen aanvuurt. Je zal enthousiasme en motivatie kweken en daardoor een beter product.

Het soort ontwikkelaars dat je wil

De belangrijkste reden waarom ik onze toepassing in Ruby on Rails wilde bouwen, is omdat het zo elegant, productief en mooi ontworpen is. Het trekt het soort ontwikkelaars aan dat hierom geeft... en dat zijn net het soort ontwikkelaars dat je in je team wil, omdat ze het soort mooie, elegante en productieve sotware creëren dat je nodig hebt om de markt te winnen.

—Charles Jolley, Managing Director bij Nisus Software (van Signal vs. Noise)


Code spreekt

Luister als je code tegenstribbelt

Luister naar je code. Ze zal suggesties doen. Ze zal tegenstribbelen. Ze zal je vertellen waar de valkuilen zitten. Ze zal nieuwe wegen suggereren om dingen te doen. Ze zal je helpen komen tot een model van minder software.

Vergt een nieuwe feature weken tijd en duizenden lijnen code? Dan vertelt je code je dat er waarschijnlijk een betere manier is. Is er een eenvoudige manier om iets te programmeren in één uur in plaats van een ingewikkelde manier die tien uur vraagt? Opnieuw is het je code die je gidst. Luister.

Je code kan je leiden naar oplossingen die goedkoop en licht zijn. Let op als er zich een eeunvoudig pad aandient. Toegegeve,, de eenvoudig te maken feature is misschien niet helemaal dezelfde als die die je in gedachten had, maar wat dan nog? Als het goed genoeg werkt en je meer tijd geeft om aan iets anders te werken, dan is het een blijver.

Luister

Maak je geen zorgen over design, als je luistert naar je code zal een goed design verschijnen... Luister naar de technische mensen. Als ze klagen over de moeilijkheid om veranderingen aan te brengen, neem zulke klachten dan ernstig en geef hen tijd om de zaken te herstellen.

—Martin Fowler, Chief Scientist, ThoughtWorks (uit Is Design Dead?)

Als programmeurs betaald werden om code te verwijderen...

Als programmeurs betaald werden om code te verwijderen uit software in plaats van nieuwe code te schrijven, dan zou software een heel stuk beter zijn.

Nicholas Negroponte, Professor Mediatechnology aan het MIT
(uit And, the rest of the (AIGA Conference) story)


Beheer schulden

Betaal je code- en design-"rekeningen" af

We denken gewoonlijk over schulden in termen van geld, maar het komt ook in andere vormen voor. Je kan snel code- en designschulden opbouwen.

Hack wat slechte code bij elkaar die functioneel is maar toch wat gammel en je bouwt een schuld op. Gooi een design bij elkaar dat goed genoeg is maar niet echt goed en je doet het opnieuw.

Het is ok om dit af en toe te doen. Het is zelfs vaak een noodzakelijke techniek die je helpt om het hele Get-Real-asap concept te doen. Maar je moet het nog steeds als schuld erkennen en het op een bepaald moment afbetalen door de gammel code op te schonen of die zo-zo-pagina opnieuw ontwerpen.

Op dezelfde manier als je regelmatig wat inkomsten opzij moet zetten voor belastingen, moet je regelmatig wat tijd opzij zetten om je code- en designschuld af te betalen. Als je dat niet doet, zal je gewoon interest moeten betalen (hacks herstellen) in plaats van de som terug te betalen (en vooruitgaan).



Open deuren

Laat gegevens vrij via RSS, APIs, enz.

Prorbeer je klanten niet op te sluiten. Laat ze hun informatie verkrijgen wanneer ze het willen en hoe ze het willen. Om dat te doen moet je af van het idee om gegevens te verzegelen. Laat ze juist loslopen. Geef mensen toegang tot hun informatie via RSS feeds. Biedt APIs aan die andere ontwikkelaars toelaat om verder te bouwen op je toepassing. Wanneer je dat doet, maak je het leven van kalnten eenvoudiger en breid je de mogelijkheden uit van wat je toepassing kan doen.

Vroeger dachten mensen dat RSS feeds louter een goede manier waren om blogs en nieuwssites op te volgen. Feeds hebben echter meer kracht dan dat. Ze geven klanten ook een geweldige manier om op de hoogte te blijven van de veranderende inhoud van een toepassing zonder herhaaldelijk te moeten inloggen. Met de feeds van Basecamp kunnen klanten de url in een nieuwslezer ploffen en de projectberichten, takenlijsten en mijlpalen in het oog houden zonder constant de site te moeten nakijken.

APIs laten ontwikkelaars toe om uitbreidingen te bouwen voor je toepassing die onbetaalbaar kunnen blijken. Backpack bijvoorbeeld voorziet een API die Chipt Productions gebruikt hebben om een Mac OS X Dashboard widget te bouwen. De widget laat mensen herinneringen, lijsten en dergelijke toevoegen en aanpassen vanop het bureaublad. Klanten hebben deze widget bejubeld en sommigen zeiden zelfs dat het de sleutelfactor was om Backpack te gaan gebruiken.

Andere goede voorbeelden van bedrijven die hun data loslieten om een boemerangeffect te verkrijgen:

Een widget maakt het verschil

Toen 37signals een tijdje geleden Backpack lanceerde, was mijn eerste indruk... eh.

Het was toen Chipt Productions een Backpack widget uitbracht voor Tiger — dat te cool was om niet te downloaden en te proberen — dat ik Backpack een tweede keer bekeek. Het resultaat? Een heel verschil.

Als ik nu een idee krijg, open ik de widget, typ en verzend — klaar! Komt er een e-mail binnen met iets dat ik wil bekijken? De widget openen, typen en verzenden — klaar! De widget biedt een onmiddellijke breindump, beschikbaar op elke Mac die ik gebruik. En omdat alles webgebaseerd is, is er geen versiecontrole of synchronisatie — enkel de eenvoudige invoer van inhoud zonder me zorgen hoeven te maken over waar het heen gaat of hoe ik er later aan zal kunnen.

—Todd Dominey, oprichter, Dominey Design
(uit Trying on Backpack)


Woorden hoofdstuk 11

Er is niets functioneel aan een functionele specificatie

Schrijf nooit een functioneel specificatiedocument

Dit soort overzichtsdocumenten draaien gewoonlijk uit op iets dat bijna niets te maken heeft met het eindproduct. Waarom?

Functionele specificaties zijn fantasie

Ze geven de werkelijkheid niet weer. Een applicatie is niet echt totdat de bouwers het bouwen, de ontwerpers het ontwerpen, en de gebruikers het gebruiken. Functionele specificaties zijn slechts woorden op papier.

Functionele specificaties houden iedereen te vriend

Ze zijn bedoeld om om iedereen zich betrokken en blij te maken hetgeen, hoewel warm en knus, niet al erg nuttig is. Ze gaan nooit over moeilijke beslissingen en het inzichtelijk maken van kosten, dingen die moeten gebeuren om een geweldige applicatie te kunnen bouwen.

Functionele specificaties leiden tot een illusie van overeenstemming

Een groepje mensen dat overeenstemming bereikt over wat paragrafen met tekst, dat is geen echte overeenkomst. Iedereen mag dan wel hetzelfde lezen maar ze denken allemaal iets anders. Later komt dit onontkoombaar uit: "Wacht even, dat is niet wat ik in gedachten had." "Huh? Dat is niet zoals we het beschreven hadden." "Ja dat was het wel en we waren het er allemaal over eens — je hebt er zelfs voor getekend." Je kent het wel.

Functionele specificaties dwingen je om de belangrijkste beslissingen te nemen wanneer je over de minste informatie bechikt

Je weet ergens het minste van wanneer je het begint te bouwen. Hoe meer je eraan bouwt, hoe meer je het gebruikt, des te meer ken je het. Dat is het moment waarop je beslissingen zou moeten nemen — wanneer je meer informatie hebt, niet minder.

Functionele specificaties leiden tot "feature overlaod"

Er is geen terughoudendheid tijdens de specificatiefase. Het kost niets om iets op te schrijven en nog een punt aan het lijstje toe te voegen. Je kunt iemand die vervelend doet tevredenstellen door zijn lievelingsmogelijkheid toe te voegen. En dan eindig je met het ontwerpen naar punten, niet naar mensen. En zo eindig je met een overladen site met 30 tabjes bovenaan het scherm.

Functionele specificaties laten je niet evalueren, veranderen, en evolueren

Een feature is afgetekend en overeengekomen. Zelfs wanneer je tijdens de ontwikkeling realiseert dat het een slecht idee is, zit je eraan vast. Specificaties houden geen rekening met de werkelijk dat zodra je iets begint te bouwen, alles verandert.

Dus wat doe je in plaats van een "spec"? Kies het kortere alternatief dat je in de richting brengt van iets echts. Schrijf een verhaal van één pagina over wat de appllicatie moet doen. Gebruik klare taal en houd het kort. Als er meer dan een pagina mee gemoeid is, dan is het te complex. Dit proces mag niet meer dan een dag kosten.

Begin dan met het bouwen van de interface — de interface wordt het alternatief voor de functionele specificatie. Teken een paar snelle en simpele papierschetsen. Codeer het vervolgens in HTML. In tegenstelling tot paragrafen tekst die onderworpen zijn aan interpretatie, zijn interface-ontwerpen gemeenschappelijk terrein waar iedereen elkaar kan vinden.

Verwarring verdwijnt zodra iedereen dezelfde schermen begint te gebruiken. Bouw een interface die iedereen kan bekijken, gebruiken, doorklikken, en "voelen" voordat je je zorgen hoeft te maken over back-end-code. Houd je zoveel mogelijk bezig met de voorkant van de gebruikerservaring.

Vergeet opgesloten specificaties. Ze dwingen je tot het in een te vroeg stadium van het proces maken van grote sleutelbeslissingen. Sla de spec-fase over en je zult de verandering goedkoop houden en flexibel blijven.

Zinloze Specs

Een "spec" is vrijwel zinloos. Ik heb nog nooit een spec gezien die zinvol en voldoende accuraat was.

En ook heb ik een hoop complete troep gezien die gebaseerd was op specs. Het is werkelijk de slechtste manier om software te schrijven, omdat de software per definitie wordt geschreven in overeenkomst met de theorie in plaats van de realiteit.

—Linus Torvalds, schepper of Linux (uit: Linux: Linus On Specifications)

Bestrijd de hinderpalen

Ik beschouwde degenen die aandringen op uitgebreide eisen-documentatie vooraf als echte hinderpalen die alleen maar probeerden om het proces te vertragen (en gewoonlijk zijn dat mensen die niets aan ontwerp of innovatief denken bijdragen).

Al ons beste werk werd gedaan met een paar concepten in het hoofd over het verbeteren van een site, het snelgemaakte prototype (statisch), het ontwerp een beetje veranderen en dan het live-prototype maken met echte data. Na het uittesten van dit prototype hadden we gewoonlijk een echt project in gang en een goed resultaat.

—Mark Gallagher, corporate intranet developer (uit Signal vs. Noise)


Geen Dode Documenten

Elimineer nodeloos papierwerk

Het vermijden van functionele specificaties is een goed begin, maar laat het daar niet bij; voorkom overtollig papierwerk overal. Produceer geen documenten tenzij die daadwerkelijk in iets echts vertaald worden.

Bouwen, niet schrijven. Als je iets moet uitleggen, probeer het in elkaar te zetten of er een prototype van te maken in plaats van er een langdradig document over te schrijven. Een echte interface of een echt prototype is op weg om een echt product te worden. Een stuk papier daarentegen is alleen op weg naar de prullenmand.

Een voorbeeld: wanneer een draadmodel voorbestemd is nooit een echt ontwerp te worden, begin er dan niet eens aan. Als het draadmodel begint als een draadmodel en zich uiteindelijk onvormt tot een echt ontwerp, ga ervoor.

Documenten die apart leven van je applicatie zijn zinloos. Ze gaan nergens naartoe. Alles wat je doet moet evolueren naar "the real thing". Als een document stopt voordat het iets echts wordt, is het dood.

Niemand gaat het lezen

Ik kan zelfs niet meer tellen hoeveel vuistdikke productspecificaties of "business requirement" documenten zijn blijven slingeren, ongelezen, stof verzamelend vlakbij mijn ontwikkelingteam terwijl we aan het programmeren waren, problemen bediscussiëerden, vragen stelden en gebruikstesten deden. Ik heb zelfs met programmeurs gewerkt die urenlang bezig waren met het schrijven van lange beschrijvende e-mails of code-standaard-documenten die ook ongelezen bleven.

Webapplicaties komen niet vooruit met lijvige documentatie. Software-ontwikkeling is een voortdurend verschuivend, iteratief proces waarmee interactie, onverwachte beslissingen en nauwelijks te voorspellen vraagstukken gemoeid zijn. Niets hiervan kan worden vastgelegd op papier.

Verspil geen tijd aan het typen van dat lange visionaire boekdeel; niemand gaat het lezen. Troost je met het feit dat als je je product voldoende ruimte geeft om te groeien, het aan het eind toch al niet zal lijken op wat je geschreven hebt.

—Gina Trapani, webprogrammeur en redacteur van Lifehacker, de productiviteits- en softwaregids


Vertel me een vlot verhaal

Schrijf verhalen, geen details

Mocht je woorden nodig hebben om een nieuwe feature of nieuw concept uit te leggen, schrijf er dan een verhaaltje over. Treed niet in technische- of ontwerpdetails, vertel gewoon een vlot verhaal. Doe het op een mensenlijke manier, zoals in een gewone conversatie.

Het hoeft geen essay te zijn. Geef alleen de verhaallijn. Als je het verhaaltje kunt plaatsen in de contekst van de schermen die je ontwikkelt, des te beter.

Blijf bij de ervaring in plaats van je te verliezen in de details. Denk strategisch, niet tactisch. De tactiek valt op zijn plaats zodra je dat gedeelte van je applicatie begint te bouwen. Voor nu wil je alleen een verhaal om de conversatie te beginnen en je op het juiste spoor te brengen.



Gebruik Echte Woorden

Voeg echte tekst in, geen "lorem ipsum"

"Lorem ipsum dolor" is een trouwe vriend van ontwerpers. Proeftekst helpt mensen begrijpen hoe het ontwerp eruit zal zien zodra het uitgewerkt is. Maar proeftekst kan ook gevaarlijk zijn.

"Lorem ipsum" verandert de manier waarop tekst wordt gezien. Het reduceert tekstuele inhoud tot een visueel ontwerpelement — een vorm van tekst — in plaats van wat het zou moeten zijn: waardevolle informatie die iemand zal moeten invoeren en/of lezen. Proeftekst betekent dat je de onvermijdelijke variaties niet ziet die de kop opsteken zodra echte informatie wordt ingevoerd. Het betekent dat je niet weet hoe het zal zijn om een formulier op je site in te vullen. Proeftekst is een sluier tussen jou en de realiteit.

Je hebt echte kopij nodig om te weten hoe lang bepaalde velden zouden moeten zijn. Je hebt echte kopij nodig om te zien hoe tabellen uitzetten en inkrimpen. Je hebt echte kopij nodig om te weten hoe je applicatie er werkelijk uitziet.

Zodra je kunt, gebruik echte en relevante woorden. Als je site of aplicatie echte data input nodig heeft, vul het echte werk in. En typ de werkelijke tekst in — plak het er niet in van een andere bron. Gaat het om een naam, typ dan een naam. Is het een stad, typ een echte stad. Is het een wachtwoord, en het wordt herhaald, typ het tweemaal.

Jazeker, het is gemakkelijker om de formulieren langs te lopen en de velden in te vullen met afval ("asdsadklja" "123usadfjasld" "snaxn2q9e7") om er zo snel mogelijk doorheen te ploegen. Maar dat is niet echt. Dat is niet wat je klanten zullen doen. Is het echt slim om een binnenweg te nemen wanneer klanten op de lange weg gedwongen worden? Wanneer je alleen namaak-kopij invult met de snelvuurmethode, dan weet je niet hoe het voelgt om dat formulier in te vullen.

Doe als je klanten doen en je zult ze beter begrijpen. Wanneer je ze beter begrijpt, en voelt wat zij voelen, zul je een betere interface maken.

"Lorem Ipsum"-rommel

Als je de verbeelding mist om te kunnen verbeelden wat de inhoud "zou" kunnen zijn, dan is een ontwerp-overweging verloren. Betekenis wordt verhuld omdat "het alleen maar tekst is", begrijpelijkheid raakt gecompromitteerd omdat niemand in de gaten had dat de tekst was bedoeld om gelezen te worden. Kansen raken verkeken omdat de "lorem ipsum"-rommel die je gebruikte in plaats van echte inhoud geen mogelijkheden suggereert. De tekst wordt dan vanzelf klein, omdat zij niet bedoeld is om gebruikt te worden. We zouden net zo goed van die prachtige witruimte kunnen creëren.

—Tom Smith, ontwerper en programmeur (uit I hate Lorem Ipsum and Lorem Ipsum Users) ("Ik haat Lorem Ipsum en Lorem Ipsum-gebruikers")


Personificeer je Product

Wat is het persoonlijkheidstype van je product?

Denk over je product als een persoon. Wat soort persoon wil je dat het is? Beleefd? Strict? Vergeeflijk? Strikt? Grappig? Zoutloos? Serieus? Los? Wil je overkomen als paranoïde of vertrouwend? Een wijsneus? Of bescheiden en sympathiek?

Zodra je besloten hebt, houd dan altijd deze persoonlijke eigenschappen in het achterhoofd wanneer het product wordt gebouwd. Gebruik ze als gids voor het tekstschrijven, de interface, en de features. Wanneer je een verandering maakt, vraag je af of die verandering past bij de persoonlijkheid van je applicatie.

Je product heeft een stem — en die spreekt 24 uur per dag met je klanten.



Prijzen en aanmelding hoofdstuk 12

Gratis staaltjes

Geef iets gratis weg

Het is een lawaaiige wereld. Om door mensen opgemerkt te worden, moet je iets gratis weggeven.

Slimme ondernemingen weten dat weggevertjes een uitstekende manier zijn om klanten te lokken. Kijk naar Apple. Ze bieden hun iTunes-software gratis aan om vraag te creëren voor de iPod en de iTunes-muziekwinkel. In de offline-wereld doen retailwinkels hetzelfde. Starbucks zegt dat ze één nieuwe aankoop stimuleren voor iedere vijf drankstaaltjes die ze weggeven aan klanten. Niet slecht.

Wat ons betreft, "Writeboard" en "Ta-da List" zijn compleet gratis producten die we gebruiken om mensen op weg te krijgen om onze andere producten te gebruiken. Ook bieden we altijd een gratis versie van al onze applicaties aan.

We willen dat het product, de interface, de bruikbaarheid van wat we hebben gemaakt wordt ervaren. Zodra mensen overhaald zijn, zullen ze veel eerder upgraden naar één van onze betalende plannen (die meer projecten of pagina's biedt en toegang geeft tot meer features zoals bestanden uploaden en SSL data-encryptie.

Hapklare brokken

Maak hapklare brokken: bedenk gespecialiseerde, kleinere aanbiedingen om klanten te laten toehappen. Beslis om minstens één product of service onder teverdelen of in een goedkope, gemakkelijke, leuke hapklare brok.

—Ben McConnell en Jackie Huba, auteurs van Church of the Customer Blog
(uit What is customer evangelism?)

Geef je hitsingle weg

Overweeg één van je liedjes (per album) weg te geven als een gratis promotionele download — ongeveer zoals een filmtrailer — zoals de hitsingle die naar de radio wordt gestuurd — het liedje dat maakt dat mensen je muziek willen kopen.

Geen zorgen over piraterij voor dit liedje. Laat mensen het afspelen, kopiëren, delen, weggeven. Vertrouw erop dat als de wereld het hoort, ze willen betalen voor meer.

—Derek Sivers, president en programmeur, CD Baby en HostBaby (uit Free Promo Track)


Gemakkelijk erop, gemakkelijk eraf

Maak inschrijven en annuleren een pijnloos proces

Maak het zo gemakkelijk mogelijk om in en uit je applicatie te stappen.

Als ik een klant ben die jouw applicatie wil gebruiken, moet het een pijnloos, gedachtenloos proces zijn. Bied een grote, duidelijke inschrijfknop die eruit springt, en zet hem op iedere pagina van je marketingsite. Vertel hoe gemakkelijk het is: "Van inschrijving tot login in slechts 1 minuut!"

Er moet altijd een gratis mogelijk zijn zodat klanten de applicatie kunnen proberen zonder hun creditcardgegevens in te voeren. Bij sommige van onze concurrenten is een telefoontje, een afspraak, of een speciaal wachtwoord vereist om hun product uit te proberen. Wat is daar nu aan? Wij laten iedereen op elk moment onze applicaties gratis proberen.

Houd het aanmeldingsformulier zo kort mogelijk. Vraag niet om dingen die je niet nodig hebt, en smijt mensen geen lang, ontmoedigend formulier in hun gezicht.

Dezelfde principes gelden voor het annuleringsproces. Je mag mensen nooit gevangen houden binnen je product. Hoewel we het jammer vinden als mensen besluiten om hun Basecamp account te annuleren, maken we dat proces nooit intimiderend of verwarrend. "Annuleer mijn account" is een link die glashelder op iemand's account-pagina vermeld staat. Er mogen geen e-mail, speciaal formulier of vragen mee gemoeid zijn.

Zorg er ook voor dat mensen hun data eruit kunnen halen als ze besluiten te vertrekken. We zorgen ervoor dat klanten gemakkelijk en op ieder gewenst moment al hun berichten en commentaar naar XML kunnen exporteren.

Dit is cruciaal omdat mensen controle geven over hun informatie vertrouwen opbouwt. Je geeft ze een brug naar hun eiland van gegevens. Je laat ze toe om zonder straf te vertrekken als ze een beter aanbod vinden. Het is de juiste manier and het bouwt goodwill op.

Gemakkelijk vertrekken

Houd gebruikers niet tegen hun wil vast. Als ze willen vertrekken, laat ze alle inhoud oppikken die ze hebben gemaakt terwijl ze op je site waren, en vertrekken... kostenloos... Je moet de staldeur openhouden en focussen op het voeden van je klanten, zodat ze willen terugkomen, in plaats van dat ze terugkomen omdat ze vast zitten.

—Charlie O'Donnell, analist, Union Square Ventures
(from 10 Steps to a Hugely Successful Web 2.0 Company)


Stom konijn, trucs zijn voor kinderen

Vermijd langetermijncontracten, registratiekosten, enz.

Niemand houdt van langetermijncontracten, kosten bij voortijdige beëindiging, of eenmalige registratiekosten. Vermijd ze dus. Onze producten worden gefactureerd op een maandelijkse basis. Je moet geen contract tekenen en je kan op elk moment zonder straf annuleren. En er zijn nooit registratiekosten.

Probeer geen "trucjes" te vinden om meer geld te krijgen. Verdien het.



Verzacht de pijn

Verzacht de pijn van slecht nieuws met een bericht vooraf en een grootvaderlijke bescherming

Moet je slecht nieuws zoals een prijsstijging aankondigen? Maak het zo pijnloos mogelijk met een bericht lang genoeg vooraf. Overweeg ook een grootvaderlijke periode, die bestaande klanten beschermt voor een bepaalde tijdsduur. Deze mensen zijn je dagelijks brood, en je wil dat ze zich gewaardeerd voelen, niet uitgemolken.



Publiciteit hoofdstuk 13

Lanceren in Hollywood-stijl

Ga van teaser via preview naar lancering.

Als een toepassing gelanceerd wordt in een bos en er is niemand die het hoort, maakt het dan geluid? Het punt is dat als je toepassing start zonder hype vooraf, de mensen er niet van gaan weten.

Lanceer, om de buzz en de verwachtingen op te wekken, in Hollywoodstijl: 1) Teaser, 2) Preview, en 3) Lancering.

Teaser

Begin enkele maanden op voorhand hints te laten vallen. Laat de mensen weten waaraan je bezig bent. Publiceer een logo. Post op je blog over de ontwikkeling. Blijf vaag, maar plant het zaadje. Zet ook een site op waar je e-mailadressen van geïnteresseerden kan verzamelen.

In deze fase moet je ook kenners en insiders beginnen verleiden. Deze mensen zitten op de cutting edge. Zij zijn de smaakmakers. Streel hun ijdelheid en hun status van voorlopens. Vertel hen dat ze een exclusieve sneak preview krijgen. Als een site als Boing Boing, Slashdot of Digg naar je applicatie linkt, zal je massa's verkeer en volgers aantrekken. Bovendien zal je page rank bij Google omhoog gaan.

Preview

Begin enkele weken voor de lancering met het tonen van features. Geef mensen toegang achter de schermen. Omschrijf het thema van het product. Voor Basecamp publiceerden we screenshots en stipten herinneringen, mijlpalen en andere features aan.

Vertel mensen voorts over de ideeën en principes achter de toepassing. Voor Backpach publiceerden we ons manifest voor de lancering. Dit bracht mensen aan het denken en het praten over de toepassing.

Je kan ook enkele speciale "gouden tickets" aanbieden aan een aantal mensen zodat ze de toepassing vroeg kunnen beginnen gebruiken. Je hebt het voordeel van enkele beta testers te hebben, terwijl zij die speciale gloed zullen voelen die mensen krijgen als ze early adopters zijn.

En opnieuw, moedig mensen aan om in te schrijven zodat je een basis van e-mailadressen hebt om te overvallen wanneer je lanceert. Op het moment dat wij onze toepassingen lanceren, hebben we duizenden e-mailadressen die we kunnen bereiken, wat een grote hulp is als je snelheid wil maken.

Lancering

Het is het moment om naar buiten te komen. Nu kunnen mensen echt naar het "theater" gaan om je toepassing te zien. Stuur emails uit naar zij die hebben ingeschreven. Lanceer je marketingsite. Verspreid de blijde boodschap zoveel mogelijk. Overhaal blogs om te linken naar je. Publiceer je vooruitgang: hoeveel mensen hebben zich ingeschreven? Welke updates/aanpassingen heb je gedaan? Toon momentum hou het vol.

De weg naar de lanceringsdag

Van zodra we wisten dat Blinksale er echt van ging komen, begonnen we enkele teasers te versturen naar onze mailinglijst. Hierop staan mensen die hebben gevraagd om informatie van ons te krijgen over onze projecten. Zij zijn onze fans, zo je wilt. Als je al de toelating hebt om tegen een groep mensen te praten, zijn zij de beste plaats om te starten.

Het tweede dat we deden was van meer mensen de toelating krijgen om te praten over ons product. Ongeveer zes weken voor de lancering van Blinksale zetten we een teaserpagina op onze website die de komst aankondigde van een eenvoudigere manier om facturen online te versturen. De pagina gaf net genoeg informatie om opwinding en spanning op te bouwen, zonder de gevoelige details weg te geven die vertrouwelijk moesten blijven. Op een prominente plaats op de pagina stond een inschrijvingsformulier voor de nieuwsbrief, waarop enkel een e-mailadres moest ingevuld worden (hou het simpel) zodat degenen die geïnteresseerd waren verwittigd konden worden als het product gelanceerd werd.

We brachten een dozijn vrienden en collega's op de hoogte van wie we dachten dat ze ook geïnteresseerd zouden zijn in het product, en zij begonnen via hun blogs en websites te vertellen over de teaserpagina. Binnen een paar dagen hadden we duizenden namen op onze mailinglijst. Dit waren uiterst belangrijke mensen — mensen die erom vroegen meer te weten over ons product en die wilden weten wanneer we zouden lanceren.

Tenslotte, ongeveer twee weken voordat we lanceerden, nodigden we een handvol vrienden, collega's en experts uit de industrie uit om ons te helpen Blinksale te testen. Dit liet ons toe om het product aan mensen te tonen van wie we dachten dat ze konden profiteren van het gebruik ervan en die ons konden helpen het woord te verspreiden over het product als we lanceerden. Het is belangrijk om te vermelden dat we niemand hebben gedwongen om het product te gebruiken of erover te schrijven. We wilden gewoon dat het gezien werd en dat mensen erover praatten als het gelanceerd werd. Als je op deze manier buzz gaat opbouwen, ben je uiteindelijk maar beter zeker dat je product zijn belofte kan houden. Zoniet, is het als wolken zonder regen.

Toen de lanceringsdag eraan kwam, stuurden we een e-mail uit naar onze mailinglijst, brachten we onze blogvrienden op de hoogte en moedigden onze betatesters aan om hun gedacht te zeggen. En tot onze grote vreugde leverde onze inspanning grote resultaten op. Kort na de lancering hadden tienduizenden mensen onze site bezocht en duizenden daarvan hadden zich ingeschreven om onze producten te gebruiken.

—Josh Williams, oprichter, Blinksale


Een krachtige promosite

Ga van teaser naar voorproef naar lancering

Het beste reclamemiddel is een geweldig product. Het nieuws zal zich verspreiden als je een toepassing hebt die mensen echt nuttig vinden.

Toch heb je ook een sterke promotiesite nodig. Wat moet je op deze site zetten? Enkele ideeën:



Surf op de bloggolf

Bloggen kan effectiever zijn dan adverteren (en het is verduiveld goedkoper)

Adverteren is duur. En de effectiviteit van verscheidende advertentietypes evalueren kan nog duurder uitdraaien dan het adverteren zelf. Als je de tijd en het geld niet hebt om de weg van traditioneel adverteren op te gaan, overweeg dan de weg van promotie via een blog.

Begin met een blog te creëren dat niet alleen je product in de kijker zet, maar ook nuttig advies, tips, trucs, links, enz. aanbiedt. Onze Signal vs. Noise blog ontvangt duizenden unieke lezers per week dankzij de nuttige, informatieve en interessante stukjes en anekdotes die we dagelijks posten.

Toen het dus tijd was om ons eerste product, Basecamp, te promoten, begonnen we daar. We lieten het nieuws los op SvN en het begon zich te verspreiden. Mensen als Jason Kottke, de BoingBoingers, Jim Coudal en verscheidene andere mensen met populaire blogs hielpen de visibiliteit groeien en de zaken kwamen van de grond.

Ta-da Lists is een ander voortreffelijk voorbeeld van de kracht van bloggebaseerde marketing. We lanceerden Ta-da met één post op Signal vs. Noise, en een aantal weken later was het vermeld op meer dan 200 blogs en meer dan 12.000 mensen hadden zich geregistreerd voor hun eigen Ta-da account. Het nieuws over Backpack verspreide zich nog sneller. Binnen de 24 uur na de lancering hadden meer dan 10.000 mensen zich geregistreerd.



Van het begin de aandacht trekken

Laat de vroege buzz en inschrijvingen zo snel mogelijk starten

We hebben het al aangeraakt, maar willen het herhalen: start zo snel mogelijk een kleine site op en begin e-mailadressen te verzamelen. Kies je domeinnaam, zet er een logo op en eventueel een zinnetje of twee dat omschrijft, of op zijn minst een idee geeft van wat je toepassing zal doen. Laat dan de mensen hun e-mailadres invullen. Nu ben je op weg om een basis van mensen op te bouwen die zitten te wachten op het bericht van je lancering.



Promoot door educatie

Deel je kennis met de wereld

Als een leraar meespeelt met Waagstuk, noemt de presentator dit vaak een "nobel beroep". Hij heeft gelijk. Er is zeker iets wonderbaarlijks en bevredigend aan het delen van je kennis met anderen. En als het onderwerp waarover je lesgeeft je applicatie is, dan dien je een dubbel doel: je kan iets teruggeven aan de gemeenschap die jou ondersteunt, en je kan tegelijk wat leuke promotionele aandacht bekomen.

Als promotionele techniek is onderricht een zachte manier om je naam — en de naam van je product — aan veel mensen te tonen. En in plaats van de harde verkoopsaanpak van "koop dit product", krijg je aandacht door een waardevolle dienst te verlenen. Dat creëert een positieve buzz die de traditionele marketingtaktieken niet kunnen evenaren. Mensen die je onderricht zullen je evangelisten worden.

Onderricht kan in vele vormen komen. Plaats op je site tips en trucs die mensen zullen willen delen met anderen. Spreek op conferenties en blijf erna om de aanwezigen te ontmoeten. Geef workshops zodat nieuwsgierige fans meer kunnen leren en met je kunnen praten in levenden lijve. Geef interview aan publicaties. Schrijf artikels die nuttig informatie geven. En schrijf boeken. ;)

Een voorbeeld uit onze eigen geschiedenis is de Yellow Fade techniek, een manier die we hebben uitgevonden om een recent veranderde plaats op de pagina subtiel te benadrukken. We schreven er een artikel over op Signal vs. Noise. Dat artikel deed de ronde en kreeg duizenden pageviews (tot op vandaag krijgt het enorm veel bezoeken).

De post deed het zowel op educationeel als op promotioneel niveau. We leerden een les en heel wat mensen die nooit zouden gehoord hebben over onze producten werden ermee geconfronteerd. Een ander voorbeeld: tijdens onze ontwikkeling van Ruby on Rails beslisten we om de intrastructuur open source te maken. Het bleek een slimme zet. We gaven iets terug aan de gemeenschap, bouwden goodwill op, kregen erkenning voor ons team, ontvingen nuttige feedback, en begonnen bijdragen en verbeteringen te ontvangen van programmeurs over de hele wereld.

Onderrichten heeft alles te maken met goede karma. Je betaalt het vooruit. Je helpt anderen. Je krijgt wat gezonde promotie. En je kan het zelfs als een nobele daad zien. Zodus, wat weet je dat de wereld wil horen?

Betaal vooruit

Het 'artikels en tips'-sectie van onze blog is een van de populairste secties op onze site. Onze kennis over email marketing door te geven, garandeert dat onze klanten het maximum uit onze software halen. Als zij een betere dienstverlening kunnen geven aan hun klanten, dan doen ze waarschijnlijk meer zaken, wat dan weer meer business voor ons creëert — iedereen wint.

Het gratis delen van onze kennis heeft ons ook geholpen om ons te positioneren als experts in onze industrie en heeft onze relatie met bestaande klanten versterkt. Ze weten dat we geven om de kwaliteit van hun werk. Tenslotte krijgen we massa's gerichte binnenkomende traffiek van zoekmachines en bloggers die onze artikels delen met hun lezers. Dit zijn mensen die nooit zouden gehoord hebben over onze software als we dat artikel niet hadden geschreven.

—David Greiner, oprichter, Campaign Monitor


"Feature voedsel"

Ze hebben er zin in, dus dien het op

Nieuwe of interessante features zijn een geweldige manier om buzz te genereren voor je applicatie. Specifieke gebruikersgroepen kauwen graag op "feature voedsel" en spuwen het terug uit over de gemeenschap. Ok, da's een onsmakelijke analogie maar je begrijpt het punt.

Bijvoorbeeld, door Ruby on Rails te gebruiken, een nieuw ontwikkelingsplatform, generereerden we een ton aandacht voor Basecamp binnen de ontwikkelaarsgemeenschap.

De Ajax-elementen die we gebruikten in onze applicaties kregen hopen buzz en maakten zelfs dat Business 2.0 Magazinee 37signals een "sleutelspeler in Ajax" noemde naast grote namen als Google, Yahoo, Microsoft en Amazon.

Een ander voorbeeld: bloggers merkten Basecamp's ondersteuning van RSS op omdat het een van de eerste zakelijke voorbeelden van RSS was.

iCal integratie, op het eerste zicht een kleinere feature, genereerde artikels op massa's Mac-gerelateerde sites die anders waarschijnlijk nooit de toepassing zouden vermeld hebben.

Kleine teams hebben een voetje voor bij het integreren van nieuwe ideeën in software. Terwijl grotere bedrijven moeten omgaan met bureaucratische barrières, kan jij snel nieuwe ideeën implementeren en aandacht krijgen omdat je ze gebruikt.

Surfen op de hypes van de technologie van de dag is een effectieve en goedkope manier om de buzz op te bouwen. Ga anderzijds niet de laatste obscure technologie toevoegen louter om wat aandacht te krijgen. Maar als je iets nieuws of opmerkelijks gebruikt, ga dan verder en plaats het in de schijnwerpers bij de specifieke gebruikersgroepen.



Volg je logs op

Bestudeerd je logs om de buzz op te volgen

Je moet weten wie er over je praat. Kijk je logs na om uit te zoeken waar de buzz vandaan komt. Wie linkt er naar jou? Wie bekritiseert je? Welke blogs in de lijst van Technorati, Blogdex, Feedster, Del.icio.us, en Daypop volgen je op de voet?

Zoek het uit en laat je aanwezigheid voelen. Laat een reactie achter op die blogs. Bedank mensen die links posten. Vraag hen of ze willen toegevoegd worden aan je speciale lijst zodat ze als eersten zullen weten over toekomstige ontwikkelingen, updates, enz. Verzamel positieve kritieken en creëer een "buzz" pagina op je site. Getuigenissen zijn een geweldige manier om je toepassing te promoten omdat lof van derden betrouwbaarder is voor de meeste mensen.

Ook als de commentaren negatief zijn, moet je er toch aandacht aan besteden. Toon dat je luistert. Beantwoord kritiek doordacht. Iets als: "We waarderen de feedback maar we hebben het op deze manier gedaan omdat..." of "Je haalt een goed punt en we werken eraan." Je verzacht de kritieken en plakt een menselijk gezicht op je product. Het is verbazend hoe een doordachte reactie op een blog de neeknikkers kan ontwapenen en zelfs klagers kan omvormen tot evangelisten.



Van binnenuit upsellen

Promoot upgrademogelijkheden binnen de toepassing.

Iedereen weet hoe je moet pitchen op de marketing website. Maar de verkoop mag daar niet stoppen. Als je een gelaagd prijsplan hebt (of een gratis versie van je toepassing), vergeet dan niet om upgrademogelijkheden te vermelden binnen het product zelf.

Vertel mensen dat je barrières zal verwijderen als ze upgraden. In Basecamp kan je bijvoorbeeld geen bestanden uploaden met een gratis account. Als iemand een bestand probeert te uploaden, zullen we hen niet zomaar afwijzen. We leggen uit dat het uploaden van bestanden niet beschikbaar is en moedigen hen aan om te upgraden naar de betaalde versie en leggen uit waarom dat een goed idee is. Dezelfde aanpak wordt gebruikt om bestaande klanten aan te moedigen om te upgraden naar een hogere account als ze het plafond van hun huidige plan bereiken.

Bestaande klanten zijn je beste gok voor verkopen. Wees niet bang om terugkerende business te proberen krijgen van klanten die je product al kennen en gebruiken.



Het naamkaartje

Geef je toepassing een gemakkelijk te onthouden naam

Een grote fout die veel mensen maken is te denken dat de naam van hun toepassing ultrabeschrijvend moet zijn. Pieker niet over een naam die levendig het doel van je toepassing omschrijft; dat leidt meestal tot een generieke, gemakkelijk te vergeten naam. Basecamp is een betere naam dan iets als Project Management Center of ProjectExpress. Writeboard is beter dan CollaborEdit.

Laat ook niet te veel focus groepen of comités los op de naamgeving. Kies een naam die kort, catchy en te onthouden is en ga er dan voor.

En geen paniek als je niet de exacte domeinnaam kan krijgen die je wilt. Je kan altijd creatief zijn en dichtbij komen met een aantal extra letters (bv. backpackit.com or campfirenow.com).

Eenvoud doet het

Begrijpt de technologische industrie niet dat catchy, zelfverklarende namen verzinnen, hen uiteindelijk op dezelfde manier zou helpen? Ze zouden meer verkopen van wat dan ook, omdat ze klanten niet zouden afschrikken die denken dat ze worden buitengesloten uit de high-tech club van een hoopje arrogante ingenieurs. De technologie zou ook sneller aanslaan. Het nieuwe product zou gemakkelijker te omschrijven, gemakkelijker te gebruiken en gemakkelijker te kopen zijn — wat voor de bedrijven betekent: gemakkelijker te verkopen.

—David Pogue, columnist, New York Times (from What's in a Product Name?)


Ondersteuning hoofdstuk 14

Voel de pijn

Breek de muren tussen ondersteuning en ontwikkeling

In de restaurantsector is er een wereld van verschil tussen zij die in de keuken werken, en zij die werken met klanten. Het is belangrijk dat beide zijden elkaar begrijpen en aanvoelen. Daarom zetten kokscholen en restaurants vaak de chefs in als obers, zodat het keukenpersoneel kan omgaan met klanten en zien hoe het er eigenlijk aan toe gaat in de frontlinies.

Veel software-ontwikkelaars ervaren eenzelfde kloof. Ontwerpers en programmeurs werken in de "keuken", terwijl de ondersteuning de klanten behandelt. Helaas betekent dat dat de software chefs nooit te horen krijgen wat de klanten in feite zeggen. Dat is problematisch omdat luisteren naar klanten de beste manier is om zicht te krijgen op de sterktes en de zwaktes van je product.

De oplossing? Bouw geen muren tussen je klanten en het ontwikkelings- en ontwerpteam. Outsource klantenondersteuning niet naar een call center of een derde partij. Doe het zelf. Jij, en je hele team, moeten weten wat je klanten zeggen. Als je klanten geïrriteerd zijn, moet je dat weten. Je moet hun klachten horen. Je moet zelf ook geïrriteerd raken.

Bij 37signals worden alle support e-mails beantwoord door de mensen die het product effectief bouwen. Waarom? Eerst en vooral zorgt het voor betere ondersteuning voor klanten. Ze krijgen een antwoord recht uit het brein van iemand die de toepassing gebouwd heeft. Daarnaast houdt het ons in contact met de mensen die onze producten gebruiken en met de problemen die zij tegenkomen. Als ze gefrustreerd zijn, zijn wij ook gefrustreerd. We kunnen zeggen, "ik voel uw pijn" en het ook menen.

Het kan aanlokkelijk zijn om te rekenen op statistische analyse om je pijnpunten bloot te leggen. Maar statistieken zijn niet hetzelfde als stemmen. Je moet zo veel mogelijk buffers elimineren tussen jezelf en de echte stem van je klanten.

De frontlinies zijn waar de actie is. Ga daarheen. Laat je chefs werken als obers. Lees e-mails van klanten, hoor hun frustraties aan, luister naar hun suggesties en leer van hen.

Weg met tussenpersonen

Bijna alle ontwikkeling, ondersteuning en marketing van Campaign Monitor wordt uitgevoerd door twee mensen. Zelfs als we verplicht worden om het team uit te breiden, zullen we nooit ondersteunen en ontwikkeling loskoppelen. Door persoonlijk op elke vraag te antwoorden, verplichten we onszelf om in de schoenen van de klanten te gaan staan en zaken vanuit hun perspectief te bekijken.

Het is belangrijk om te begrijpen waarom je klant iets nodig heeft, en niet alleen wat hij nodig heeft. Die context heeft dikwijls een rechtstreekse impact op hoe we iets ontwerpen. Verwijder tussenpersonen. Het is veel eenvoudiger om je klanten te geven wat ze willen als je met je oren dichtbij de grond zit.

Ik heb deze aanpak met verscheidene mensen besproken en hun eerste reactie is vaak: "zou je niet beter een junior je ondersteuning laten doen?" Plaats jezelf in de schoenen van je klanten. Als je je steak precies gebakken wil zoals jij het graag hebt, zou je dan het liefst spreken met de afwasser of met de chef die hem gaat bakken?

—David Greiner, oprichter, Campaign Monitor


Geen opleiding

Gebruik hulp en FAQs van binnenin zodat je geen handleidingen of opleidingen nodig hebt

Je hebt geen handleiding nodig om Yahoo of Google of Amazon te gebruiken. Dus waarom kan jij geen product bouwen dat geen handleiding vereist? Tracht een toepassing te bouwen die geen training vereist.

Hoe doe je dit? Wel, zoals we eerder vermeld hebben, begin je met alles eenvoudig te houden. Hoe minder complex je toepassing is, hoe minder je de mensen zal moeten helpen. Daarna is een geweldige manier om ondersteuning te vermijden door hulp en FAQs binnenin het product te vermelden op mogelijk verwarrende punten.

Wij bieden bijvoorbeeld preventieve ondersteuning op het scherm dat mensen toelaat om hun logo te uploaden op Basecamp. Sommige mensen ondervonden problemen omdat ze het oude logo bleven zien door de browser-caching. Daarom plaatsten we naast het 'voeg je logo toe'-gedeelte een link naar een FAQ die klanten vertelde hun pagina te herladen om het nieuwe logo te zien. Voordat we dit deden, kregen we 5 e-mails per dag over dit probleem. Nu krijgen we er geen meer.



Antwoord snel

Snelle antwoordtijd bij vragen voor ondersteuning moet een topprioriteit zijn

Klanten klaren op als je hun vragen snel beantwoordt. Ze zijn zo gewend aan voorverpakte antwoorden die dagen later aankomen (in het beste geval) dat je jezelf echt kan differentiëren van concurrenten door een meteen een doordacht antwoord te bieden. Tijdens de kantooruren beantwoorden we 90% van alle ondersteuningsvragen via e-mail binnen de 90 minuten — en vaak binnen het half uur. En de mensen zijn daar blij om.

Zelfs als je geen perfect antwoord hebt, zeg iets. Je kan goodwill kopen met een antwoord dat snel aankomen en open en eerlijk is. Als iemand klaagt over een probleem dat niet onmiddellijk kan opgelost worden, vertel dan iets als: "We begrijpen wat je zegt en we zullen eraan werken in de toekomst." Het is een geweldige manier om een mogelijk negatieve situatie te ontmijnen.

Klanten stellen directheid op prijs en veranderen vaak van kwaad naar beleefd als je snel en op een rechtlijninge manier antwoord.

Een groot leger

Hoe kan een klein team van amper drie ontwikkelaars een innovatief product creëren en succesvol concurreren met de grote jongens? Het antwoord is een een groot leger aan te werven.

Onthou vanaf je eerste dag dat je klanten je belangrijkste troef zijn en dat ze absoluut vitaal zijn voor je langetermijnsucces, dus behandel je gebruikersgemeenschap als koningen. De manier om te concurreren met de grote jongens is door klein te beginnen en aandacht te besteden aan elk van je klanten.

Het zijn je klanten die je als eerste zullen wijzen op bugs, die je als eerste zullen wijzen op noden die niet zijn ingewilligd en het is je eerste klant die de vlag zal dragen en jouw boodschap zal verspreiden.

Dit betekent niet dat je product perfect moet zijn wanneer je lanceert. Wel integendeel, kies voor een snelle lancering en voor veel updates. Niettemin, als je klanten bugs tegenkomen, stuur ze dan zeker snel een antwoord om hen te bedanken voor hun input.

Klanten verwachten niet van je product dat het perfect is en ze verwachten niet dat al hun features zullen geïmplementeerd zijn. Wat klanten wel verwachten is dat je naar hen luistert en toont dat je erom geeft - toon dus dat je erom geeft. Dit is een gebied waarop de meeste grote bedrijven enorm tekortschieten, dus ontwikkel al van vroeg een gemeenschapsgevoel.

Bij Blinklist wordt iedere e-mail van klanten beantwoord, meestal binnen het uur (tenzij we toevallig aan het slapen zijn). We hebben ook een online forum en zorgen ervoor dat elke bijdrage erkend wordt.

Even belangrijk is dat al onze ontwikkelaars de feedback van onze klanten ontvangen en dat ze actief deelnemen in de online discussieforums. Op deze manier bouwen we langzaam maar zeker een actieve en loyale Blinklist gemeenschap uit.

—Michael Reining, mede-oprichter, MindValley & Blinklist


Moeilijke liefde

Wees bereid om nee te zeggen tegen je klanten

Als het gaat over feature vragen, heeft de klant niet altijd gelijk. Als we elk dingetje hadden toegevoegd dat onze klanten vroegen, zou niemand onze producten willen.

Als we elke gril van onze klanten hadden gehoorzaamd, zou Basecamp het volgende hebben: uitvoerige tijdsregistratie, uitvoerige facturatie, uitvoerige vergaderplanning, uitvoerige kalenders, uitvoerige taaksystemen, uitvoerige instant message chatmogelijkheden, uitvoerige wiki functionaliteit, en uitvoerige wat-je-maar-kan-indenken.

En toch is de belangrijkste vraag die we krijgen bij klantenenquêtes om Basecamp eenvoudig te houden.

Een ander voorbeeld: ondanks enkele klachten beslisten we om IE5 niet te ondersteunen bij onze producten. Het ging over 7% van de markt die we afschreven. We beslisten dat het belangrijker was om ons bezig te houden met de andere 93%. Bugs herstellen en testen voor IE5 is gewoon de tijd niet waard. We maken liever een beter product voor alle anderen.

Als softareontwikkelingsbedrijf moet je een filter zijn. Niet alles wat iedereen suggereert is het juiste antwoord. We overwegen alle vragen maar de klant heeft niet altijd gelijk. Er zullen altijd momenten zijn dat je sommige mensen moet teleurstellen. C'est la vie.

Hiermee verbonden: het is van cruciaal belang dat je als ontwikkelingsbedrijf je product graag ziet. En je zal je product niet graag zien als het vol zit met dingen waar je het niet mee eens bent. Dat is nog een andere rechtvaardiging om een veto te stellen tegen vragen van klanten waarvan je de noodzaak niet inziet.



Een geweldig forum

Gebruik forums of chat om klanten elkaar te laten helpen

Forums en webgebaseerde groepchat zijn een geweldige manier om klanten vragen te laten stellen en elkaar te helpen. Door de tussenpersoon te elimineren — dat ben jij — lever je een open communicatiestroom en bespaar je jezelf intussen tijd.

Op onze productforums plaatsen klanten tips en trucs, feature-aanvragen, verhalen en meer. Wij springen van tijd tot tijd ook binnen om wat hulp te bieden, maar de forums zijn voornamelijk een plaats waar de gemeenschap elkaar kan helpen en hun ervaringen met het product kunnen uitwisselen.

Je zal versteld staan hoeveel mensen elkaar willen helpen.



Publiceer je flaters

Vertel over je slecht nieuws, en zet je erover

Als er iets misgaat, vertel het dan. Zelf als ze het om te beginnen nooit gezien hebben.

Bijvoorbeeld, Basecamp was eens enkele uren onbereikbaar in het midden van de nacht. 99% van onze klanten hebben het nooit geweten, maar toch publiceerden we een bericht over de "onverwachte downtime" op onze Everything Basecamp blog. We vonden dat onze klanten dit verdienden te weten.

Hier is een staaltje van wat we schrijven als er iets misgaat: "We verontschuldigen ons voor de downtime deze ochtend — we hadden wat problemen met de database die grote vertragingen en downtime veroorzaakten voor sommige mensen. We hebben het probleem opgelost en ondernemen stappen om te verzekeren dat dit niet meer gebeurt... Bedankt voor uw geduld en nogmaals onze excuses voor de downtime."

Wees zo open, eerlijk en transparant mogelijk. Bewaar geen geheimen en verstop je niet achter praatjes. Een geïnformeerde klant is je beste klant. Bovendien zal je merken dat de meeste flaters niet eens zo erg zijn in de ogen van je klanten. Klanten geven je meestal graag wat ademruimte, zolang ze weten dat je eerlijk bent met hen.

Tussen haakjes, over het vertallen van slecht en goed nieuws, dit: als er slecht nieuws komt, breng het dan meteen volledig uit. Goed nieuws, anderzijds, moet langzaam uitlekken. Als je de goede golven kan verlengen, doe het dan.

Wees snel, direct en eerlijk

Het kan vreemd klinken, maar het best mogelijke scenario is als het bedrijf zelf het slechte nieuws vertelt. Dit is proactief en voorkomt dat je bedrijf in een zwakke, defensieve positie wordt gedwongen.

—Greg Sherwin, Vice-president van Application Technology, CNET, en Emily Avila, hoofd van, Calypso Communications (from A Primer for Crisis PR (Crisis PR voor beginners))


Na de lancering hoofdstuk 15

Bijstellen na een maand

Geef een belangrijke update 30 dagen na de lancering

Een snelle update geeft blijk van momentum. Het toont dat je luistert. Het toont dat je nog meer trucks in je mouw hebt zitten. Het geeft je een tweede buzz-golf. Het bevestigt het goed gevoel. Het geeft jou iets om over te praten, en anderen om over te bloggen.

Als je weet dat er een snelle upgrade komt, kan je ook focussen op de meest cruciale componenten voor de lancering. In plaats van er nog wat meer zaken bij te proppen, kan je beginnen met de kernmogelijkheden te perfectioneren. Daarna kan je het product loslaten op de echte wereld. Eens het daar is, kan je feedback van klanten beginnen verzamelen om te weten te komen welke gebieden je onmiddellijke aandacht vragen.

Deze aanpak met baby-stapjes heeft goed gewerkt bij Backpack. We lanceerden eerst het basisproduct en dan, enkele weken later, voegden we mogelijkheden toe zoals Backpack Mobile voor mobieltjes en tagging, want dat waren de dingen waar onze klanten het meest om vroegen.



Blijf publiceren op je blog

Toon dat je product leeft door na de lancering een blog bij te houden over de productontwikkeling

Stop niet met bloggen na de lancering. Toon dat je product een levend wezen is door een speciale blog bij te houden die je regelmatig ververst (minstens een keer per week, vaker als je kan).

Zaken die erin moeten:

Een blog toont niet alleen dat je toepassing springlevend is, het maakt je bedrijf ook menselijker. Opnieuw, wees niet bang om de toon vriendelijk en persoonlijk te houden. Kleine teams hebben soms het gevoel dat ze aldoor groot en ultra-professioneel moeten klinken. Het is bijna een zakelijke versie van het Napoleon-complex. Wees niet bang om klein te klinken. Maak gebruik van het feit dat je met je klanten kan praten als een vriend.

Het leeft!

Een vaak aangepaste productblog is de beste indicatie dat een webtoepassing in actieve ontwikkeling is, dat het geliefd is en dat er thuis een licht brandt. Een verlaten productblog is een teken van een verlaten product, en vertelt dat de leidende mensen in slaap gevallen zijn achter het stuur.

Hou de conversatie gaande met je gebruikers op je productblog, en wees transparant en gul met de informatie die je deelt. Laat de filosofie van je bedrijf doorschemeren. Link openlijk en spreek over concurrenten. Maak toespelingen op aankomende features en laat commentaar toe.

Een levend product is er een dat spreekt en luistert naar zijn gebruikers. Een vaak bijgewerkte productblog promoot transparantie, een gemeenschapszin en loyauteit aan je merk. Extra, gratis publiciteit is een bonus.

Als uitgeefster van Lifehacker scan ik onophoudelijk productblogs van webtoepassingen waar ik van hou — zoals Google, Flickr, Yahoo, del.icio.us, en 37signals. Ik zal veel liever over hen spreken dan over de webtoepassingen die uit het niets eenzijdige persberichten uitsturen en geen open conversatie aanhouden met hun gebruikers en fans.

—Gina Trapani, webontwikkelaar en uitgeefster van Lifehacker, de gids voor productiviteit en software


Beter, niet Bèta

Gebruik "bèta" niet als zondebok

Vandaag de dag lijkt het wel of alles voor eeuwig in de bèta-fase is. Dat is een punt eraf. Een oneindige beta-fase vertelt klanten dat je niet werkelijk geenageerd bent om een afgewerkt product uit te rollen. Het zegt, "Gebruik het maar, maar als het niet goed is, is het onze fout niet."

Bèta verplaatst het risico naar je klanten. Als je onvoldoende vertrouwen hebt in je uitgifte, hoe kun je dat dan van je publiek verwachten? Private betas zijn prima, maar publieke bèta's zijn flauwekul. Als het niet goed genoeg is voor publieke consumptie, geef het dan niet aan het publiek voor consumptie.

Wacht niet tot je product perfectie bereikt. Dat gaat niet gebeuren. Neem verantwoordelijkheid voor wat je uitgifte. Gooi het naar buiten en noem het een release. Anders ben je toch maar excuses aan het verzinnen.

Bèta betekent niets

Google e.a. de oorzaak van dit soort problemen. Voor nu zijn gebruikers door alle programmeurs samen gaan denken dat "bèta" werkelijk helemaal niets betekent.

—Mary Hodder, informatie-architect and interactie-ontwerper (uit The Definition of Beta)

De hele tijd

Ligt het aan mij, of zijn we allemaal de hele tijd in bèta?

—Jim Coudal, founder, Coudal Partners


Niet alle bugs zijn even gelijk geboren

Rangschik je bugs naar prioriteit (en negeer zelfs een aantal van hen)

Dat je een bug ontdekt in je product is nog geen reden tot paniek. Alle software heeft bugs — dat hoort gewoon bij het leven.

Je hoeft niet iedere bug onmiddellijk op te lossen. De meeste bugs zijn vervelend, maar niet vernietigend. Over irritaties kan gediscussieerd worden. Bugs die resulteren in "het ziet er niet goed uit"-fouten en andere gedragsproblemen kunnen rustig even opzij worden gezet. Als een bug je database vernielt, dan moet je hem duidelijk onmiddellijk oplossen.

Rangschik je bugs naar prioriteit. Hoeveel mensen worden getroffen? Hoe erg is het probleem? Verdient deze bug onmiddellijke aandacht of kan het wachten? Wat kun je nu doen zodat je de grootste impact hebt op het grootste aantal mensen? Soms kan het toevoegen van een nieuwe feature belangrijker zijn dan het herstellen van een bestaande bug.

Creëer ook geen cultuur van angst rondom bugs. Bugs komen voor. Zoek niet voortdurend iemand om te beschuldigen. Het laatste wat je wilt is een omgeving waar bugs onder het tapijt worden gewerkt in plaats van openlijk bediscussiëerd.

En onthoud wat we eerder zeiden over het belang van eerlijkheid. Als klanten klagen over een bug, wees eerlijk tegen ze. Vertel ze dat je het probleem hebt opgemerkt en dat je er mee bezig bent. Als het niet gelijk wordt opgelost, vertel waarom en leg uit dat je je concentreert op gebieden van het product die een groter aantal mensen beïnvloeden. Eerlijkheid is de beste policy.



Laat de storm overwaaien

Wacht tot de automatische reacties op veranderingen verstomd zijn voordat je actie onderneemt

Wanneer je je boot op snelheid brengt, zijn er golven. Zodra je een nieuwe feature introduceert, een policy verandert, of iets verwijdert, dan stromen de automatische reacties, vaak negatief, naar binnen.

Weersta de neiging om in paniek te raken of snel dingen te veranderen. Emoties lopen hoog op in het begin. Maar als je deze initiële 24-48-uurs periode uitzit, dan dwarrelt het stof gewoonlijk neer. De meeste mensen reageren voordat ze zich er echt in hebben verdiept en hebben gebruikt wat je hebt toegevoegd (of zich verzoend hebben met het feit dat je iets verwijderd hebt.) Ga achteroverzitten, laat het op je inwerken, en doe niets voordat er wat tijd overheen is gegaan. Daarna zul je in staat zijn om een meer doordacht antwoord te geven.

Onthoud ook dat negatieve reacties bijna altijd luider en geëmotioneerder zijn dan positieve. In feite zou je wel eens alleen negatieve stemmen mogen horen zelfs wanneer de meerderheid van je gebruikers tevreden is over de aanpassing. Zorg ervoor dat je niet met hangende pootjes terugkomt op een noodzakelijke maar controversiële beslissing.



Doe niet onder voor de buren

Abonneer je op nieuwsfeeds over je concurrenten

Abonneer je op nieuwsfeeds over zowel je product als dat van je concurrenten (het is altijd goed om de wegen van je vijand te kennen). Gebruik diensten als PubSub, Technorati, Feedster, en andere om op de hoogte te blijven (voor sleutelwoorden, gebruik bedrijfsnamen en productnamen). Met RSS wordt deze constant veranderende informatie direct bij je thuis geleverd, dus blijf je altijd bij.



Hoedt u voor het Opblaasmonster

Volwassener hoeft niet meer gecompliceerd te betekenen

Wees naarmate de zaken vooruitgaan niet bang om weerstand te bieden tegen het opblazen. Er zal verleiding zijn om op te schalen. Maar zo hoeft het niet te gaan. Alleen omdat iets ouder en volwassener wordt, hoeft het niet gecompliceerder te worden.

Je hoeft geen buitenaardse ruimtepen te zijn die ondersteboven kan schrijven. Soms is het OK om gewoon een potlood te zijn. Je hoeft geen Zwitsers zakmes te zijn. Je kunt gewoon een schroevedraaier zijn. Je hoeft niet een tot 5000 meter diepte waterbestending duikhorloge te zijn als je klanten landdieren zijn die alleen willen weten hoe laat het is.

Vergroot niet iets alleen maar om het te vergroten. Zo raken apps namelijk opgeblazen.

Nieuw betekent niet altijd verbeterd. Soms is er een punt waar je een product gewoon met rust moet laten.

Dit is één van de sleutelvoordelen van het bouwen van web-based software in plaats van traditionele desktop-software. Desktop-softwaremakers zoals Adobe, Intuit en Microsoft moeten je ieder jaar nieuwe versies verkopen. En omdat ze je niet steeds dezelfde versie kunenn verkopen, moeten ze de kosten rechtvaardigen door nieuwe features toe te voegen. Dat is waar het opblazen begint.

Met web-based software gebaseerd op het abonnementsmodel betaalt men een maandelijkse fee om een service te gebruiken. Je hoeft ze niet steeds allerlei extra's te verkopen, je hoeft alleen een doorgaande, waardevolle service te bieden.



Volg de stroming

Sta open voor nieuwe wegen en verandering van richting

Een deel van de schoonheid van een webapplicatie is zijn vloeibaarheid. Je kunt hem niet in een doosje verpakken, versturen, en dan jaren wachten met de nieuwe release. Je kunt bijschaven en veranderen terwijl je verdergaat. Sta open voor het feit dat je oorspronkelijke idee niet je beste hoeft te zijn.

Kijk naar Flickr. Het begon als een multiplayer online spel genaamd "The Game Neverending". De makers realiseerden zich al gauw dat het fotodelen-aspect van het spel een geloofwaardiger product was dan het spel zelf (dat uiteindelijk geklasseerd werd). Wees bereid om fouten toe te geven en koers te wijzigen.

Wees een surfer. Hou de oceaan in de gaten. Zoek uit waar de grote golven opkomen en pas je eraan aan.



Conclusie hoofdstuk 16

Start de motoren

Klaar!

Mooi, je bent er! Hopelijk ben je klaar om "Getting Real" te beginnen met je applicatie. Nooit was er een betere tijd voor het maken van fantastische software met minimale middelen. Met het juiste idee, de juiste passie, tijd, en vaardigheden, the sky's the limit.

Een paar gedachten tot slot:

Uitvoering

Iedereen kan een boek lezen. Iedereen kan met een idee komen. Iedereen heeft een neef die webdesigner is. Iedereen kan een blog schrijven. Iedereen kan iemand inhuren om wat code in elkaar te knutselen.

Het verschil tussen jou en alle anderen is hoe goed je uitvoert. Succes heeft alles te maken met superieure uitvoering.

Voor software, dat betekent dat je een heleboel dingen goed moet doen. Je kunt niet alleen maar goed schrijven maar vervolgens de beloften in je proza niet inlossen. Schoon interface-ontwerp overleeft het niet als je code vol hacks zit. Een fantastische applicatie is waardeloos als door gebrek aan publicteit niemand er ooit iets over hoort. Om hoog te scoren moet je al deze elementen combineren.

De sleutel is balans. Als je teveel helt in één richting, dan ben je gedoemd te mislukken. Zoek continu naar je zwakke schakels en besteedt er aandacht aan totdat ze in balans zijn.

Mensen

Het is zinvol om te benadrukken dat, wanneer het gaat om het bouwen van een succesvolle webapplicatie, het meest belangrijke ingrediënt bestaat uit de betrokken mensen. Mantra's, epicentrum-ontwerp, minder software, en al deze prachtige ideeën doen er niet werkelijk toe wanneer je niet de juiste mensen aan boord hebt om ze te implementeren.

Je hebt mensen nodig die gepassioneerd zijn over wat ze doen. Mensen die geven om hun stiel — en het ook als een stiel beschouwen. Mensen die trots zijn op hun werk, onafhankelijk van geldelijk gewin. Mensen die zich in het zweet werken voor details die door 95% van de gebruikers niet wordt opgemerkt. Mensen die iets geweldigs willen maken en het niet voor minder doen. People who need people. OK, dat laatste natuurlijk niet echt maar we konden het niet laten om een beetje Streisand in de mix te gooien. Hoe dan ook, wanneer je deze mensen vindt, houdt ze vast. Aan het eind van de rit zijn het de mensen in je team die het project maken of breken — en je bedrijf erbij.

Meer Dan Alleen Software

Het is ook de moeite van het vermelden waard dat het "Getting Real"-concept niet alleen van toepassing is op alleen het maken van een webappllicatie. Zodra je de ideeën begrijpt, zie je ze overal. Een paar voorbeelden:

Zeker, "Getting Real" gaat over het bouwen van geweldige software. Maar er is geen reden waarom het daar op zou moeten houden. Neem deze ideeën en probeer ze toe te passen op veschillende aspecten van je leven. Je zou zomaar tegen een paar leuke resultaten aan kunnen lopen.

Blijf in contact

Laat ons weten hoe "Getting Real" voor jou werkt. Stuur een email naar gettingreal [at] 37signals [dot] com.

Blijf ook op de hoogte van de laatste activiteiten van 37signals via Signal vs. Noise, ons blog over "Getting Real", usability, ontwerp, en allerlei andere onderwerpen.

Bedankt voor het lezen en veel succes!



37signals' bronnen



Vertaling

Dank aan de volgende vertalers: Jorn Mineur (e-accent BV) en Michiel Loncke (Webcraft).

De rest van het boek is nog niet vertaald in het Nederlands. Neem contact met ons op via email als je zou willen helpen vertalen. Het hele boek is beschikbaar in het Engels.