Ingenieurs zijn uw beste ontwerpers

Iedereen die bij een technologiebedrijf heeft gewerkt, weet hoe productontwerpers en softwareontwikkelaars anders zijn: ze hebben vaak verschillende vaardigheden, uiteenlopende verantwoordelijkheden en, in veel opzichten, werken hun hersenen gewoon anders. Omdat ontwerpers en ontwikkelaars zo verschillend zijn, is het logisch om ze gescheiden te houden bij projecten.

Rechtsaf?

Traditioneel zouden we voor elke afzonderlijke activiteit in een meerstappenproces een gespecialiseerde silo maken en specialisten toewijzen om zich op elk van die onafhankelijke stappen te concentreren. Dit was en is nog steeds een redelijk populaire assemblagelijnbenadering van een productieproces.

De lopende band is nog steeds echt een wonder.

Het bovenstaande sleutelwoord is productie. Als u duizenden en duizenden eenheden van hetzelfde product produceert, allemaal op basis van een enkele blauwdruk, is die aanpak tot op de dag van vandaag geweldig (behalve, natuurlijk, zijn er niet zoveel mensen betrokken bij de assemblagelijn) meer).

Laten we verder gaan naar de moderne wereld van constante technologische innovatie. Innovatie houdt per definitie het creëren van iets nieuws in, over het algemeen een ietwat aangepast, uniek digitaal product. Het meest eenvoudige is hier om diezelfde bekende assemblagelijn, watervalaanpak, toe te passen.

Traditionele watervalbenadering.

Nou, dit lijkt ons niet goed - en voor de meeste bedrijven die er zijn. De Agile-methode is voor velen het antwoord geworden, waardoor bedrijven het snelle en flexibele, op sprint gebaseerde schema binnen het ontwikkelteam hebben overgenomen.

Agile-geïnspireerde watervalbenadering.

Hoewel het is geïnspireerd door Agile, kan het nauwelijks een echt Agile-aanpak worden genoemd, omdat het niet zo veel flexibiliteit toevoegt aan het bedrijf als geheel. Met dat in gedachten gaan veel bedrijven verder en breiden ze het sprintgebaseerde schema uit buiten het ontwikkelingsteam en omvatten ze productmanagement- en ontwerpgroepen.

Een betere op Agile geïnspireerde watervalbenadering.

Helaas is dat vaak de mate waarin organisaties de Agile-aanpak zien. Ja, nu kunt u genieten van de behendigheid van het runnen van de productteams op een manier die het gemakkelijk maakt om van de markt te leren en vrij snel van koers te veranderen.

De daadwerkelijke workflow binnen de sprints is echter nog steeds in wezen een assemblagelijn - vaak met te leveren producten van het ene gespecialiseerde team naar het andere "over het hek". Terwijl op de productiefabriek van Ford het assemblagelijnwerk volledig was ingekapseld in de productiefase ('implementatie') van het productieproces - jarenlang steeds hetzelfde product efficiënt produceren, vraagt ​​de complexiteit van modern technologisch innovatiewerk wat Agile aanpak gaat echt over. Het gaat niet zozeer over het plannen van het werk in brokken van 1 tot 4 weken (wat natuurlijk de gewenste flexibiliteit voor het bedrijf geeft), maar veel meer over het nemen van de juiste beslissingen op basis van de verzamelde en bijgedragen gegevens - in wezen doen het juiste werk - in samenwerking.

Ik geloof echt dat de ware kracht van de Agile-aanpak alleen wordt gerealiseerd als je verschillende mensen, die divers zijn in hun achtergrond en vaardigheden, uit alle delen van je organisatie samenbrengt.

Bij Handsome breken we de silo's af en laten we leden van onze productteams samen dingen bouwen, waaronder ingenieurs die nauw samenwerken met ontwerpers.

Een voorbeeld van collaboratieve Agile-aanpak. Allocaties variëren van project tot project, van product tot product.

We nemen ingenieurs op om deel uit te maken van elke fase van een project, waardoor ze de visie, zakelijke behoeften en tijdlijnvereisten van een klant volledig kunnen begrijpen. Ze krijgen ook uit de eerste hand toegang tot het inzicht in de behoeften van de eindgebruiker, waardoor een aanzienlijke hoeveelheid empathie in het productontwikkelingsproces wordt opgebouwd.

De voordelen van het toevoegen van ontwikkelaars aan uw ontwerpteam houden daar echter niet op.

Definieer samen het juiste product

