A legtöbb terméket fejlesztő csapatnál a backlog az a hely, ahol a sürgősség meghal. Minden, ami bekerül, sürgős volt a hozzáadáskor — egy ügyfélpanasz, egy értékesítési kérés, egy versenytárs funkciója, egy belső ötlet. Hat hónappal később még mindig mind ott van, még mindig mind sürgősnek tűnik, és senki sem tudja pontosan, melyiket kellene következőnek csinálni.
A probléma nem az eszközök hiánya. Több tucat prioritizálási keretrendszer létezik: RICE, MoSCoW, Kano, ICE, súlyozott pontozás. A gond az, hogy a legtöbb keretrendszer valamiféle áltudományos pontosságot követel — számokat rendel az ismeretlenekhez —, amitől szigorúnak tűnik, miközben valójában csak a megérzést mossa tisztára egy táblázaton keresztül.
Ami valóban működik, az egyszerűbb: két dimenzió, őszintén értékelve, és a fegyelem, hogy az eredmény alapján cselekedj.
A prioritizálás két kérdésre egyszerűsödik. Először: mennyit javít ez azon az eredményen, amely számunkra fontos? (Hatás.) Másodszor: mennyibe kerül a megvalósítása? (Erőfeszítés.) Minden más vagy e kettő finomítása, vagy elterel tőlük.
A magabiztosságot (confidence) néha harmadik dimenzióként hozzáadják — „mennyire biztosak vagyunk a hatásban?” —, és érdemes észben tartani. A gyakorlatban azonban a legtöbb csapat tudja, mikor találgat. A fegyelem abban áll, hogy a találgatást őszintén megjelölöd, nem pedig 1–5-ös skálán pontozod és egy képletbe építed.
A nehéz rész nem a mátrix megértése — hanem az őszinteség a kitöltésekor. Minden csapatnak vannak olyan funkciói, amelyeket szívesen megépítene, és amelyek az „Időpazarlás” kategóriába tartoznak, de újra meg újra „Nagy tétek”-ként sorolják át őket. A keretrendszer csak akkor működik, ha a csapat őszinte tud lenni a hatásról.
A hatás az a dimenzió, amelyet a csapatok a legnehezebbnek találnak értékelni, mert gyakran a jövő megjóslását igényli. A kísértés az, hogy számszerűen pontozod, és tudományosnak érzed magad. Jobb megközelítés a kvalitatív, de strukturált.
Tedd fel ezt a három kérdést minden mérlegelt funkcióhoz:
A csapatok rendszeresen alulbecslik az erőfeszítést. Ez jól dokumentált — a tervezési tévedéssel és az optimizmus-torzítással függ össze —, és különösen kifejezett azoknál a funkcióknál, amelyek több rendszert érintenek, csapatok közötti koordinációt igényelnek, vagy olyan képességeket, amelyeket a csapat korábban még nem épített.
Két gyakorlat segít. Először: az erőfeszítés pontozása előtt mindig kérdezd meg a fejlesztőket, ne utána. Azok a termékmenedzserek, akik egyoldalúan pontozzák az erőfeszítést, szinte mindig alulbecsülik. Másodszor: használd az „ismeretlen ismeretlenek” fogalmát kifejezett erőfeszítési szorzóként. Minden olyan funkció, amely a kódbázis egy új területét, egy harmadik fél API-ját vagy egy mostanában nem tesztelt felhasználói folyamatot érint, 1,5-szer magasabb erőfeszítési pontszámot érdemel, mint amit az egyértelmű munka sugall.
A backlogban lévő sürgősség nagy része nem valódi sürgősség — hanem frissesség. Egy ügyfél múlt héten panaszkodott, ezért a kérése sürgetőnek tűnik. Egy versenytárs múlt hónapban kijött valamivel, ezért az utolérése kritikusnak tűnik. De a frissesség nem azonos a fontossággal, és a frissességre való reagálás az egyik legbiztosabb módja annak, hogy a valóban fontos munka háttérbe szoruljon.
Egy gyakorlati teszt: kérdezd meg magadtól, hogy még mindig sürgősnek tartanád-e ezt, ha hat hónapja hallottál volna róla, nem pedig a múlt héten. Ha a válasz nem, akkor az újdonság-torzítás (recency bias) működik, nem a stratégiai prioritás. Jegyezd fel, nyugodtan értékeld a mátrixon, és állj ellen a kísértésnek, hogy előresorold, csak mert friss.
A mátrix nem mindig ad egyértelmű választ. Két elem ugyanabba a negyedbe esik hasonló pontszámmal, és mégis választanod kell egyet. Ilyenkor két döntetlenfeloldó szempont hasznos: a stratégiai illeszkedés (melyik visz közelebb ahhoz, ahol 18 hónap múlva lenni szeretnél?) és a visszafordíthatóság (melyiket nehezebb visszacsinálni, ha rossz?). Részesítsd előnyben azt az elemet, amelyik stratégiailag jobban illeszkedik, és könnyebben visszafordítható.