Герой материала — начинающий менеджер проектов Игорь, который старается планировать работу команды и соблюдать дедлайны. Пока что у него не очень выходит: на каждом этапе происходит что-то неожиданное, и сроки сдвигаются. Но пришло время научиться работать в этом хаосе: Игоря ждёт важный запуск, и ему нужно поскорее понять, как предсказывать и учитывать возможные трудности.

Разберёмся, какие инструменты могут помочь Игорю (и тем, кто узнал в нашем выдуманном персонаже себя), вместе с Тарасом Пащенко, заведующим лабораторией проектирования содержания образования в НИУ ВШЭ и соавтором курса «Критическое мышление: анализ информации, аргументация и принятие решений» в Яндекс.Практикуме, и Виктором Горбатовым — сооснователем «Свободного университета», преподавателем логики и наставником в Практикуме.

Проблема

Менеджеру проектов Игорю нужно запланировать запуск лендинга. У него есть готовое техническое задание (ТЗ) и команда из пяти человек, однако только один из них готов назвать конкретные сроки – 10 рабочих дней. Как спланировать релиз? Игорь пытается спрогнозировать сроки, опираясь на интуицию и опыт коллег, и даёт предварительную оценку: нужно три месяца, причём с запасом на форс-мажоры.

Что важно учесть, чтобы понять, сможет ли команда уложиться в эти сроки? Давайте пошагово разберём, как Игорю стоило бы планировать запуск в условиях неопределённости.

Шаг 1: отделяем известное от неизвестного

Прежде чем приступать к планированию, нужно понять, что нам точно известно, а что — нет. Это не так просто, как кажется, но очень полезно для принятия решений в любой области.

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

Чтобы разобраться, составим квадрат «известного–неизвестного» и распределим всё, что Игорь знает о проекте, по четырём его секторам:

1. Известное известное. То, что нам доподлинно известно.

Например, ТЗ и состав команды, а также дедлайн, который назвал дизайнер.

2. Неизвестное известное. То, что мы ошибочно оцениваем как известное.

Например, если Игорь слышал, что команда конкурентов справилась с подобным проектом за год, он может предположить, что его отделу понадобится примерно столько же времени. Однако он слабо представляет, каковы в реальности опыт и навыки у конкурентов и не может объективно оценить, насколько они лучше или хуже, чем у его коллег.

3. Известное неизвестное. То, про что мы знаем, что оно нам неизвестно, и то, что мы при этом стремимся узнать. Например, каким точно будет продукт на выходе и когда он выйдет.

4. Неизвестное неизвестное. То, что остаётся за пределами поля зрения, вещи, которые мы не учитываем. Например, кто-то из членов команды может планировать уволиться.

Очень важно не переоценивать объём известной информации. Игорь знает, что дизайнер справится с задачей за 10 рабочих дней и ошибочно принимает это за отправную точку. На самом деле, даже известное известное нужно подвергать сомнению: за ним может скрываться неизвестное неизвестное, о котором мы даже не подозреваем. Откуда у дизайнера такая уверенность в том, что он уложится в срок? Достаточно ли хорошо изучил ТЗ и понимает ли, чего хочет клиент? Были ли у него в прошлом аналогичные проекты?

Шаг 2: исследуем неизвестное неизвестное

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

К — компетентность. Достаточно ли я компетентен, чтобы правильно оценить свои знания?

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

О — отсутствие свидетельств. Не путаю ли я отсутствие информации с информацией о ее отсутствии?

Тут можно вспомнить об «ошибке выжившего»: когда мы знаем о положительном опыте от людей, которые о нём рассказывают, но ничего не знаем об отрицательном — потому что о нём никто не говорит. Из-за этого нам может казаться, что его просто нет.

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

Ж — желаемое за действительное. Открыт ли я для информации, которая мне не нравится?

Все мы склонны судить предвзято, опираясь на наш личный опыт. Игорю кажется, что работа над проектом — это прямая линия из точки А в точку Б. На деле в каждом промежуточном пункте можно свернуть в сторону (а то и не в одну) и в финале прийти к совсем другому результату. Этого не стоит бояться.

З — знание задним числом. Что из того, что сейчас кажется невозможным, потом будет выглядеть ожидаемым и предсказуемым?

Американский писатель и риск-трейдер Нассим Талеб назвал подобные явления «черными лебедями». В рамках проекта это может быть что угодно: например, внезапное увольнение сотрудника.

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

Г — групповые убеждения. Не принимаю ли я групповое убеждение за истину, потому что боюсь возразить?

Это ещё одна типичная ошибка новичка. Когда у всех в команде больше опыта, может быть сложно подвергать их слова сомнению – даже если интуиция подсказывает вам, что что-то не так.

Например, в ТЗ, с которым работает наш начинающий менеджер Игорь, есть спорный пункт, который стоило бы дополнительно обсудить с клиентом. Другие участники команды говорят ему, что всё будет в порядке, ведь они уже сталкивались с подобным – однако это не показатель того, что так произойдёт и в этот раз. Поэтому лучше перестраховаться, объяснить свою позицию коллегам и всё же поговорить с заказчиком.

