Software Premortem - jak zachránit pacienta po jeho smrti?

Jak opravit problémy dříve, než k nim dojde?

Jaký je nápad za premortem?

Myšlenka za premortem je najít problémy dříve, než k nim dojde.

Ve vývoji softwaru, ať už máte formální spuštění velké verze nebo neformální jednu z malých funkcí, je čas v okamžiku, kdy můžete zastavit a představit si, co by se stalo, kdyby.

Koncept premortem podporuje tým, aby předpokládal, že pacient zemřel, nebo ve světě softwaru - projekt selhal. Projekt může selhat poté, co byl uvolněn z několika důvodů.

Možná byla kvalita kódu nízká.

Možná nebyly některé klíčové funkce implementovány, což způsobilo, že přijetí na trh bylo pomalé.

Možná, že zavedení trhu bylo rychlejší, než jsme očekávali, takže počet lidí, kteří jej využívali, byl tak velký, že způsobil problémy s rozsahem infrastruktury, která projekt provozuje.

Možná by bylo mnoho zákazníků, kteří by se obrátili na středisko podpory a položili otázky o nové lesklé funkčnosti, ale oddělení podpory není personálně vybaveno, aby jim odpovědělo, nebo možná ani nevědí, že jsme dodali nový projekt.

Možná, že projekt přinese problémy s ochranou soukromí a naše právní oddělení není ani ve smyčce, nebo možná bílý hacker najde nedostatky v průniku zabezpečení.

Možná, že někdo bude tweetovat negativní zpětnou vazbu na funkci, a to by se stalo virovou.

Možná nebudeme vědět, zda je projekt úspěšný nebo neúspěšný.

Existuje mnoho důvodů, proč může projekt selhat.

Obvykle, když zahájíme nový projekt a začneme jej realizovat, je naše mysl nastavena na konkrétní stav.

Zaměřujeme se na to, abychom včas splnili všechny požadavky dané funkce a splnili jsme lištu kvality. Ve vyspělejší organizaci jsme si možná také stanovili metriky úspěchu.

No, to je vlastně skvělé.

Pokud máme plán a požadavky a lištu kvality a metriky, které je třeba měřit, jsme v pořádku.

Ale sračky se stávají. To je fakt.

Chyby jsou odhaleny po uvolnění projektů.

Okolnosti nejsou známy přinejlepším nebo se mění v nejhorším případě.

Projekty selhávají.

Do prdele.

Ale a to je hlavní myšlenka za premortem, co - pokud se dokážeme dostat do stavu mysli, kde si myslíme, že projekt po jeho vydání skutečně selhal.

Můžeme být ve stavu mysli, že se to vlastně stalo?

Pokud můžeme, Pokud jsme za předpokladu, že se všechno peklo uvolnilo, musíme pochopit proč? Proč se to stalo? Co jsme udělali špatně? Co jsme měli udělat jinak?

Podle výzkumu (dobrý odkaz na něj lze nalézt v příspěvku HBR ze září 2007) a podle mých zkušeností i z minulého roku bychom byli schopni zabránit alespoň některým z nejkritičtějších problémů, které mohou selhat projekt. Úžasné!

Je premortem stejný jako modelování hrozeb?

Ačkoli existují určité podobnosti, není to stejné.

Modelování hrozeb je obvykle předdefinovaná sada otázek, na které musíte odpovědět, abyste se ujistili, že jste se zabýval svou základnou. To je podobná část.

Rozdíl je v tom, že v premortem neodpovídáte na temné otázky. Naopak. Snažíte se dostat do nálady, selhání. Pacient zemřel. Projekt selhal. Svět se zhroutí. Co jsme sakra udělali špatně? Jedná se spíše o představivostní cvičení než o výslech.

Jak to udělat premortem správně? Gamifikace, gamifikace a gamifikace

Dostávat se do požadovaného stavu mysli pro premortem je těžké. Velmi obtížné.

Proč? Nejprve musíte skočit do budoucnosti, a pokud nemáte automobil ...

„Šedé kupé na silnici“ od Francka V. na Unsplash

Za druhé, pacient nezemřel. Projekt nezklamal. Za předpokladu, že selhala, vyžaduje nějakou docela kreativní představivost!

Za třetí, lidé jsou skeptičtí. Vývojáři softwaru jsou cyničtí.

Nedokoupili by se k té předsmrtelné věci.

Ve své mysli byly věci, o kterých si mohli myslet, přemýšleny, a věci, které ne… dobře, nepomohlo by žádné představení.

To je místo, kde se hraje gamifikace a atmosféra.

