Skjulte omkostninger og ægte agilitet i produktudviklingsprocessen

Wu-Tang Clan havde ret

Kontanter styrer alt omkring mig. Selv de mest turkise organisationer kan ikke benægte det. Udviklingen af projekt ledelsesmetoder, tilpasning og optimering af processer eller medarbejdermotivation udløses grundlæggende af det universelle behov for penge. Designagilitet indebærer visse risici.

Vi vil alle gerne være slanke og smidig så resultatet af vores aktiviteter, målt i tal, bliver så højt som muligt. Selv om vi bruger det meste af vores energi på at reducere tab, tager vi i sidste ende hensyn til det overskud, der er steget takket være de opnåede besparelser.

Disse besparelser falder i samme lomme som de øvrige faktorer og forbliver kun tilgængelige for de mest nysgerrige. På den måde mister vi fokus og udelader utilsigtet en masse værdifulde data og i sidste ende intelligens.

Erfaringer fra fejltagelser

At lære af sine egne fejl er en særlig nyttig (men dyr) færdighed, men den organisationskultur og det diplomati, der er indlejret i denne evne, hjælper ikke altid. Vi skjuler ofte de negative konsekvenser af økonomien med "røgslør". Når en investor råber "Jeg har tabt mine penge!", kommunikerer manageren det til de andre. hold ved at sige "vi burde være mere effektive", og vi leder alle som standard efter nye løsninger og forbedringer - i stedet for at se tilbage er vi konstant på udkig efter måder at komme videre på.

I mellemtiden er tab ofte nøglen til at drage de rigtige konklusioner. Hvis vi gennemgår de enkelte trin i processen uden at tænke os ordentligt om, vil de næste løsninger højst sandsynligt blive inficeret med de samme fejl.

Et eksempel: 

Et lille team af senior JS-udviklere leverer ikke funktionalitet inden for den forventede tid. Investoren, som ønsker at fremskynde udviklingen, beordrer, at der skal ansættes en ny programmør. At introducere en ny person til projektet vil distrahere teamet, hvilket bremser projektets fremskridt yderligere.

Hvis investoren bedre kunne forstå årsagerne til teamets ineffektivitet, ville han konkludere, at det kun udnytter sit potentiale i 60-70%. Bedre udstyr og et par arbejdsdage afsat til automatisering af arbejdet ville løse problemet.

Desværre skal han nu betale for en anden udvikler, som skal arbejde på det samme udstyr, og hans effektivitet vil også ligge på 60-70%.

Løsning A:

• Team (2 x senior JS dev): $20k / måned
• Sky tjenester: 200$ / måned
• Ny hardware til udviklere: $10k

Fra nu af koster projektet $20.200 / måned

Samlet forbrug på 12 måneder: 12 * 20.200 + 10.000 = $252.400

Løsning B:

• Team (2 x senior JS dev): $20k / måned
• Ny udvikler (1 x senior JS-udvikler): $10k / måned

Fra nu af koster projektet: $30.000 / måned

Samlet forbrug på 12 måneder: 12 * 30.000 = $360.000

To udviklere, der arbejder på 100%, gør nogenlunde det samme som tre udviklere, der arbejder på 60-70%. Investoren betaler over $ 100.000 mere for den samme behandlingskapacitet pr. år på grund af en forkert designbeslutning!

At bygge et perfekt produkt er som at jage en kanin

Agilitet i processen betyder ikke nødvendigvis, at man skal stræbe efter 100% testdækning eller slå præstationsrekorden. Mens disse målinger giver et overblik over projektets tekniske tilstand, er de så ubetydelige set fra slutkundens perspektiv, at det ikke er nødvendigt at bringe dem til en ideel tilstand i en virkelig agil proces, da de ikke giver reelle fordele. marked værdi.

Udvikling af perfekte tekniske løsninger kræver et stort team-engagement og meget mere omfattende kommunikation. Resultatet er, at patches arbejder langsommere, og at projektet bliver tungt på grund af overudvikling.

Agil udvikling handler om at levere en fungerende Kode med en minimal indsats. Kodetestning er uden tvivl en god praksis, og testene siger meget om, hvordan koden fungerer, men de bør ikke udføres bare for at udføre dem og prale af det - den optimale tekniske kvalitet af løsninger ligger et sted mellem det minimum, der bestemmes af Udviklingsteam og det maksimale, der er begrænset af budgettet.

