En veldig bra bok om problemløsing og applikasjonsutvikling: Getting Real

Har nettopp lest ferdig Gettin Real -- en bok om softwareutvikling fra 37Signals, et lite selskap med fem ansatte som har utviklet noen helt fantastiske produkter som bl.a. Basecamp. Boken kan kjøpes for $19 elektronisk eller selskaps-lisens for $49.  Den er lettlest og leses i løpet av en kort flytur.   Dette ble en ganske lang omtale -- og endte faktisk opp som en slags oppsummering av hele boka. 

Boken har allerede fått mye omtale.

Noen av kapitlene kan du lese gratis:

• Introduksjon: Hva er Getting Real
• Skaler senere
• Møter er giftige
• Design bruker-grensesnittet først (kanskje det viktigste kapitlet)

Dette er en fabelaktig bok om å utvikle web-applikasjoner, men den handler like mye om strategisk problemløsing i grupper. Hva kan være mer aktuelt enndet? Og den har mye til felles med det å spille musikk; om å gjøre ting enkelt, om å ikke være for mange involvert i prosesser, å angripe problemer ettersom de dukker opp, og å være beinhard på å definere hvilket problem man ønsker å løse.  Hold tett kontakt med publikum, vær ydmyk og lydhør, og del kunnskapen med andre. Det høres enkelt ut, men denne boken er litt som gutten som påpeker keiserens nakenhet. I store selskaper er det vanskelig å få ting gjort, ting skal planlegges i detalj, og resultaet er at ting tar alt for lang tid. Det er mange keisere og mye klær. 

Her er noen punkter (rett fra hjernebarken og derfor ikke kronologisk eller prioritert) fra boken GettingReal (og etter disse kommer innholdsfortegnelsen med mine notater):

