Как избежать ошибок при планировании работы над проектом

Во многих командах решения начинают обсуждать до того, как стало понятно, что нужно изменить. Формулировки запроса вроде «оптимизировать снабжение» или «ускорить согласования» кажутся понятными — но часто за ними скрыт набор противоречивых ожиданий и интересов, которые никто не зафиксировал и не свел в общее поле.

В таких случаях ранние выводы работают против результата. Детальная проработка гипотез при незафиксированной ключевой проблеме грозит тратой ресурсов без получения эффекта — потому что изначально никто не проговорил, в чем суть проблемы, для кого она важна и как измеряется успех.

В консалтинге мы не начинаем с предложений. Сначала — проверяем, есть ли сама задача. Если ее нет в рабочем виде, мы собираем ее заново. Это часть нашей профессиональной ответственности.

Изначальная постановка проблемы должна подвергаться критической оценке, даже если проект стартует с готовых гипотез. Формулировка проблемы определяет пространство наших решений и важно понять истинную проблему, очищенную от субъективных суждений заказчика и команды. И это касается даже узких задач, решаемых отдельными стримами и аналитиками. В реальной жизни запрос может трансформироваться, а приоритеты поменяться, и это часть работы консультанта на любом грейде, — быть не просто исполнителем задачи, но и управлять ее границами.

То, как сформулирована задача, влияет не только на стартовые действия в начале проекта, но и на логику итогового решения.

На одном из проектов запрос звучал как «оптимизировать закупки». Но после проработки стало ясно: речь идет о переходе к централизованной модели, перераспределении полномочий и пересборке всей логики управления.

Если бы команда приняла формулировку как есть, результатом были бы технические улучшения без стратегического эффекта. Проблема осталась бы нетронутой.

Если задача сформулирована неточно — это сказывается на всем: от сбора данных до архитектуры решений. Проект идет, ресурсы тратятся, но результат не появляется, потому что начальная точка задана неправильно.

Четкая постановка задачи дает понимание:

• зачем мы это делаем
• где границы и ограничения
• как поймем, что решение найдено
• какие риски и конфликты надо учесть заранее

Чтобы зафиксировать контекст задачи и не терять направление по ходу проекта, мы используем внутренний инструмент — «карту проблемы». В ней фиксируются параметры, которые обычно распадаются по разным документам: суть вопроса, информация о контексте, критерии решения, ограничения, роли и источники. Это не отчет — это рабочая модель, на которую команда опирается в ходе проекта. В ходе ее заполнения мы проверяем, насколько мы в целом понимаем текущую ситуацию и даже фиксируем предварительные гипотезы. Это не означает масштабную проработку, а скорее первый подход к снаряду и погружение в контекст.

Как устроен ownership в команде

В ATK Консалтинг формулировка задачи — не разовая активность на старте и не зона ответственности только руководителя проекта. Если у кого-то в команде возникает сомнение в постановке задачи — это сигнал, а не помеха. Мы не идем дальше, пока не понятно, что именно нужно решить, для кого и зачем.

Ownership в этом контексте — не про инициативность одного сотрудника, а про норму. Даже если ты отвечаешь за один участок, ты не ограничиваешься только им, а держишь в поле зрения суть всего проекта и как твоя работа влияет на другие стримы. Если задача размывается или трансформируется — мы возвращаемся к ней вместе. В такие моменты важно помнить о ценности итеративного подхода, который помогает перепроверить себя и свериться с видением клиента и команды. И такой подход не противоречит понятию ownership, он является его частью.

Аналитик в проекте не ждет «готового запроса». Он участвует в его сборке: уточняет цели, проговаривает противоречия, проверяет фокус команды. 

Когда этой установки нет, проект легко уходит в сторону:

• собираются нерелевантные данные
• обсуждаются решения «на всякий случай»
• действия есть, а результата нет.

Ответственность в проекте — это не контроль задач по списку. Это способность задать вопрос в момент, когда формулировка начинает расползаться, и не бояться приостановить ход работы, чтобы чтобы вернуть проект в рамки осмысленного запроса.

Если не задать правильный вопрос в начале — не поможет ни один план

В проектах с высокой степенью неопределенности важно не только что мы решаем, но и зачем именно мы это делаем. Ответственность начинается не с исполнения, а с проверки того, правильно ли поставлена задача. Если этого не сделать в начале, проект может сохранить активность — но потерять фокус и результат.