![\"Tidseffektivitet\"](\"\/app\/uploads\/2024\/05\/1tR8fGHRhmgTIZqb1ad_X-Q.jpeg\" "\\"Tidseffektivitet\\"")
<\/p>\n
Vi vil alle gerne v\u00e6re slanke og smidig<\/a> s\u00e5 resultatet af vores aktiviteter, m\u00e5lt i tal, bliver s\u00e5 h\u00f8jt som muligt. Selv om vi bruger det meste af vores energi p\u00e5 at reducere tab, tager vi i sidste ende hensyn til det overskud, der er steget takket v\u00e6re de opn\u00e5ede besparelser.<\/p>\n Disse besparelser falder i samme lomme som de \u00f8vrige faktorer og forbliver kun tilg\u00e6ngelige for de mest nysgerrige. P\u00e5 den m\u00e5de mister vi fokus og udelader utilsigtet en masse v\u00e6rdifulde data<\/a> og i sidste ende intelligens.<\/p>\n At l\u00e6re af sine egne fejl er en s\u00e6rlig nyttig (men dyr) f\u00e6rdighed, men den organisationskultur<\/a> og det diplomati, der er indlejret i denne evne, hj\u00e6lper ikke altid. Vi skjuler ofte de negative konsekvenser af \u00f8konomien med \"r\u00f8gsl\u00f8r\". N\u00e5r en investor r\u00e5ber \"Jeg har tabt mine penge!\", kommunikerer manageren det til de andre. hold<\/a> ved at sige \"vi burde v\u00e6re mere effektive\", og vi leder alle som standard efter nye l\u00f8sninger og forbedringer - i stedet for at se tilbage er vi konstant p\u00e5 udkig efter m\u00e5der at komme videre p\u00e5.<\/p>\n I mellemtiden er tab ofte n\u00f8glen til at drage de rigtige konklusioner. Hvis vi gennemg\u00e5r de enkelte trin i processen uden at t\u00e6nke os ordentligt om, vil de n\u00e6ste l\u00f8sninger h\u00f8jst sandsynligt blive inficeret med de samme fejl.<\/p>\n Et eksempel:<\/em><\/strong>\u00a0<\/p>\n Et lille team af senior JS<\/a> udviklerne leverer ikke funktionalitet inden for den forventede tid. Investoren, som \u00f8nsker at fremskynde udviklingen, beordrer, at der skal ans\u00e6ttes en ny programm\u00f8r. At introducere en ny person til projektet vil distrahere teamet, hvilket bremser projektets fremskridt yderligere.<\/p>\n Hvis investoren bedre kunne forst\u00e5 \u00e5rsagerne 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\u00f8se problemet.<\/p>\n Desv\u00e6rre skal han nu betale for en anden udvikler, som skal arbejde p\u00e5 det samme udstyr, og hans effektivitet vil ogs\u00e5 ligge p\u00e5 60-70%.<\/p>\n L\u00f8sning A:<\/strong><\/p>\n \nFra nu af koster projektet $20.200 \/ m\u00e5ned<\/p>\n Samlet forbrug p\u00e5 12 m\u00e5neder: 12 * 20.200 + 10.000 = $252.400<\/p>\n L\u00f8sning B:<\/strong><\/p>\n \nFra nu af koster projektet: $30.000 \/ m\u00e5ned<\/p>\n Samlet forbrug p\u00e5 12 m\u00e5neder: 12 * 30.000 = $360.000<\/p>\n To udviklere, der arbejder p\u00e5 100%, g\u00f8r nogenlunde det samme som tre udviklere, der arbejder p\u00e5 60-70%. Investoren betaler over $ 100.000 mere for den samme behandlingskapacitet pr. \u00e5r p\u00e5 grund af en forkert designbeslutning!<\/p>\n Agilitet i processen betyder ikke n\u00f8dvendigvis, at man skal str\u00e6be efter 100% testd\u00e6kning eller sl\u00e5 pr\u00e6stationsrekorden. Mens disse m\u00e5linger giver et overblik over projektets tekniske tilstand, er de s\u00e5 ubetydelige set fra slutkundens perspektiv, at det ikke er n\u00f8dvendigt at bringe dem til en ideel tilstand i en virkelig agil proces, da de ikke giver reelle fordele. marked<\/a> v\u00e6rdi.<\/p>\n Udvikling af perfekte tekniske l\u00f8sninger kr\u00e6ver et stort team-engagement og meget mere omfattende kommunikation. Resultatet er, at patches arbejder langsommere, og at projektet bliver tungt p\u00e5 grund af overudvikling.<\/p>\n Agil udvikling<\/a> handler om at levere en fungerende Kode<\/a> med en minimal indsats. Kodetestning er uden tvivl en god praksis, og testene siger meget om, hvordan koden fungerer, men de b\u00f8r ikke udf\u00f8res bare for at udf\u00f8re dem og prale af det - den optimale tekniske kvalitet af l\u00f8sninger ligger et sted mellem det minimum, der bestemmes af Udviklingsteam<\/a> og det maksimale, der er begr\u00e6nset af budgettet.<\/p>\n I sidste ende kommer man ingen vegne med perfektion. Interessant nok er selv sp\u00f8rgsm\u00e5let om sikkerhed underlagt denne regel - teoretisk set kan ethvert system hackes. Men det f\u00f8rn\u00e6vnte udviklingsminimum skal v\u00e6re tilsvarende h\u00f8jere og relevant for v\u00e6gten, 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\u00f8j risiko for fejl og indf\u00f8relse af sikkerhedshuller, er det ofte bedre at bruge f.eks. knappen \"Log ind med Google\", hvis korrekte implementering er relativt hurtig og sikker.<\/p>\n S\u00e5 l\u00e6nge m\u00e5let er en kort time-to-market, vil alt for ambiti\u00f8se antagelser vise sig at v\u00e6re kontraproduktive. I en tilsyneladende perfekt proces kan overentusiasme v\u00e6re spild af ressourcer<\/a>.<\/p>\n Brugercentreret design er cool. Menneskecentreret samarbejde er vigtigere. N\u00e5r teamet kommunikerer p\u00e5 samme b\u00f8lgel\u00e6ngde, kan det spontant reducere yderligere potentielle tab.<\/p>\n A UX<\/a> designer, der er opdateret med frontend-teknologier, vil ikke foresl\u00e5 en l\u00f8sning p\u00e5 MVP<\/a> fase, der vil tage urimelig lang tid i implementeringsfasen.<\/p>\n En frontend-udvikler, der kender til brugervenlighedsheuristik, vil v\u00e6re i stand til at justere gr\u00e6nsefladen til en given sk\u00e6rmopl\u00f8sning uden at involvere UX-designeren - quick fix, preview, accept.<\/p>\n Arbejdet med en applikation kr\u00e6ver synkronisering af aktiviteter fra mennesker med helt forskellige kompetenceprofiler. Du er n\u00f8dt til at kende fordelingen af f\u00e6rdigheder i dit team for effektivt at kunne levere v\u00e6rdi til dine kunder.<\/p>\n Et engageret og synkroniseret team er en vigtig kilde til besparelser. Denne type agilitet kr\u00e6ver optimal produktudvikling<\/a>.<\/p>\n God teampr\u00e6station forst\u00e5et p\u00e5 denne m\u00e5de er overordentlig vanskelig at opn\u00e5, is\u00e6r i en tid med fjernarbejde<\/a>. Virksomheder, der har v\u00e6ret \"fjernvenlige\" i \u00e5revis, har en betydelig fordel p\u00e5 dette omr\u00e5de i forhold til dem, der har v\u00e6ret tvunget til at indstille organisationen under nedlukningen og f\u00f8rst nu er ved at l\u00e6re om nye metoder og former for kommunikation.<\/p>\n I forbindelse med de voksende kommunikationsbehov har v\u00e6rkt\u00f8jer som Whimsical, Miro, Mural, Figma og Balsamiq oplevet en imponerende stigning i popularitet.<\/p>\n Nedlukningen og behovet for at arbejde p\u00e5 afstand har helt sikkert spillet en rolle i denne eksplosion af brugere. Jeg mener, at valget af v\u00e6rkt\u00f8j skal matche individuelle pr\u00e6ferencer, men lad os se p\u00e5 Miro:<\/p>\n Popularisering af s\u00e5danne v\u00e6rkt\u00f8jer driver naturligvis stigningen i populariteten af selve metoderne. En person, der har k\u00f8bt Miro til at arbejde med personaer, f\u00e5r adgang til dusinvis af andre skabeloner, som kan vise sig at v\u00e6re interessante og p\u00e5virke teamets daglige arbejde positivt.<\/p>\n Du b\u00f8r altid udstyre dig med v\u00e6rkt\u00f8jer, der kan str\u00f8mline informationsstr\u00f8mmen i projektet. \u00c5benhed over for nye v\u00e6rkt\u00f8jer og metoder er ogs\u00e5 et af fundamenterne for effektiv produktudvikling<\/a>.<\/p>\n Erfarne designere af b\u00e5de gr\u00e6nsefladen og software-arkitektur<\/a> ser som regel flere potentielle l\u00f8sninger, som b\u00f8r verificeres i begyndelsen af samarbejdet, og leder effektivt efter passende inspiration eller endda f\u00e6rdige l\u00f8sninger p\u00e5 markedet. Et godt eksempel er Material UI-frameworket, som normalt er et sikkert valg p\u00e5 prototypestadiet.<\/a>.<\/p>\n Nogle gange er det nok at gennemg\u00e5 et par implementeringer p\u00e5 Behance eller Dribble og bruge inspirationen til at udvikle et moodboard og derefter sende det videre til udvikleren. Denne person vil bruge det til at sammens\u00e6tte en klikbar prototype<\/a> som kan pr\u00e6senteres for tidlige brugere for at indsamle feedback. Denne organiske str\u00e6ben efter en effektiv proces hos designmindede og engagerede mennesker er naturlig.<\/p>\n Hvis du vil levere digitale produkter effektivt, er du n\u00f8dt til at lade folk g\u00f8re deres arbejde. Du ved, hvilken v\u00e6rdi\/service du vil levere til dine kunder - det er nok. Et kompetent og veldrevet projektteam ved bedst, hvordan man leverer denne v\u00e6rdi\/service s\u00e5 hurtigt som muligt med den n\u00f8dvendige omkostningseffektivitet.<\/p>\n Vis din tillid, del ansvaret og \u00e5bn op for en \u00e6gte tovejskommunikation, s\u00e5 din produkt<\/a> vil v\u00e6re bedre, og byrden ved at skulle klare det hele selv vil v\u00e6re v\u00e6k fra dine skuldre, hvilket ofte viser sig at v\u00e6re en dr\u00e6nende tur for grundl\u00e6ggere og iv\u00e6rks\u00e6ttere! P\u00e5 Codest<\/a>Vi oms\u00e6tter dette princip ikke kun til projekter, men ogs\u00e5 til interne processer - det er sandsynligvis derfor, vi har en h\u00f8j fastholdelsesgrad for b\u00e5de kunder og medarbejdere (sand historie, begge dele> 90%).<\/p>\n Fork\u00e6l dig selv med lidt dovenskab, overf\u00f8r modigt ansvar og giv slip p\u00e5 alt overfl\u00f8digt arbejde, der ikke er n\u00f8dvendigt for at komme videre - funktioner, der ville v\u00e6re \"nice to have\", kan altid vente.<\/p>\n Processen med at skabe et digitalt produkt er en konstant kollision mellem forskellige perspektiver, erfaringer og informationskilder - og hver af disse kollisioner indeb\u00e6rer en risiko for at tr\u00e6ffe en forkert designbeslutning.<\/p>\n God intern kommunikation reducerer denne risiko, men det er kun den ene side af sagen. Sp\u00f8rgsm\u00e5let om, hvordan man holder sig i kontakt med markedet, er endnu ikke besvaret.<\/p>\n Business Intelligence, kundesupport, UX-forskningsafdelinger og mange andre - ligesom de udviklingsteam<\/a>b\u00f8r de str\u00e6be efter det minimum, der er n\u00f8dvendigt for at give specifikke svar p\u00e5 sp\u00f8rgsm\u00e5l, som stilles af produktejeren eller UX-teamet.<\/p>\n Selve brandingen og brandkommunikationsstrategien er ogs\u00e5 vigtig. De tjener til at opbygge et kvalitativt forhold til kunderne, som s\u00e5 udm\u00f8nter sig i deres engagement. Hvis du vil stille sp\u00f8rgsm\u00e5l til kunderne, skal du s\u00f8rge for, at de er villige til at besvare disse sp\u00f8rgsm\u00e5l. Tonen i din stemme betyder noget.<\/p>\n Det er helt sikkert, at man ved at v\u00e6re i konstant kontakt med markedet kan definere den rigtige kurs for projektet og f\u00e5 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\u00f8rgsm\u00e5l og besvare dem) og opbygge en produktstrategi, der vil involvere m\u00e5lgrupperne.<\/p>\n I betragtning af alle de ovenn\u00e6vnte sp\u00f8rgsm\u00e5l kan vi observere flere problemer, som j\u00e6vnligt dukker op i designprocessen:<\/p>\n - at v\u00e6re alt for profitorienteret og undg\u00e5 at se p\u00e5 fiaskoer,<\/p>\n - un\u00f8jagtighed og ikke r\u00f8ntgenfotografering af egne fejl,<\/p>\n - At jagte et perfekt produkt, som du har i dit hoved, men som ikke er det, markedet har brug for,<\/p>\n - overivrig implementering af l\u00e6rebogsprocesser - overudvikling og overdesign,<\/p>\n - ufleksibelt teamwork og tvinger medarbejderne til kun at blive inden for deres specialomr\u00e5der,<\/p>\n - ineffektiv kommunikation,<\/p>\n - tendens til at genopfinde hjulet.<\/p>\n Procesoptimering p\u00e5 makroniveau omfatter summen af besparelser. For at im\u00f8deg\u00e5 de ovenn\u00e6vnte udfordringer skal du involvere dine kolleger, s\u00e5 de \u00e5bent freml\u00e6gger ideer til forbedring af processen.<\/p>\n Nogle gange er det nok at tale mindre og lytte mere opm\u00e6rksomt til underordnede, kunder og partnere - i overensstemmelse med den enkeltes rolle og ansvar - for at opn\u00e5 succes.<\/p>\n N\u00e5r du ikke er helt nok, overinvesterer du h\u00f8jst sandsynligt.<\/a>. Har du for mange penge?<\/p>\n L\u00e6s mere om det:<\/strong><\/p>\n CTO-udfordringer - opskalering og v\u00e6kst af softwareprodukter<\/a><\/p>\nErfaringer fra fejltagelser<\/h2>\n
\n
\n
At bygge et perfekt produkt er som at jage en kanin<\/h2>\n
Det er godt at vide alt om noget og noget om alt<\/h2>\n
Kraftigt udstyr, 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 doven<\/h2>\n
Fokus p\u00e5 at finde de rigtige svar<\/h2>\n
Konklusioner<\/h2>\n
![\"Hold](\"\/app\/uploads\/2024\/05\/meme.png\" "\\"Hold")
<\/p>\nHold k\u00e6ft og tag dine penge! Og i \u00f8vrigt:<\/h2>\n
\n