Dolda kostnader och verklig agilitet i produktutvecklingsprocessen

Wu-Tang Clan hade rätt

Kontanter styr allt runt omkring mig. Det kan inte ens de mest turkosa organisationerna förneka. Utvecklingen av projekt Ledningsmetoder, optimering av processer eller medarbetarnas motivation drivs i grunden av det universella behovet av pengar. Design agility innebär vissa risker.

Vi vill alla vara smidiga och agil så att resultatet av vår verksamhet, mätt i siffror, blir så högt som möjligt. Även om vi lägger mest energi på att minska förlusterna, tar vi i slutändan hänsyn till den vinst som har ökat tack vare de besparingar som genererats.

Dessa besparingar hamnar i samma fack som de övriga faktorerna och är bara tillgängliga för de mest nyfikna. På så sätt tappar vi fokus och utelämnar oavsiktligt mycket värdefull data och i slutändan intelligens.

Lärdomar från misslyckanden

Att lära sig av sina egna misstag är en särskilt användbar (men dyr) färdighet, men organisationskultur och den diplomati som ligger i denna förmåga hjälper inte alltid. Vi döljer ofta finansernas negativa inverkan med "rökridå"-ord. När en investerare skriker "Jag förlorade mina pengar!", kommunicerar förvaltaren det till Team genom att säga "vi borde vara mer effektiva" och vi letar alla automatiskt efter nya lösningar och förbättringar - i stället för att blicka bakåt letar vi ständigt efter sätt att gå framåt.

Samtidigt är förluster ofta nyckeln till att dra rätt slutsatser. Om vi går igenom vissa flödessteg i processen utan att tänka efter ordentligt, kommer nästa lösning sannolikt att vara infekterad av samma fel.

Exempel: 

Ett litet team av seniora JS-utvecklare levererar inte funktionalitet inom den förväntade tiden. Investeraren, som vill påskynda utvecklingen, beordrar att en ny programmerare ska anställas. Att introducera en ny person i projektet kommer att distrahera teamet, vilket saktar ner projektets framsteg ytterligare.

Om investeraren bättre skulle förstå orsakerna till teamets ineffektivitet skulle han dra slutsatsen att det bara utnyttjar sin potential under 60-70%. Bättre utrustning och några arbetsdagar som ägnas åt automatisering av arbetet skulle lösa problemet.

Tyvärr måste han nu betala för en annan utvecklare som ska arbeta med samma utrustning och vars effektivitet också kommer att ligga på 60-70%.

Lösning A:

• Team (2 x senior JS dev): $20k / månad
• Moln tjänster: 200$ / månad
• Ny hårdvara för utvecklare: $10k

Från och med nu kostar projektet $20.200 / månad

Total utgift under 12 månader: 12 * 20.200 + 10.000 = $252.400

Lösning B:

• Team (2 x senior JS dev): $20k / månad
• Ny utvecklare (1 x senior JS utvecklare): $10k / månad

Från och med nu kostar projektet: $30.000 / månad

Total utgift på 12 månader: 12 * 30 000 = $360 000

Två utvecklare som arbetar på 100% gör ungefär samma sak som tre utvecklare som arbetar på 60-70%. Investeraren kommer att betala över $ 100 000 mer för samma bearbetningskapacitet per år på grund av ett felaktigt designbeslut!

Att bygga en perfekt produkt är som att jaga en kanin

Agilitet i processen innebär inte nödvändigtvis att man strävar efter 100%-testtäckning eller att slå prestandarekord. Även om dessa mått ger en översikt över projektets tekniska tillstånd är de så obetydliga ur slutkundens perspektiv att det inte är nödvändigt att uppnå dem till ett idealiskt tillstånd i en verkligt agil process eftersom de inte ger någon verklig marknad värde.

Att utveckla perfekta tekniska lösningar kräver ett stort engagemang från teamet och mycket mer omfattande kommunikation. Följden blir att patcherna arbetar långsammare och att projektet blir tungt på grund av överutveckling.

