Допущения в ИТ-проекте: как они становятся рисками
«Мы предполагали, что разработчик будет доступен. А он ушёл в отпуск»
Вы спланировали проект, исходя из того, что ключевой разработчик будет работать полный день, а через месяц он уходит в отпуск, замены нет, проект стопорится. Это было допущение, которое стало риском, а потом — проблемой.
Допущения — это предположения, которые мы делаем, чтобы иметь возможность планировать: «Мы предполагаем, что API не изменится», «Предполагаем, что заказчик утвердит бюджет», «Предполагаем, что команда будет доступна». Каждое допущение — это спящий риск.
Что такое допущение
Допущение — это предположение, которое считается верным («Ключевой разработчик не уволится»). Риск — это событие, которое может произойти («Ключевой разработчик уволится → задержка»). Допущение считается верным, пока не доказано обратное, риск ещё не произошёл, но может произойти. Допущение принимается на веру, чтобы двигаться дальше, риск требует плана реагирования.
Связь простая: если допущение не выполняется — возникает риск.
Как допущения становятся рисками
«Ключевой разработчик не уволится» → если нарушится, уход приведёт к задержке и потере экспертизы. «Заказчик даст доступ до тестирования» → если нарушится, нет доступа → сдвиг графика. «API останется стабильным» → если нарушится, изменение API приведёт к переделке и перерасходу. «Бюджет утвердят вовремя» → если нарушится, задержка бюджета приведёт к остановке работ.
Почему допущения опасны
Мы их не замечаем — они кажутся очевидными: «Конечно, разработчик не уволится», «Конечно, бюджет утвердят». А потом оказывается, что не уволился, а ушёл в отпуск, что бюджет утвердили, но на месяц позже. Мы их не фиксируем — то, что не записано, не существует, вы можете вспомнить допущение только тогда, когда оно нарушится. Мы не проверяем их в процессе — допущение, которое было верно на старте, может перестать быть верным через месяц.
Как управлять допущениями
Фиксируйте их в уставе, в описании содержания, в реестре допущений. Назначайте владельца — кто проверяет, что допущение остаётся верным. Определяйте контрольные точки — когда и как проверяем. Если нарушено — создавайте риск: оцените влияние, создайте запись в реестре, примените стратегию реагирования.
Чек-лист допущений для ИТ-проекта
На старте каждого проекта пройдите по этим пунктам. Доступность ключевых людей — кто занят в проекте, есть ли у них другие обязательства? Стабильность внешних систем и API — есть ли у вендора планы по изменениям? Соответствие инфраструктуры минимальным требованиям — проверено ли оборудование? Своевременность поставок и оплат — какие сроки у поставщиков, есть ли задержки? Готовность заказчика выделять время на проект — согласовано ли участие ключевых сотрудников заказчика? Стабильность требований — зафиксированы ли требования, есть ли процедура изменений? Каждый пункт — потенциальный риск.
Что делать при нарушении допущения
Зафиксируйте факт нарушения. Оцените влияние — сколько дней, сколько денег. Создайте риск в реестре рисков. Примените план реагирования (если есть), если плана нет — создайте его сейчас. При необходимости — эскалируйте спонсору. Подробнее о реестре рисков — в статье Реестр рисков ИТ-проекта.
Что в понедельник утром
Найдите в уставе вашего проекта раздел «Допущения». Если его нет — создайте, выпишите все предположения, на которых вы строите план. Назначьте владельца для каждого допущения. Установите контрольные точки: «Когда и как мы проверяем, что допущение всё ещё верно?». Если какое-то допущение вызывает сомнения — немедленно превратите его в риск.
Заключение
Каждое допущение — потенциальный риск. Фиксируйте их, назначайте владельцев, регулярно проверяйте, превращайте нарушенные допущения в риски.
Хотите научиться управлять допущениями на практике? В модуле 6 курса «Мастер управления IT-проектами» мы на воркшопах составляем реестр допущений для ваших проектов. Подробнее о курсе →