Skip to main content

9 sätt att göra din utvecklare enklare

Dota Basics Episode 1: This is Dota (April 2025)

Dota Basics Episode 1: This is Dota (April 2025)
Anonim

Som en grundare och enstaka freelance produktchef, designer och utvecklare har jag arbetat på båda sidor av bordet: som en utvecklare som hanteras och som en chef som arbetar med en utvecklare.

Så om du är en grundare, produktchef eller någon som arbetar med ett tekniskt team - vill jag dela några saker att göra för att hålla dina anställda lyckliga och göra deras liv enklare.

Varför bry sig? Tja, förutom att helt enkelt vilja vara en bra chef, desto lättare är utvecklarens liv, desto snabbare och mer effektivt kan hon implementera funktioner. Och på internet, där tiden rör sig med hundåren, är det definitivt en fördel.

Här är nycklarna till framgång när du arbetar med ditt tekniska team.

Förstå skillnaden mellan en CTO och Lead Engineer

Du kommer antingen att arbeta med en CTO eller en Lead Engineer, och det är viktigt att förstå att de inte nödvändigtvis är samma person.

Ibland har du en fantastisk CTO som inte bara är teknisk utan också en bra chef, kommunikatör och delegator. Dessa typer vill sannolikt veta allt om vad du bygger, vad slutmålet är för användaren och dina övergripande affärsmål. Toppen! Tro mig, det är en tillgång. Sköta det.

Men för det mesta - speciellt i denna utvecklare-knappa ekonomi - har du en Lead Engineer: en person som är fantastisk att konstruera en produkt, men inte nödvändigtvis har färdigheter (eller önskan) att hantera ett team och produkt.

Ju snabbare du inser vilken typ av person du behöver (eller har anställt), desto bättre förberedda är du att hantera den personen och produkten.

Omsorg om hur saker är

Utvecklare är tillverkare, inte maskiner. Så lyssna på deras idéer och se till att du tänker på dem - även om du inte har någon aning om vad i helvete de pratar om när de börjar kasta tekniska termer. Vet du inte skillnaden mellan den här och den stacken? Fråga. Använd det som en möjlighet att lära sig. Du bör ha minst en grundläggande förståelse för den tekniska sidan av din produkt.

Var specifik

Det är mycket mer användbart för ditt tekniska team att tilldela dem specifika, små uppgifter - inte bara dela ut ett gäng mock-ups och berätta att de ska vara klara på fredag. I själva verket borde du vara den som hanterar projektet för dem. Lär dig hur du använder projekthanteringsprogramvara som Pivotal Tracker eller Trello och spårar utvecklingen av funktionsutveckling per dag eller per arbetssession.

Och kolla in ofta, både personligen och via ditt projekthanteringsprogram. Det är mycket lättare att förhindra att saker går på fel väg om du kan fånga dem vid gaffeln.

Förändra inte ditt sinne varje dag

Jag vet att du tycker att det låter uppenbart. Men när du är ute efter att sälja din produkt varje dag, höra feedback och brainstorma sätt att göra det bättre - det är verkligen lätt att komma tillbaka med nya idéer hela tiden. Gör inte detta för ditt team.

Definiera en specifik och liten sak du vill bygga: en minimal livskraftig produkt (eller "MVP"). Har din MVP specificerad och redo att byggas. Och gör den liten. Om du har designat en gigantisk app, bryt den ner och börja med en del. Skicka din MVP - och ändra sedan tanken baserat på data.

Om du inte redan har gjort det, läs The Lean Startup av Eric Ries. Följ det - släng inte bara coola jargong vid nätverksevenemang.

Ställ in mål, inte tidsfrister

I den tekniska världen fungerar inte alltid tidsfristerna. Även den mest erfarna utvecklaren bryter saker, och det är svårt att uppskatta hur lång tid det tar att fixa saker.

Jag är verkligen inne på Trackers idé att dela upp funktioner och tilldela svårighetspoäng, inte timmar. Markera ett problem som "enkelt", "medium" eller "svårt" och spåra framstegen snarare än att hålla sig till tidsfristerna. Tilldela mestadels svåra uppgifter? De kan antagligen delas upp ytterligare.

Få en bra designer

Formgivare löser problem och kan göra produktbyggprocessen mycket enklare. Speciellt UX / UI (användarupplevelse och användargränssnitt) designers. De hjälper dig ta reda på hur din produkt ska se ut och agera - pixel för pixel, användarinteraktion efter användarinteraktion (tänk: Vilken knapp klickar användaren på nästa sida? Var finns den på sidan? Var tar den henne?).

Detta är inte din utvecklare jobb. Jag är seriös. Din utvecklare har till uppgift att skriva kod - inte utforma produkten. En bra designer hjälper dig faktiskt att spara på utvecklingskostnader, eftersom de hjälper teamet att tänka igenom och fånga saker som andra kan ha förbisett. De kan också föreslå att du gör enkla men kraftfulla förändringar som gör din produkt mer intuitiv och lättare att använda.

Samtidigt - se till att din designer är mager. Ibland är det inte värt kostnaden att bygga anpassade allt. Det är en skillnad mellan uppmärksamhet på detaljer och att vara en diva. Om din utvecklare klagar på en design - det är ett tecken på att du måste stoppa, diskutera det, justera och kompromissa.

Test, Test, Test

Om du bryr dig om din produkt - hjälp din utvecklare att testa den. Hon har stirrat på detta i timmar. Ge henne en ny uppsättning ögon. Beröm henne för vad hon gjorde rätt, och ge henne specifika uppgifter för vad som fortfarande behöver göras eller fixas.

Utvecklare klagar ofta till mig för att de spenderade massor av tid på något och sedan startade det med saker trasiga eftersom ingen såg dem. Kom ihåg att det är din produkt. Och ingen vill arbeta för någon som inte bryr sig om produkten de lägger ut där.

Kompensera ganska

Du är en affärsperson och affärsmän förhandlar. Vanligtvis mycket bättre än icke-affärsmän.

Så var försiktig.

Du kan förhandla med en utvecklare om hennes ränta, men om det låter rimligt är det förmodligen. Tänk på att det finns många andra där ute som är villiga och kan anställa henne för vad hon citerade. Och om hon känner att hon har förhandlats ut och hon inte kompenseras för vad hon är värd, är chansen stor att hon inte kommer att prioritera ditt arbete framför annat arbete (eller över andra, roligare saker). Eller så hittar hon någon annan som kommer att betala hennes ränta och sedan låta dig hänga. Jag har sett det om och om igen.

Ett alternativ är att förhandla om en ränta under en provperiod för en liten funktion, och säga till henne att du ska betala hela priset om projektet går bra.

Lita på ditt team

Är du misstänksam över att din utvecklare stoppar timmar eller slackar av genom att gå till närmaste biergarten? Kom ihåg att om du inte anställer människor du litar på och som är bättre än du på något, så anställer du inte rätt personer.

Lita på de experter du har anställt för att göra sitt jobb. Ge dem de verktyg de behöver för att göra det, inklusive riktning, flexibilitet, andningsrum och auktoritet. Och kolla in ofta.