w startupie radzę, zadania złożone przez PMs dla inżynierów do wdrożenia miały niski/średni/wysoki priorytet.
ponieważ jest to startup na wczesnym etapie, zawsze jest więcej do zrobienia niż czas lub ludzie, więc inżynierowie nigdy nie wykonywali żadnych niskich lub średnich zadań.
więc PMs przestał wypełniać zadania o niskim i średnim priorytecie.
teraz wszystkie zadania mają wysoki priorytet. Tak więc priorytety są przekazywane nieformalnie: „tak, oba mają wysoki priorytet, ale X jest przed Y”. Co naturalnie prowadzi do nieporozumień: „Dlaczego nie skończyłeś A? Ponieważ pracowałem nad B. Ale A jest priorytetem.””Nie, mają ten sam priorytet wysokiego.”
ciekawe jest to, że tak się nie stało, bo jedna strona wywróciła system. Wręcz przeciwnie — obie strony robiły to, co miały robić w ramach systemu. Inżynierowie rezygnując z niskich i średnich zadań mieli sens, ponieważ cały sens priorytetyzacji polega na tym, co można porzucić, gdy nie można zrobić wszystkiego. Decyzja PMs o ponownym składaniu tylko zadań o wysokim priorytecie miała sens, ponieważ jaki jest sens składania zadań, które i tak nie zostaną wykonane? Marnuje to tylko czas dla wszystkich zaangażowanych. Albo plik jako wysoki, albo nie.
więc system się zepsuł.
jakie są alternatywy?
metoda ustalania priorytetów, która działa, ma mieć priorytety, które są obiektywnie zdefiniowane. W Google, na przykład, P0 oznaczało awaryjne produkcji: zatrzymać to, co robisz i pracować nad tym. Nie jest nierozsądne, aby ludzie byli wzywani do naprawy P0, obudzeni w środku nocy. P1 oznaczało zadanie o niezwykle wysokim priorytecie — nie musisz przerywać tego, co robisz, aby pracować na P1 (nie jest to P0), ale kiedy skończysz z tym, co robisz, musisz pracować na P1. P2 był używany do większości zadań. A P3 i P4 nigdy by się nie udało.
ten system działał, ponieważ priorytety były obiektywnie zdefiniowane i szeroko rozumiane, więc ludzie mogli odepchnąć i ustawić odpowiedni priorytet: „nie, to nie jest P0 — to nie jest nagły wypadek produkcyjny” lub „nie, to nie jest P1 — tak, to ważne, ale nie ma pierwszeństwa nad całą naszą pracą.”Podczas gdy w przypadku niskiego / średniego / wysokiego, czy dane zadanie jest średnie czy wysokie? To kwestia opinii. Może oznaczać wszystko, powodując awarię systemu.
druga metoda ustalania priorytetów, która działa, polega na tym, że PM definiuje cykl lub sprint składający się z określonej listy zadań do wykonania w uzgodnionym czasie. Jeśli zadanie jest zawarte w bieżącym cyklu, oznacza to, że powinno być wykonane w tym cyklu, więc priorytet jest mniej istotne .
trzecia metoda ustalania priorytetów, która działa, polega na tym, że PM definiuje listę priorytetów zadań. Numerowana lista, w której pierwsza jest ważniejsza od drugiej, która jest ważniejsza od trzeciej i tak dalej. To znowu ma sens. Ostatecznie liczy się to, czy inżynier powinien wykonać zadanie X czy Y, gdy nie ma czasu na jedno i drugie. Nie, czy X jest medium w sensie absolutnym, co i tak nie ma sensu.
w każdym razie nie używaj niskiego/średniego / wysokiego priorytetu. Użyj czegoś takiego jak Trello, gdzie przeciągasz zadania w górę lub w dół, aby ustawić Ukryty priorytet .
działa to szczególnie dobrze, jeśli lista zawiera cel wysokiego poziomu, taki jak launch feature X. To daje ludziom poczucie własności i motywuje ich.
oczywiście wszystko to zakłada, że masz kompetentne i dobre intencje PMs. Pracowałem z kilkoma drugorzędnymi PMs, którzy próbują wcisnąć jak najwięcej zadań w cykl, a następnie są źli, gdy rzeczy są dłuższe niż oczekiwano. Nie mogą ustalać priorytetów. Chcą wszystkiego. Albo nie rozumieją zasadniczego kompromisu w zarządzaniu projektami, a mianowicie kompromisu między czasem, zakresem i jakością.
lub rozumieją to wszystko, ale używają tego do manipulowania inżynierami, aby uzyskać więcej pracy z nich. To nie działa na długo-przestałem podawać istotne informacje premierowi, ponieważ zwykle nadużywałby tego jako okazji do krytyki mnie. Odrzuciłbym wszystko, co mówi. Kiedy nie zgadzał się z nikim innym w zespole, zaczynałem od założenia, że ta druga osoba ma rację.
jeśli masz drugorzędne lub złe intencje PMs, żadna metoda ustalania priorytetów nie zadziała dobrze.
to ciekawe, że narzędzia do śledzenia błędów zaprojektowane dla inżynierów nie działają tak dobrze, jak narzędzia do śledzenia zadań zaprojektowane do każdego rodzaju zadań. Jest to prawdopodobnie spowodowane tendencją inżynierów do umieszczania interfejsu użytkownika na bazie danych. Ale ludzie nie myślą jak baza danych. Lepszym modelem może być metafora w prawdziwym świecie, taka jak kilka kart ułożonych i posortowanych na biurku.