En CEO sier "kan vi sende dette i mars?" CTO-en sier ja. I mars er det ikke sendt. Ingen av dem løy.
CEO-en hørte: vil kunder kunne bruke dette i mars? CTO-en svarte: vil ingeniørarbeidet være ferdig i mars? Mellom de to setningene sitter QA, app store-gjennomgang, en migrering, et supportteam som trenger opplæring, og en juridisk godkjenning ingen eier. Alle var ærlige. Datoen var fortsatt feil.
Jeg har vært på begge sider av dette bordet — jeg kjørte en startup før jeg ledet ingeniørteam — og det er, mer enn noe teknisk problem, tingen som stille ødelegger roadmaps.
De fire setningene som forårsaker mest skade
- "Nesten ferdig." For en ingeniør: den vanskelige delen er løst. For en leder: arbeidet er nesten ferdig. De gjenstående 10% av det vanskelige er rutinemessig 50% av kalenderen.
- "Bare en liten endring." Liten i grensesnittet er ikke liten i systemet. Å endre et valutafelt er en ettermiddag eller ett kvartal, og ingenting ved forespørselen avslører hvilket.
- "Det er teknisk gjeld." Hørt som: ingeniørene vil rydde opp. Betyr faktisk: en beslutning tatt under tidspres lader nå rente, og betalingen forfaller enten det er planlagt eller ikke.
- "Vi må refaktorere." Nesten alltid et symptom, ikke en forespørsel. Spør hva det vil gjøre mulig. Hvis svaret ikke er et forretningsresultat, er det en preferanse. Hvis det er det, er det en roadmap-post du har priset feil.
Hvorfor det vedvarer
Fordi begge mennesker er rasjonelle. CTO-en gir et teknisk estimat fordi det er delen de kontrollerer og kan forsvare. CEO-en ber om en dato fordi en dato er det styret, kunden og kampanjen alle trenger.
Ingen har feil. Men ingen i rommet eier rommet mellom de to — og det rommet er hvor hver frist dør.
Fire fikser som faktisk fungerer
Spør for datoen noe er foran en bruker
Ikke "når er det ferdig." Når kan en ekte kunde gjøre tingen? Denne enkeltomkodingen overflater alle skjulte avhengigheter — gjennomgang, migrering, opplæring, juridisk — fordi de alle sitter mellom kodekomplett og kundebrukbar.
Få CTO-en til å oppgi hva de antar
Ethvert estimat hviler på antagelser: at en API oppfører seg, at en tredjepart svarer, at ingen blir dratt på noe presserende. Skrevet ned blir de risikker du kan administrere. Uskrevet blir de unnskyldninger i april.
Oversett teknisk arbeid til en forretningssetning
Ikke "vi må migrere databasen." I stedet: "hvis vi ikke migrerer innen Q3, vil innføring av en kunde på over 10 000 seter ta tre uker i stedet for en dag." Nå kan CEO-en prioritere den mot alt annet, som er deres faktiske jobb.
Skill de tre spørsmålene du egentlig stiller
- Kan vi bygge dette? — nesten alltid ja.
- Hva ville vi slutte å gjøre for å bygge det? — spørsmålet folk hopperover, og det eneste som avslører echt kostnad.
- Hva skjer hvis vi har feil om datoen? — bestemmer om du trenger et fast vindu eller et fleksibelt.
Tegnet på at du har dette problemet
Estimater som alltid er ganske riktige på oppgavenivå og alltid feil på utgivelsenivå. Det mønsteret betyr at dine ingeniører estimerer godt og noe mellom ingeniørkraft og kunden er utelatt.
Det er nesten aldri et tilfelle av mennesker som arbeider for sakte. Det er et tilfelle av to mennesker som beskriver ulike mållinjer og antar de er det samme.
Hvis du ikke har noen som gjør oversettelsen
Noen selskaper har denne personen naturlig — en teknisk grunnlegger som har båret en P&L, en VP som kom opp gjennom ingeniørkraft og holdt seg nær virksomheten. De fleste gjør det ikke, og ansetter rundt gapet uten å navngi det.
Det er vanligvis der jeg kommer inn. Ikke for å skrive kode som et godt team kunne skrive, men for å sitte i rommet mellom de to svarene og sikre at de handler om samme mållinjen. Beslutningen om hvorvidt du skal ansette for det permanent er sitt eget spørsmål.