Som medstifter og lejlighedsvis freelance produktleder, designer og udvikler har jeg arbejdet på begge sider af bordet: som en udvikler, der administreres, og som en manager, der arbejder med en udvikler.
Så hvis du er en grundlægger, produktchef eller nogen, der arbejder med et teknisk team - vil jeg dele et par ting at gøre for at holde dine medarbejdere glade og gøre deres liv lettere.
Hvorfor bekymre sig? Jo, bortset fra blot at ønske at være en god chef, jo lettere er din udviklers liv, jo hurtigere og mere effektiv vil hun være i stand til at implementere funktioner. Og på internettet, hvor tiden bevæger sig med hundeårens hastighed, er det bestemt en fordel.
Her er nøglerne til succes, når du arbejder med dit tekniske team.
Forstå forskellen mellem en CTO og en ledende ingeniør
Du arbejder enten med en CTO eller en Lead Engineer, og det er vigtigt at forstå, at de ikke nødvendigvis er den samme person.
Nogle gange har du en fantastisk CTO, der ikke kun er teknisk, men også en fantastisk manager, kommunikator og delegator. Disse typer vil sandsynligvis vide alt om, hvad du bygger, hvad slutmålet er for brugeren og dine overordnede forretningsmæssige mål. Det er fantastisk! Tro mig, det er et aktiv. Pleje det.
Det meste af tiden, dog - især i denne udviklings-knappe økonomi - har du en Lead Engineer: en person, der er fantastisk til at konstruere et produkt, men ikke nødvendigvis har evnerne (eller ønsket om) at styre et team og produkt.
Jo hurtigere du er klar over, hvilken type person du har brug for (eller har ansat), desto bedre forberedt vil du være at styre denne person og produktet.
Omsorg for, hvordan tingene er
Udviklere er producenter, ikke maskiner. Så lyt til deres ideer, og sørg for at overveje dem - selvom du ikke har nogen idé om, hvad fanden de taler om, når de begynder at smide om tekniske termer. Ved du ikke forskellen mellem denne og den stak? Spørg. Brug det som en mulighed for at lære. Du skal mindst have en grundlæggende forståelse af den tekniske side af dit produkt.
Vær specifik
Det er meget mere nyttigt for dit tekniske team at tildele dem specifikke, små opgaver - ikke bare dele en masse mock-ups ud og fortæl dem, at de skal være færdige inden fredag. Faktisk skal du være den, der administrerer projektet for dem. Lær hvordan du bruger projektstyringssoftware som Pivotal Tracker eller Trello og sporer udviklingen i funktionsudvikling om dagen eller pr. Arbejdssession.
Og check ofte ind, både personligt og via dit projektstyringssoftware. Det er meget lettere at forhindre, at ting går ned på den forkerte vej, hvis du kan fange dem ved gaffelen.
Skift ikke dit sind hver dag
Jeg ved, du synes, det lyder indlysende. Men når du er ude med at slå og sælge dit produkt hver dag, høre feedback og brainstorme måder til at gøre det bedre - er det virkelig nemt at komme tilbage med nye ideer hele tiden. Gør ikke dette for dit team.
Definer en bestemt og lille ting, du vil opbygge: et minimum levedygtigt produkt (eller "MVP"). Få din MVP specificeret og klar til at blive bygget. Og gør det lille. Hvis du har designet en gigantisk app, skal du nedbryde den og starte med en del. Send din MVP - og skift derefter tankerne baseret på data.
Hvis du ikke allerede har gjort det, skal du læse The Lean Startup af Eric Ries. Følg det - kaste ikke bare cool jargon ved netværksbegivenheder.
Angiv mål, ikke tidsfrister
I den tekniske verden fungerer frister ikke altid. Selv den mest erfarne udvikler bryder ting, og det er svært at estimere, hvor lang tid det vil tage at ordne tingene.
Jeg går virkelig ind på Tracker's idé om at nedbryde funktioner og tildele vanskelighedspoint, ikke timer. Marker et problem som "let", "medium" eller "vanskeligt", og spor fremskridt snarere end at holde sig til tidsfrister. Tildele det meste vanskelige opgaver? De kan sandsynligvis opdeles yderligere.
Få en stor designer
Designere løser problemer og kan gøre produktopbygningsprocessen meget lettere. Især UX / UI (brugeroplevelse og brugergrænseflade) designere. De hjælper dig med at finde ud af, hvordan dit produkt skal se ud og fungere - pixel efter pixel, brugerinteraktion efter brugerinteraktion (tænk: Hvilken knap klikker brugeren næste? Hvor er det på siden? Hvor tager det hende?).
Dette er ikke din udviklers job. Jeg er seriøs. Din udviklers job er at skrive kode - ikke designe produktet. En stor designer vil faktisk hjælpe dig med at spare på udviklingsomkostninger, fordi de vil hjælpe teamet med at tænke igennem og fange ting, som andre måske har overset. De kan også foreslå, at der foretages enkle, men kraftfulde ændringer, der vil gøre dit produkt mere intuitivt og lettere at bruge.
På samme tid - sørg for, at din designer er slank. Nogle gange er det ikke værd at prisen er at bygge tilpassede alt. Der er forskel mellem opmærksomhed på detaljer og at være en diva. Hvis din udvikler klager over et design - det er et tegn på, at du skal stoppe, diskutere det, finpudse det og gå på kompromis.
Test, Test, Test
Hvis du overhovedet er interesseret i dit produkt - hjælp din udvikler med at teste det. Hun har stirret på dette i timevis. Giv hende et nyt sæt øjne. Ros hende for det, hun gjorde rigtigt, og giv hende specifikke opgaver for, hvad der stadig skal gøres eller rettes.
Udviklere klager ofte over for mig, at de har brugt en masse tid på noget, og så blev det lanceret med ødelagte ting, fordi ingen så dem. Husk, det er dit produkt. Og ingen vil arbejde for nogen, der ikke er interesseret i det produkt, de lægger derude.
Kompensere ret
Du er en forretningsmand, og forretningsfolk forhandler. Normalt meget bedre end ikke-forretningsfolk.
Så vær forsigtig.
Du kan forhandle med en udvikler om hendes sats, men hvis det lyder rimeligt, er det sandsynligvis. Husk, at der er masser af andre mennesker derude, der er villige og i stand til at ansætte hende til det, hun citerede. Og hvis hun har det som om, at hun er blevet forhandlet uden for, og at hun ikke får kompenseret, hvad hun er værd, er chancerne for, at hun ikke prioriterer dit arbejde frem for andet arbejde (eller over andre, sjovere ting). Eller så finder hun en anden, der betaler hendes sats og derefter lader dig hænge. Jeg har set det igen og igen.
Et alternativ er at forhandle om en sats i en prøveperiode for en lille funktion, og fortælle hende, at du betaler den fulde sats, hvis projektet går godt.
Stol på dit team
Er du mistænksom over, at din udvikler har polstret timer eller slukket ved at gå til den nærmeste biergarten? Husk, at hvis du ikke ansætter folk, som du har tillid til, og som er bedre end dig til noget, så ansætter du ikke de rigtige mennesker.
Stol på de eksperter, du har ansat for at gøre deres job. Giv dem de værktøjer, de har brug for for at gøre det, inklusive retning, fleksibilitet, åndedrætsværelse og autoritet. Og check ofte ind.
