Nyckeln till exekvering ligger inte i programmeringsteknik utan i att välja vad som inte ska inkluderas i den första versionen av din applikation. Jag förespråkar inte att lansera betakod, långt därifrån – att släppa betaprogramvara, vare sig det är öppet eller under sken av v1.0, är oprofessionellt om du tänker debitera dina kunder för privilegiet. Nej, det jag föreslår är att du noggrant beskär din funktionsuppsättning till det minimum som krävs för att utföra det avsedda jobbet. Endast nödvändiga funktioner bör finnas kvar, och de trevliga att ha bör spetsas tills du tar reda på om dina användare verkligen vill ha dem. Detta uppnår två saker: du får en stabil applikation på marknaden tidigare och du kan se hur folk använder din applikation i fält innan de bestämmer sig för nya funktioner. En sak som jag kan garantera är att de inte kommer att använda den som du förväntade dig!
Basecamp, planeringsapplikationen jag nämnde tidigare, utvecklades av 37signals, en mästare på detta tillvägagångssätt. Med Basecamp var 37signals mål att effektivisera projektdriven utveckling. Den beslutade att den viktigaste orsaken till att projekt misslyckas med att leverera i tid och budget inte är brist på planering utan dålig kommunikation, så Basecamps fokus på att dela information är helt annorlunda än dess huvudkonkurrent, Microsoft Project, en berömd komplex applikation som möjliggör planering och uppföljning av projektet från början till slut. Basecamps tillvägagångssätt passar inte alla, men i den verkliga världen är att smörja in kommunikationshjulen både inom ett projektteam och med kunder det enskilt viktigaste bidraget som webben kan ge, och Basecamp gör det utmärkt.
Om du vill ta reda på mer om 37signals tillvägagångssätt rekommenderar jag boken Getting Real: The smarter, faster, easy way to build a successful web application, som du kan se online gratis (http://gettingreal.37signals.com ), men jag skulle föreslå att du lägger upp $25 (Kr12,32) för den tryckta versionen: det är bara ett par hundra sidor, men väl värt det. För mig bekräftar det åsikter som jag har kommit fram till under lång tid om det ineffektiva sättet på vilket programvaruprojekt utvecklas.
d.konstruera 07
På tal om det, veckan efter att jag läst 37signals-boken deltog jag i d.construct 07, en webbdesign- och utvecklingskonferens som hölls varje år i Brighton. Årets tema var användarupplevelsen, och eftersom jag är mer av en utvecklare än en designer var jag inte helt säker på att jag skulle gilla det. Min rädsla mildrades av en fascinerande första session från användarvänlighetsexperten Jared Spool, men mest användbar var ett föredrag av Leisa Reichelt om utvecklingsprocesser.
Det vanligaste sättet att utveckla en webbapplikation (eller vilken applikation som helst) använder sig av ”vattenfall”-metoden, som vanligtvis har fyra steg: omfattning, design, programmering och implementering (deras faktiska namn kan variera mellan organisationer). På första sidan verkar detta tillvägagångssätt logiskt – specificera först applikationen i detalj och skicka sedan den här specifikationen till designteamet; de kommer att rita upp look-and-feel, som sedan skickas till programmerarna som skriver kod för att implementera den designen, och slutligen levererar den koden till den verkliga världen.
Problemet är att detta schema ofta har liten likhet med vad som verkligen händer. Enligt min erfarenhet läggs för mycket tid på specifikationsfasen, vilket resulterar i en press på den tillgängliga tiden för programmering, men det är inte det enda problemet. Faktum är att det är praktiskt taget omöjligt att specificera en stor, sofistikerad webbapp i detalj i förväg – det skulle kräva en övermänsklig förmåga att visualisera slutresultaten så detaljerat. De flesta levererade produkter avviker väsentligt från sin ursprungliga specifikation, och de som inte gör det är ofta sämre för det.
