Софтуер Premortem - как да спасим пациента след смъртта му?

Как да отстраним проблемите, преди те да се появят?

Каква е идеята зад предсказанието?

Идеята, която стои зад преморте, е да се намерят проблеми, преди да се появят.

При разработването на софтуер, независимо дали имате официално стартиране на голямо издание или неформално нещо от малка функция, има момент във времето, в който можете да спрете и да си представите какво би станало, ако.

Концепцията на предродия насърчава екипа да приеме, че пациентът е починал или в софтуерния свят - проектът се е провалил. Проектът може да се провали след пускането му поради няколко причини.

Може би качеството на кода беше ниско.

Може би някои ключови характеристики не бяха приложени, което доведе до бавно усвояване на пазара.

Може би, приемането на пазара беше по-бързо, отколкото очаквахме, следователно, броят на хората, които го използват, беше толкова голям, че предизвика мащабни проблеми за инфраструктурната услуга, която изпълнява проекта.

Може би ще има много клиенти, които се обаждат в центъра за поддръжка, за да задават въпроси относно новата лъскава функционалност, но отделът за поддръжка не разполага с персонал, който да им отговори, или може би дори не знаят, че сме доставили нов проект.

Може би проектът ще въведе проблеми с поверителността, а правният ни отдел дори не е в контура или може би бял хакер ще открие пропуски в сигурността.

Може би някой ще туитва отрицателна обратна връзка за функцията и тя ще стане вирусна.

Може би няма да знаем дали проектът е успешен или неуспешен.

Има много причини даден проект може да се провали.

Обикновено, когато стартираме нов проект и започнем да го реализираме, умът ни е настроен на конкретно състояние.

Ние сме насочени да изпълним всички изисквания на функцията навреме, отговаряйки на някаква лента за качество. В по-зряла организация може би сме задали и няколко показателя за успех.

Е, това всъщност е страхотно.

Ако имаме план и изисквания и лента за качество и показатели за измерване, ние сме добри.

Но, лайна се случва. Това е факт.

Грешки се разкриват след пускането на проекти.

Обстоятелствата не са известни в най-добрия случай или се променят в най-лошия.

Проектите се провалят.

Лайна се случва.

Но и това е основната идея, която стои зад премора, какво - ако можем да се приведем в състояние на ума, в което смятаме, че проектът наистина се е провалил, след като сме го пуснали.

Можем ли да сме в състояние на ума, че всъщност лайна се е случило?

Ако можем, ако сме под предположението, че целият ад се е разпаднал, тогава трябва да разберем защо? Защо това се е случило? Какво сме погрешили? Какво трябваше да направим по различен начин?

Според изследването (добро препращане към него може да бъде намерено в публикацията на HBR от септември 2007 г.) и според моя опит от миналата година бихме могли да предотвратим поне някои от най-критичните проблеми, които може да се провалят проект. Страхотно!

Преморте е същото като моделирането на заплахи?

Въпреки че има някои прилики, не е същото.

Моделирането на заплахи обикновено е предварително определен набор от въпроси, на които трябва да отговорите, за да сте сигурни, че сте покрили основата си. Това е подобна част.

Разликата е в това, че в предродия не отговаряте на шаблонирани въпроси. Напротив. Опитвате се да влезете в настроение, на провал. Пациентът е починал. Проектът се провали. Светът се срива, какво по дяволите сме погрешили? Това е по-скоро тренировка за въображение, отколкото разпит.

Как да направим премъртния десен? Gamification, Gamification и Gamification

Да влезеш в нужното състояние на духа за предмъртеле е трудно. Много трудно.

Защо? На първо място, трябва да скочите в бъдещето и ако нямате автомобила ...

„Сиво купе на път“ от Франк В. на Unsplash

Второ, пациентът не е умрял. Проектът не се провали. Ако приемем, че се е провалил, изисква малко творческо въображение!

Трето, хората са скептични. Софтуерните разработчици са цинични.

Те не биха се присъединили към всичко предимствено.

Според тях нещата, за които биха могли да се замислят, са били обмислени и неща, които не са ... е, никакви упражнения за въображение не биха помогнали.

