i en oppstart jeg anbefaler, oppgaver arkivert Av PMs for ingeniører å implementere hadde en lav/middels / høy prioritering.
siden det er en tidlig oppstart, er det alltid mer arbeid å gjøre enn tid eller folk, så ingeniører kom aldri til å gjøre noen lave eller mellomstore oppgaver.
Så PMs sluttet å arkivere lav og middels prioriterte oppgaver.
nå er alle oppgaver høyt prioritert. Så prioriteringer kommuniseres uformelt: «ja, begge er høy prioritet, Men X kommer før Y». Som naturlig fører til uenigheter: «Hvorfor gjorde Du ikke ferdig A?»»Fordi Jeg jobbet På B. «» Men A er høyere prioritet.»»Nei, de har samme prioritet av hoy.»
det interessante er at dette ikke skjedde fordi den ene siden undergravde systemet. Tvert imot-begge sider gjorde det de skulle gjøre under systemet. Ingeniører som slipper de lave og mellomstore oppgavene, var fornuftige fordi hele poenget med prioritering er å si hva som kan slippes når de ikke alle kan gjøres. PMs ‘ beslutning om å sende bare høyt prioriterte oppgaver igjen var fornuftig fordi hva er poenget med å arkivere oppgaver som ikke vil bli gjort, uansett? Å gjøre det bare kaster bort tid for alle involverte. Enten fil det så høyt eller ikke.
så systemet brøt sammen.
Hva er noen alternativer?
en prioriteringsmetode som fungerer er å ha prioriteringer som er objektivt definert. På Google, for Eksempel, betydde P0 en produksjonskrise: stopp hva du gjør og arbeid på dette. Det er ikke urimelig for folk å bli paged for å fikse En P0, våknet midt på natten. P1 betydde en uvanlig høy prioritert oppgave — du trenger ikke å stoppe hva du gjør for å jobbe På P1 (det er ikke En P0), men når du er ferdig med det du gjør, må du jobbe Med P1. P2 ble brukt til de fleste oppgavene. Og P3 Og P4 ville ikke bli gjort, noensinne.
dette systemet fungerte fordi prioriteringene var objektivt definert og bredt forstått, slik at folk kunne presse tilbake og sette riktig prioritet: «Nei, Det er ikke En P0 — det er ikke en produksjonskrise» eller «Nei, Det er Ikke En P1 — ja, det er viktig, men det har ikke forrang over alt arbeidet vi har.»Mens med lav / middels / høy, er en bestemt oppgave et medium eller en høy? Det er et spørsmål om mening. Det kan bety noe, forårsaker systemet til å bryte ned.
EN annen prioriteringsmetode som fungerer, er AT PM skal definere en syklus eller en sprint som består av en definert liste over oppgaver som skal gjøres i en avtalt tidsperiode. Hvis en oppgave er inkludert i gjeldende syklus, betyr det at det skal gjøres denne syklusen, så prioritet er mindre relevant .
EN tredje prioriteringsmetode som fungerer, er AT PM definerer en prioritert oppgaveliste. En nummerert liste hvor 1. er viktigere enn 2., noe som er viktigere enn den tredje, og så videre. Dette er igjen fornuftig. Til syvende og sist er det viktig om en ingeniør skal gjøre oppgave X eller Y, når det ikke er tid til å gjøre begge deler. Ikke Om X er medium i absolutt forstand, noe som ikke gir mening uansett.
bruk I alle fall ikke en lav/middels/høy prioritering. Bruk Noe Som Trello der du drar oppgaver opp eller ned for å angi en implisitt prioritet .
dette fungerer spesielt godt hvis listen består av et høyt nivå mål, som launch feature X. Det gir folk eierskap og motiverer dem.
selvfølgelig antar alt dette at du har kompetent Og velmenende PMs. Jeg har jobbet med noen annenrangs PMs som prøver å stappe så mange oppgaver som mulig inn i en syklus, og er så sint når ting lenger enn forventet. De kan ikke prioritere. De vil ha alt. Eller de forstår ikke den grunnleggende avviket i prosjektledelse, nemlig avviket mellom tid, omfang og kvalitet.
eller de forstår alt ovenfor, men bruk dette til å manipulere ingeniører for å få mer arbeid ut av dem. Dette virker ikke lenge – jeg sluttet å gi relevant informasjon til PM, fordi han vanligvis ville misbruke det som en mulighet til å kritisere meg. Jeg ville rabatt alt han sier. Når han hadde en uenighet med noen andre i laget, ville jeg begynne med å anta at den andre personen har rett.
hvis Du har annenrangs Eller dårlige hensikter, vil ingen prioriteringsmetode fungere bra.
det er interessant at feilsporingsverktøy designet for ingeniører ikke fungerer, så vel som oppgavesporingsverktøy designet for noen form for oppgave. Dette er sannsynligvis på grunn av ingeniørers bias å bare sette ET BRUKERGRENSESNITT på toppen av en database. Men mennesker tenker ikke som en database. En ekte metafor som en haug med kort arrangert og sortert på et skrivebord kan være en bedre modell.