С — слепота к собственным искажениям. Готов ли я признать, что могу быть подвержен когнитивным искажениям?

Когнитивные искажения — это своеобразные ловушки нашего восприятия. Например, если мы узнали о каком-то новом психотипе людей, то начинаем видеть их повсюду. Нам кажется, что они стали попадаться нам чаще, хотя это не так: просто раньше мы их не замечали.

Ф — фокусировка. Могу ли я упустить что-то важное, потому что слишком сконцентрирован на других вещах?

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

Этот набор вопросов — условный и не даёт нам новой информации, но помогает лучше разобраться с тем, что мы действительно знаем. Теперь Игорь может оценить исходные данные критически и учесть максимум возможных рисков при принятии решения.

Шаг 3: проверяем решение

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

Теперь перед Игорем стоят две главные задачи:

1. Объективно оценить то, что он знает о проекте, заказчике и исполнителях и подготовиться к тому, что в любой точке всё может пойти не по плану.

Например, нам известно, что дизайнер проекта готов сделать первый прототип за пяти рабочих дней. Другие участники не называют сроков, но мы знаем, что UX-редактор может работать параллельно с дизайнером, а программист — нет. Исходя из этого, можно предположить, что двое из пяти членов команды справятся первыми, а остальным потребуется ещё как минимум столько же времени.

Но это не обязятельно будет так: UX-редактор может закончить работу раньше, а остальные решат, что времени в запасе достаточно, и не будут торопиться. Или же UX-редактор и дизайнер, работая параллельно, на выходе покажут совершенно разные решения: тогда придётся заново переделывать дизайн или UX-интерфейс.

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

Кроме того, сотрудники часто оценивают свои силы в максимально продуктивном состоянии. Тогда как в состоянии усталости или стресса каждый из них может работать в два раз медленнее и допускать множество ошибок. Узнать об этом заранее мы тоже не можем.

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

2. Заложить в прогноз максимум возможных рисков.

Допустим, дизайнер и копирайтер справились вовремя, и заказчик сразу одобрил результат. Но это ещё не значит, что оставшиеся этапы будут такими же успешными. Клиент может в любой момент урезать бюджет, внести много правок или затянуть согласование. Со всеми этими проблемами можно разобраться — однако это повлияет на сроки.

Сам Игорь, с его установками и представлениями, тоже влияет на объективность принимаемого решения. Его действия могут как ускорить, так и замедлить ход проекта: например, если он слишком фокусируется на дедлайнах и упускает из виду то, насколько промежуточные версии продукта отвечают задаче клиента.

Шаг 4: применяем полученный опыт

Теперь Игорь понимает, что его изначальное решение было слишком поспешным, потому что он опирался на данные, которые оценивал необъективно. Дальше он может пойти двумя путями:

1. Микропланирование. При микропланировании задачу разбивают на максимально короткие этапы, а затем последовательно их выполняют. Когда этап окончен, менеджер собирает всё, что команда узнала в процессе, заново оценивает известное и неизвестное и вносит коррективы в планы на следующие этапы. Важный момент: на каждом этапе нужно собирать обратную связь от участников и отмечать все неожиданные события и факторы, которые возникли в процессе. Так будет проще вовремя отследить все изменения в исходных данных.

2. Параллельные процессы. Мы уже упоминали, что дизайнер и UX-редактор могут работать параллельно. Наверняка найдутся и другие задачи и этапы, которые можно делать одновременно, периодически сверяясь. Если вдруг один из процессов застопорится, то параллельный будет идти своим чередом.

Эти подходы позволят ему ускорить работу команды и чувствовать больший контроль за происходящим.

Подведём итоги

Сможет ли команда запустить проект за 3 месяца ― срок, который в самом начале обозначил Игорь? Никто точно не знает. Поэтому Игорю не стоит давать однозначного ответа на вопрос о сроках. Лучше критически проанализировать, каким исходным данным он может доверять, а каким — нет, объективен ли он или существуют важные условия, о которых Игорь даже не догадывается? Когда у Игоря появятся ответы на эти вопросы, он сможет просчитать 3-5 наиболее вероятных сценариев — от самого позитивного до самого негативного — и на основании этого предложить приблизительный диапазон сроков. При этом нужно будет сразу оговориться, что на каждом этапе проекта предположительная дата может меняться с учётом новых обстоятельств и инсайтов.

Выводы

— Не нужно бояться принимать решения в условиях неизвестности. Даже если на старте у нас есть от 10 до 20% всей нужной информации — этого уже достаточно.

— На объективность принимаемых нами решений влияет даже то, о чём мы не догадываемся.

— Неизвестность и неопределенность — это нормально. Опытные команды формируют сроки и бюджет с запасом, стараясь учесть возможные форс-мажоры. Но и это не гарантирует того, что всё пойдет по плану. Важно объективно оценивать известное и неизвестное, просчитывать риски и строить прогнозы.

— Для того, чтобы оценивать принимаемые решения, есть вполне конкретные и рабочие инструменты. Нужно только научиться ими пользоваться.