1. Dropp kravspekk – lag prototype umiddelbart. Gå rett på, lag en kjapp skisse over hva du vil ha, deretter gå rett i HTML og lag brukergrensesnitt selv om det ikke er noe bak. Drit i detaljene, begynn med de viktige tingene. Lag prototyper med fokus på det viktigste på hver side. Ta deg av ytterkantene i etterkant – fokuser på kjernen i hver webside. Fokuset på det viktige er det som holder momentumet og energien oppe.  Jobb på det som faktisk skal bli noe. Et godt poeng her: Man vet lite om applikasjonen før man har jobbet med den en stund. Derfor er det også vanskelig å beskrive hva man lager før man har kommet igang. Gjør man det risikerer man at man ikke får med seg de gode ideene og den innsikten man opparbeider seg i prosessen. Store kravspekk blir aldri lest, og det er altfor lett å slenge på en ekstra bullet når noe vil ha noe som i praksis er dyrt og tungvindt å gjennomføre.
2. Hold tidsrammer og budsjetter og kutt heller i funksjonalitet for å bli ferdig i tide. Lag applikasjoner med mindre funksjonalitet. Si nei til alt som blir foreslått i utgangspunktet. Hold fokuset. Gjør noen få ting bra. Lag et mantra for applikasjonen – Basecamp, prosjekledelse er kommunikasjon. Campfire – gruppe IM suger. Writeboard – Word er overkill. Tada-list – konkurrere med Post-It.
3. Forstå de skjulte kostnadene ved en ekstra funksjon. Ofte er det slik at en ekstra funksjon trekker med seg en hel rekke andre funksjoner som man ikke har tenkt på.
4. Betal gjeld til applikasjonen før den blir for stor. Alle raske løsninger, spaghetti-kode og annet rask er som gjeld; hvis man ikke betaler i tide blir det til slutt helt uoversiktlig.
5. Lag API’er på alt. Det gjør at kundene dine utvider produktet på en måte som gjør produktet bedre. Og når produktet blir bedre vil flere bruke det – uten at du har gjort noe mer.
6. Fokuser på problemene rett foran deg i stedet for de lengre vekk. F.eks. fokuser på å få mange brukere før du begynner å bekymre deg for skalerbarehet (les hele kapitlet gratis).
7. Jobb i små team -- store team fører til møter og kaster bort tid.
8. Sørg for at alle har uforstyrret tid uten epost, kollegaer som stikker innom etc. Gjerne seks timer hver dag. De beste ideene får man når man kommer i the Zone. Det kan ta en halv time å komme tilbake til zonene hvis man blir forstyrret.
9. Skriv maks en side som beskriver hva du vil gjøre før du setter igang. Dette bør ikke ta mer enn en dag. Hvis du ikke får det inn på en side er det for komplisert.
10. Jobb fortest mulig med å lage noe som faktisk skal brukes. Begynn med front-end – det kundene ser. Dette er det du selger; begynner du med alt det andre først ender du opp med en front-end som ser ut som et juletre.
11. Godt språk er en integrert del av god design. Tenk igjennom hva som står, og ikke skriv som en ingeniør. Det får folk til å føle seg dumme.
12. Ansett folk som er gode til å uttrykke seg skriftlig. Hvis de ikke kan skrive det tydelig kan de antagelig ikke tenke tydelig heller.
13. Ikke ansett folk før de har blitt prøvekjørt; la dem bryne seg på noen oppgaver først – før de blir ansatt. Unngå å ansette folk så lenge som mulig.
14. La utviklerne svare på henvendelser fra kunder og forsøk å svare så raskt som mulig. Etabler forum hvor kundene kan hjelpe hverandre. Lag link til FAQ fra steder i applikasjonen hvor det kan være bugs.
15. Ikke lag en logg over kjente bugs. De viktigste bugsene blir du alikevel hele tiden minnet på av dine kunder.
16. Blog om alt som skjer -- vær kontant med dårlige nyheter, trekk gode nyheter ut i langdrag. Blogging er også en måte å sette forventninger om ny funksjonalitet.
17. Gi noe gratis, trekk kundene inn i en konversasjon. Promoter oppsalg i selve applikasjonen. Forklar hvorfor noe koster penger – når kunden trenger den funksjonen du ønsker å selge.
18. Velg gode navn på en tjeneste, de trenger ikke beskrive alt. Basecamp er et bedre navn en ProjectExpress.
19. Unngå penger fra investorer. Fund selv hvis du kan -- det gir bedre løsninger og alt skjer raskere.  Det gjør deg også istand til å beholde mer lidenskap for prosjektet fordi du kan fortsette å fokusere på de tingene som er nyttige for dine kunder.
20. Unngå møter og hvis du har møter, stopp etter 30 minutter. Ingen ting stjeler mer energi enn dårlige møter. Og det er alltid en jævel der som kaster bort andres tid for å få oppemerksomhet.
21. Webmodeller trenger ikke å ha store oppgraderinger for å rettferdiggjøre at folk betaler penger. Folk betaler for den verdien du hele tiden tilbyr dem. Det er bare de store som Microsoft, Adobe og andre som shipper programvare som trenger å ha masse oppgraderinger for å rettferdiggjøre at folk skal betale for oppgraderinger
22. Ha enkle kontrakter med kunder – gjør det lett å avslutte en kunderelasjon for kunden. Gjør det like lett å avslutte som å begynne en relasjon. Fjern mest mulig switchingkosts. Det er god folkeskikk og det bygger tillit som gjør at folk er villige til å begynne å bruke programvaren.
23. Vær så åpen som mulig i forhold til kundene dine. Del så mye informasjon som mulig med dem. Gi og du får mye mer tilbake.
24. Bruk deg selv som målgruppe. Løs dine egne problemer – antagelig har millioner av andre folk det samme problemet.

Alle disse forslagene er krevende for selskaper å gjennomføre fordi de går på tvers av selskapets kultur. Det er ihvertfall tilfelle i de selskapene jeg har jobbet i. Men jeg tror dette er  gode råd når man starter et nytt selskap. Og jeg tror rådene er gode for alle som ikke er programmere også fordi denne boken i stor grad snakker om hvordan man best mulig løser problemer – ved å nøste fra nesen og fremover. Rett og slett. Hvis du står i en urskog og skal frem må du bruke machete. Du kan ikke tenke for mye på hva som skjer etterpå. For det spiller ingen rolle hvis du ikke kommer deg frem! Slik er det i utvikling av webapplikasjoner, og slik er det i stor grad i andre yrker også.

Her kan du se innholdsfortegnelsen:

Introduction

• What is Getting Real?
• About 37signals
• Caveats, disclaimers, and other preemptive strikes

The Starting Line

• Build Less 
• What's Your Problem?  Viktig å definere hvilket problem man skal løse
• Fund Yourself -- ikke ta penger fra investorer -- det kompliserer og gjør ting vanskelig
• Fix Time and Budget, Flex Scope -- lag heller mindre funksjonlalitet og få ting ut døra tidsnok
• Have an Enemy -- vær tydelig på hvem du konkurrerer mot
• It Shouldn't be a Chore -- sørg for at det er gøy.  Gi folka de verktøyene de trenger, og sørg for hyppige releaser slik at man føler at man gjøre noe nyttig. 

