GÅ TILBAKE
Jakten på enhjørninger er en fordømt dyr hobby. Hvert år spiser oppstartsbedrifter opp milliarder slik at bare én av titalls eller hundrevis kan tjene millioner. Gründere og produkteiere samler inn penger fra investorer og ofrer sin uavhengighet for å erobre markedet raskere. Til syvende og sist skaffer de imidlertid ikke nok midler mesteparten av tiden. Kanskje det var riktig å si "hold kjeft og ta pengene dine" i det rette øyeblikket?
Kontanter styrer alt rundt meg. Selv de mest turkise organisasjonene kan ikke benekte det. Utviklingen av prosjekt ledelsesmetoder, prosessjustering og -optimalisering eller ansattes motivasjon utløses i bunn og grunn av det universelle behovet for penger. Smidig design innebærer en viss risiko.
Vi ønsker alle å være slanke og smidig slik at resultatet av aktivitetene våre, målt i tall, blir så høyt som mulig. Selv om vi bruker mest energi på å redusere tapene, tar vi til slutt hensyn til overskuddet som har økt takket være besparelsene vi har generert.
Disse besparelsene faller i samme lomme som de resterende faktorene og forblir bare tilgjengelige for de mest nysgjerrige. På denne måten mister vi fokus og utelater utilsiktet mye verdifull informasjon og til syvende og sist intelligens.
Å lære av egne feil er en spesielt nyttig (om enn kostbar) ferdighet, men den organisasjonskultur og diplomatiet som ligger i denne evnen, hjelper ikke alltid. Vi skjuler ofte de negative konsekvensene av økonomien med "røykteppe"-ord. Når en investor roper "Jeg har tapt pengene mine!", kommuniserer forvalteren det til team Vi sier "vi burde være mer effektive", og vi leter alle som standard etter nye løsninger og forbedringer - i stedet for å se oss tilbake, leter vi hele tiden etter måter å komme videre på.
Samtidig er tap ofte nøkkelen til å trekke de riktige konklusjonene. Hvis vi går over enkelte trinn i prosessen uten å tenke oss godt nok om, vil de neste løsningene mest sannsynlig være infisert av de samme feilene.
Eksempel:
Et lite team av erfarne JS-utviklere klarer ikke å levere funksjonalitet innen forventet tid. Investoren, som ønsker å fremskynde utviklingen, beordrer å ansette en ny programmerer. Når en ny person introduseres i prosjektet, vil det distrahere teamet, noe som bremser fremdriften i prosjektet ytterligere.
Hvis investoren hadde forstått årsakene til teamets ineffektivitet bedre, ville han konkludert med at det kun utnytter sitt potensial i 60-70%. Bedre utstyr og noen få arbeidsdager til automatisering av arbeidet ville løst problemet.
Dessverre må han nå betale for en annen utvikler som skal jobbe med det samme utstyret, og effektiviteten hans vil også ligge på 60-70%.
Løsning A:
Fra nå av koster prosjektet $20 200 / måned
Totale utgifter i løpet av 12 måneder: 12 * 20 200 + 10 000 = $252 400
Løsning B:
Fra nå av koster prosjektet: $30 000 / måned
Totale utgifter i løpet av 12 måneder: 12 * 30 000 = $360 000
To utviklere som jobber på 100% gjør omtrent det samme som tre utviklere som jobber på 60-70%. Investoren betaler over 100 000TP60T mer for samme prosesseringskapasitet per år på grunn av en feilaktig designbeslutning!
Smidighet i prosessen betyr ikke nødvendigvis at man skal strebe etter 100% testdekning eller slå ytelsesrekorden. Selv om disse måltallene gir en oversikt over prosjektets tekniske tilstand, er de så ubetydelige sett fra sluttkundens perspektiv at det ikke er nødvendig å bringe dem til en ideell tilstand i en virkelig smidig prosess, ettersom de ikke gir noen reell marked verdi.
Å utvikle perfekte tekniske løsninger krever mye engasjement fra teamet og mye mer omfattende kommunikasjon. Resultatet er at oppdateringene går tregere, og prosjektet blir tungt på grunn av overutvikling.
Smidig utvikling handler om å levere en fungerende kode med minimal innsats. Kodetesting er utvilsomt en god praksis, og testene sier mye om hvordan koden fungerer, men de bør ikke gjøres bare for å gjøre dem og skryte av det - den optimale tekniske kvaliteten på løsningene ligger et sted mellom det minimum som er bestemt av utviklingsteam og det maksimale som er begrenset av budsjettet.
Til syvende og sist kommer du ingen vei med perfeksjon. Interessant nok er til og med sikkerhetsspørsmålet underlagt denne regelen - i teorien kan ethvert system hackes. Imidlertid må det nevnte utviklingsminimumet være tilsvarende høyere og relevant for vekten, omfanget og kostnadene ved potensielle konsekvenser av kodeuhell. Ofte, i stedet for å skrive påloggingsmodulen fra bunnen av, som alltid er belastet med høy risiko for feil og innføring av sikkerhetsproblemer, er det bedre å bruke for eksempel "Logg på med Google" -knappen, hvis riktig implementering er relativt rask og sikker.
Så lenge målet er kort tid til markedet, vil overambisiøse antakelser virke mot sin hensikt. I en tilsynelatende perfekt prosess kan overentusiasme være sløsing med ressurser.
Brukersentrert design er kult. Menneskesentrert samarbeid er viktigere. Når teamet kommuniserer på samme bølgelengde, kan det spontant redusere ytterligere potensielle tap.
En UX-designer som er oppdatert på frontend-teknologier, vil ikke foreslå en løsning på MVP fase som vil ta urimelig mye tid i gjennomføringsfasen.
En frontend-utvikler som kjenner til heuristikk for brukervennlighet, vil kunne tilpasse grensesnittet til en gitt skjermoppløsning uten å involvere UX-designeren - quick fix, forhåndsvisning, aksept.
Arbeidet med en applikasjon krever synkronisering av aktiviteter fra personer med helt ulike kompetanseprofiler. For å kunne levere verdi til kundene på en effektiv måte, må du vite hvordan kompetansen i teamet ditt er fordelt.
Gode teamprestasjoner forstått på denne måten er svært vanskelig å oppnå, spesielt i en tid med fjernarbeid. Bedrifter som har vært "fjernstyringsvennlige" i årevis, har en betydelig fordel på dette feltet i forhold til de som har blitt tvunget til å tilpasse organisasjonen under nedstengningen og først nå er i ferd med å lære seg nye metoder og kommunikasjonsformer.
I forbindelse med de økende kommunikasjonsbehovene har verktøy som Whimsical, Miro, Mural, Figma og Balsamiq registrert en imponerende økning i popularitet.
Nedstengningen og behovet for å jobbe eksternt har helt klart spilt en rolle i denne eksplosjonen av brukere. Jeg mener at valget av verktøy bør tilpasses individuelle preferanser, men la oss ta en titt på Miro:
Populariseringen av slike verktøy fører naturlig nok til at metodene i seg selv øker i popularitet. Den som har kjøpt Miro for å jobbe med personas, får tilgang til dusinvis av andre maler som kan vise seg å være interessante og ha en positiv innvirkning på teamets daglige arbeid.
Du bør alltid utstyre deg med verktøy som effektiviserer informasjonsflyten i prosjektet. Åpenhet for nye verktøy og metoder er også en av grunnpilarene i effektiv produktutvikling.
Erfarne designere av både grensesnitt og programvarearkitektur ser vanligvis flere potensielle løsninger som bør verifiseres i begynnelsen av samarbeidet, og leter effektivt etter passende inspirasjon eller til og med ferdige løsninger på markedet. Et godt eksempel er Material UI-rammeverket, som vanligvis er et trygt valg på prototypstadiet.
Noen ganger er det nok å se gjennom noen få implementeringer på Behance eller Dribble og bruke inspirasjonen til å utvikle et moodboard og deretter sende det til utvikleren. Denne personen vil bruke det til å sette sammen en klikkbar prototype som kan presenteres for tidlige brukere for å innhente tilbakemeldinger. Denne organiske streben etter en effektiv prosess hos designorienterte og engasjerte mennesker er naturlig.
Hvis du vil levere digitale produkter på en effektiv måte, må du la folk gjøre jobben sin. Du vet hvilken verdi/tjeneste du ønsker å levere til kundene dine - det er nok. Et kompetent og godt ledet prosjektteam vet best hvordan denne verdien/tjenesten kan leveres så raskt som mulig med nødvendig kostnadseffektivitet.
Vis tillit, del ansvaret og åpne opp for en ekte toveiskommunikasjon, slik at dere kan produkt vil bli bedre, og du slipper å tenke på å gjøre alt selv, noe som ofte kan være en slitsom opplevelse for gründere og entreprenører! På The CodestDette prinsippet omsetter vi ikke bare i prosjekter, men også i interne prosesser - det er sannsynligvis grunnen til at vi har en høy grad av lojalitet blant både kunder og ansatte (sann historie, begge deler> 90%).
Unn deg selv litt latskap, overfør ansvar og gi slipp på overflødig arbeid som ikke er nødvendig for å komme videre - funksjonaliteter som er "kjekke å ha" kan alltid vente.
Prosessen med å skape et digitalt produkt er en konstant kollisjon mellom ulike perspektiver, erfaringer og informasjonskilder - og hver slik kollisjon innebærer en risiko for å ta feil designbeslutning.
God internkommunikasjon reduserer denne risikoen, men det er bare én side av saken. Spørsmålet om hvordan man holder kontakten med markedet, er ennå ikke besvart.
Business Intelligence, Customer Support, UX research departments and many others – just like the utviklingsteam, they should strive for the minimum necessary to provide specific answers to questions asked by the product owner or the UX team.
Selve merkevarebyggingen og kommunikasjonsstrategien er også viktig. De tjener til å bygge et kvalitativt forhold til kundene, noe som igjen fører til at de forplikter seg. Hvis du ønsker å stille spørsmål til kundene, bør du sørge for at de er villige til å svare på disse spørsmålene. Tonen i stemmen din er viktig.
Det er ingen tvil om at det å være i konstant kontakt med markedet gjør det mulig å definere de riktige veiene for prosjektet for å få det til å fly. Mindre opplagt er det at behovet for denne kontakten bør vurderes helt i begynnelsen av prosjektet, for å forutse riktig kompetanse i teamet (for å stille de riktige spørsmålene og svare på dem) og for å bygge en produktstrategi som involverer målgruppene.
Med tanke på alle de ovennevnte problemstillingene kan vi observere flere problemer som regelmessig dukker opp i designprosessen:
- å være overdrevent profittorientert og unngå å se på feil,
- unøyaktighet og ikke røntgen av egne feil,
- å jakte på et perfekt produkt som du har i hodet, men som ikke er det markedet trenger,
- overivrig implementering av lærebokprosesser - overutvikling og overdesign,
- ufleksibelt teamarbeid og tvinger de ansatte til å holde seg til sine spesialiseringsområder,
- ineffektiv kommunikasjon,
- tendens til å finne opp hjulet på nytt.
Prosessoptimalisering på makronivå omfatter summen av besparelser. For å møte de ovennevnte utfordringene på en god måte må du involvere kollegene dine slik at de åpent kan komme med ideer til hvordan prosessen kan forbedres.
Noen ganger er det nok å snakke mindre og lytte mer til underordnede, kunder og samarbeidspartnere - i henhold til den enkeltes rolle og ansvar - for å oppnå suksess.
Når du ikke er helt nok, overinvesterer du mest sannsynlig. Har du for mye penger?
Les mer om dette:
CTO-utfordringer - oppskalering og vekst av programvareprodukter
Hvilken DB skal du velge for den spesifikke datatypen i programvareprosjektet ditt?
Norwegian 
English 
German 
Swedish 
Danish 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Dutch