Communication Framework

Останні кілька років майже для всіх завдань та комунікацій я використовував фреймворк SCR (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 (https://gist.github.com/korchasa/49da2144e2e21a6cec2af53b78c4e9ec): Goal, Overview, Definition of Done, Solution. Треба було б, звісно, гарний сайт зробити. Але не думаю, що вдасться цю справу популяризувати. Я все-таки не McKinsey, які розробили SCR. Але в майбутніх проєктах спробую використати.