Stay Lean

• Less Mass.  Unngå å ansette for mange folk.  Gjør ting enklere. Skriv mindre kode.  Løser du 80% av problemet med 20% av koden har du en stor seier. 
• Lower Your Cost of Change.  Vær fleksibel også i hodet.  Flickr startet som et spill.  De oppdaget fotosharing.  Nå har de droppet spillet. 
• The Three Musketeers.  Ikke vær for mange folk. 
• Embrace Constraints.  Begrensninger skaper kreativitet.  Nød lærer naken kvinne å spinne.  Apple har kuttet sine R&D budsjetter men er mer innovative enn noen gang. 
• Be Yourself.  Ikke lat som du er et stort selskap, ikke prøv å snakke til kundene som om du er større enn du er.  Vær deg selv i måten du snakker på og kommuniser hele tiden med kundene. 

Priorities

• What's the Big Idea.  Skjær vekk alt fettet.  Hva er det vi skal oppnå?  Fokuser på å løse ett problem av gangen. 
• Ignore Details Early On.  Zoom inn på det som skjer midt på siden -- ta deg av ytterkantene senere.
• It's a Problem When it's a Problem.  Ikke kast bort tid på ting før de dukker opp på radaren. 
• Hire the Right Customers.  Vær nøye med hvem du vil ha som kunder.  Velg bort noen kunder slik at du kan levere verdi til de som er igjen. 
• Scale Later.  Ikke bekymre deg for skala når du ikke har noen brukere. Skaff brukerne først.  Skalering fikser du senere.
• Make Opinionated Software.  Ikke forsøk å være alt for alle.  Vær strategisk. 

Feature Selection

• Half, Not Half-Assed.  Gjør mindre men gjør det bedre. 
• It Just Doesn't Matter.  Når alle kommer med ting de vil ha inn i applikasjonen, spør om det virkelig spiller noen rolle.  Som regel gjør det ikke det. 
• Start With No.  Si nei først når noen vil ha noe nytt inn i programmet.  Hvis det er viktig dukker det opp igjen og igjen. 
• Hidden Costs.  Se opp for skjulte kostnader når du velger ny funksjonalitet.  Ofte kan det balle på seg.  Vær obs på det og styr unna. 
• Can You Handle It?  Ikke legg ut på lengre turer uten at du er i god form.  Ikke tilby funksjonalitet du ikke klarer å håndtere. 
• Human Solutions.  Fokuser på at det er mennesker som skal bruke applikasjonen.  Ikke test på andre, test på deg selv, og ha noen du stoler på som kan teste det for deg.   
• Forget Feature Requests.  Du trenger ikke ha en fil med feature requests. De viktige kommer tilbake hele tiden og de glemmer du ikke. 
• Hold the Mayo.  Den største tjenesten du kan gjøre for en kunde er å utelate ting.  Spør kundene dine "hva kan jeg droppe?". 

Process

• Race to Running Software.  Få noe ut døra, opp å stå så snart som mulig.  Tenk akuttmotak.  Noen blør.  Stopp blødningen.  Et programvare selskap uten programvare er som en blødende pasient.  Få noe opp å stå.  Nå. 
• Rinse and Repeat.  Det beste er det godes fiende.  Få noe ut selv om det ikke er perfekt.  Kunder forstår at ikke alt er perfekt med en gang.  Når først ting er ute får du hjelp av kundene dine. 
• From Idea to Implementation.  Først brainstormer man.  Så lager man en skisse -- på papir.  Dette handler om å få ideer fra hodet og ut på papiret.  Ikke noe mer.  Deretter HTML bilder, og få dette til å funke.  tilslutt: kode ut greiene. 
• Avoid Preferences.  Det er mye bedre å ta enkle beslutninger der og da på vegne av kundene.  Ikke forsøke å gi dem alt.  Ta beslutninger og holde momentumet.  Ikke la de stakkars kundene velge at mulig fordi du ikke klarer å ta en beslutning. 
• "Done!"  Ingen beslutninger er for alltid.  Ta beslutningen og kom deg videre -- selv om den kanskje ikke er perfekt.  Som de sier, dette er ikke hjernekirurgi, det er web-utvikling. 
• Test in the Wild.  Det er ingenting bedre enn ordentlige brukere som bruker app'en på ordentlig.  Usability i lab funker ikke.  Istedet er det bedre å slippe beta-funksjoner inne i en funksjonell app til noen utvalgte og få feedback fra disse. 
• Shrink Your Time.  Å planlegge måneder ut i fremtiden er rent vås.  Bryt oppgaver ned i ting som kan gjøres i løpet av noen timer.  Programmere som skal gjøre noe som tar tre uker, gruer seg i 19 dager og gjør jobben på to dager. 

