Эту страницу открывают, когда команда уже обсуждает работу, но у участников нет единого ответа на вопрос, что именно должно появиться на выходе проекта или этапа.
Если результат определён слабо, проект начинает жить в режиме бесконечного «ещё немного доделать». Тогда ломаются приёмка, проверка готовности, демонстрации, а сроки и ожидания становятся спором интерпретаций.
Что это за компетенция
Определение результата — это умение перевести цель проекта в конкретный и наблюдаемый выход: что именно должно быть создано, изменено, внедрено, согласовано или запущено.
Результат отвечает не на вопрос «что мы будем делать», а на вопрос «что должно существовать в конце работы».
Зачем нужна
Навык нужен, чтобы:
- привязать активность команды к реальному выходу;
- сделать обсуждаемыми критерии приёмки;
- не путать процесс выполнения с фактом поставки результата;
- собирать этапы, релизы и границы scope;
- удерживать общее понимание, к чему проект идёт.
Где проявляется в реальной работе
Навык критичен:
- на старте проекта;
- при декомпозиции на этапы;
- при подготовке project brief и ТЗ;
- при согласовании с заказчиком, что именно будет считаться поставленным;
- в проектах, где есть несколько релизов или промежуточных результатов.
Что ломается без неё
- команда выполняет задачи, но проект не приближается к понятному финалу;
- заказчик и исполнители по-разному представляют итог;
- демонстрации превращаются в обсуждение того, «это уже оно или ещё нет»;
- PM не может жёстко отличить результат от списка пожеланий;
- растёт риск бесконечных доработок после формального завершения.
Что можно делегировать, а что нельзя
Нельзя делегировать управленческую ответственность за то, чтобы результат был определён и понятен всем ключевым участникам.
Можно делегировать:
- описание технического наполнения результата;
- детализацию составляющих результата;
- оформление описания в документе или схеме.
Как выглядит слабый уровень
- результат описан как «сделать доработки»;
- он неотличим от списка задач;
- никто не может показать, где заканчивается работа и начинается поддержка;
- каждый стейкхолдер держит в голове свою версию финала.
Как выглядит сильный уровень
- результат можно продемонстрировать, проверить и принять;
- он связан с целью проекта;
- его можно разложить на этапы или поставки;
- по нему можно собрать критерии приёмки и критерии качества;
- он отделён от внутренней активности команды.
Как понять, что это ваш пробел
- можете ли вы коротко объяснить, что будет на выходе проекта;
- можно ли по текущему описанию результата провести приёмку;
- отличается ли описание результата от списка действий;
- понимают ли одинаково результат все ключевые участники.
Что делать пошагово
1. Возьмите текущую цель проекта. 2. Спросите, что должно реально появиться или измениться, чтобы можно было сказать, что цель реализована. 3. Разделите конечный результат, промежуточные результаты и внутренние задачи. 4. Опишите, в каком виде результат будет доступен, проверен и принят. 5. Сверьте его с ожиданиями заказчика и команды. 6. Зафиксируйте результат в основном артефакте проекта.
Рабочий шаблон
Полезно описывать результат через четыре вопроса:
- что именно должно появиться;
- для кого это будет работать;
- в каком объёме или контуре;
- как будет подтверждаться факт готовности.
Практический ориентир
Чтобы не смешивать результат с процессом, удобно раскладывать его по трём типам:
- артефакт: документ, система, интеграция, витрина данных, регламент;
- изменение состояния: процесс запущен, данные перенесены, команда переведена на новый контур;
- управленческое решение: согласованный и зафиксированный вариант, после которого проект может идти дальше.
Если описание результата не попадает ни в один тип и звучит как «провести», «обсудить» или «доработать», значит это ещё не результат, а работа вокруг него.
Как отделить конечный результат от промежуточных
Полезно задавать три вопроса подряд:
1. Что должно быть у проекта на выходе целиком. 2. Какие промежуточные поставки доказывают, что мы движемся к этому выходу. 3. Какие внутренние задачи нужны команде, но не должны попадать в описание результата.
Такая раскладка особенно нужна перед декомпозицией на этапы и сборкой ТЗ, иначе этапы начинают строиться вокруг активности, а не вокруг проверяемых поставок.
Связка с приёмкой
Хорошее описание результата должно почти напрямую переводиться в критерии приёмки. Если между формулировкой результата и проверкой готовности лежит большой слой догадок, результат описан слишком размыто.
Практически полезно проверять:
- можно ли показать результат на демонстрации;
- можно ли по нему собрать проверку готовности;
- можно ли отличить первую поставку от будущих улучшений;
- понятно ли, где заканчивается проект и начинается поддержка или развитие.
Типовые ошибки
- путать результат с процессом;
- описывать результат через активность команды;
- смешивать итоговый результат и полный backlog будущих улучшений;
- не связывать результат с приёмкой;
- не проверять, одинаково ли понимают результат разные участники.
Как качать навык
- на каждом проекте отдельно выписывайте цель, результат и scope;
- после созвонов проверяйте, не скатились ли обсуждения обратно в список задач;
- связывайте описание результата с критериями приёмки и sign-off flow;
- анализируйте споры на демонстрациях: часто они начинаются именно с плохо определённого результата.