Останні кілька років майже для всіх задач і комунікацій я використовував фреймворк SCR (Situation-Complication-Resolution):
- Situation: Фактичний опис поточної ситуації.
- Complication: Причина, через яку ситуація потребує дій. У чому проблема (або можливість)?
- Resolution: Що нам потрібно зробити, щоб розв’язати цю складність (або скористатися можливістю)? Його плюси — універсальність, простота і наявність контексту. Його легко впровадити й контролювати виконання.
Тут потрібно зробити невеликий відступ. У будь-якої платформної команди є 3 джерела задач (і ще більше типів): задачі від продуктових команд, задачі підтримки/розвитку платформи та інциденти. І вони сильно відрізняються:
- інциденти: термінові задачі, які зазвичай не мають рішення на початковій стадії
- операційні задачі платформи: короткі й передбачають наявність готових рішень у вигляді ранбуків та автоматизації у вигляді скриптів
- задачі розвитку платформи: часто передбачають R&D для побудови можливих рішень, тривають довго і добре працюють через опис проблеми, що вирішується, або бажаного результату
- задачі продуктових команд: їх ставлять люди, які не знають, як їхні задачі будуть вирішувати, плюс важлива валідованість, щоб не було непорозумінь
І з властивостей задач платформної команди випливають мінуси SCR:
- за ним не можна валідовувати результат
- не для всіх задач можна заповнити “рішення” в момент створення
- його часто доводиться заповнювати з середини, бо “ситуацію” доводиться описувати залежно від того, що написано в “складності”, щоб дати весь потрібний контекст, але не писати зайвого. А іноді “ситуацію” взагалі немає сенсу описувати, бо всі все розуміють. Останні два мінуси мінорні, але аналога DoD справді не вистачає.
Тому, поки відпочиваю, я вирішив зробити ще один підхід і подивитися, що ще придумали за останні кілька років. І якось усе сумно. Усі ці PAS, STAR, What-So What-Now What та інші 5W1H підходять для наших задач не краще, ніж SCR і GOS (Goal-Obstacle-Solution), які я використовував раніше.
Ми з o3-mini-high зробили власний фреймворк — G.O.D.S: Goal, Overview, Definition of Done, Solution. Треба б, звісно, зробити красивий сайт. Але не думаю, що вийде це популяризувати. Я все-таки не McKinsey, які розробили SCR. Але в майбутніх проєктах спробую використовувати.