Vad betyder allt detta för den som utvecklar webbappar enligt den spekulativa modellen?
Jag vill dröja lite vid ordet ”rudimentärt” – att man börjar med att släppa något rudimentärt, som en fråga till sina användare. Det är nämligen väldigt passande.
I överförd bemärkelse syftar ordet ”rudiment” enligt NE på ”ngt som endast är påbörjat och ännu outvecklat” (ursprungligen betyder det dock ett kroppsligt organ som tillbakabildats, t.ex. mannens bröstvårtor).
Mina tankar om detta började under ett möte med ett företag om ett eventuellt community kring deras programvaror. Samtalet gick via insikten att det kanske duger att låta diskussionen om produkterna ske ”där ute” till att handla om en social webbsajt kring det ”innehåll” som skapas med programvarorna.
Denna webbsajt skulle utvecklas spekulativt och börja med ett rudimentärt första släpp, med dess epicenter.
Flera gånger när vi diskuterade funktioner insåg vi att de kunde vänta. De var inga funktioner sajten skulle stå eller falla med.
Och flera av de icke-essentiella funktionerna var sådana att de skulle kunna ersättas med mer generella och öppna funktioner, vilket därmed skulle skapa utrymme för konventioner att uppstå.
Eftersom jag inte kan gå in på detaljer återanvänder jag exemplet med taggarna på Flickr. Genom att införa taggar för foton har Flickr sett en mängd konventioner uppstå och därmed kunnat undslippa att bygga en mängd specifika funktioner.
Det slår mig att användare uppfinner konventioner hur svårt du än gör det för dem. Jag hörde en gång en historia om ett företags rätt inflexibla interna affärssystem där en mängd konventioner uppfanns. T.ex. använde de fältet för efternamn till att ”märka” kunderna på olika sätt. Vid ett möte hade en kund råkat se att han i systemet hade ett suffix i stil med ”Larsson/Jobbig”.
Nu vet jag inte hur stor nytta de hade av att kunna urskilja de jobbiga kunderna. Men troligen märkte de också på andra sätt och det kan ses som uttryck för något som missats i projektets analysfas.
Den spekulativa utvecklingsmodellen har inget större behov av analys. I ett projekt med långa iterationer behövs viss analys. Men hur underbyggd den än är kommer den alltid vara lite av en gissning. Först efter släpp kan man veta om en funktion möter behovet.
Spekulativ utveckling välkomnar gissningen. Och just därför, just för att man släpper något rudimentärt så snart man kan, efter så lite arbete som möjligt, är det förmodligen en god idé att försöka maximera utdelningen på ens gissning. Alltså att släppa något som samtidigt som det är användbart kan ge så bra svar som möjligt på frågan om den fortsatta utvecklingen.
Generellt och öppet snarare än specifikt.
För att göra det extra tydligt för mig själv: som jag skrev i februari så handlar det om att börja ”med det element med vilket helheten står och faller” – fast det heter väl ”står eller faller”?.
Men det handlar också om att inte vara för specifik, att inte göra för många antaganden om sina användare.
Ett exempel på det vore att inte tänka ut en massa fält för olika attribut hos objekten i ens system. Att i stället nöja sig med ett fritextfält för godtycklig information om objektet. Och att man efter man släppt ser vad de använt fältet till. Kanske kan man hitta något som förtjänar en specifik funktion?
Även om iterationerna är korta – även om det kan gå 30 minuter mellan släpp – så kostar det att fråga. Jag inbillar mig att det är ”billigare” att släppa något som kan utvecklas vidare i någon riktning, snarare än något som måste stöpas om. Frågor ska inte behöva formuleras om, de ska bygga på de tidigare.
Inte så att det är ”dyrare” i sig att kasta något och göra en ny ansats. Snarare handlar det om att man måste ha sina användare med på noterna.
Det är ju en dialog, inte en föreläsning.
Recent Comments