Som en av grunnleggerne og en og annen freelance produktleder, designer og utvikler, har jeg jobbet på begge sider av bordet: som en utvikler som blir administrert, og som en manager som jobber med en utvikler.
Så hvis du er en grunnlegger, produktleder eller noen som jobber med et teknisk team - vil jeg dele noen ting du kan gjøre for å holde dine ansatte glade og gjøre livet deres enklere.
Hvorfor bry seg? Vel, bortsett fra å bare være en god sjef, jo lettere er utviklerens liv, jo raskere og mer effektivt vil hun kunne implementere funksjoner. Og på internett, der tiden beveger seg med hundeårens hastighet, er det definitivt en fordel.
Her er nøklene til suksess når du jobber med ditt tekniske team.
Forstå forskjellen mellom en CTO og en ledende ingeniør
Du vil enten jobbe med en CTO eller en ledende ingeniør, og det er viktig å forstå at de ikke nødvendigvis er den samme personen.
Noen ganger har du en fantastisk CTO som ikke bare er teknisk, men også en god leder, kommunikator og delegator. Disse typene vil sannsynligvis vite alt om hva du bygger, hva sluttmålet er for brukeren og dine overordnede forretningsmessige mål. Det er flott! Tro meg, det er et aktivum. Pleier det.
Mesteparten av tiden, men - spesielt i denne utvikle-knappe økonomien - vil du ha en ledende ingeniør: en person som er fantastisk til å konstruere et produkt, men ikke nødvendigvis har ferdighetene (eller ønsket) til å styre et team og produkt.
Jo raskere du innser hvilken type person du trenger (eller har ansatt), jo bedre forberedt vil du være å administrere den personen og produktet.
Bryr deg om hvordan ting er
Utviklere er produsenter, ikke maskiner. Så hør på ideene deres og sørg for at du vurderer dem - selv om du ikke aner hva faen de snakker om når de begynner å kaste rundt tekniske termer. Vet du ikke forskjellen mellom denne og den stabelen? Spørre. Bruk den som en mulighet til å lære. Du bør minst ha en grunnleggende forståelse av den tekniske siden av produktet.
Vær spesifikk
Det er mye mer nyttig for det tekniske teamet ditt å tildele dem spesifikke, små oppgaver - ikke bare dele ut en haug med mock-ups og fortelle dem at de skal være ferdig innen fredag. Faktisk bør du være den som administrerer prosjektet for dem. Lær hvordan du bruker prosjektstyringsprogramvare som Pivotal Tracker eller Trello og sporer utviklingen av funksjonsutvikling etter dag eller per arbeidsøkt.
Og sjekk inn ofte, både personlig og via prosjektstyringsprogramvaren. Det er mye lettere å forhindre at ting går feil vei hvis du kan fange dem ved gaffelen.
Ikke endre mening hver dag
Jeg vet at du synes dette høres opplagt ut. Men når du er ute og slår og selger produktet ditt hver dag, hører tilbakemeldinger og brainstormer måter å gjøre det bedre - det er veldig enkelt å komme tilbake med nye ideer hele tiden. Ikke gjør dette for laget ditt.
Definer en spesifikk og liten ting du vil bygge: et minimum levedyktig produkt (eller “MVP”). La MVP-enheten din være klar og klar til å bygges. Og gjør den liten. Hvis du designet en gigantisk app, kan du bryte den ned og begynne med en del. Send MVP-enheten din, og endre tankene dine basert på data.
Hvis du ikke allerede har gjort det, kan du lese The Lean Startup av Eric Ries. Følg den - ikke bare kast rundt kule sjargonger på nettverksarrangementer.
Sett mål, ikke tidsfrister
I den tekniske verden fungerer ikke alltid frister. Selv den mest erfarne utvikleren bryter ting, og det er vanskelig å estimere hvor lang tid det vil ta å fikse ting.
Jeg er virkelig inne på Tracker sin idé om å bryte ned funksjoner og tildele vanskelighetspoeng, ikke timer. Merk et problem som "enkelt", "middels" eller "vanskelig", og følg fremdriften i stedet for å holde seg til tidsfrister. Tildele stort sett vanskelige oppgaver? De kan sannsynligvis bli brutt ned ytterligere.
Få en flott designer
Designere løser problemer og kan gjøre produktbyggingsprosessen mye enklere. Spesielt UX / UI (brukeropplevelse og brukergrensesnitt) designere. De hjelper deg med å finne ut hvordan produktet ditt skal se ut og fungere - piksel etter piksel, brukerinteraksjon etter brukerinteraksjon (tenk: Hvilken knapp klikker brukeren neste? Hvor er den på siden? Hvor tar den henne?).
Dette er ikke utviklerens jobb. Jeg er seriøs. Utviklerens jobb er å skrive kode - ikke utforme produktet. En flott designer vil faktisk hjelpe deg å spare på utviklingskostnader, fordi de vil hjelpe teamet med å tenke gjennom og fange ting som andre kan ha oversett. De kan også foreslå å gjøre enkle, men kraftige endringer som vil gjøre produktet ditt mer intuitivt og enklere å bruke.
Samtidig - sørg for at designeren din er mager. Noen ganger er det ikke verdt kostnaden å bygge tilpassede alt. Det er en forskjell mellom oppmerksomhet på detaljer og å være en diva. Hvis utvikleren klager på et design - det er et tegn på at du må stoppe, diskutere det, finpusse det og inngå kompromisser.
Test, Test, Test
Hvis du i det hele tatt bryr deg om produktet ditt, kan du hjelpe utvikleren med å teste det. Hun har stirret på dette i flere timer. Gi henne et nytt sett med øyne. Ber henne for det hun gjorde riktig, og gi henne konkrete oppgaver for det som fremdeles må gjøres eller fikses.
Utviklere klager ofte til meg at de har brukt massevis av tid på noe, og så ble det lansert med ødelagte ting fordi ingen så dem. Husk at det er ditt produkt. Og ingen vil jobbe for noen som ikke bryr seg om produktet de legger ut der.
Kompensere ganske
Du er en forretningsmann, og forretningsfolk forhandler. Vanligvis mye bedre enn ikke-forretningsfolk.
Så vær forsiktig.
Du kan forhandle med en utvikler om prisen hennes, men hvis det høres rimelig ut, er det sannsynligvis. Husk at det er mange andre mennesker der ute som er villige og i stand til å ansette henne for det hun siterte. Og hvis hun føler at hun har blitt forhandlet frem og ikke får kompensert det hun er verdt, er sjansen stor for at hun ikke vil prioritere arbeidet ditt fremfor annet arbeid (eller over andre, morsommere ting). Eller så vil hun finne noen andre som betaler prisen, og lar deg henge igjen. Jeg har sett det om og om igjen.
Et alternativ er å forhandle om en sats for en prøveperiode for en liten funksjon, og fortelle henne at du vil betale hele prisen hvis prosjektet går bra.
Stol på teamet ditt
Er du mistenksom over at utvikleren din polstrer timer eller slapper av ved å gå til nærmeste biergarten? Husk at hvis du ikke ansetter folk du stoler på og som er bedre enn deg til noe, så ansetter du ikke de riktige personene.
Stol på ekspertene du har ansatt for å gjøre jobben sin. Gi dem verktøyene de trenger for å gjøre det, inkludert retning, fleksibilitet, pusterom og autoritet. Og sjekk inn ofte.
