Для аналитика работа в условиях неопределенности и сжатых сроков — обычное дело. Особенно, если он участвует в исследованиях или стартапах. Но обычное дело ≠ норма. В таком режиме мозгу приходится тяжело, когнитивные способности снижаются: планировать и принимать решения становится сложнее. 

Динар Каримов, аналитик в Naumen Contact Center, рассказал, в какие моменты возникает неопределенность и как снизить риск ее возникновения. 

Динар Каримов

Аналитик в Naumen Contact Center

В чем сложность работы аналитика

Аналитик — посредник между бизнес-заказчиком и разработчиком. Бизнес хочет быть уверен, что на выходе он получит именно то, что он ожидает. Разработчику нужно понимать, что требуется сделать и какой результат обеспечить. Так аналитику необходимо понять, для чего нужна разработка бизнесу, провести аналитическую работу и на выходе в виде постановки сообщить разработчику, что от него требуется. 

Наша задача звучит довольно просто: выясни, что нужно, собери требования, проведи анализ и поставь задачу разработчику. Но как быть, если нужно учесть невыявленные или неформализованные требования?

В одном из проектов я столкнулся именно с такой ситуацией. Задачей нашей команды стала разработка пилотной системы, которая должна была учитывать нововведения в отдельной отрасли. На уровне концепции и идеи все было понятно, но для того, чтобы разработать детальные требования и спроектировать решение, нужна была более подробная и конкретная информация. Ее у нас не было — отсутствовали нормативный документ и рекомендации от ведомства, которое планировало нововведение. Мы собирали информацию по крупицам, искали статистические данные в интернете, консультировались с ведомством и даже вступили в рабочую группу, которая обсуждала планируемые нововведения. Именно так мы смогли сформулировать требования и разработать пилотную систему. Но поскольку нормативный документ так и не был принят, уровень неопределенности в любом случае оставался.

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

Когда проявляется неопределенность

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

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

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

Чем ближе мы к завершению проекта, тем меньше у нас возможностей для влияния на проект, а внесение изменений обходится дороже. Ниже график, на котором показано, как уровень неопределенности и возможность влияния на проект меняются в зависимости от стадии жизненного цикла проекта.

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

Как минимизировать неопределенность

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

Шаг 1. Создание майндмэпа

Этот инструмент использую как базу знаний. Майндмэп всегда под рукой, так что я активно применяю его при выполнении задач аналитики, чтобы исключить вероятность упустить что-то. 

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

Часто есть задачи, которые регулярно повторяются. Я взял из майндмэпа аспекты, вопросы и инструменты, которые помогают прорабатывать такие задачи. Получился чек-лист, который ускоряет выполнение типовых задач: прохожусь по вопросам и уточняю информацию при помощи инструментов.

Шаг 3. Итеративный подход

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

Шаг 4. Актуализация майндмэпа

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

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