Låt oss säga det rakt ut.
Idag är snabba leveranser inte längre något som är trevligt att ha. Det är en självklarhet. Om du inte lär dig något i produktionsmiljön, lär du dig för långsamt.
För några dagar sedan visade en grundare mig en fintech-produkt som de hade ”finslipat” i åtta månader. Ett snyggt användargränssnitt. Smidiga animationer. Noll riktiga användare. Under samma tid hade en konkurrent släppt tre mer grovhuggna versioner, haft regelbunden kontakt med användarna varje vecka, fått fart på verksamheten och precis genomfört en ordentlig finansieringsrunda.
Samma marknad. Samma tidpunkt. Helt olika resultat.
Det är här de flesta teamen hamnar i förvirring: hastighet utan kvalitet skapar kaos, medan kvalitet utan hastighet gör att man tappar relevansen.
De lag som vinner väljer inte en enda lösning. De omdefinierar vad ”kvalitet” egentligen innebär i varje skede – ett problem som behandlas ingående i Startup Methods när det gäller att definiera kvalitet i varje skede av en startups utveckling.
Efter att ha utvecklat och granskat hundratals produkter har ett tydligt mönster framträtt.
Alla kvalitetsaspekter har inte samma betydelse.
Ett fel i inloggningen, ett misslyckat betalningsförsök eller ett dataläckage är existentiellt. En felplacerad knapp eller en bristfällig animation är det inte.
Starka team fokuserar på kärnkvalitet: den lilla uppsättning saker som definierar förtroende och användbarhet:
Allt annat får gärna vara ofullkomligt i början.
Ett enkelt men effektivt knep: fastställ kvalitetsnivåer.
Bara detta eliminerar en enorm mängd falskt arbete.
Lär dig hur tidiga upptäckter och designbeslut hjälper teamen att undvika att behöva välja mellan hastighet och kvalitet senare i utvecklingsprocessen.
De flesta team arbetar inte långsamt för att de programmerar långsamt. De arbetar långsamt för att arbetet sker stegvis.
Designavdelningen väntar på specifikationer. Frontend-avdelningen väntar på backend-avdelningen. Kvalitetsavdelningen väntar på ”slutgiltiga” versioner.
Högpresterande team har en övergripande inverkan på allt:
Vinsterna beror inte på att man skriver snabbare. De beror på att man utnyttjar den tid som annars skulle gå till spillo.
Jag har sett team som har lyckats minska leveranstiden med cirka 40 % enbart genom att förbättra överlämningarna.
Automatisering är till hjälp – men bara när den är målinriktad.
Att blint sträva efter ”hög testtäckning” brukar bromsa teamen och skapa en falsk känsla av trygghet.
Det som verkligen spelar roll:
En strikt standard på 60 % som skyddar intäkterna och förtroendet är bättre än en standard på 95 % som ingen förstår eller underhåller.
Att försöka förutse alla undantagsfall fungerar inte, men att lansera produkten med inbyggda säkerhetsåtgärder gör det.
Det innebär att:
Team som använder den här metoden genomför driftsättningar flera gånger om dagen – inte för att ingenting går fel, utan för att eventuella fel begränsas och kan åtgärdas.
Det är verkligt självförtroende.
Det är meningslöst med snabb leverans om återkopplingen går långsamt.
Feedback måste byggas in i produkten:
Dina användare talar om för dig vad ditt företag egentligen står för. Frågan är bara hur snabbt den signalen når dig.
Vissa saker är inte förhandlingsbara:
Att stressa igenom dem gör dig inte snabbare. Det gör dig sårbar.
Genvägar är inte något ont. Det är däremot genvägar som inte hanteras.
Lösningen är enkel men används sällan: planera skuldåterbetalningen noggrant.
Redan en enda vecka per månad som ägnas åt målmedveten refaktorisering förändrar utvecklingen av en kodbas.
Vinnande lag är inte de snabbaste eller de mest välpolerade.
Det är de som levererar rätt kvalitet i rätt takt för det skede de befinner sig i.
Din uppgift är inte att välja mellan hastighet och kvalitet. Din uppgift är att definiera vad kvalitet innebär just nu och få hela teamet att enas kring den definitionen.
Det är så man kan agera snabbt utan att sätta företaget i gungning.
Är du redo att påskynda din produktlansering utan att det blir kaos?