I sidste ende kommer man ingen vegne med perfektion. Interessant nok er selv spørgsmålet om sikkerhed underlagt denne regel - teoretisk set kan ethvert system hackes. Men det førnævnte udviklingsminimum skal være tilsvarende højere og relevant for vægten, omfanget og omkostningerne ved de potentielle konsekvenser af kodefejl. I stedet for at skrive login-modulet fra bunden, som altid er belastet med en høj risiko for fejl og indførelse af sikkerhedshuller, er det ofte bedre at bruge f.eks. knappen "Log ind med Google", hvis korrekte implementering er relativt hurtig og sikker.

Så længe målet er en kort time-to-market, vil alt for ambitiøse antagelser vise sig at være kontraproduktive. I en tilsyneladende perfekt proces kan overentusiasme være spild af ressourcer.

Det er godt at vide alt om noget og noget om alt

Brugercentreret design er cool. Menneskecentreret samarbejde er vigtigere. Når teamet kommunikerer på samme bølgelængde, kan det spontant reducere yderligere potentielle tab.

En UX-designer, der er opdateret med frontend-teknologier, vil ikke foreslå en løsning på MVP fase, der vil tage urimelig lang tid i implementeringsfasen.

En frontend-udvikler, der kender til brugervenlighedsheuristik, vil være i stand til at justere grænsefladen til en given skærmopløsning uden at involvere UX-designeren - quick fix, preview, accept.

Arbejdet med en applikation kræver synkronisering af aktiviteter fra mennesker med helt forskellige kompetenceprofiler. Du er nødt til at kende fordelingen af færdigheder i dit team for effektivt at kunne levere værdi til dine kunder.

Et engageret og synkroniseret team er en vigtig kilde til besparelser. Denne type agilitet kræver optimal produktudvikling.

God teampræstation forstået på denne måde er overordentlig vanskelig at opnå, især i en tid med fjernarbejde. Virksomheder, der har været "fjernvenlige" i årevis, har en betydelig fordel på dette område i forhold til dem, der har været tvunget til at indstille organisationen under nedlukningen og først nu er ved at lære om nye metoder og former for kommunikation.

Kraftigt udstyr, før du går i gang

I forbindelse med de voksende kommunikationsbehov har værktøjer som Whimsical, Miro, Mural, Figma og Balsamiq oplevet en imponerende stigning i popularitet.

Nedlukningen og behovet for at arbejde på afstand har helt sikkert spillet en rolle i denne eksplosion af brugere. Jeg mener, at valget af værktøj skal matche individuelle præferencer, men lad os se på Miro:

Popularisering af sådanne værktøjer driver naturligvis stigningen i populariteten af selve metoderne. En person, der har købt Miro til at arbejde med personaer, får adgang til dusinvis af andre skabeloner, som kan vise sig at være interessante og påvirke teamets daglige arbejde positivt.

Du bør altid udstyre dig med værktøjer, der kan strømline informationsstrømmen i projektet. Åbenhed over for nye værktøjer og metoder er også et af fundamenterne for effektiv produktudvikling.

Du kan (og bør) være doven

Erfarne designere af både grænsefladen og softwarearkitekturen opdager normalt flere potentielle løsninger, som bør verificeres i begyndelsen af samarbejdet, og leder effektivt efter passende inspiration eller endda færdige løsninger på markedet. Et godt eksempel er Material UI-frameworket, som normalt er et sikkert valg på prototypestadiet..

Nogle gange er det nok at gennemgå et par implementeringer på Behance eller Dribble og bruge inspirationen til at udvikle et moodboard og derefter sende det til udvikleren. Denne person vil bruge det til at sammensætte en klikbar prototype, der kan præsenteres for tidlige brugere for at indsamle feedback. Denne organiske stræben efter en effektiv proces hos designmindede og engagerede mennesker er naturlig.

Hvis du vil levere digitale produkter effektivt, er du nødt til at lade folk gøre deres arbejde. Du ved, hvilken værdi/service du vil levere til dine kunder - det er nok. Et kompetent og veldrevet projektteam ved bedst, hvordan man leverer denne værdi/service så hurtigt som muligt med den nødvendige omkostningseffektivitet.

