Денис Николаев: Как мы внедряли риск-менеджмент в hh.ru и научились точнее оценивать задачи
Денис, расскажите немного о себе и своей роли в hh.ru.
Меня зовут Денис Николаев, я менеджер проектов в hh.ru — ведущем сервисе по поиску работы и сотрудников. Я руководитель проектов в направлении из пяти команд разработки и одной кросс-функциональной команды, в которую входят владельцы продукта, технические лиды, аналитики, дизайнеры и маркетологи. Недавно я внедрил процесс управления рисками в наших технических командах, и этот подход уже начал приносить ощутимые результаты.
Что вы вкладываете в понятие «работа с рисками» в разработке?
Я начну с определений и чуть позже поясню, почему это было важно именно нам. Риск-менеджмент — это системный подход к работе с неопределённостью и потенциальными угрозами, которые могут негативно повлиять на успех проекта, продукта или бизнеса в целом.
А зачем вообще нужно управлять этими рисками? В чём практическая польза?
Цель риск-менеджмента — вовремя заметить возможные проблемы, подготовиться к ним и минимизировать их влияние, а в идеале — и вовсе избежать негативных последствий. Раннее понимание подобных рисков позволяет проекту двигаться по более предсказуемому и стабильному сценарию, поскольку вы заранее устраняете проблемы, не доводя до «режима тушения пожаров». Расскажу, какую задачу я решал в нашем направлении, когда внедрял этот инструмент. Наш процесс устроен так, что перед началом разработки технические специалисты оценивают задачи и делают прогноз по срокам. Поскольку у нас вся разработка внутренняя, эти сроки служат ориентиром, а не обязательством — за исключением срочных проектов с конкретными дедлайнами. Такие ориентиры важны как для разработчиков, чтобы понимать, укладываются ли они в ожидаемые рамки, так и для владельцев продукта, которые планируют бэклог или принимают решение об отмене задачи, если её стоимость оказывается слишком высокой. Проблема была в том, что первоначальная оценка сроков и реальное время реализации часто сильно расходились. Например, в одной из команд большинство задач оценивались в рамках одного месяца, но чтобы доверять этим оценкам хотя бы на уровне 85-го процентиля, нам приходилось добавлять в среднем ещё 28 календарных дней к каждой задаче. Это говорит о том, что изначальные прогнозы в текущем виде не были надёжны. В таких условиях и возникают перекосы: менеджеры на разных уровнях начинают перестраховываться и умножают сроки «на два», в результате чего до топ-менеджмента доходят уже искажённые, нереалистичные цифры. Я решил изменить ситуацию — и в качестве решения выбрал внедрение риск-менеджмента. Это дало нам инструмент, позволяющий точнее прогнозировать сроки, чего нельзя было добиться только с помощью story points и стандартной оценки.
Как именно вы внедряли процесс управления рисками в своих командах?
Как я уже говорил, у нас есть этап декомпозиции: на нём разработчики делят задачу (фичу) на более мелкие подзадачи, оценивают их и формируют общий прогноз по срокам. Я предложил добавить к этому этапу практики из классического проектного управления — и начать проводить отдельную риск-сессию для крупных фичей. В результате у нас появился единый артефакт, описывающий все риски, связанные с задачей.
Процесс устроен следующим образом. На первом этапе, во время проработки задачи, разработчик не только делит её на подзадачи, но и составляет таблицу, в которой фиксирует потенциальные проблемы, которые могут возникнуть при реализации. Эти риски могут относиться как к конкретным задачам, так и ко всей фиче в целом. Затем команда собирается на встречу по декомпозиции, обсуждает предложенные риски и при необходимости дополняет список. На втором этапе мы приоритизируем риски, чтобы сфокусироваться только на действительно значимых. Для этого мы используем адаптированную под нас матрицу рисков: добавляем к каждой записи два параметра — «вероятность» и «сила влияния». Оба параметра имеют три уровня — низкий, средний и высокий. Это позволяет нам отсеивать несущественные угрозы и сосредотачиваться на ключевых рисках, которые реально могут повлиять на результат.
Третий этап — это классификация рисков по методике ROAM (Resolved, Owned, Accepted, Mitigated).
Resolved — уже устранённые риски, которые более не актуальны. Owned — риски, за которыми закреплены конкретные ответственные. Accepted — риски, с которыми команда осознанно соглашается и не предпринимает дополнительных действий. Mitigated — риски, для которых мы разрабатываем меры по снижению вероятности или силы последствий.
Для финальной таблицы мы добавляем ещё два столбца: ROAM-категория и действия. В первом указываем классификацию, во втором — конкретный план работы с риском, если он реализуется или начинает проявляться. В итоге у нас появляется прозрачный, понятный список всех значимых рисков по фиче, с оценкой их приоритетности и планом реагирования. Такой подход не только позволяет заранее продумать защиту от проблем, но и помогает командам формировать более реалистичные оценки, избавляясь от излишнего оптимизма.
Можете привести конкретные примеры рисков, с которыми вы столкнулись на практике?
Попробую. Например, мы хотим дать возможность отправлять текущую локацию с помощью нашего внутреннего мессенджера, будем делать это и на вебе, и в мобильных устройствах. При глубокой проработке задачи можно найти целую кучу рисков, связанных, например, с новыми для нас технологиями, с интеграцией клиента и сервера, внешними по отношению мессенджера сервисами, работой с базой, юридическими или административными рисками. Но давайте все упростим до пары пунктов. Допустим, мы считаем, что у нас узкое звено - это работа с базой данных (БД). Наш процесс построен таким образом, что все выпускаемые на прод задачи всей компании, связанные с базой, как правило подхватываются раз в сутки и делаются в это «релизное окно». Тогда риск может звучать как «не попадем в релизное окно БД» по отношению с запланированными датами. Влияние - сдвижение релиза на сутки. Дальше подумаем о последствии. Допустим, мы оцениваем вероятность наступления события как среднюю, а вот с силой влияния все интереснее. В зависимости от контекста один и тот же риск может приносить разный урон. Если эта задача, которая не блокирует другие задачи фичи и не влияет на сроки ее реализации, то нам в целом задержка релиза базы данных на сутки не навредит, и тогда сила влияния слабая или средняя. Но может быть и такое, что релиз задачи с БД влияет на срок реализации небольшой фичи, у которой есть жесткий дедлайн (допустим, в параллельной вселенной нас законодательно обязали давать возможность делиться геопозицией, и дали нам срок реализации неделю), и тогда сила влияния очень высокая. В первом случае мы скорее всего не пошли бы придумывать план устранения риска. Во втором случае мы, например, можем назначить ответственного, который будет следить за этой задачей, и в случае чего сходит к администраторам и попросит задержать релизный цикл.
Следующий риск - модераторы не пропускают наше приложение в магазины приложений. Конкретно в этом случае вероятность события высокая, так как мы запрашиваем у пользователя новые разрешения (на геолокацию). У модераторов могут появиться вопросы, а зачем такие доступы приложению по поиску работы? И в этом случае мы должны обработать этот риск заранее. В качестве плана действия перед тем, как отправлять приложение в магазин, мы заранее готовим пояснительную записку и инструкцию, как смотрящий может проверить этот новый функционал.
С учетом всего этого у нас начинает появляться такая таблица:
Задача Риск Влияние Сила влияния Вероятность ROAMing Действия Обновление базы данных Не попадем в релизное окно БД Задержка на сутки Высокая Средняя Owned - Василий Релиз мобильных приложений Модераторы не пропустят наше приложение в магазины приложений Наше приложение не опубликуют Высокая Высокая Mitigated Заранее готовим пояснительную записку и инструкцию, как модератор может проверить работу с геопозицией
И как внедрение риск-менеджмента повлияло на результат? Что изменилось?
Мы начали внедрять эту систему около четырёх месяцев назад, и уже сейчас видим ощутимый эффект. Риск-сессии мы проводим только для крупных задач — как раз для тех, по которым точность оценок традиционно была ниже. После внедрения риск-менеджмента задачи либо стали чаще укладываться в прогнозируемые сроки, либо отклонения от планов стали минимальными. Особенно показателен один кейс. Изначально разработчики оценили задачу в полтора месяца, но после проведения риск-сессии и детального анализа стало очевидно, что срок ближе к трём месяцам. Такая оценка не устроила владельца продукта, и в итоге команда вместе с ним пересмотрела требования. В результате задачу реализовали за три недели — почти в два раза быстрее первоначальной оценки, при этом без потери ценности для бизнеса.
Важно отметить, что наша цель изначально не была в том, чтобы сократить сроки разработки. Мы хотели добиться, чтобы изначальной оценке можно было доверять для более осознанного управления процессом. Тем не менее, в ряде случаев это помогает и ускорить реализацию — просто потому, что заранее видны узкие места, и есть время на принятие решений.
Какие у вас планы по дальнейшему развитию этой практики?
У меня есть идеи по развитию этого инструмента. По мере накопления опыта можно анализировать те риски, которые мы уже описывали. Я хочу собрать типовые риски в одну базу знаний, и тогда продумывать список и потенциальное влияние станет гораздо проще. Это еще больше упростит работу с инструментом, и позволит более точно прогнозировать задачи.
Внедрение риск-менеджмента в технических командах hh.ru стало важным шагом в сторону более предсказуемой, осознанной разработки. Мы не просто стали точнее в оценках — мы научились смотреть на задачи шире, заранее замечать потенциальные проблемы и принимать управленческие решения до того, как появится необходимость «тушить пожары». Этот процесс повысил прозрачность внутри команд и улучшил взаимопонимание между разработкой и бизнесом. Я уверен, что дальнейшее развитие инструмента — в том числе за счёт базы типовых рисков — поможет нам ещё точнее планировать и устойчиво развивать продукт.