in a startup I advising, tasks filed by PMS for engineers to implement had a low/medium/high priorisation.
koska kyseessä on alkuvaiheen startup, töitä on aina enemmän kuin aikaa tai ihmisiä, joten insinöörit eivät koskaan päässeet tekemään mitään matala-tai keskitason tehtäviä.
joten PMs lopetti matalan ja keskitason tehtävien kirjaamisen.
nyt kaikki tehtävät ovat etusijalla. Prioriteetit viestitään siis vapaamuotoisesti:”kyllä, molemmat ovat tärkeysjärjestyksessä korkealla, mutta X tulee Y: n edelle”. Mikä luonnollisesti johtaa erimielisyyksiin: ”Miksi et lukenut loppuun?”Koska työstin B: tä, mutta A on tärkeämpi.””Ei, heillä on sama prioriteetti korkea.”
mielenkiintoista on, että näin ei tapahtunut, koska toinen puoli kumosi järjestelmän. Päinvastoin-molemmat osapuolet tekivät sitä, mitä heidän pitikin tehdä järjestelmän alaisuudessa. Insinöörien pudottaminen matalan ja keskitason tehtävistä oli järkevää, koska priorisoinnin koko pointti on sanoa, mitä voi pudottaa, kun kaikkia ei voi tehdä. PMs: n päätös arkistoida vain erittäin tärkeitä tehtäviä oli taas järkevää, koska mitä järkeä on arkistoida tehtäviä, joita ei muutenkaan tehdä? Se vain tuhlaa aikaa kaikilta asianosaisilta. Joko tiedosto se korkea tai ei.
niin järjestelmä hajosi.
mitä vaihtoehtoja on?
toimiva priorisointimenetelmä edellyttää, että prioriteetit määritellään objektiivisesti. Esimerkiksi Googlella P0 tarkoitti tuotantohätää: lopeta se, mitä olet tekemässä, ja tee töitä tämän eteen. Ei ole kohtuutonta, että ihmisiä kutsutaan korjaamaan P0: tä, joka herätetään keskellä yötä. P1 tarkoitti epätavallisen korkea prioriteetti tehtävä-sinun ei tarvitse lopettaa mitä olet tekemässä työskennellä P1 (se ei ole P0), mutta kun olet tehnyt mitä olet tekemässä, sinun täytyy työskennellä P1. P2: ta käytettiin useimmissa tehtävissä. Ja P3 ja P4 eivät koskaan valmistuisi.
tämä järjestelmä toimi, koska prioriteetit oli objektiivisesti määritelty ja laajasti ymmärretty, jotta ihmiset voisivat työntää taaksepäin ja asettaa oikean prioriteetin: ”ei, se ei ole P0 — se ei ole tuotantohätätila” tai ”ei, se ei ole P1 — kyllä, se on tärkeää, mutta se ei mene kaiken työn edelle.”Kun taas matala / keskitaso / korkea, onko tietty tehtävä keskitaso vai korkea? Se on mielipidekysymys. Se voi tarkoittaa mitä tahansa, jolloin järjestelmä hajoaa.
toinen toimiva priorisointimenetelmä on, että PM määrittelee syklin tai pyrähdyksen, joka koostuu määritellystä luettelosta tehtävistä, jotka on tehtävä sovitussa ajassa. Jos tehtävä sisältyy nykyiseen sykliin, se tarkoittaa, että se olisi tehtävä tässä syklissä, joten prioriteetti on vähemmän merkityksellinen .
kolmas toimiva priorisointimenetelmä on, että PM määrittelee priorisoidun tehtävälistan. Numeroitu luettelo, jossa 1. on tärkeämpi kuin 2., joka on tärkeämpi kuin kolmas, ja niin edelleen. Tässäkin on järkeä. Viime kädessä ratkaisevaa on, pitäisikö insinöörin tehdä tehtävä X vai Y, kun ei ole aikaa tehdä molempia. Ei sitä, onko X absoluuttisessa mielessä medium, jossa ei muutenkaan ole järkeä.
älä missään tapauksessa käytä matalaa/keskitasoa/korkeaa priorisointia. Käytä jotain Trello jossa raahaat tehtäviä ylös tai alas asettaa implisiittinen prioriteetti .
tämä toimii erityisen hyvin, Jos listassa on kovatasoinen tavoite, kuten laukaisuominaisuus X. Se antaa ihmisille omistajuutta ja motivoi heitä.
tietenkin kaikki tämä edellyttää, että sinulla on pätevä ja hyvää tarkoittava PMs. Olen työskennellyt joidenkin toisen luokan PMs: ien kanssa, jotka yrittävät sulloa mahdollisimman monta tehtävää kierteeseen ja ovat sitten vihaisia, kun asiat venyvät odotettua pidemmiksi. He eivät osaa priorisoida. He haluavat kaiken. Tai he eivät ymmärrä projektinhallinnan peruslähtökohtaa, nimittäin ajan, laajuuden ja laadun välistä kauppaa.
tai he ymmärtävät kaiken edellä mainitun, mutta käyttävät tätä manipuloidakseen insinöörejä saadakseen heistä enemmän työtä. Tämä ei toimi kauan-lakkasin antamasta olennaisia tietoja pääministerille, koska hän yleensä käytti sitä väärin mahdollisuutena arvostella minua. Vähättelisin kaikkea, mitä hän sanoo. Kun hänellä oli erimielisyyksiä jonkun muun kanssa joukkueessa, aloittaisin olettamalla, että toinen on oikeassa.
jos sinulla on toisen luokan tai pahaa tarkoittava PMs, mikään priorisointimenetelmä ei toimi hyvin.
on mielenkiintoista, että insinööreille suunnitellut vianseurantatyökalut eivät toimi yhtä hyvin kuin mihin tahansa tehtävään suunnitellut tehtäväseurantatyökalut. Tämä johtuu luultavasti insinöörien bias vain laittaa UI päälle tietokantaan. Mutta ihmiset eivät ajattele kuin tietokanta. Reaalimaailman metafora, kuten kasa pöydällä järjestettyjä ja lajiteltuja kortteja, voi olla parempi malli.