Перед предпоследней статьёй серии хочу сделать одну оговорку.

Всё, о чём я пишу в этой серии – это мой собственный опыт работы в проектах. Здесь есть мои ошибки, решения, которые сработали, решения, которые не сработали, и выводы, к которым я пришёл иногда уже спустя годы. С выводами можно спорить. Собственно, ради этого такие статьи и стоит писать. Ну а теперь к делу.

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

ТЗ действительно существовало. Если сильно упростить его содержание, получалось примерно следующее:

Новую систему нужно сделать хорошо, плохо делать не нужно, а закончить всё желательно очень быстро.

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

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

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

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

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

Мы позицию не поменяли.

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

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

Именно отсюда возникает вопрос этой статьи: сколько нужно знать о проекте, прежде чем уже можно отвечать за результат?

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

TL;DR

• Готовность принять обязательство определяется не количеством страниц ТЗ, а тем, способна ли оставшаяся неопределённость разрушить конкретное обещание.

• Обязательный объём – это то, без чего первый запуск не выполняет свою задачу. Остальное можно продолжать уточнять позже.

• У допуска к реализации больше двух исходов: кроме «да» и «нет» можно сузить объём, закрыть конкретный пробел или сознательно принять риск.

• Практический инструмент статьи – протокол допуска к реализации: короткая фиксация того, за что мы уже готовы отвечать и на каких условиях.

Ранее в серии

До этой статьи мы последовательно прошли семь вопросов:

1. Диагностика – как понять проблему до того, как проект уже начал производить решение.

2. Ценность – как связать возможности системы с изменением работы и бизнес-результатом.

3. Ответственность и полномочия – кто имеет право принять решение и кто отвечает за последствия.

4. Процесс и бизнес-правила – что происходит, когда ИТ вынуждено самостоятельно додумывать правила работы бизнеса.

5. Данные и источники – кто определяет корпоративный смысл данных и какой источник считается авторитетным.

6. Выбор решения – как сравнивать несколько допустимых вариантов вместе с их будущими проблемами.

7. Первая реализация – как определить границу первого запуска и не превращать MVP в произвольное урезание системы.

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

Приоритет максимальный – значит, успеем?

Заказчик считал, что риски управляемы. Если не хватит людей – добавим. Если появятся препятствия – снимем. У проекта максимальный приоритет собственника, значит ресурсы и решения будут получены.

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

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

Приоритет помогает получать ресурсы и решения. Он не уменьшает объём работы и не превращает предположение в факт.

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

ЛПР согласился, что в представленном виде проект запускать нельзя. Цели требовалось оцифровать, объём – пересобрать. Но одну вещь он менять не стал: срок.

Дата была связана с внешним событием. Если бы новая система к этому моменту не заработала, последствия для бизнеса могли быть очень дорогими.

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

Дата жёсткая – двигаем объём

После решения ЛПР мы не стали начинать с переписывания ТЗ. Сначала оцифровали цели проекта.

Это изменило сам способ разговора о требованиях. Вместо вопроса «хотим ли мы эту функцию?» можно было спрашивать: «Если её не будет к первой дате запуска, получим ли мы тот результат, ради которого дата вообще важна?»

Так начал отделяться обязательный контур. Мы обследовали функции, без которых новая система не могла нормально заработать. Не весь будущий функционал, не все удобства и не всё развитие на годы вперёд – только то, без чего первый запуск терял смысл.

Оказалось, что такого объёма значительно меньше, чем следовало из исходного ТЗ.

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

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

Это не было сокращением ради сокращения. Маленький, но плохо понятый объём вполне способен оказаться опаснее большого и нормально исследованного. Нам нужно было понять, для какого объёма мы уже способны обоснованно оценить срок, ресурсы и стоимость.

Для допуска нужно определить всё, что способно сделать конкретное обязательство необоснованным.

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

Что может разрушить обещание

После пересборки объёма мы смогли нормально оценить трудоёмкость. Использовали PERT: оптимистичную, наиболее вероятную и пессимистичную оценки. Это не превращало срок в точную величину, зато позволяло видеть разброс и понимать, где нужен резерв.

Архитектура в целом была понятна. Мы не создавали неизвестный класс решения с нуля, а заменяли существующую корпоративную систему более современной системой того же назначения. В обязательном объёме не было критических интеграций, которые могли бы внезапно перестроить весь проект.

Но одна существенная неизвестность оставалась – ресурсы заказчика. Нам требовалось заметное участие его сотрудников. Мы определили необходимые роли и примерный объём их работы, заказчик подтвердил, что людей предоставит. Жёсткой договорной ответственности за выполнение этого условия мы, однако, не получили.

Мне этот компромисс не очень нравился. Но риск был достаточно понятен, чтобы с ним работать.

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

Тут важна именно механика. Фразы «заказчик обещал» для срока недостаточно. У нас была понятная потребность в ролях, известный риск дефицита и способ закрыть его в разумных пределах. Без этого подписаться под датой было бы значительно сложнее обосновать.

В предыдущей статье о выборе решения уже возникала похожая мысль: выбрать вариант – значит принять не только его преимущества, но и оставшиеся последствия. Здесь тот же принцип работает на следующем уровне. Проект можно допустить с риском, если мы понимаем, что именно принимаем и что будем делать, когда риск перестанет быть гипотетическим.

После этого мы были готовы зафиксировать объём, срок и бюджет в договоре.