Agil utveckling handlar om att leverera en fungerande kod med minimal ansträngning. Kodtestning är utan tvekan en bra metod och testerna säger mycket om hur koden fungerar, men de ska inte göras bara för att man ska göra dem och skryta om det - den optimala tekniska kvaliteten på lösningar ligger någonstans mellan den miniminivå som fastställs av utvecklingsteam och det maximala som begränsas av budgeten.

I slutändan kommer man ingenstans med perfektion. Intressant nog är även säkerhetsfrågan föremål för denna regel - teoretiskt sett kan alla system hackas. Det tidigare nämnda utvecklingsminimumet måste dock vara motsvarande högre och relevant för vikten, skalan och kostnaden för potentiella konsekvenser av kodmisstag. Ofta, istället för att skriva inloggningsmodulen från grunden, som alltid är belastad med en hög risk för fel och införa säkerhetsproblem, är det bättre att använda till exempel knappen "Logga in med Google", vars korrekta implementering är relativt snabb och säker.

Så länge målet är en kort time-to-market är överdrivet ambitiösa antaganden kontraproduktiva. I en till synes perfekt process kan överentusiasm vara ett slöseri med resurser.

Det är bra att veta allt om något och något om allt

Användarcentrerad design är coolt. Människocentrerat samarbete är viktigare. När teamet kommunicerar på samma våglängd kan det spontant minska ytterligare potentiella förluster.

En UX-designer som är uppdaterad med frontend-teknik kommer inte att föreslå en lösning på MVP fas som kommer att ta orimligt mycket tid i anspråk i genomförandeskedet.

En frontend-utvecklare som kan användbarhetsheuristik kommer att kunna anpassa gränssnittet till en viss skärmupplösning utan att involvera UX-designern - quick fix, förhandsgranska, acceptera.

Att arbeta med en applikation kräver synkronisering av aktiviteter hos personer med helt olika kompetensprofiler. Du måste veta hur kompetensen är fördelad i ditt team för att effektivt kunna leverera värde till dina kunder.

Ett engagerat och synkroniserat team är en viktig faktor för att skapa besparingar. Denna typ av smidighet kräver optimal produktutveckling.

Bra teamprestationer på det här sättet är oerhört svårt att uppnå, särskilt i en tid av distansarbete. Företag som har varit "fjärrvänliga" i flera år har en betydande fördel på detta område jämfört med dem som har tvingats anpassa organisationen under nedstängningen och först nu lär sig om nya metoder och former för kommunikation.

Kraftfull utrustning innan du går igång

I samband med de växande kommunikationsbehoven noterar verktyg som Whimsical, Miro, Mural, Figma och Balsamiq en imponerande ökning i popularitet.

Visst har nedstängningen och behovet av att arbeta på distans spelat sin roll i denna explosion av användare. Jag anser att valet av verktyg bör matcha individuella preferenser, men låt oss ta en titt på Miro:

Popularisering av sådana verktyg driver naturligtvis ökningen av populariteten för själva metoderna. Den som köpt Miro för att arbeta med personas får tillgång till dussintals andra mallar som kan visa sig vara av intresse och påverka teamets dagliga arbete positivt.

Du bör alltid utrusta dig med verktyg som effektiviserar informationsflödet i projektet. Öppenhet för nya verktyg och metoder är också en av grunderna för ett effektivt produktutveckling.

Du kan (och bör) vara lat

Erfarna designers av både gränssnittet och programvaruarkitekturen upptäcker vanligtvis flera potentiella lösningar som bör verifieras i början av samarbetet och letar effektivt efter lämpliga inspirationskällor eller till och med färdiga lösningar på marknaden. Ett bra exempel är ramverket Material UI, som vanligtvis är ett säkert kort i prototypstadiet.

Ibland räcker det med att granska några implementeringar på Behance eller Dribble och använda inspirationen för att ta fram en moodboard och sedan skicka den till utvecklaren. Denna person använder den för att sätta ihop en klickbar prototyp som kan presenteras för tidiga användare för att samla in feedback. Denna organiska strävan efter en effektiv process hos designintresserade och engagerade människor är naturlig.

Om du vill leverera digitala produkter på ett effektivt sätt måste du låta människor göra sitt jobb. Du vet vilket värde/vilken tjänst du vill ge dina kunder - det räcker. Ett kompetent och välskött projektteam vet bäst hur man levererar detta värde/denna tjänst så snabbt som möjligt med nödvändig kostnadseffektivitet.