Това е мястото, където играта и атмосферата идват да играят.

Създайте покана за среща в календара: Проект „someProjName“ - предварителен дизайн “.

Поканете целия екип.

Разработчици, QA, продуктови мениджъри, ux дизайнери.

Ако можете, трябва да поканите още няколко души, които не са толкова запознати с този проект.

Може би някои хора от друг екип или хора от групата за поддръжка на клиенти. Всъщност няма значение. Хубавото на това да привлечете хора, които не са частен екип е, че те са най-близкото нещо, което трябва да имате на истински клиент.

Преди самата среща изпратете на всички поканени няколко думи за предимство, или още по-добре, изпратете им тази статия (-:

В самата среща ще получите скептични погледи.

Сега трябва да настроите сцената.

Бъдете драматични. Покажете им снимки.

„Разрушена бяла авиокомпания на земята през деня“ от Хао Джан на Unsplash

Разкажете им история.

Предоставете колкото се може повече подробности на сцената.

Изберете конкретна дата в бъдеще. Например 3 и половина месеца след изстрелването.

Разберете точната дата. Да допуснем, че това е 14 март 2019 г.

Разберете някои интересни несвързани подробности за този ден, които биха поставили хората в настроение.

Например 14 март е пи ден. Уведомете екипа за това.

Кажете им, че на 14.03. проект “someprojname” - поправете X веднага.

Нашата работа е да намерим X.

Сега те започват да влязат в настроение.

Обяснете им, че за да подправите нещата, ги разделяте на 2 групи.

Червени и сини.

Преди срещата подгответе предварително бележки със следните заглавия:

  • Охранител
  • Началник на бизнеса
  • Началник на качеството
  • Юридически служител
  • Началник на маркетинг

Създайте един комплект сини бележки и един комплект червени бележки.

Ако нямате достатъчно хора, просто пропуснете някои от заглавията (това не е критично).

Сега прекарайте шапка с бележките вътре и оставете всеки да избере случайна бележка. Това ще раздели помещението на 2 групи (червено и синьо), всеки човек с конкретно заглавие.

В този момент бихте могли да усетите напрежението във въздуха, тъй като хората усещат, че идва конкуренция.

Те са прави.

Обяснете им правилата на игрите.

  • Всяка група ще отиде в специална зала за срещи.
  • Всяка група ще има 45 минути, за да излезе с най-сериозните проблеми, които доведоха до неуспех на проекта.
  • Всеки човек от групата може да допринесе за издаване в каквато и да е област, но трябва да помни, че е специално отговорен за определен. Това създава у индивида чувство за собственост. Никой началник на маркетинга не би искал това по време на смяната им, някои пропуснати маркетингови материали / кампании предизвикаха липса на осведоменост за нова функционалност.
  • След 45 минути екипите ще се присъединят отново и ще преодолеят проблемите.
  • Екипът с най-сериозни проблеми (можете да го класирате според тежестта им или не) ще спечели сладолед, или кекс или права на самохвалство.
  • Можете да подправите горното със собствените си креативни идеи - обичам да чувам за тях!

Това е. Ти си готов. Моята препоръка е да не продължавате, а да спрете срещата. Целта на срещата беше постигната. Целта беше творчески да се мисли какво е причинило проекта да се провали. Това е.

Офлайн трябва да прегледате списъка с елементи, които екипът е намерил, и да очертаете неща, които са дублирани или неотносими (тъй като те са тествани и валидирани, или с 0 вероятност, или вече са обработени).

Важен отказ от отговорност тук е, че не сте принудени да поправяте или да не се справяте с всички проблеми, които са били повдигнати по време на предизборната сесия. От екипа зависи да реши ROI (Възвръщаемост на инвестициите) за всяка от задачите. Ако възвръщаемостта на инвестициите е ниска, затворете ги като „няма да поправим“.

За проблемите, които са уместни, екипът трябва да назначи собственици, за да може да се работи през следващите няколко дни, преди проектът да стартира на живо.

Току-що запазихте проект.