![\"tidseffektivitet\"](\"\/app\/uploads\/2024\/05\/1tR8fGHRhmgTIZqb1ad_X-Q.jpeg\" "\\"tidseffektivitet\\"")
<\/p>\n
Vi \u00f8nsker alle \u00e5 v\u00e6re slanke og smidig<\/a> slik at resultatet av aktivitetene v\u00e5re, m\u00e5lt i tall, blir s\u00e5 h\u00f8yt som mulig. Selv om vi bruker mest energi p\u00e5 \u00e5 redusere tapene, tar vi til slutt hensyn til overskuddet som har \u00f8kt takket v\u00e6re besparelsene vi har generert.<\/p>\n Disse besparelsene havner i samme lomme som de \u00f8vrige faktorene, og forblir bare tilgjengelige for de mest nysgjerrige. P\u00e5 denne m\u00e5ten mister vi fokus og utelater utilsiktet mye verdifullt data<\/a> og til syvende og sist intelligens.<\/p>\n \u00c5 l\u00e6re av egne feil er en spesielt nyttig (om enn kostbar) ferdighet, men den organisasjonskultur<\/a> og diplomatiet som ligger i denne evnen, hjelper ikke alltid. Vi skjuler ofte de negative konsekvensene av \u00f8konomien med \"r\u00f8ykteppe\"-ord. N\u00e5r en investor roper \"Jeg har tapt pengene mine!\", kommuniserer forvalteren det til team<\/a> Vi sier \"vi burde v\u00e6re mer effektive\", og vi leter alle som standard etter nye l\u00f8sninger og forbedringer - i stedet for \u00e5 se oss tilbake, leter vi hele tiden etter m\u00e5ter \u00e5 komme videre p\u00e5.<\/p>\n Samtidig er tap ofte n\u00f8kkelen til \u00e5 trekke de riktige konklusjonene. Hvis vi g\u00e5r over enkelte trinn i prosessen uten \u00e5 tenke oss godt nok om, vil de neste l\u00f8sningene mest sannsynlig v\u00e6re infisert av de samme feilene.<\/p>\n Eksempel:<\/em><\/strong>\u00a0<\/p>\n Et lite team av senior JS<\/a> utviklerne ikke leverer funksjonalitet innen forventet tid. Investoren, som \u00f8nsker \u00e5 fremskynde utviklingen, beordrer \u00e5 ansette en ny programmerer. N\u00e5r en ny person introduseres i prosjektet, vil det distrahere teamet, noe som bremser fremdriften i prosjektet ytterligere.<\/p>\n Hvis investoren hadde forst\u00e5tt \u00e5rsakene til teamets ineffektivitet bedre, ville han konkludert med at det kun utnytter sitt potensial i 60-70%. Bedre utstyr og noen f\u00e5 arbeidsdager til automatisering av arbeidet ville l\u00f8st problemet.<\/p>\n Dessverre m\u00e5 han n\u00e5 betale for en annen utvikler som skal jobbe med det samme utstyret, og effektiviteten hans vil ogs\u00e5 ligge p\u00e5 60-70%.<\/p>\n L\u00f8sning A:<\/strong><\/p>\n \nFra n\u00e5 av koster prosjektet $20 200 \/ m\u00e5ned<\/p>\n Totale utgifter i l\u00f8pet av 12 m\u00e5neder: 12 * 20 200 + 10 000 = $252 400<\/p>\n L\u00f8sning B:<\/strong><\/p>\n \nFra n\u00e5 av koster prosjektet: $30 000 \/ m\u00e5ned<\/p>\n Totale utgifter i l\u00f8pet av 12 m\u00e5neder: 12 * 30 000 = $360 000<\/p>\n To utviklere som jobber p\u00e5 100% gj\u00f8r omtrent det samme som tre utviklere som jobber p\u00e5 60-70%. Investoren betaler over 100 000TP60T mer for samme prosesseringskapasitet per \u00e5r p\u00e5 grunn av en feilaktig designbeslutning!<\/p>\n Smidighet i prosessen betyr ikke n\u00f8dvendigvis at man skal strebe etter 100% testdekning eller sl\u00e5 ytelsesrekorden. Selv om disse m\u00e5ltallene gir en oversikt over prosjektets tekniske tilstand, er de s\u00e5 ubetydelige sett fra sluttkundens perspektiv at det ikke er n\u00f8dvendig \u00e5 bringe dem til en ideell tilstand i en virkelig smidig prosess, ettersom de ikke gir noen reell marked<\/a> verdi.<\/p>\n \u00c5 utvikle perfekte tekniske l\u00f8sninger krever mye engasjement fra teamet og mye mer omfattende kommunikasjon. Resultatet er at oppdateringene g\u00e5r tregere, og prosjektet blir tungt p\u00e5 grunn av overutvikling.<\/p>\n Smidig utvikling<\/a> handler om \u00e5 levere en fungerende kode<\/a> med minimal innsats. Kodetesting er utvilsomt en god praksis, og testene sier mye om hvordan koden fungerer, men de b\u00f8r ikke gj\u00f8res bare for \u00e5 gj\u00f8re dem og skryte av det - den optimale tekniske kvaliteten p\u00e5 l\u00f8sningene ligger et sted mellom det minimum som er bestemt av utviklingsteam<\/a> og det maksimale som er begrenset av budsjettet.<\/p>\n Til syvende og sist kommer du ingen vei med perfeksjon. Interessant nok er til og med sikkerhetssp\u00f8rsm\u00e5let underlagt denne regelen - i teorien kan ethvert system hackes. Imidlertid m\u00e5 det nevnte utviklingsminimumet v\u00e6re tilsvarende h\u00f8yere og relevant for vekten, omfanget og kostnadene ved potensielle konsekvenser av kodeuhell. Ofte, i stedet for \u00e5 skrive p\u00e5loggingsmodulen fra bunnen av, som alltid er belastet med h\u00f8y risiko for feil og innf\u00f8ring av sikkerhetsproblemer, er det bedre \u00e5 bruke for eksempel \"Logg p\u00e5 med Google\" -knappen, hvis riktig implementering er relativt rask og sikker.<\/p>\n S\u00e5 lenge m\u00e5let er kort tid til markedet, vil overambisi\u00f8se antakelser virke mot sin hensikt. I en tilsynelatende perfekt prosess kan overentusiasme v\u00e6re sl\u00f8sing med ressurser<\/a>.<\/p>\n Brukersentrert design er kult. Menneskesentrert samarbeid er viktigere. N\u00e5r teamet kommuniserer p\u00e5 samme b\u00f8lgelengde, kan det spontant redusere ytterligere potensielle tap.<\/p>\n A UX<\/a> designer som er oppdatert p\u00e5 frontend-teknologier, vil ikke foresl\u00e5 en l\u00f8sning p\u00e5 MVP<\/a> fase som vil ta urimelig mye tid i gjennomf\u00f8ringsfasen.<\/p>\n En frontend-utvikler som kjenner til heuristikk for brukervennlighet, vil kunne tilpasse grensesnittet til en gitt skjermoppl\u00f8sning uten \u00e5 involvere UX-designeren - quick fix, forh\u00e5ndsvisning, aksept.<\/p>\n Arbeidet med en applikasjon krever synkronisering av aktiviteter fra personer med helt ulike kompetanseprofiler. For \u00e5 kunne levere verdi til kundene p\u00e5 en effektiv m\u00e5te, m\u00e5 du vite hvordan kompetansen i teamet ditt er fordelt.<\/p>\n Et engasjert og synkronisert team er en viktig kilde til besparelser. Denne typen smidighet krever optimal produktutvikling<\/a>.<\/p>\n Gode teamprestasjoner forst\u00e5tt p\u00e5 denne m\u00e5ten er sv\u00e6rt vanskelig \u00e5 oppn\u00e5, spesielt i en tid med fjernarbeid<\/a>. Bedrifter som har v\u00e6rt \"fjernstyringsvennlige\" i \u00e5revis, har en betydelig fordel p\u00e5 dette feltet i forhold til de som har blitt tvunget til \u00e5 tilpasse organisasjonen under nedstengningen og f\u00f8rst n\u00e5 er i ferd med \u00e5 l\u00e6re seg nye metoder og kommunikasjonsformer.<\/p>\n I forbindelse med de \u00f8kende kommunikasjonsbehovene har verkt\u00f8y som Whimsical, Miro, Mural, Figma og Balsamiq registrert en imponerende \u00f8kning i popularitet.<\/p>\n Nedstengningen og behovet for \u00e5 jobbe eksternt har helt klart spilt en rolle i denne eksplosjonen av brukere. Jeg mener at valget av verkt\u00f8y b\u00f8r tilpasses individuelle preferanser, men la oss ta en titt p\u00e5 Miro:<\/p>\n Populariseringen av slike verkt\u00f8y f\u00f8rer naturlig nok til at metodene i seg selv \u00f8ker i popularitet. Den som har kj\u00f8pt Miro for \u00e5 jobbe med personas, f\u00e5r tilgang til dusinvis av andre maler som kan vise seg \u00e5 v\u00e6re interessante og ha en positiv innvirkning p\u00e5 teamets daglige arbeid.<\/p>\n Du b\u00f8r alltid utstyre deg med verkt\u00f8y som effektiviserer informasjonsflyten i prosjektet. \u00c5penhet for nye verkt\u00f8y og metoder er ogs\u00e5 en av grunnpilarene i effektiv produktutvikling<\/a>.<\/p>\n Erfarne designere av b\u00e5de grensesnittet og programvarearkitektur<\/a> vanligvis flere potensielle l\u00f8sninger som b\u00f8r verifiseres i begynnelsen av samarbeidet, og leter effektivt etter passende inspirasjon eller til og med ferdige l\u00f8sninger p\u00e5 markedet. Et godt eksempel er Material UI-rammeverket, som vanligvis er et trygt valg p\u00e5 prototypstadiet<\/a>.<\/p>\n Noen ganger er det nok \u00e5 se gjennom noen f\u00e5 implementeringer p\u00e5 Behance eller Dribble og bruke inspirasjonen til \u00e5 utvikle et moodboard og deretter sende det videre til utvikleren. Denne personen vil bruke det til \u00e5 sette sammen et klikkbart prototype<\/a> som kan presenteres for tidlige brukere for \u00e5 innhente tilbakemeldinger. Det er naturlig at designorienterte og engasjerte mennesker streber etter en effektiv prosess.<\/p>\n Hvis du vil levere digitale produkter p\u00e5 en effektiv m\u00e5te, m\u00e5 du la folk gj\u00f8re jobben sin. Du vet hvilken verdi\/tjeneste du \u00f8nsker \u00e5 levere til kundene dine - det er nok. Et kompetent og godt ledet prosjektteam vet best hvordan denne verdien\/tjenesten kan leveres s\u00e5 raskt som mulig med n\u00f8dvendig kostnadseffektivitet.<\/p>\n Vis tillit, del ansvaret og \u00e5pne opp for en ekte toveiskommunikasjon, slik at dere kan produkt<\/a> vil bli bedre, og du slipper \u00e5 tenke p\u00e5 \u00e5 gj\u00f8re alt selv, noe som ofte kan v\u00e6re en slitsom opplevelse for gr\u00fcndere og entrepren\u00f8rer! P\u00e5 The Codest<\/a>Dette prinsippet omsetter vi ikke bare i prosjekter, men ogs\u00e5 i interne prosesser - det er sannsynligvis grunnen til at vi har en h\u00f8y grad av lojalitet blant b\u00e5de kunder og ansatte (sann historie, begge deler> 90%).<\/p>\n Unn deg selv litt latskap, overf\u00f8r ansvar og gi slipp p\u00e5 overfl\u00f8dig arbeid som ikke er n\u00f8dvendig for \u00e5 komme videre - funksjonaliteter som er \"kjekke \u00e5 ha\" kan alltid vente.<\/p>\n Prosessen med \u00e5 skape et digitalt produkt er en konstant kollisjon mellom ulike perspektiver, erfaringer og informasjonskilder - og hver slik kollisjon inneb\u00e6rer en risiko for \u00e5 ta feil designbeslutning.<\/p>\n God internkommunikasjon reduserer denne risikoen, men det er bare \u00e9n side av saken. Sp\u00f8rsm\u00e5let om hvordan man holder kontakten med markedet, er enn\u00e5 ikke besvart.<\/p>\n Business Intelligence, kundesupport, UX-forskningsavdelinger og mange andre - akkurat som utviklingsteam<\/a>b\u00f8r de strekke seg s\u00e5 langt som mulig for \u00e5 gi konkrete svar p\u00e5 sp\u00f8rsm\u00e5l som stilles av produkteieren eller UX-teamet.<\/p>\n Selve merkevarebyggingen og kommunikasjonsstrategien er ogs\u00e5 viktig. De tjener til \u00e5 bygge et kvalitativt forhold til kundene, noe som igjen f\u00f8rer til at de forplikter seg. Hvis du \u00f8nsker \u00e5 stille sp\u00f8rsm\u00e5l til kundene, b\u00f8r du s\u00f8rge for at de er villige til \u00e5 svare p\u00e5 disse sp\u00f8rsm\u00e5lene. Tonen i stemmen din er viktig.<\/p>\n Det er ingen tvil om at det \u00e5 v\u00e6re i konstant kontakt med markedet gj\u00f8r det mulig \u00e5 definere de riktige veiene for prosjektet for \u00e5 f\u00e5 det til \u00e5 fly. Mindre opplagt er det at behovet for denne kontakten b\u00f8r vurderes helt i begynnelsen av prosjektet, for \u00e5 forutse riktig kompetanse i teamet (for \u00e5 stille de riktige sp\u00f8rsm\u00e5lene og svare p\u00e5 dem) og for \u00e5 bygge en produktstrategi som involverer m\u00e5lgruppene.<\/p>\n Med tanke p\u00e5 alle de ovennevnte problemstillingene kan vi observere flere problemer som regelmessig dukker opp i designprosessen:<\/p>\n - \u00e5 v\u00e6re overdrevent profittorientert og unng\u00e5 \u00e5 se p\u00e5 feil,<\/p>\n - un\u00f8yaktighet og ikke r\u00f8ntgen av egne feil,<\/p>\n - \u00e5 jakte p\u00e5 et perfekt produkt som du har i hodet, men som ikke er det markedet trenger,<\/p>\n - overivrig implementering av l\u00e6rebokprosesser - overutvikling og overdesign,<\/p>\n - ufleksibelt teamarbeid og tvinger de ansatte til \u00e5 holde seg til sine spesialiseringsomr\u00e5der,<\/p>\n - ineffektiv kommunikasjon,<\/p>\n - tendens til \u00e5 finne opp hjulet p\u00e5 nytt.<\/p>\n Prosessoptimalisering p\u00e5 makroniv\u00e5 omfatter summen av besparelser. For \u00e5 m\u00f8te de ovennevnte utfordringene p\u00e5 en god m\u00e5te m\u00e5 du involvere kollegene dine slik at de \u00e5pent kan komme med ideer til hvordan prosessen kan forbedres.<\/p>\n Noen ganger er det nok \u00e5 snakke mindre og lytte mer til underordnede, kunder og samarbeidspartnere - i henhold til den enkeltes rolle og ansvar - for \u00e5 oppn\u00e5 suksess.<\/p>\n N\u00e5r du ikke er helt nok, overinvesterer du mest sannsynlig<\/a>. Har du for mye penger?<\/p>\n Les mer om dette:<\/strong><\/p>\n CTO-utfordringer - oppskalering og vekst av programvareprodukter<\/a><\/p>\nL\u00e6rdom fra feil<\/h2>\n
\n
\n
\u00c5 bygge et perfekt produkt er som \u00e5 jakte p\u00e5 kaninen<\/h2>\n
Det er godt \u00e5 vite alt om noe og noe om alt<\/h2>\n
Kraftig utstyr f\u00f8r du g\u00e5r i gang<\/h2>\n
![\"Miro\"](\"\/app\/uploads\/2024\/05\/miro.png\" "\\"Miro\\"")
<\/p>\nDu kan (og b\u00f8r) v\u00e6re lat<\/h2>\n
Fokuser p\u00e5 \u00e5 finne de riktige svarene<\/h2>\n
Konklusjoner<\/h2>\n
![\"Hold](\"\/app\/uploads\/2024\/05\/meme.png\" "\\"Hold")
<\/p>\nHold kjeft og ta pengene dine! Og dessuten..:<\/h2>\n
\n