Het is bewezen: u krijgt een product van hogere kwaliteit als een meer divers team het bouwt. Ik heb het niet alleen over demografie - diversiteit omvat de breedte van ervaringen uit het verleden, vaardigheden, benaderingen voor het oplossen van problemen en zelfs verschillende denkrichtingen. Ja, ontwerpers en ontwikkelaars worden vaak als tegengestelden beschouwd - daarom vullen ze elkaar buitengewoon goed aan. Ontwikkelaars zullen natuurlijk proberen antwoorden te krijgen op vragen waar ontwerpers misschien niet aan denken, en vice versa.

Aangezien de hoofdverantwoordelijkheid van een ingenieur het bouwen van een product is, zijn ze de perfecte metgezel voor degenen die de ervaring ontwerpen. Ze zorgen voor de haalbaarheid van ontwerpideeën en -concepten en introduceren creatief technologisch denken dat het ontwerpproces versterkt.

Bouw de eerste keer goed

Het gaat niet alleen om het juiste product dat wordt gebouwd, het gaat ook om het op de juiste manier bouwen van het product. Met de juiste context - gebruikersbehoeften, doelstellingen van een klant, zakelijke beperkingen - kunnen ontwikkelaars vanaf het begin betere technische beslissingen nemen.

Als ontwikkelaars het zwijgen opleggen, kunnen ze dingen bouwen die een product tot stand brengen met onbedoelde toekomstige beperkingen. Met de juiste context kunnen ze beter codebases bouwen die flexibiliteit bieden wanneer dat nodig is. Dit is vooral belangrijk bij het bouwen van een MVP - vooral omdat volgens een recente EPFL-studie elke 3 van de 4 startups draaien.

Werk slimmer niet harder. Schrijf de juiste code, niet meer code. In de juiste omgeving worden deze theoretische principes een realistische praktijk.

Moedig overhead aan en verlaag beheer

Wanneer ontwikkelaars het waarom achter een vraag weten, zakelijke behoeften begrijpen en empathisch werken met gebruikers in gedachten, is het veel gemakkelijker voor hen om de oplossing te bezitten die ze bouwen. Deze nieuwe vorm van verantwoording wordt niet verplicht gesteld door een manager, maar komt eerder intrinsiek van de ontwikkelaar zelf.

Ingenieurs zullen al weten wat er moet worden gedaan en waarom het moet worden gedaan, zonder zich - bewust of onbewust - bepaalde productbeslissingen te moeten afvragen. Teamleiders hoeven niet langer uitvoering te geven aan micromanage, maar kunnen zich richten op het helpen bouwen van het juiste framework om te zorgen dat ingenieurs het meest productief en efficiënt zijn.

Verhoog empathie binnen het team

Elimineer vinger-wijzend en stuur deliverables over het hek, wat vaak gebeurt wanneer ontwikkelaars vastzitten aan de achterkant van een project. Wanneer uw team is ingesteld vanaf dag 1, heeft elk lid meer empathie voor elkaar.

Deze structuur leidt tot een meer natuurlijke en effectieve samenwerking bij het oplossen van problemen. Interpersoonlijke uitdagingen worden ook gemakkelijker opgelost als uw team allemaal dezelfde North Star-visie volgt.

Verhoog het geluk en behoud van medewerkers

Veel ingenieurs raken opgebrand of vervelen op het werk omdat ze geen zicht hebben op wat er gebeurt nadat hun code is geschreven. Ze staan ​​los van de rest van het proces en veel van hun werk lijkt misschien zinloos. Het ligt in onze aard om impact te willen hebben, uitdagingen voor mensen op te lossen en iets te maken dat er echt toe doet. Je krijgt dit alleen als ontwikkelaar als je het volledige beeld ziet beginnend met de behoeften en pijnpunten van een gebruiker.

De behoefte aan zelfactualisatie - bovenaan de hiërarchie van Maslow - mag nooit worden uitgesloten. Ondanks dat het bij veel bedrijven de best betaalde werknemers is, is het het gevoel van voldoening dat een ontwikkelaar krijgt van het werk waardoor ze vaak willen blijven, zelfs als ze een saaie B2B-app bouwen. Inzicht in het verhaal van hun gebruiker en het waarom maakt het verschil.

Er is geen zilveren kogel of een universele manier om deze workflow te omarmen, en deze zal voor de meeste bedrijven variëren. Niet elk project heeft een ingenieur nodig voor elke stap van het proces, en vanuit puur economisch oogpunt lijkt het misschien duur om een ​​ingenieur te betalen om iets anders dan code te doen.

Door echter de typische assemblagelijnbenadering van digitaal productontwerp en -ontwikkeling uit te dagen door ontwerp- en ontwikkelingsfuncties echt te integreren, kunnen bekroonde ideeën worden ontgrendeld voor wat anders een gemiddeld product zou kunnen zijn.