The Organization

• Unity.  Ikke bryt ned i siloer.  Da mister man oversikten over oppgavene.  Få folk til å jobbe sammen -- designere og skribenter og kodere. 
• Alone Time.  Jobb uten epost, mobil og chat og ingen avbrytelser.  Det er da de fleste får ting unna.  Finn tid til å komme in the Zone.  Og respekter andres tid på samme måte. 
• Meetings Are Toxic.
• Seek and Celebrate Small Victories.

Staffing

• Hire Less and Hire Later
• Kick the Tires.  Test nye folk før du ansetter dem.  Gi dem en oppgave, og se hvordan de løser den. 
• Actions, Not Words.  Vurder teknologi folk på hva de har gjort av open-source programmering tidligere, ikke eksamener og hvilke skoler de har gått på. 
• Get Well Rounded Individuals.   Få folk som er allsidige.
• You Can't Fake Enthusiasm.  Velg heller en som er passe god og kjempentusiastisk fremfor et surt geni. 
• Wordsmiths.  Ansett folk som er gode til å skrive.  De tenker bedre.

Interface Design

• Interface First.  utvikle frontend først.  Dette er det kundene ser og det viktigste.  Sørg også for å integrere admin-delen av applikasjonen som en del av front-end slik at dette ikke blir uleselige sider. 
• Epicenter Design.  Igjen, fokuser på det som er midt på siden, det viktigste for brukeren. 
• The Three State Solution. Hvor hver webside må man tenke tre ulike scenarioer: For vanlig bruk, hvordan det ser ut første gang man bruker det, og hva som skjer hvis det er en feil. 
• The Blank Slate.  Å ignorere brukerens første møte med applikasjonen er et stort feiltrinn.  Jeg husker selv mitt første møte med iPod -- da jeg åpnet esken -- ah, for en opplevelse!  Og jeg husker også mitt første møte med MS Office -- når man skal begynne og ingenting funker.  Hvordan ser applikasjonen ut første gang en bruker møter den?  Ekstremt viktig.  viktig at de som utvikler også legger inn ordentlig data for å se hvordan det er å legge inn noe annet enn løkjaserkja lkjøasdraøl. 
• Get Defensive.  Design med tanke på at ting går i dass engang i blandt. 
• Context Over Consistency.  Den gamle ideen om at man alltid skal være konsistent er død.  På nettet driter brukere i det -- de vil at det skal funke, og de forstår av konteksten når ting kanskje ser annerledes ut. 
• Copywriting is Interface Design.  Å skrive godt er like viktig som god design.  Det er god design. 
• One Interface.  Ikke tenk at admin skal ha et annet interface enn brukeren.  Admin er en bruker. 

Code

• Less Software.  Skriv mindre kode. 
• Optimize for Happiness.  Gi teamet de verktøyene de trenger for å være fornøyde og entusiastiske. 
• Code Speaks.  Lytt til utviklerne.  Når du ber de om noe og de nøler kan det være smart å spørre de hvordan de kan løse problemet eller deler av det på en annen måte. 
• Manage Debt.  Ikke la dårlig kode bli liggende. 
• Open Doors.  Bruk RSS og API for å få alt ut.  Gjør det lett for folk å bruke dine ting. 

Words

• There's Nothing Functional about a Functional   Spec.  De er døde dokumenter. Ingen leser dem.  Det som står der har lite å gjøre med det som blir utviklet.  De er fantasier, ønskelister og politiske dokumenter som gir et inntrykk av enighet.  Den enigheten man tror man oppnår gjennom kravspekk er illusorisk.  Kravspekk tvinger deg til å ta de viktigste avgjørelsene når du har minst informasjon og erfaring -- på begynnelsen av prosjektet.  Kravspekk leder til for mye funksjonalitet. Når listen over funksjonalitet er avgjort og signet på er det for seint å utelate den.  Ved å dropp kravspekk holder man fleksibilitet mye lenger -- til man vet mer. 
• Don't Do Dead Documents.  Hvis et dokument ikke leder til noe er det liten vits å skrive det.  Bygg applikasjoner i stedet for å skrive om det.  Et eksempel er en wireframe.  Hvis den ikke blir til en prototype er det like greit å gå rett på prototypen. 
• Tell Me a Quick Story.  istedet for å gå i tekniske detaljer, fortell heller en historie slik du ville fortalt den til en person.  Unngå teknospeak.  Det er det ingen som forstår selv om ingen vil innrømme det. 
• Use Real Words.  Ikke legg inn lorem ipsum, men skriv istedet skikkelig tekst slik brukerne ville ha gjort. 
• Personify Your Product.  Hva slags person er ditt produkt?  Tenk på applikasjonen som en person.  Hva slags person er den? 

