Als mede-oprichter en incidenteel freelance productmanager, ontwerper en ontwikkelaar, heb ik aan beide kanten van de tafel gewerkt: als een ontwikkelaar die wordt beheerd en als een manager die samenwerkt met een ontwikkelaar.
Dus als u een oprichter, productmanager of iemand bent die met een technisch team werkt, wil ik een paar dingen delen om uw werknemers tevreden te houden en hun leven gemakkelijker te maken.
Waarom zou je je drukmaken? Nou, afgezien van simpelweg een goede baas willen zijn, is het leven van je ontwikkelaar eenvoudiger, hoe sneller en efficiënter ze functies kan implementeren. En op internet, waar de tijd met de snelheid van hondenjaren beweegt, is dat absoluut een voordeel.
Hier zijn de sleutels tot succes bij het werken met uw technisch team.
Begrijp het verschil tussen een CTO en een hoofdingenieur
Je werkt samen met een CTO of een hoofdingenieur en het is belangrijk om te begrijpen dat ze niet noodzakelijkerwijs dezelfde persoon zijn.
Soms heb je een geweldige CTO die niet alleen technisch is, maar ook een geweldige manager, communicator en delegator. Deze typen willen waarschijnlijk alles weten over wat u bouwt, wat het einddoel is voor de gebruiker en uw algemene bedrijfsdoelen. Dat is geweldig! Geloof me, het is een pluspunt. Voed het.
Meestal echter - vooral in deze ontwikkelaar-schaarse economie - heb je een hoofdingenieur: een persoon die geweldig is in het ontwerpen van een product, maar niet noodzakelijk de vaardigheden (of de wens) heeft om een team te beheren en product.
Hoe sneller je je realiseert wat voor soort persoon je nodig hebt (of hebt aangenomen), hoe beter je voorbereid bent om die persoon en het product te beheren.
Zorg over hoe dingen zijn
Ontwikkelaars zijn makers, geen machines. Dus luister naar hun ideeën en zorg ervoor dat je ze in overweging neemt - zelfs als je geen idee hebt waar ze het in godsnaam over hebben als ze technische termen gaan gebruiken. Weet je het verschil niet tussen deze en die stapel? Vragen. Gebruik het als een gelegenheid om te leren. U moet ten minste een basiskennis hebben van de technische kant van uw product.
Wees specifiek
Het is veel nuttiger voor uw technische team om ze specifieke, kleine taken toe te wijzen - overhandig niet alleen een aantal mock-ups en vertel ze dat ze voor vrijdag klaar moeten zijn. In feite zou u degene moeten zijn die het project voor hen beheert. Leer hoe u projectbeheersoftware zoals Pivotal Tracker of Trello kunt gebruiken en volg de voortgang van de functieontwikkeling per dag of per werksessie.
En check-in vaak, zowel persoonlijk als via uw projectbeheersoftware. Het is veel gemakkelijker om te voorkomen dat dingen de verkeerde kant opgaan als je ze bij de vork kunt vangen.
Verander niet elke dag van gedachten
Ik weet het, je denkt dat dit vanzelfsprekend klinkt. Maar wanneer u uw product elke dag pitchen en verkoopt, feedback hoort en brainstormt over manieren om het te verbeteren - het is heel gemakkelijk om altijd met nieuwe ideeën terug te komen. Doe dit niet aan je team.
Definieer een specifiek en klein ding dat u wilt bouwen: een Minimum haalbaar product (of "MVP"). Zorg dat uw MVP gereed is om te worden gebouwd. En maak het klein. Als je een gigantische app hebt ontworpen, breek deze dan af en begin met één onderdeel. Verzend uw MVP - en verander vervolgens van gedachten op basis van gegevens.
Lees ook, als je dat nog niet hebt gedaan, The Lean Startup van Eric Ries. Volg het - gooi niet alleen cool jargon rond bij netwerkevenementen.
Stel doelen, geen deadlines
In de technische wereld werken deadlines niet altijd. Zelfs de meest ervaren ontwikkelaar maakt dingen kapot en het is moeilijk om in te schatten hoe lang het duurt om dingen te repareren.
Ik hou echt van het idee van Tracker om functies op te splitsen en moeilijkheidspunten toe te wijzen, geen uren. Markeer een probleem als "gemakkelijk", "gemiddeld" of "moeilijk" en houd de voortgang bij in plaats van dat u zich aan deadlines houdt. Meestal moeilijke taken toewijzen? Ze kunnen waarschijnlijk verder worden afgebroken.
Koop een geweldige designer
Ontwerpers lossen problemen op en kunnen het productopbouwproces een stuk eenvoudiger maken. Vooral UX / UI (gebruikerservaring en gebruikersinterface) ontwerpers. Ze helpen u erachter te komen hoe uw product eruit moet zien en hoe het moet werken: pixel voor pixel, gebruikersinteractie per gebruikersinteractie (denk: op welke knop klikt de gebruiker vervolgens? Waar staat het op de pagina? Waar brengt het haar naartoe?).
Dit is niet de taak van je ontwikkelaar. Ik meen het. De taak van uw ontwikkelaar is om code te schrijven en niet om het product te ontwerpen. Een geweldige ontwerper zal u daadwerkelijk helpen te besparen op ontwikkelingskosten, omdat ze het team helpen nadenken en dingen vangen die anderen misschien over het hoofd hebben gezien. Ze kunnen ook voorstellen om eenvoudige maar krachtige wijzigingen aan te brengen die uw product intuïtiever en gebruiksvriendelijker maken.
Tegelijkertijd: zorg ervoor dat uw ontwerper slank is. Soms is het de kosten niet waard om alles op maat te maken. Er is een verschil tussen aandacht voor detail en diva zijn. Als uw ontwikkelaar klaagt over een ontwerp, is dat een teken dat u moet stoppen, het moet bespreken, aanpassen en compromissen sluiten.
Test, test, test
Als u überhaupt om uw product geeft, helpt u uw ontwikkelaar het te testen. Ze staart hier al uren naar. Geef haar een nieuw stel ogen. Prijs haar voor wat ze goed heeft gedaan en geef haar specifieke taken voor wat nog moet worden gedaan of opgelost.
Ontwikkelaars klagen vaak tegen me dat ze tonnen tijd aan iets hebben besteed en toen is het begonnen met dingen die kapot waren omdat niemand ze zag. Onthoud, het is jouw product. En niemand wil werken voor iemand die niet geïnteresseerd is in het product dat ze op de markt brengen.
Eerlijk compenseren
Je bent een ondernemer en mensen uit het bedrijfsleven onderhandelen. Meestal veel beter dan niet-zakelijke mensen.
Dus wees voorzichtig.
U kunt met een ontwikkelaar onderhandelen over haar snelheid, maar als het redelijk klinkt, is het waarschijnlijk. Houd in gedachten dat er genoeg andere mensen zijn die haar willen en kunnen inhuren voor wat ze citeerde. En als ze het gevoel heeft dat ze te veel is onderhandeld en niet wordt gecompenseerd wat ze waard is, is de kans groot dat ze uw werk niet voorrang geeft op ander werk (of op andere, leukere dingen). Of ze vindt iemand anders die haar tarief betaalt en laat je dan hangen. Ik heb het steeds weer gezien.
Een alternatief is om voor een kleine functie een tarief te bedingen voor een proefperiode en haar te vertellen dat u het volledige tarief betaalt als het project goed verloopt.
Vertrouw op je team
Ben je achterdochtig over het opvullen van uren voor je ontwikkelaar of verslappen door naar de dichtstbijzijnde biergarten te gaan? Onthoud dat als u geen mensen inhuurt die u vertrouwt en die ergens beter in zijn dan u, u niet de juiste mensen inhuurt.
Vertrouw op de experts die u hebt ingehuurd om hun werk te doen. Geef ze de tools die ze nodig hebben om het te doen, waaronder richting, flexibiliteit, ademruimte en autoriteit. En check vaak in.