Vis din tillid, del ansvaret og åbn op for en ægte tovejskommunikation, så din produkt vil være bedre, og byrden ved at skulle klare det hele selv vil være væk fra dine skuldre, hvilket ofte viser sig at være en drænende tur for grundlæggere og iværksættere! På CodestVi omsætter dette princip ikke kun til projekter, men også til interne processer - det er sandsynligvis derfor, vi har en høj fastholdelsesgrad for både kunder og medarbejdere (sand historie, begge dele> 90%).

Forkæl dig selv med lidt dovenskab, overfør modigt ansvar og giv slip på alt overflødigt arbejde, der ikke er nødvendigt for at komme videre - funktioner, der ville være "nice to have", kan altid vente.

Fokus på at finde de rigtige svar

Processen med at skabe et digitalt produkt er en konstant kollision mellem forskellige perspektiver, erfaringer og informationskilder - og hver af disse kollisioner indebærer en risiko for at træffe en forkert designbeslutning.

God intern kommunikation reducerer denne risiko, men det er kun den ene side af sagen. Spørgsmålet om, hvordan man holder sig i kontakt med markedet, er endnu ikke besvaret.

Business Intelligence, kundesupport, UX-forskningsafdelinger og mange andre - ligesom de udviklingsteambør de stræbe efter det minimum, der er nødvendigt for at give specifikke svar på spørgsmål, som stilles af produktejeren eller UX-teamet.

Selve brandingen og brandkommunikationsstrategien er også vigtig. De tjener til at opbygge et kvalitativt forhold til kunderne, som så udmønter sig i deres engagement. Hvis du vil stille spørgsmål til kunderne, skal du sørge for, at de er villige til at besvare disse spørgsmål. Tonen i din stemme betyder noget.

Det er helt sikkert, at man ved at være i konstant kontakt med markedet kan definere den rigtige kurs for projektet og få det til at flyve. Mindre indlysende er det, at behovet for denne kontakt skal overvejes helt fra begyndelsen af projektet, hvor man skal forudse de rigtige kompetencer i teamet (til at stille de rigtige spørgsmål og besvare dem) og opbygge en produktstrategi, der vil involvere målgrupperne.

Konklusioner

I betragtning af alle de ovennævnte spørgsmål kan vi observere flere problemer, som jævnligt dukker op i designprocessen:

- at være alt for profitorienteret og undgå at se på fiaskoer,

- unøjagtighed og ikke røntgenfotografering af egne fejl,

- At jagte et perfekt produkt, som du har i dit hoved, men som ikke er det, markedet har brug for,

- overivrig implementering af lærebogsprocesser - overudvikling og overdesign,

- ufleksibelt teamwork og tvinger medarbejderne til kun at blive inden for deres specialområder,

- ineffektiv kommunikation,

- tendens til at genopfinde hjulet.

Procesoptimering på makroniveau omfatter summen af besparelser. For at imødegå de ovennævnte udfordringer skal du involvere dine kolleger, så de åbent fremlægger ideer til forbedring af processen.

Nogle gange er det nok at tale mindre og lytte mere opmærksomt til underordnede, kunder og partnere - i overensstemmelse med den enkeltes rolle og ansvar - for at opnå succes.

Når du ikke er helt nok, overinvesterer du højst sandsynligt.. Har du for mange penge?

Hold kæft og tag dine penge! Og i øvrigt:

1. Indfør ikke Scrum bare for at øve Scrum.
2. Vær mere opmærksom på fejl i processen.
3. Sæt mindre mål, som er opnåelige og målbare på kort sigt - hold dig generelt til et minimum.
4. Nogle gange er en god køreplan er nok til at give teamet en fornemmelse af et fælles mål og engagere dem i effektivt arbejde her og nu.
5. Opbyg et godt team for at kunne give det den frihed, det har brug for.
6. Sæt altid spørgsmålstegn ved det nuværende sæt værktøjer - søg efter mulige forbedringer i dit værksted.
7. Design processen ud fra den dovne persons perspektiv - som om du vil gøre så lidt som muligt.

Læs mere om det:

CTO-udfordringer - opskalering og vækst af softwareprodukter

Hvilken DB skal du vælge til din specifikke datatype i dit softwareprojekt?