Vytvořte pozvánku na schůzku kalendáře: Projekt „someProjName“ - premortem “.

Pozvěte celý tým.

Vývojáři, QA, produktoví manažeři, návrháři ux.

Pokud můžete, měli byste pozvat několik dalších lidí, kteří nejsou s tímto projektem tak dobře obeznámeni.

Možná někteří lidé z jiného týmu nebo lidé ze skupiny zákaznické podpory. Na tom opravdu nezáleží. Dobrá věc, která přináší lidem, kteří nejsou součástí týmu, je to, že jsou nejblíže ke skutečnému zákazníkovi.

Před samotnou schůzkou pošlete všem pozvaným pár slov k premortemu, nebo ještě lépe, zašlete jim tento článek (-:

Na samotné schůzce získáte skeptický vzhled.

Nyní musíte nastavit scénu.

Buďte dramatičtí. Ukažte jim obrázky.

„Rozbitá bílá letecká společnost na zemi ve dne“ od Hao Zhanga na Unsplash

Řekněte jim příběh.

Poskytněte na scéně co nejvíce podrobností.

Vyberte konkrétní datum v budoucnosti. Například 3 a půl měsíce po uvedení na trh.

Zjistěte přesné datum. Předpokládejme, že je 14. března 2019.

Zjistěte nějaké zajímavé nepříbuzné podrobnosti o tom dni, které by lidi vladěly.

Například 14. března je pi den. Dejte o tom vědět týmu.

Řekněte jim, že v březnu, 14., přesně v 17:12, 3 minuty před vložením notebooku do batohu, připravením na zavření dne, jste dostali e-mail od generálního ředitele společnosti s následujícím předmětem: URGENT! projekt „someprojname“ - X okamžitě opravit.

Naší úlohou je najít X.

Nyní začínají mít náladu.

Vysvětlete jim, že abyste trochu okořenili, rozdělujete je do dvou skupin.

Červená a modrá.

Před zasedáním připravte předem poznámky s těmito názvy:

  • Bezpečnostní důstojník
  • Vedoucí obchodu
  • Šéf kvality
  • Právní úředník
  • Vedoucí marketingu

Vytvořte jednu sadu modrých poznámek a jednu sadu červených poznámek.

Pokud nemáte dostatek lidí, prostudujte některé tituly (není to kritické).

Nyní předejte klobouk s poznámkami uvnitř a nechte si každý vybrat náhodnou poznámku. Tím se místnost rozdělí na 2 skupiny (červená a modrá), každá osoba s konkrétním názvem.

V tuto chvíli byste mohli cítit napětí ve vzduchu, protože lidé cítí, že se blíží konkurence.

Mají pravdu.

Vysvětlete jim pravidla her.

  • Každá skupina půjde do vyhrazené zasedací místnosti.
  • Každá skupina bude mít 45 minut na to, aby vyřešila nejzávažnější problémy, které způsobily selhání projektu.
  • Každá osoba ve skupině může přispět k problému v jakékoli doméně, ale měla by si pamatovat, že má na starosti konkrétní. To vytváří pro jednotlivce pocit vlastnictví. Žádný náčelník marketingu by si přál, aby během jejich posunu některé zmeškané marketingové materiály / kampaně způsobily nedostatečné povědomí o nové funkčnosti.
  • Po 45 minutách se týmy znovu připojí a překonají problémy.
  • Tým s nejzávažnějšími problémy (můžete to zařadit podle jejich závažnosti nebo ne) vyhraje zmrzlinu, košíček nebo vychvalovací práva.
  • Můžete okořenit výše uvedenými kreativními nápady - rád o nich slyším!

A je to. Jsi hotov. Mým doporučením není pokračovat, ale zastavit schůzku. Cíl setkání byl dosažen. Cílem bylo kreativně přemýšlet o tom, co způsobilo selhání projektu. A je to.

V režimu offline byste měli projít seznam položek, které tým našel, a přeškrtnout věci, které jsou duplikovány nebo nejsou relevantní (protože byly testovány a validovány, s 0 pravděpodobností nebo již byly zpracovány).

Důležitým prohlášením je, že nejste nuceni řešit nebo řešit všechny problémy, které vznikly během předsmrtelné relace. Je na týmu, aby rozhodl o návratnosti investic pro každý z úkolů. Pokud je návratnost investic nízká, zavřete je jako „neopraví se“.

V otázkách, které jsou relevantní, musí tým přiřadit vlastníky, aby bylo možné je řešit v příštích několika dnech před zahájením projektu.

Právě jste uložili projekt.