i en opstart anbefaler jeg, at opgaver, der blev indgivet af PMs for ingeniører at implementere, havde en lav/medium/høj prioritering.
da det er en tidlig opstart, er der altid mere arbejde at gøre end tid eller mennesker, så ingeniører kom aldrig rundt til at lave lave eller mellemstore opgaver.
så PMs stoppet arkivering lav og medium prioriterede opgaver.
nu er alle opgaver højt prioriteret. Så prioriteter kommunikeres uformelt:”Ja, begge har høj prioritet, men H kommer før Y”. Hvilket naturligvis fører til uenigheder: “Hvorfor er du ikke færdig med A?””Fordi jeg arbejdede på B. “” Men A er højere prioritet.””Nej, de har samme prioritet som høj.”
det interessante er, at dette ikke skete, fordi den ene side undergravede systemet. Tværtimod-begge sider gjorde, hvad de skulle gøre under systemet. Ingeniører, der droppede de lave og mellemstore opgaver, gav mening, fordi hele pointen med prioritering er at sige, hvad der kan tabes, når de ikke alle kan gøres. PMs ‘ beslutning om kun at indgive højt prioriterede opgaver igen gav mening, fordi hvad er meningen med arkiveringsopgaver, der alligevel ikke vil blive gjort? Dette spilder kun tid for alle involverede. Enten fil det så højt eller ikke.
så systemet brød sammen.
hvad er nogle alternativer?
en prioriteringsmetode, der fungerer, er at have prioriteter, der er objektivt defineret. Hos Google betød P0 for eksempel en produktionsnødsituation: stop det, du laver, og arbejd på dette. Det er ikke urimeligt for folk at blive siddet for at rette en P0, vågnet op midt om natten. P1 betød en usædvanlig høj prioriteret opgave — du behøver ikke stoppe, hvad du laver for at arbejde på P1 (Det er ikke en P0), men når du er færdig med det, du laver, skal du arbejde på P1. P2 blev brugt til de fleste opgaver. Og P3 og P4 ville aldrig blive gjort.
dette system fungerede, fordi prioriteterne var objektivt defineret og bredt forstået, så folk kunne skubbe tilbage og sætte den rigtige prioritet: “Nej, det er ikke en P0 — det er ikke en produktionssituation” eller “nej, det er ikke en P1 — ja, det er vigtigt, men det har ikke forrang for alt det arbejde, vi har.”Mens med lav/medium/høj, er en bestemt opgave et medium eller en høj? Det er et spørgsmål om mening. Det kan betyde noget, hvilket får systemet til at bryde ned.
en anden prioriteringsmetode, der fungerer, er, at PM definerer en cyklus eller en sprint bestående af en defineret liste over opgaver, der skal udføres inden for en aftalt tid. Hvis en opgave er inkluderet i den aktuelle cyklus, betyder det, at den skal udføres denne cyklus, så prioritet er mindre relevant .
en tredje prioritetsmetode, der fungerer, er, at PM definerer en prioriteret liste over opgaver. En nummereret liste, hvor 1.er vigtigere end 2., hvilket er vigtigere end den tredje osv. Dette giver igen mening. I sidste ende er det vigtigt, om en ingeniør skal udføre opgave H eller Y, når der ikke er tid til at gøre begge dele. Ikke om K er medium i absolut forstand, hvilket alligevel ikke giver mening.
brug under alle omstændigheder ikke en lav/medium/høj prioritering. Brug noget som Trello, hvor du trækker opgaver op eller ned for at indstille en implicit prioritet .
dette fungerer især godt, hvis listen indeholder et mål på højt niveau, som f. eks. Det giver mennesker ejerskab og motiverer dem.
selvfølgelig forudsætter alt dette, at du har kompetent og velmenende PMs. Jeg har arbejdet med nogle andenrangs PMs, der forsøger at proppe så mange opgaver som muligt ind i en cyklus, og er så vred, når tingene længere end forventet. De kan ikke prioritere. De vil have det hele. Eller de forstår ikke den grundlæggende afvejning i projektledelse, nemlig afvejningen mellem tid, omfang og kvalitet.
eller de forstår alt det ovenstående, men bruger dette til at manipulere ingeniører for at få mere arbejde ud af dem. Dette fungerer ikke længe — jeg stoppede med at give relevant information til premierministeren, fordi han normalt ville misbruge det som en mulighed for at kritisere mig. Jeg ville rabat alt, hvad han siger. Da han var uenig med nogen anden i holdet, ville jeg begynde med at antage, at den anden person har ret.
hvis du har andenrangs eller dårlig hensigt PMs, vil ingen prioriteringsmetode fungere godt.
det er interessant, at fejlsporingsværktøjer designet til ingeniører ikke fungerer så godt som opgavesporingsværktøjer designet til enhver form for opgave. Dette skyldes sandsynligvis ingeniørernes bias for bare at sætte et brugergrænseflade oven på en database. Men mennesker tænker ikke som en database. En metafor i den virkelige verden som en flok kort arrangeret og sorteret på et skrivebord kan være en bedre model.