bij een startup adviseer ik, taken die door PMS zijn ingediend voor engineers om te implementeren, hadden een lage/gemiddelde/hoge prioritering.
omdat het een vroege opstartfase is, is er altijd meer werk te doen dan tijd of mensen, dus ingenieurs zijn er nooit toe gekomen om kleine of middelgrote taken uit te voeren.
dus stopte PMs met het indienen van taken met lage en gemiddelde prioriteit.
nu hebben alle taken hoge prioriteit. Dus prioriteiten worden informeel gecommuniceerd: “ja, beide hebben hoge prioriteit, maar X komt voor Y”. Wat natuurlijk leidt tot meningsverschillen: “Waarom heb je A niet afgemaakt? Omdat ik aan B werkte, maar A heeft hogere prioriteit.””Nee, ze hebben dezelfde prioriteit van hoog.”
het interessante is dat dit niet gebeurde omdat één kant het systeem ondermijnde. Integendeel, beide partijen deden wat ze moesten doen onder het systeem. Ingenieurs die de lage en middelgrote taken laten vallen was logisch, omdat het hele punt van prioritering is om te zeggen wat kan worden geschrapt als ze niet allemaal kunnen worden gedaan. De beslissing van de PMs om alleen taken met hoge prioriteit weer in te dienen was logisch, want wat is het nut van het indienen van taken die niet zullen worden gedaan, toch? Dat kost alleen maar tijd voor alle betrokkenen. Bestand het als hoog of niet.
dus het systeem ging kapot.
Wat zijn enkele alternatieven?
een methode voor prioritering die werkt, is het hebben van prioriteiten die objectief zijn gedefinieerd. Bij Google betekende P0 bijvoorbeeld een productie-noodsituatie: stop met wat je doet en werk hieraan. Het is niet onredelijk dat mensen opgepiept worden om een P0 te repareren, die midden in de nacht wakker wordt. P1 betekende een ongewoon hoge prioriteit taak-je hoeft niet te stoppen met wat je doet om te werken aan de P1 (Het is geen P0), maar als je klaar bent met wat je doet, moet je werken aan de P1. P2 werd gebruikt voor de meeste taken. En P3 en P4 zouden nooit klaar zijn.
dit systeem werkte omdat de prioriteiten objectief werden gedefinieerd en breed werden begrepen, zodat mensen terug konden duwen en de juiste prioriteit konden stellen: “nee, dat is geen P0 — het is geen productie noodsituatie” of “nee, dat is geen P1 — Ja, Het is belangrijk, maar het heeft geen voorrang op al het werk dat we hebben.”Terwijl bij laag / gemiddeld / hoog, is een bepaalde taak een medium of een high? Dat is een kwestie van mening. Het kan van alles betekenen, waardoor het systeem instort.
een tweede prioriteitsmethode die werkt, is dat de PM een cyclus of een sprint definieert die bestaat uit een gedefinieerde lijst van taken die binnen een overeengekomen tijd moeten worden uitgevoerd. Als een taak is opgenomen in de huidige cyclus, dat betekent dat het moet worden gedaan deze cyclus, dus prioriteit is minder relevant .
een derde prioriteitsmethode die werkt, is dat de PM een prioriteitenlijst van taken vaststelt. Een genummerde lijst waar de eerste belangrijker is dan de tweede, wat belangrijker is dan de derde, enzovoort. Dit is weer logisch. Uiteindelijk gaat het erom of een ingenieur taak X of Y moet doen, als er geen tijd is om beide te doen. Niet of X in absolute zin medium is, wat toch niet logisch is.
gebruik in ieder geval geen lage/middelhoge / hoge prioritering. Gebruik iets als Trello waar je taken omhoog of omlaag sleept om een impliciete prioriteit in te stellen .
dit werkt vooral goed als de lijst een doel op hoog niveau bevat, zoals lanceerfunctie X. Dat geeft mensen eigendom en motiveert hen.
dit alles veronderstelt natuurlijk dat u competente en goedbedoelde PMs hebt. Ik heb gewerkt met een aantal tweederangs PMs die proberen te proppen zo veel taken mogelijk in een cyclus, en zijn dan boos wanneer dingen langer dan verwacht. Ze kunnen geen prioriteiten stellen. Ze willen alles. Of ze begrijpen de fundamentele afweging in projectmanagement niet, namelijk de afweging tussen tijd, omvang en kwaliteit.
of ze begrijpen al het bovenstaande, maar gebruiken dit om ingenieurs te manipuleren om meer werk uit hen te krijgen. Dit werkt niet lang-ik stopte met het geven van relevante informatie aan de Premier, omdat hij dat meestal zou misbruiken als een kans om mij te bekritiseren. Ik zou alles wat hij zegt uitsluiten. Als hij een meningsverschil had met iemand anders in het team, zou ik beginnen met aan te nemen dat de andere persoon gelijk heeft.
als u een tweederangs of slecht bedoeld PMs heeft, zal geen prioriteringsmethode goed werken.
het is interessant dat bug tracking tools ontworpen voor ingenieurs niet zo goed werken als taak tracking tools ontworpen voor elke vorm van taak. Dit komt waarschijnlijk door de voorkeur van ingenieurs om gewoon een gebruikersinterface bovenop een database te plaatsen. Maar mensen denken niet als een database. Een metafoor uit de echte wereld, zoals een stel kaarten die op een bureau zijn gerangschikt en gesorteerd, kan een beter model zijn.