Протокол допуска – одна страница, а не новый регламент

В том проекте документа под названием «протокол допуска к реализации» не существовало. Все его будущие элементы были разбросаны между решениями, оценками, рисками, ресурсными договорённостями и самим договором.

Сегодня я бы собрал их в одном месте.

Название здесь не нужно воспринимать как попытку придумать новый универсальный стандарт. По смыслу эта идея родственна контрольным точкам между стадиями: в Stage-Gate в таких точках принимается решение о продолжении инвестиций и ресурсах, а PRINCE2 использует управленческие стадии и решение о продолжении проекта на их границах.

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

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

На нашем проекте он мог выглядеть примерно так:

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

У допуска не два исхода

Если свести всё к «разрешить» или «запретить», право на отлагательное вето быстро становится слишком грубым инструментом. Между этими решениями есть ещё несколько рабочих вариантов.

1. Допустить. Оснований достаточно – можно брать согласованное обязательство.

2. Сузить первую реализацию. Проект реализуем, но заявленный объём пока не подтверждается сроком или ресурсами.

3. Вернуть конкретный вопрос на диагностику. Не нужно обследовать всё заново; нужно закрыть определённый пробел, способный изменить оценку или решение.

4. Продолжить с принятым риском. Последствия известны, реакция определена, а риск принимает человек с нужными полномочиями.

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

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

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

С принятым риском другая опасность – подменить управление надеждой.

Принятый риск оставляет неопределённость, но даёт сценарий действий. Авантюра оставляет только надежду, что неблагоприятный сценарий не наступит.

Кто говорит «да»

Допуск не является подписью одного «главного» человека. В нашем случае со стороны интегратора я отвечал за реализуемость и готовность команды принять обязательства. Бюджет у заказчика утверждал финансовый директор, объём и срок – функциональный заказчик, будущий владелец продукта. ЛПР обеспечивал полномочия и вмешивался там, где решения выходили за рабочий уровень.

В тот же день мы сформировали группу управления проектом. В неё вошли не только руководители: во время обследования уже было понятно, какие специалисты действительно знают процессы и способны принимать содержательные решения. ЛПР дал им соответствующие полномочия.

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

Вето должно иметь условие снятия

Здесь появляется обратная сторона всей конструкции, с которой начиналась серия.

Если ИТ получает право сказать «пока нельзя», оно должно уметь назвать условие, после которого станет можно. Иначе вето перестаёт быть отлагательным. Всегда найдётся ещё одно требование, которое можно исследовать, дополнительный риск, который можно снизить, или техническая деталь, которую хотелось бы определить заранее.

Если ИТ говорит «пока нельзя», вместе с этим должно прозвучать, что именно нужно решить или подтвердить, чтобы стало можно.

В начале нашего проекта причины остановки можно было назвать вполне конкретно: цели не оцифрованы, исходный объём не поддаётся нормальной оценке, связь этого объёма со сроком не подтверждена.

После пересборки ситуация изменилась. У нас всё ещё оставались неизвестные требования и ресурсный риск, но вопросы, которые мешали взять первое обязательство, получили ответы.

Продолжать удерживать проект только потому, что нам хотелось бы знать ещё больше, было бы уже странно. Неопределённость после этой точки никуда не исчезает – просто с ней начинает работать уже проект.

Допуск не замораживает проект

Старт реализации не означает, что первоначальное решение становится неприкосновенным.

В нашем проекте мы заранее договорились о правилах изменений. Новое требование фиксировалось и первоначально оценивалось тем, кому оно назначено. Затем группа управления смотрела на его влияние на объём, срок и бюджет. Существенное изменение возвращалось к совместному решению с заказчиком.

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

Поэтому допуск не замораживает решение. Он фиксирует базу текущей договорённости. Пока она сохраняется, проект идёт дальше. Когда одна из опор меняется существенно, пересматривается затронутая часть договорённости.

Риск сработал

Ресурсный риск потом действительно реализовался. Заказчик смог обеспечить примерно 60% того объёма участия, на который мы рассчитывали.

Я бы не стал описывать это словами «заказчик подвёл». Он действительно старался дать нужных людей, но возможностей оказалось меньше, чем мы ожидали.

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

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

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

В нашем случае выдержало.

Сколько нужно знать, чтобы уже отвечать за результат

В начале проекта мы отказались подписываться под исходным ТЗ, несмотря на максимальный приоритет, обещание необходимых ресурсов и аргумент про другого интегратора. Спустя некоторое время сами зафиксировали объём, срок и бюджет, хотя всей будущей системы всё ещё не знали.

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

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

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

Что можно сделать уже сегодня

1. Возьмите один вопрос, из-за которого сейчас не готовы подтвердить срок, объём или бюджет. Попробуйте вместо «нужно дообследовать» записать конкретно: чего не хватает и какое обещание из-за этого нельзя подтвердить.

2. Посмотрите на границу первой реализации. Что действительно необходимо для результата первого запуска, а что просто хотелось бы получить сразу?

3. Возьмите главный оставшийся риск и допишите к нему три вещи: кто его принимает, что произойдёт при реализации и каким ресурсом или решением вы будете отвечать.

4. Если проект завис между «можно» и «нельзя», попробуйте выбрать один из пяти исходов допуска. Часто уже сама необходимость назвать решение показывает, какого именно управленческого шага не хватает.

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