![](https://habrastorage.org/getpro/habr/upload_files/440/065/963/440065963b62803efdcc6ff4e6e75558.png)
Для аналитика работа в условиях неопределенности и сжатых сроков — обычное дело. Особенно, если он участвует в исследованиях или стартапах. Но обычное дело ≠ норма. В таком режиме мозгу приходится тяжело, когнитивные способности снижаются: планировать и принимать решения становится сложнее.
Динар Каримов, аналитик в Naumen Contact Center, рассказал, в какие моменты возникает неопределенность и как снизить риск ее возникновения.
![](https://habrastorage.org/getpro/habr/upload_files/590/b5d/027/590b5d027207b0730562144482119306.png)
Динар Каримов
Аналитик в Naumen Contact Center
В чем сложность работы аналитика
Аналитик — посредник между бизнес-заказчиком и разработчиком. Бизнес хочет быть уверен, что на выходе он получит именно то, что он ожидает. Разработчику нужно понимать, что требуется сделать и какой результат обеспечить. Так аналитику необходимо понять, для чего нужна разработка бизнесу, провести аналитическую работу и на выходе в виде постановки сообщить разработчику, что от него требуется.
Наша задача звучит довольно просто: выясни, что нужно, собери требования, проведи анализ и поставь задачу разработчику. Но как быть, если нужно учесть невыявленные или неформализованные требования?
В одном из проектов я столкнулся именно с такой ситуацией. Задачей нашей команды стала разработка пилотной системы, которая должна была учитывать нововведения в отдельной отрасли. На уровне концепции и идеи все было понятно, но для того, чтобы разработать детальные требования и спроектировать решение, нужна была более подробная и конкретная информация. Ее у нас не было — отсутствовали нормативный документ и рекомендации от ведомства, которое планировало нововведение. Мы собирали информацию по крупицам, искали статистические данные в интернете, консультировались с ведомством и даже вступили в рабочую группу, которая обсуждала планируемые нововведения. Именно так мы смогли сформулировать требования и разработать пилотную систему. Но поскольку нормативный документ так и не был принят, уровень неопределенности в любом случае оставался.
Отсутствие формализованных требований напрямую связано со сложностью задачи: чем задача сложнее, тем неопределенность выше. Яркий пример — работа в стартапах, инновационных проектах и проектах, в которых много исследовательских задач. Когда мы задействованы в подобных проектах и участвуем в разработке продуктов и отдельных фич, мы не можем заранее точно сказать, к какому результату, каким путем придем и получим ли то, что изначально планировали.
Когда проявляется неопределенность
Отлично демонстрирует поведение неопределенности конус неопределенности — график, который показывает изменения в оценке проекта в зависимости от того, на каком этапе выполняется оценка. То есть объем работы, затраты и функциональность становятся яснее с появлением новой информации.
![](https://habrastorage.org/getpro/habr/upload_files/d64/296/65e/d6429665e9665f9b4c26fdc0a9754c18.png)
Начальный этап работы над проектом — исходная концепция. Автор идеи, Барри Боэм, посчитал, что оценка на этом этапе может отклоняться от итоговых значений в несколько раз. После начального этапа идет согласование требований к продукту, завершение требований и так далее. В финале мы получаем готовый программный продукт. Именно на этом этапе, когда разработка уже завершена, мы понимаем, сколько потратили времени на эти работы, сколько трудозатрат и какая функциональность в этом продукте.
Идеальная ситуация — нам удалось определить и учесть все требования на старте проекта. Но, к сожалению, полностью исключить неопределенность на ранних этапах получается крайне редко — невозможно знать абсолютно все заранее. Неопределенность почти всегда есть на старте проекта, но она может появиться и в будущем. Например, если мы работаем по гибкой методологии: у нас есть бэклог, расставили приоритеты, оценили трудозатраты, спланировали ближайшие спринты. Но мы не можем на 100% быть уверены, что завтра заказчик не скажет, что хочет поменять приоритет какой-то фичи или вовсе от нее отказаться. Такое решение может повлиять на другие фичи и даже на архитектуру решения.
Чем ближе мы к завершению проекта, тем меньше у нас возможностей для влияния на проект, а внесение изменений обходится дороже. Ниже график, на котором показано, как уровень неопределенности и возможность влияния на проект меняются в зависимости от стадии жизненного цикла проекта.
![](https://habrastorage.org/getpro/habr/upload_files/f54/42d/31b/f5442d31bc99b50c1afba94bc2ae9b82.png)
Ниспадающая кривая — неопределенность, которая снижается к завершению проекта. Восходящая кривая показывает стоимость внесения изменений в проект на разных стадиях. График демонстрирует, что если мы столкнемся с изменениями в конце проекта, они будут нам стоить гораздо дороже. Поэтому чем раньше мы снизим неопределенность, тем больше мы сможем снизить не только риски, но и потери для команды, компании и бизнес-заказчика в целом.
Как минимизировать неопределенность
Итак, что же делать, чтобы минимизировать неопределенность? Делюсь планом действий, который помогает мне работать в условиях неопределенности.
Шаг 1. Создание майндмэпа
Этот инструмент использую как базу знаний. Майндмэп всегда под рукой, так что я активно применяю его при выполнении задач аналитики, чтобы исключить вероятность упустить что-то.
Создаю его так: свою зону ответственности разбиваю на области → области раскладываю на аспекты → разделяю аспекты на вопросы, на которые нужно ответить и получить решение, и инструменты, которые нужны для ответа на вопросы.
![](https://habrastorage.org/getpro/habr/upload_files/704/ada/a2c/704adaa2c08e240fdc879af33ff90109.png)
Шаг 2. Использование майндмэпа для типовых задач
Часто есть задачи, которые регулярно повторяются. Я взял из майндмэпа аспекты, вопросы и инструменты, которые помогают прорабатывать такие задачи. Получился чек-лист, который ускоряет выполнение типовых задач: прохожусь по вопросам и уточняю информацию при помощи инструментов.
Шаг 3. Итеративный подход
Со временем возвращаюсь к тем вопросам, которые не удалось прояснить сразу же. Если кажется, что что-то упустил — перепроверяю. Возможно, это какой-то важный вопрос, который нужно учесть.
Шаг 4. Актуализация майндмэпа
Если в задачах встречаю вопросы и инструменты, которые помогли уточнить необходимую информацию, то пополняю майндмэп и содержу его в актуальном виде.
Эти шаги помогают мне контролировать и минимизировать неопределенность. Но предвидеть все требования получается не всегда. И в этом нет ничего страшного: я рассматриваю такие кейсы как урок и возможность для роста, а еще регулярно пополняю и актуализирую майндмэп, чтобы не наступать на те же грабли.