KEREN TERUG
Jagen op eenhoorns is een verdomd dure hobby. Elk jaar slokken startups miljarden op zodat slechts één van de tientallen of honderden miljoenen winst kan maken. Oprichters en producteigenaren halen geld op bij investeerders en offeren hun onafhankelijkheid op om de markt sneller te veroveren. Maar uiteindelijk halen ze meestal niet genoeg geld op. Misschien was het juist om op het juiste moment te zeggen "hou je mond en pak je geld"?
Geld beheerst alles om me heen. Zelfs de meest turquoise organisaties kunnen het niet ontkennen. De ontwikkeling van project managementmethoden, het afstemmen en optimaliseren van processen of de motivatie van werknemers wordt in principe getriggerd door de universele behoefte aan geld. Aan ontwerpflexibiliteit zijn bepaalde risico's verbonden.
We willen allemaal slank en agile zodat het resultaat van onze activiteiten, gemeten in aantallen, zo hoog mogelijk is. Ook al richten we ons vooral op het verminderen van verliezen, uiteindelijk houden we rekening met de winst die is toegenomen dankzij de gegenereerde besparingen.
Deze besparingen vallen in dezelfde zak als de overige factoren en blijven alleen beschikbaar voor de meest nieuwsgierigen. Op deze manier verliezen we onze focus en laten we onbedoeld veel waardevolle gegevens en uiteindelijk intelligentie achterwege.
Leren van je eigen fouten is een bijzonder nuttige (hoewel dure) vaardigheid, maar de organisatiecultuur en de diplomatie die in dit vermogen besloten ligt, helpen niet altijd. We verbergen de negatieve impact van financiën vaak met "rookgordijn"-woorden. Als een belegger schreeuwt "Ik ben mijn geld kwijt!", communiceert de manager dit naar de team door te zeggen "we zouden effectiever moeten zijn" en we zoeken allemaal standaard naar nieuwe oplossingen en verbeteringen - in plaats van achterom te kijken, zoeken we voortdurend naar manieren om vooruit te komen.
Ondertussen zijn verliezen vaak de sleutel tot het trekken van de juiste conclusies. Als we bepaalde stroomstappen in het proces overlopen zonder er goed over na te denken, zullen de volgende oplossingen hoogstwaarschijnlijk besmet zijn met dezelfde fouten.
Voorbeeld:
Een klein team van senior JS-ontwikkelaars levert geen functionaliteit binnen de verwachte tijd. De investeerder wil de ontwikkeling versnellen en geeft opdracht om een nieuwe programmeur aan te nemen. De introductie van een nieuwe persoon in het project leidt het team af, waardoor de voortgang van het project nog verder vertraagt.
Als de investeerder de redenen achter de ineffectiviteit van het team beter zou begrijpen, zou hij concluderen dat het team zijn potentieel alleen gebruikt in 60-70%. Betere apparatuur en een paar werkdagen gewijd aan werkautomatisering zouden het probleem oplossen.
Helaas moet hij nu betalen voor een andere ontwikkelaar die op dezelfde apparatuur zal werken en zijn efficiëntie zal ook op 60-70% liggen.
Oplossing A:
Vanaf nu kost het project $20.200 / maand
Totale uitgaven in 12 maanden: 12 * 20.200 + 10.000 = $252.400
Oplossing B:
Vanaf nu kost het project: $30.000 / maand
Totale uitgaven in 12 maanden: 12 * 30.000 = $360.000
Twee ontwikkelaars die werken op 100% doen ongeveer hetzelfde als drie ontwikkelaars die werken op 60-70%. De investeerder betaalt meer dan $ 100.000 meer voor dezelfde verwerkingscapaciteit per jaar door een foutieve ontwerpbeslissing!
Wendbaarheid in het proces betekent niet noodzakelijk streven naar 100% testdekking of het breken van het prestatierecord. Hoewel deze meetgegevens een overzicht geven van de technische staat van het project, zijn ze zo onbelangrijk vanuit het perspectief van de eindklant dat het niet nodig is om ze naar een ideale staat te brengen in een echt Agile proces, omdat ze geen echte resultaten opleveren. markt waarde.
Het ontwikkelen van perfecte technische oplossingen vereist veel inzet van het team en veel uitgebreidere communicatie. Als gevolg hiervan werken patches langzamer en wordt het project zwaar door overontwikkeling.
Agile ontwikkeling draait om het leveren van een werkende code met minimale inspanning. Het testen van code is ongetwijfeld een goede praktijk en de tests zeggen veel over de werking van de code, maar ze moeten niet alleen worden gedaan om ze te doen en erover op te scheppen - de optimale technische kwaliteit van oplossingen ligt ergens tussen het minimum bepaald door de ontwikkelteam en het maximum dat wordt beperkt door het budget.
Uiteindelijk bereik je met perfectie niets. Interessant genoeg is zelfs de beveiliging onderworpen aan deze regel - theoretisch kan elk systeem gehackt worden. Echter, het eerder genoemde ontwikkelingsminimum moet overeenkomstig hoger zijn en relevant voor het gewicht, de schaal en de kosten van de potentiële gevolgen van code fouten. Vaak is het beter om, in plaats van de aanmeldingsmodule helemaal opnieuw te schrijven, wat altijd gepaard gaat met een hoog risico op fouten en het introduceren van beveiligingslekken, bijvoorbeeld de knop "Aanmelden met Google" te gebruiken, waarvan de juiste implementatie relatief snel en veilig is.
Zolang het doel een korte time-to-market is, blijken al te ambitieuze aannames contraproductief. In een schijnbaar perfect proces kan overenthousiasme een verspilling van middelen zijn.
Gebruikersgericht ontwerp is cool. Mensgerichte samenwerking is belangrijker. Als het team op dezelfde golflengte communiceert, kan het spontaan verdere potentiële verliezen beperken.
Een UX-ontwerper die op de hoogte is van frontend-technologieën zal geen oplossing voorstellen op het moment dat MVP fase die onredelijk veel tijd zal kosten in de implementatiefase.
Een frontend ontwikkelaar met kennis van usability heuristics kan de interface aanpassen aan een bepaalde schermresolutie zonder de UX designer erbij te betrekken - quick fix, preview, accept.
Werken aan een applicatie vereist synchronisatie van activiteiten van mensen met totaal verschillende competentieprofielen. Je moet de verdeling van vaardigheden in je team kennen om effectief waarde te kunnen leveren aan je klanten.
Goede teamprestaties op deze manier begrijpen is bijzonder moeilijk om te bereiken, vooral in het tijdperk van telewerk. Bedrijven die al jaren "afstandsvriendelijk" zijn, hebben een aanzienlijk voordeel op dit gebied ten opzichte van bedrijven die gedwongen werden de organisatie af te stemmen tijdens de lockdown en nu pas leren over nieuwe methoden en vormen van communicatie.
In de context van de groeiende communicatiebehoeften registreren tools zoals Whimsical, Miro, Mural, Figma en Balsamiq een indrukwekkende toename in populariteit.
De lockdown en de noodzaak om op afstand te werken hebben zeker een rol gespeeld in deze explosie van gebruikers. Ik ben van mening dat de keuze van de tool moet overeenkomen met individuele voorkeuren, maar laten we eens kijken naar Miro:
De popularisering van dergelijke tools leidt natuurlijk tot een toename in populariteit van de methodologieën zelf. Iemand die Miro heeft gekocht om aan persona's te werken, krijgt toegang tot tientallen andere sjablonen die interessant kunnen blijken en het dagelijkse werk van het team positief kunnen beïnvloeden.
Je moet jezelf altijd uitrusten met hulpmiddelen die de informatiestroom in het project stroomlijnen. Openstaan voor nieuwe tools en methoden is ook een van de fundamenten van effectieve productontwikkeling.
Ervaren ontwerpers van zowel de interface als de softwarearchitectuur zien meestal verschillende potentiële oplossingen die aan het begin van de samenwerking moeten worden geverifieerd en gaan efficiënt op zoek naar geschikte inspiratie of zelfs kant-en-klare oplossingen op de markt. Een goed voorbeeld is het Material UI-framework, dat meestal een veilige keuze is in het prototypestadium.
Soms is het voldoende om een paar implementaties te bekijken op Behance of Dribble en de inspiratie te gebruiken om een moodboard te ontwikkelen en dit vervolgens door te geven aan de ontwikkelaar. Deze persoon zal het gebruiken om een klikbaar prototype samen te stellen dat kan worden gepresenteerd aan early adopters om feedback te verzamelen. Dit organische streven naar een effectief proces bij ontwerpgerichte en toegewijde mensen is natuurlijk.
Als je efficiënt digitale producten wilt leveren, moet je mensen hun werk laten doen. U weet welke waarde/dienst u uw klanten wilt bieden - dat is genoeg. Een competent en goed geleid projectteam weet het beste hoe het deze waarde/dienst zo snel mogelijk kan leveren met de nodige kosteneffectiviteit.
Toon je vertrouwen, deel de verantwoordelijkheid en stel je open voor een echte tweerichtingscommunicatie zodat je product Het zal beter gaan en de last om het allemaal alleen te doen zal van je schouders vallen, wat vaak een slopende rit blijkt te zijn voor oprichters en ondernemers! Op The CodestDit principe vertalen we niet alleen naar projecten, maar ook naar interne processen - dat is waarschijnlijk de reden waarom we een hoge retentiegraad hebben voor zowel klanten als medewerkers (waargebeurd verhaal, beide> 90%).
Gun jezelf een beetje luiheid, draag verantwoordelijkheid over en laat overbodig werk los dat niet nodig is om vooruit te komen - functionaliteiten die "leuk zijn om te hebben" kunnen altijd wachten.
Het maakproces van een digitaal product is een constante botsing van verschillende perspectieven, ervaringen en informatiebronnen - bij elke botsing bestaat het risico dat er een verkeerde ontwerpbeslissing wordt genomen.
Goede interne communicatie vermindert dit risico, maar het is slechts één kant van de medaille. De vraag hoe je in contact blijft met de markt moet nog worden beantwoord.
Business Intelligence, Customer Support, UX-onderzoeksafdelingen en vele andere - net als de ontwikkelingsteamZe moeten streven naar het minimum dat nodig is om specifieke antwoorden te geven op vragen van de producteigenaar of het UX-team.
De branding zelf en de communicatiestrategie van het merk zijn ook belangrijk. Ze dienen om een kwalitatieve relatie met klanten op te bouwen, die zich vervolgens vertaalt in hun betrokkenheid. Als je vragen wilt stellen aan klanten, moet je ervoor zorgen dat ze bereid zijn deze vragen te beantwoorden. De toon van je stem is belangrijk.
Het is zeker dat voortdurend in contact staan met de markt je in staat stelt om de juiste trajecten voor het project te bepalen om het te laten vliegen. Minder voor de hand liggend is het feit dat de noodzaak van dit contact moet worden overwogen aan het begin van het project, rond het anticiperen op de juiste competenties in het team (om de juiste vragen te stellen en te beantwoorden) en het bouwen van een productstrategie die de doelgroepen zal betrekken.
Als we alle bovengenoemde kwesties in overweging nemen, kunnen we verschillende problemen waarnemen die regelmatig opduiken in het ontwerpproces:
- overmatig winstgericht zijn en niet naar mislukkingen kijken,
- onnauwkeurigheid en het niet röntgenologisch beoordelen van eigen fouten,
- een perfect product achtervolgen dat je in je hoofd hebt, maar dat niet is wat de markt nodig heeft,
- overijverige implementatie van leerboekprocessen - overontwikkeling en overontwerp,
- inflexibiliteit van teamwerk en het dwingen van werknemers om alleen in hun specialisatiegebied te blijven,
- ineffectieve communicatie,
- neiging om het wiel opnieuw uit te vinden.
Procesoptimalisatie op macroschaal omvat de som van besparingen. Om de bovengenoemde uitdagingen goed aan te gaan, moet je je collega's erbij betrekken zodat ze openlijk met ideeën komen om het proces te verbeteren.
Soms is het genoeg om minder te praten en beter te luisteren naar ondergeschikten, klanten, partners - afhankelijk van ieders rol en verantwoordelijkheid - om succes te boeken.
Als je niet genoeg hebt, ben je waarschijnlijk aan het overinvesteren. Heb je te veel geld?
Lees meer:
CTO uitdagingen - schaalvergroting en groei van softwareproducten
Welke DB kiezen voor je specifieke gegevenstype in je softwareproject
Dutch 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Estonian 
Greek