Pricing and Signup

• Free Samples.  Gi folk gratis prøver av noe som faktisk er verd noe. 
• Easy On, Easy Off.  Gjør det lett å signe opp og lett å komme ut. 
• Silly Rabbit, Tricks are for Kids.  Ikke prøv å lure kundene. 
• A Softer Bullet.  Når du skal gi dårlige nyheter, så forsøk å gi folk tid til å venne seg til en tanke. 

Promotion

• Hollywood Launch.  Det betyr at du først gir folk en teaser -- fortell dem om hva som kommer, deretter en smakebit -- som en slags forfilm med screenshots og videoer som viser hvordan produktet skal virke, og tilslutt, lansering.   Bygg forventninger.
• A Powerful Promo Site.  Ha oversikter, guidet tur, skjermbilder, forklaring av filosofi, caser som viser kundeverdi,  kanskje sitater fra kjente brukere, forum hvor brukere kan diskutere, pris-oversikt og selvfølgelig -- en blogg. 
• Ride the Blog Wave.  Blogging er mer effektivt enn reklame og mye billigere. 
• Solicit Early.  Få tak i epost adresser så snart som mulig og bruk disse til å informere folk om når du går live. 
• Promote Through Education.  Det er ingenting som er bedre reklame enn å dele din kunnskap med dine brukere. 
• Feature Food.  Ny funksjonalitet er en fin måte å få omtale på.  Blogg om det og andre bloggere vil linke til din side.   Da Basecamp introduserte iCal, fikk de masse omtale blandt McBrukere. 
• Track Your Logs.  Les loggene over hvem som kommer til din blogg.  Takk folk for deres kommentarer og skriv på deres blogger. 
• Inline Upsell.  Promoter oppgraderinger inne i selve applikasjonen. 
• Name Hook.  Finn et kult navn. 

Support

• Feel the Pain. Ikke separerer utvikling og kundesupport.  Hold disse samlet slik at utvikling forstår hva kundene er opptatt av. 
• Zero Training.  Lag alt så enkelt at brukere ikke trenger opplæring.  iPod.  Jeg sier ikke mer. 
• Answer Quick.  Svar på henvendelser med en gang.  Ingenting er værre enn store selskaper som ikke svarer eller gir deg et meningsløst svar etter noen dager.  Få ting gir deg mer lojale kunder enn kjapp oppfølging av forespørsler. 
• Tough Love.  Ikke vær redd for å si nei til kunder -- spesielt når de ber om mer funksjonalitet. 
• In Fine Forum.  La kundene snakke til hverandre. 
• Publicize Your Screwups.  Vær ærlig og si ifra når noe inntreffer.  Det bygger tillit. 

Post-Launch

• One Month Tuneup.  Smell ut en stor oppgradering 30 dager etter at du har launchet.  Det skaper gode følelser, gir folk noe å blogge om og deg noe å snakke om. 
• Keep the Posts Coming.   Å blogge er som å gå tur med bikkja.  Sørg for å holde liv i bloggen og snakk om produktet. 
• Better, Not Beta.  Ikke ha ting i beta forever. 
• All Bugs are Not Created Equal.  Noen feil kan du faktisk ignorere på kort sikt fordi det er viktigere ting å gjøre enn å få alt perfekt. 
• Ride Out the Storm.  Hold hodet kaldt når det stormer.  Det hender at det lønner seg å vente til ting roer seg ned før man agerer på sinte kunder eller hva det nå er.  Negative reaksjoner er alltid høyere enn positive.  Det kan hende at de fleste kundene er fornøyde selv om noen skriker og bærer seg. 
• Keep Up with the Joneses. Sørg for å holde deg oppdatert om konkurrentene via tjenester som PubSub, Technocrati og Feedster. 
• Beware the Bloat Monster.  Selv om produktet ditt modner betyr ikke det at det må bli mer komplisert.  Når man får betalt månedsvis har man ikke samme insentivet til å selge kunder nye store oppgraderinger.  Unngå økt kompleksitet over tid.  Tenk på Microsoft...
• Go With the Flow.  Vær åpen for at nye ting kan skje og man må forandre ting underveis.