Om du arbetar på en produkt som innehåller mjukvara kan du komma att inse att många av de funktioner du bygger aldrig kommer att användas av konsumenten. Vissa funktioner finns kanske där av juridiska skäl, men det faktum att du spenderat resurser med liten eller ingen avkastning ändras inte.
Och för att göra saken ännu värre, ökar dessa funktioner systemets komplexitet och gör det svårare att hitta och använda övriga funktioner. Detta kombinerat med insikten att majoriteten av arbetet som läggs på en produkt inte läggs på funktionalitet som särskiljer sig från konkurrenterna, har jag blivit en stark förespråkare av datadrivna beslut.
Dessvärre krävs en markant investering innan man når den efterlängtade fas där organisationen kan hämta in och utnyttja data, samt använda den som grund för sina beslut. Investering krävs i både relevant teknisk infrastruktur, produktfunktioner och i människors mentalitet. Till exempel måste funktionalitet som tillåter datainsamling, snabba feedbackloopar och experiment implementeras. Dessutom måste individer acceptera att det är otroligt dyrt och riskfyllt att navigera marknaden baserat på åsikter eller – ännu värre – den berömda "magkänslan". Ärligt talat kommer en sådan övergång inte att ske över en natt, och handlar i grund och botten om kultur. Innan en förändring kan ske måste status quo ifrågasättas.
Du kan påbörja inställningen mot en datadriven approach genom att tydliggöra behovet. När någon föreslår ett nytt krav, en ny funktion eller ändring vars behov inte är uppenbart, ställer du helt enkelt frågan "Varför? Vilket värde tillförs och för vem?". Den här frågan tvingar begäraren att överväga den potentiella avkastningen och argumentera logiskt varför funktionen bör implementeras. Dessutom kan det starta en diskussion om hur förändringen kan påverka prestandan, komplexiteten eller arkitekturen. När begäran väl har försvarats och begäraren inte har ändrat åsikt är nästa fråga "Okej, kan du bevisa det?".
Det är osannolikt att du får ett svar som består av rena fakta och data. Om du har tur kan ett exempel från en eller flera kunder nämnas. Det kan räcka om du arbetar för just den kunden, d.v.s. du är deras leverantör. Men, om produkten riktas mot en större kundbas räcker det inte med något eller några use cases. Du skapar inte produkten efter kundernas specifika behov, och därför är viljan att göra vissa kunder nöjda inte tillräcklig för att implementera en ändring.
Ibland kan du dock behöva ge efter för begäran i slutänden. Det kan bero på att du inte har tillräckliga data eller inte vill framstå som oresonabelt negativ. Men, under diskussionen har du förhoppningsvis sått ett litet frö. Fortsätt påminna att det är bättre att få nöjda kunder än att göra kunder nöjda. Med andra ord; det är bättre att vara proaktiv än reaktiv. Var det tillräckligt mycket, så kommer din organisation att röra sig längre och längre ifrån dagens åsiktsbaserade approach.
Att undvika funktioner som inte ökar värdet på produkten tillräckligt handlar inte bara om att spara pengar. Funktionerna påverkar användarupplevelsen, underhållet av mjukvaran och oftast även den tekniska skulden. Ju fler funktioner du lägger till, desto rörigare riskerar produkten att bli. Samtidigt lär komplexiteten öka, vilket utan tvekan påverkar möjligheten att underhålla produkten. Det var denna insikt som gjorde att jag numer är helt såld på den motsägelsefulla sanningen bakom Worse is better.
Worse is better (Sämre är bättre) eller "New Jersey style" är en approach som sätter enkelheten främst inom mjukvarudesign, till och med före korrekthet. Den här approachen accepterar att konsistens och fullständighet offras till fördel för andra kvalitetsegenskaper, i synnerhet när komplexiteten ökar på grund av dem. Jag har fått en förkärlek till det här uttrycket, inte bara för att det är provocerande underhållande, utan för att vad det saknar i tydlighet kompenseras av den sanning som ligger bakom. "Sämre" är faktiskt bättre när ett projekt bombarderas av önskemål om funktioner som baseras på godtyckliga hypoteser med ifrågasättbar säljbarhet. Att säljarna vill göra nya potentiella kunder nöjda är inte en anledning för FoU-avdelningen att trycka in nya funktioner i produkten. Det kommer bara att resultera i en neråtgående spiral där balansen mellan företaget och dess kunder slutligen lutar över mot den senare. Om det här förhållandet misshandlas, kan det leda till att ditt företag slutligen gör allt för att göra ett litet antal "högljudda" kunder nöjda, och samtidigt ignorerar behoven hos en mycket större grupp användare.
I stället för att komma med en slutsats, tänker jag starkt rekommendera att du läser de utmärkta texterna skrivna av professorn i mjukvarututveckling på Chalmers, Jan Bosch. De har varit en underbar källa till inspiration för många av de tankar och åsikter som illustreras i den här artikeln: