Ingeniører er de beste designerne

Alle som har jobbet i et teknologiselskap vet hvordan produktdesignere og programvareutviklere er forskjellige: de har ofte forskjellige ferdighetssett, forskjellige ansvarsområder, og på mange måter fungerer hjernen deres bare annerledes. Siden designere og utviklere er så forskjellige, er det fornuftig å holde dem adskilt på prosjekter.

Ikke sant?

Tradisjonelt ville vi lage en spesialisert silo for hver enkelt aktivitet i en flertrinnsprosess og tildele spesialister å fokusere på hvert av de uavhengige trinnene. Dette var, og er fremdeles, en ganske populær samlebåndstilnærming til en produksjonsprosess.

Samlebåndet er virkelig et mirakel, fremdeles.

Nøkkelordet ovenfor er produksjon. Hvis du produserer tusenvis og tusenvis av enheter av samme produkt, alt basert på en enkelt blåkopi, er den tilnærmingen fantastisk, frem til i dag (bortsett fra, selvfølgelig, det er ikke så mange mennesker som er involvert i samlebåndarbeidet) lenger).

La oss gå videre til den moderne verdenen med konstant teknologisk innovasjon. Innovasjon innebærer per definisjon opprettelse av noe nytt, - generelt et noe tilpasset, enestående digitalt produkt. Det mest greie her er å bruke den samme kjente samlebånd, fossefall tilnærming til den.

Tradisjonell fossefall.

Dette ser ikke riktig ut for oss - og for de fleste selskaper der ute. Agile Methodology har blitt svaret for mange, noe som resulterer i at selskaper tar i bruk den raske og fleksible, sprintbaserte timeplanen innen utviklingsteamet.

Agile-inspirert fossefall.

Selv om det er inspirert av Agile, kan det knapt kalles en virkelig Agile tilnærming, siden det ikke tilfører all så mye smidighet i virksomheten som helhet. Med det i bakhodet går mange selskaper lenger og utvider den sprintbaserte timeplanen utenfor utviklingsgruppen, og inkluderer produktstyring og designgrupper.

En bedre Agile-inspirert fossefall.

Dessverre, veldig ofte er det i hvilken grad organisasjoner ser Agile-tilnærmingen. Ja, nå kan du glede deg over smidigheten ved å drive produktteamene på en måte som gjør det enkelt å lære fra markedet og endre løpet ganske raskt.

Imidlertid er den faktiske arbeidsflyten i spurtene fremdeles i hovedsak en samlebånd - ofte med leveranser kastet fra et spesialisert team til et annet "over gjerdet". Mens i Fords produksjonsfabrikkgulvet ble samlebåndarbeidet innkapslet rent innenfor produksjonsstadiet ("implementering") av produksjonsprosessen - effektivt å produsere det samme produktet om og om igjen i årevis, krever kompleksiteten i moderne teknologisk innovasjonsarbeid det Agile tilnærming handler virkelig om. Det handler ikke så mye om å planlegge arbeidet i 1-4 ukers biter (noe som selvfølgelig gir ønsket fleksibilitet til virksomheten), like mye handler det om å ta riktige beslutninger basert på data samlet og bidratt - egentlig å gjøre det rette arbeidet — i samarbeid.

Jeg er en sann tro på at den sanne kraften i Agile-tilnærmingen bare blir realisert når du tar forskjellige mennesker, som er forskjellige i deres bakgrunn og ferdighetssett, - fra alle deler av organisasjonen din - sammen.

Hos Handsome bryter vi ned siloene og lar medlemmer av våre produktteam bygge ting sammen, som inkluderer ingeniører som jobber i lås-trinn med designere.

Et utvalg av samarbeidende agile tilnærminger. Tildelingene varierer fra prosjekt til prosjekt, fra produkt til produkt.

Vi inkluderer ingeniører som skal være en del av hver fase av et prosjekt, som lar dem forstå forståelse av en klients visjon, forretningsbehov og tidslinjekrav. De får også førstehånds tilgang til å forstå sluttbrukerens behov, og bygger en betydelig mengde innlevelse i produktutviklingsprosessen.

Fordelene ved å legge utviklere til designteamet ditt stopper ikke der.

Definer riktig produkt sammen

Det er velprøvd: du vil ha et produkt av høyere kvalitet hvis et mer mangfoldig team bygger det. Jeg snakker ikke bare om demografi - mangfold inkluderer bredden av tidligere erfaringer, ferdighetssett, tilnærminger til å løse problemer og til og med varierte tankesett. Ja, designere og utviklere blir ofte sett på som motsetninger - og det er derfor de kompletterer hverandre ekstremt godt. Utviklere vil naturlig nok prøve å få svar på spørsmål som designere kanskje ikke tenker på, og omvendt.

Siden en ingeniørs hovedansvar er å bygge et produkt, er de den perfekte følgesvennen til de som designer opplevelsen. De vil sikre gjennomførbarheten til designideer og konsepter, og introdusere kreativ teknisk tenking som styrker designprosessen.

Bygg riktig første gang

Det handler ikke bare om det rette produktet som bygges, det handler også om å bygge produktet på riktig måte. Med all riktig kontekst - brukerbehov, en klients mål, forretningsbegrensninger - kan utviklere ta bedre tekniske beslutninger fra starten av.

Hvis utviklere blir tåket, kan de ende opp med å bygge ting som setter opp et produkt med utilsiktede fremtidige begrensninger. Med riktig kontekst kan de bedre bygge kodebaser som gir mulighet for fleksibilitet ved behov. Dette er spesielt viktig når du bygger en MVP - spesielt siden hver tredje av fire oppstarter ender med å svinge, ifølge en fersk EPFL-studie.

Jobb smartere ikke hardere. Skriv riktig kode, ikke mer kode. Innenfor det rette miljøet blir disse teoretiske prinsippene en realistisk praksis.

Oppmuntre eierforhold og reduser administrasjonsomkostningene

Når utviklere vet hvorfor bak et spørsmål, forstår forretningsbehov og jobber empatisk med brukere i tankene, er det mye lettere for dem å eie løsningen de bygger. Denne nye typen ansvarlighet er ikke pålagt av en leder, men kommer snarere iboende fra utvikleren selv.

Ingeniører vil allerede vite hva som må gjøres, og hvorfor det må gjøres, uten å måtte stille spørsmål om - enten bevisst eller underbevisst - bestemte produktbeslutninger. Lagledere kan ikke lenger behøve å gjennomføre utførelse, og fokusere på å hjelpe til med å bygge de rette rammene for å sikre at ingeniører er mest produktive og effektive.

Øk empati i teamet

Fjern fingerspiss og sending av leveranser over gjerdet, noe som ofte skjer når utviklere sitter fast i bakenden av et prosjekt. Når teamet ditt er satt fra dag 1, vil hvert medlem ha mer empati for hverandre.

Denne strukturen fører til mer naturlig og effektiv samarbeidsproblemløsning. Mellommenneskelige utfordringer blir også lettere løst når teamet ditt alle følger den samme North Star-visjonen.

Øk ansattes lykke og oppbevaring

Mange ingeniører blir utbrente eller kjeder seg på jobb fordi de ikke har noen synlighet i hva som skjer etter at koden deres er skrevet. De er koblet fra resten av prosessen, og mye av arbeidet deres kan ende ut til å være meningsløst. Det ligger i vår natur å ønske å gjøre inntrykk, løse utfordringer for mennesker og skape noe som virkelig betyr noe. Du får bare føle dette som en utvikler når du ser hele bildet som begynner med brukerens behov og smertepunkter.

Behovet for selvaktualisering - fra toppen av Maslows hierarki - bør aldri diskonteres. Til tross for at de er de høyest betalte ansatte i mange selskaper, er det følelsen av oppfyllelse en utvikler får fra arbeidet som ofte får dem til å ønske å bli, selv om de bygger det som kan virke som en kjedelig B2B-app. Å forstå brukerens historie og hvorfor gjør hele forskjellen.

Det er ingen sølvkule eller en universell måte å omfavne denne arbeidsflyten på, og den vil variere for de fleste selskaper. Ikke hvert prosjekt trenger en ingeniør for hvert trinn i prosessen, og fra et rent kortsiktig økonomisk synspunkt kan det virke dyrt å betale en ingeniør for å gjøre noe annet enn kode.

Å utfordre den typiske samlebåndstilnærmingen til digital produktdesign og utvikling ved å virkelig integrere design- og utviklingsfunksjoner kan imidlertid låse prisvinnende ideer til det som ellers bare kan være et gjennomsnittlig produkt.