Visa förtroende, dela ansvaret och öppna upp för en verklig tvåvägskommunikation så att din Produkt kommer att bli bättre och bördan av att göra allt själv kommer att vara borta från dina axlar, vilket ofta visar sig vara en ansträngande resa för grundare och entreprenörer! På CodestVi omsätter denna princip inte bara i projekt utan även i interna processer - det är förmodligen därför vi har en hög retention av både kunder och medarbetare (sann historia, båda> 90%).

Unna dig lite lättja, överför ansvar och släpp taget om allt överflödigt arbete som inte är nödvändigt för att komma vidare - funktioner som skulle vara "trevliga att ha" kan alltid vänta.

Fokusera på att hitta rätt svar

Processen med att skapa en digital produkt är en ständig kollision mellan olika perspektiv, erfarenheter och informationskällor - och varje sådan kollision medför en risk för att fatta fel designbeslut.

En god intern kommunikation minskar denna risk, men det är bara en sida av myntet. Frågan om hur man håller kontakten med marknaden återstår fortfarande att besvara.

Business Intelligence, Customer Support, UX research departments and many others – just like the utvecklingsteam, they should strive for the minimum necessary to provide specific answers to questions asked by the product owner or the UX team.

Själva varumärkesprofileringen och kommunikationsstrategin är också viktiga. De tjänar till att bygga en kvalitativ relation med kunderna, vilket sedan översätts till deras engagemang. Om du vill ställa frågor till kunderna bör du se till att de är villiga att svara på dessa frågor. Tonen i din röst är viktig.

Det är säkert så att man genom att ha ständig kontakt med marknaden kan definiera de rätta vägarna för projektet för att få det att flyga. Mindre uppenbart är det faktum att behovet av denna kontakt bör beaktas redan i början av projektet, när det gäller att förutse rätt kompetens i teamet (för att ställa rätt frågor och besvara dem) och bygga upp en produktstrategi som involverar målgrupperna.

Slutsatser

Med tanke på alla de frågor som nämns ovan kan vi konstatera att det finns flera problem som regelbundet dyker upp i designprocessen:

- är alltför vinstinriktade och undviker att titta på misslyckanden,

- felaktigheter och inte röntga egna misstag,

- Jaga en perfekt produkt som du har i ditt huvud, men som inte är vad marknaden behöver,

- övernitisk implementering av textboksprocesser - överutveckling och överdesign,

- oflexibelt teamarbete och tvingar medarbetarna att stanna kvar endast inom sina specialområden,

- ineffektiv kommunikation,

- tendens att uppfinna hjulet på nytt.

Processoptimering på makronivå omfattar summan av besparingar. För att på rätt sätt möta de ovan nämnda utmaningarna måste du involvera dina kollegor så att de öppet kan presentera idéer för att förbättra processen.

Ibland räcker det med att prata mindre och lyssna mer uppmärksamt på underordnade, kunder och partners - i enlighet med var och ens roll och ansvar - för att nå framgång.

När du inte riktigt räcker till är du troligen överinvesterad. Har du för mycket pengar?

Håll käften och ta dina pengar! Och förresten..:

1. Inför inte Scrum bara för att öva Scrum.
2. Var mer uppmärksam på avbrott i processen.
3. Sätt upp mindre mål som är uppnåeliga och mätbara på kort sikt - håll dig i allmänhet till det minsta möjliga.
4. Ibland kan en bra Färdplan räcker för att ge teamet en känsla av ett gemensamt mål och engagera dem i ett effektivt arbete här och nu.
5. Bygg upp ett bra team för att kunna ge det den frihet det behöver.
6. Ifrågasätt alltid den nuvarande uppsättningen verktyg - sök efter möjliga förbättringar i din verkstad.
7. Utforma processen ur den lata personens perspektiv - som om du vill göra så lite som möjligt.

Läs mer om detta:

CTO-utmaningar - uppskalning och tillväxt av mjukvaruprodukter

Vilken DB ska du välja för din specifika datatyp i ditt programvaruprojekt?