PRODUCTFLOW a barátod
Körülvesz minket a termékfejlesztés. Mindig, amikor valami meglévőt változtatunk, vagy új dolgot hozunk létre, szükségszerűen “termékfejlesztünk”. A skála igen széles, vacsorakészítéstől egy atomerőmű megtervezéséig. A feladat komplexitásától és méretétől függetlenül vannak közös pontok. Ilyen, reményeink szerint mindenhol, egy végcél, egy vízió. Vannak szükséges alapanyagok, eszközök, kompetenciák. És jellemzően időkeret is.
Mindemellett elkerülhetetlen döntési helyzetek garmadája, és számtalan kihívás kísér az utadon.
Néhány tipikus eset:
- Várjunk a UX-re, hogy véglegesítse a protókat, vagy vágjunk bele a munkába azzal, amink van? A vezetés azt várja el tőlünk, hogy azonnal kezdjünk, de ez egy csomó reworkkel járna. Ugyanakkor, ha megvárjuk a végleges prototípusokat, biztosan nem készülünk el időre.
- Maradjunk a klasszikus projektszervezetnél, hiszen minden stakeholder és csapattag látott már olyat, vagy tegyünk időt és energiát a scrum megtanulásába, mert ez tűnik a helyes és korszerű döntésnek?
- Mit csináljak vacsorára? Csirkeszárnyat, mert finom és van benne fehérje, vagy tésztát, mert 4 perc alatt kész?
Ezek mind döntési pontok, ahol mérlegelnünk kell. Előfordul, hogy az intuíció és a vágyakozás megfelelő tanácsadó, hisz ritkán végzünk kiterjedt kockázatelemzést például a rendkívül súlyos “csirkeszárny vagy tészta” kérdés megválaszolásakor.
Viszont üzleti környezetben, ha a cél az optimális végeredmény elérése, igenis elemzünk (de legalábbis illene) a döntés meghozatala előtt. Az ilyen, értékláncban elhelyezkedő döntések meghozatalában tud a PRODUCTFLOW-szemléletű termékfejlesztés segíteni…
Gazdasági és matematikai eszközöket vet be a tudatos döntéshozás támogatásához ahelyett, hogy a döntéseket dogmák mentén, intuitívan, vagy filozófiai kérdésként kezelnénk. Tudomásul kell tudnunk venni a trade-offok elkerülhetetlenségét, a variabilitás meglétét és kell egy segítség, hogy ezeket legalább mitigálni, és ahol lehetséges, értékként tudjuk kezelni.
Amikor a termékfejlesztés kapcsán felmerülő kihívásokra gondolunk -sok más mellett persze-
- A határidőket tartani képtelen csapatok,
- Kínosan lassú jóváhagyási folyamatok,
- Általános kiszámíthatatlanság,
- Tragikus bukási ráta juthatnak eszünkbe
Ezek nagyon is valódi és látható problémák. És gyakran nem többek, mint néhány sokkal kevésbé látható, de nem kevésbé valódi jelenség tünetei. Ezen háttérproblémák kezelése sokkal kevésbé intuitív, mint a jól ismert tüneteké, de cserébe oki kezelés. Nem ártalomcsökkentés, hanem gyógymód és megelőzés.
A csapatok következetesen megcsúsznak a szállítással.
Miért nem nézünk rá a queue-ikra (sorban álló feladatok)? Lehetséges, hogy nagyon is képesek lennének időre szállítani, ha egyszerre kevesebb dologgal kellene foglalkozniuk. Csökkentsük hát a kihasználtságukat, és helyezzük a fókuszt a legértékesebb elemekre. Igen, kontraintuitív. És működik.
Egy hónapot kellett várnunk egy tesztmenedzsment szoftver megvásárlásának jóváhagyására.
Nyilván. A döntéshozónak lehet, hogy fontosabb dolga van, mint egy fejlesztő 160$-os szoftvervásárlási igényét elbírálni. Adjunk döntési jogkört a fejlesztőknek! Hozzunk olyan szabályokat, amik biztosítják, hogy a döntéseik a teljes szervezet célját szolgálják. Mikromenedzsment helyett gyakoroljuk a kontrollt transzparencián és önszerveződésen keresztül.
- Kiszámíthatatlanság. Hát, a termékfejlesztés természeténél fogva variábilis.
Önmagában ez nem probléma. A variabilitás negatív gazdasági hatásai viszont nagyon határozottan problémát jelentenek. Kezeljük inkább azokat. Gyakran, amikor egy adott kompetenciára nő az igény, egy másikra csökken. Tegyük lehetővé, hogy a csapat tagjai segíthessenek egymásnak. Csökkentsük a kihasználtságot, adjunk nekik időt, hogy krosszkompetenssé váljanak, és használjuk ki ezt a felmerülő negatív kovarianciát.
- Szégyenletes volt a bukási ráta.Élesítés után rászántunk egy hónapot, hogy az összes rögzített hibát kijavítsuk, és az egy héttel ezután visszakapott tesztriport még mindig tele volt vörössel.
Rövidítsünk a ciklusidőn. Iteráljunk többet. Adjunk ki több, kisebb csomagot. Nem lesznek öreg hibajegyek. A helytelen feltételezések, félreértések sokkal rövidebb ideig maradnak a rendszerben, és sokkal könnyebb lesz az értékes célpontokon tartani a fókuszt.
Az a tudás és eszközkészlet, amit a PRODCTFLOW megközelítés nyújt, nem ezüstgolyó. Hanem egy tapasztalati úton validált, közgazdasági alapokra, valószínűségszámítási és statisztikai módszerekre felépített keretrendszer, ami segít azonosítani a nem nyilvánvaló javítási potenciállal bíró területeket. Így gazdaságilag tudatosabb(!) döntéseket hozhatunk, és muníciót kapunk ahhoz is, hogy ezeket a döntéseket a stakeholdereknek is át tudjuk adni.