Почему одинаковые отклонения получают разную оценку
В моей практике были проекты с внешне похожими проблемами, которые заказчики оценивали совершенно по-разному. Разработка сайта для производственной компании завершилась с задержкой на два месяца. Хотя сам проект длился около полугода, руководство сочло это достаточным основанием, чтобы признать управление неуспешным.
Другой проект — создание программного продукта для дистрибьюторской компании — продолжался значительно дольше первоначального срока. При этом заказчик был готов признать его успешным, потому что решение создавало новый стандарт обслуживания клиентов и сохраняло для бизнеса высокую ценность.
Дело не в том, что сроки в одном проекте важны, а в другом ими можно пренебречь. Просто у проектов были разные критерии успеха и разная цена отклонения. Для одного заказчика календарное обязательство оказалось определяющим. Для другого ценность продукта перевесила увеличение длительности.
Отсюда первый управленческий вывод: универсального критерия успеха нет. Традиционный треугольник «содержание — срок — бюджет» полезен для контроля delivery, но он не отвечает на вопросы, начал ли бизнес пользоваться системой и получил ли ожидаемый эффект. Набор критериев нужно выбирать под конкретную инвестицию и согласовывать до её запуска.
Критерии нельзя придумывать при закрытии проекта
Однажды на заседании совета директоров руководитель проекта предложил закрыть свою инициативу со статусом «успешно». Ему отказали, сославшись на ошибку в отчётности и месячное опоздание, возникшее не только по его вине. До этого момента стороны не договорились, что именно будет означать успех, поэтому итоговая оценка появилась ретроспективно.
После этой ситуации я стал включать в устав проекта таблицу «критерий успешности — способ проверки». Сегодня я бы расширил её ещё тремя полями: владелец показателя, источник данных и момент измерения.
Такая таблица защищает не руководителя проекта от критики, а качество управленческого решения. До старта спонсор вынужден определить, что для него важнее; команда понимает, какой результат нельзя обменять на второстепенную функциональность; а на закрытии участники сравнивают факт с согласованной моделью, а не с изменившимися ожиданиями.
Критерии должны быть понятны бизнесу, измеримы доступными данными и находиться в зоне влияния проекта. Если эффект зависит от действий операционного подразделения после запуска, ответственность за adoption и достижение результата нужно разделить между проектной командой и владельцем процесса.
- критерий — какое состояние будет считаться успехом;
- метрика — чем оно измеряется;
- способ проверки — откуда берутся данные;
- владелец — кто подтверждает результат;
- момент оценки — при запуске, закрытии или после стабилизации.
Критерий 1. Реализованы ключевые функции системы
Первый критерий отвечает на вопрос: способна ли система поддержать бизнес-процесс, ради которого начался проект? Речь идёт не о количестве закрытых требований, а о готовности критического контура.
Например, для call-центра ключевой функцией может быть автоматическая регистрация обращения и передача его ответственному сотруднику. Цвет группировки в отчёте тоже является требованием, но отсутствие этой настройки обычно не блокирует запуск процесса. Если обе функции имеют одинаковый приоритет, проект будет расходовать ресурсы на удобство и на бизнес-критические возможности без различия.
Формулировка «реализованы все функции системы» выглядит строго, но для крупного или инновационного проекта почти бесполезна. В начале невозможно одинаково подробно и точно описать весь будущий продукт. Кроме того, часть требований изменится после первых итераций и обратной связи пользователей.
Поэтому я разделяю обязательный контур запуска, необходимые улучшения и backlog развития. Для ключевых функций заранее определяются критерии приёмки, сценарии проверки, ответственный заказчик и необходимые данные. Остальные возможности могут перейти в следующий релиз без автоматического признания проекта неуспешным.
Итерационный подход полезен именно здесь: он позволяет раньше проверить ценность на рабочем сценарии. Но сам факт использования Agile не гарантирует успех. Каждая итерация должна приближать бизнес к готовому процессу, а не просто увеличивать количество разработанных функций.
- какой бизнес-процесс должен заработать;
- без каких функций запуск не имеет смысла;
- как заказчик проверит сквозной сценарий;
- какие данные и интеграции критичны;
- что допустимо перенести в следующий релиз.
Критерий 2. Система введена в эксплуатацию к нужной дате
Время нельзя накопить и вернуть в проект позже. Но заказчику обычно важна не абстрактная дата завершения всех работ, а конкретная бизнес-веха: начало сезона, запуск филиала, переход на новые правила, выполнение обязательства перед клиентом или отключение старой системы.
Поэтому в расписании полезно разделять как минимум две точки: «система введена в эксплуатацию» и «проект закрыт». Между ними могут находиться стабилизация, устранение некритичных замечаний, передача поддержки и завершение договорных процедур.
В одном из проектов разработка системы и интеграция с внешней стороной заняли около двух лет. Рабочий контур был введён с небольшой задержкой относительно согласованной даты, и заказчик высоко оценил результат. Формальное закрытие потребовало ещё нескольких месяцев, потому что стороны согласовывали условия поддержки и время реакции на ошибки интеграции. Если бы мы оценивали только дату закрытия, потеряли бы главное: бизнес уже пользовался системой.
Однако разделение вех не должно превращаться в способ скрыть незавершённую работу. Для даты запуска определяется конкретное состояние: ключевые сценарии работают, данные перенесены, пользователи обучены, поддержка готова, риски перехода приняты. Для даты закрытия — завершены обязательства и передан устойчивый операционный контур.
Срок также зависит от решений заказчика: согласований, предоставления данных, участия экспертов и приёмки. Эти обязательства нужно включить в governance и расписание. Иначе фиксированный deadline просто переносит все риски неопределённости на техническую команду.
Критерий 3. Системой действительно пользуются
Запуск сервера, подписание акта и рассылка инструкции не означают внедрения. Информационная система создаёт ценность только тогда, когда становится частью ежедневной работы людей и источником достоверных данных для процесса.
В старых проектах я видел много решений, которые формально были внедрены, но использовались несколькими сотрудниками вместо заявленной аудитории. Особенно показателен был визит в крупную банковскую группу с тысячами сотрудников. Организация представляла решение как масштабную инновацию, но фактически активных пользователей оказалось всего четыре.
Этот пример научил меня осторожно относиться к метрике «пользователи зарегистрированы». Гораздо важнее активность по целевым ролям, регулярность ключевых операций, полнота данных и снижение количества обходных действий в таблицах, почте или старой системе.
Проверять adoption в момент запуска рано. Нужен согласованный период стабилизации, после которого проводится аудит использования. Для разных процессов это может быть неделя, месяц, квартальный цикл или другой естественный период. Главное — определить его заранее.
Низкая активность не всегда означает плохой интерфейс или сопротивление сотрудников. Причиной могут быть неверно спроектированный процесс, отсутствие управленческого требования, плохие данные, недостаточное обучение, незакрытая интеграция или сохранение удобного обходного пути. Поэтому метрика использования должна вести к диагностике, а не к наказанию пользователей.
- доля активных пользователей по целевым ролям;
- частота выполнения ключевых операций;
- полнота и качество данных;
- доля процесса, проходящая через новую систему;
- использование обходных каналов и старых инструментов.
Критерий 4. Бюджет находится под контролем
Соблюдение бюджета важно, но это слабый самостоятельный критерий успеха. Можно потратить ровно запланированную сумму и не получить работающий процесс. Можно завершить проект дешевле только потому, что часть содержания не была реализована. Наконец, можно осознанно увеличить инвестицию, если дополнительный результат создаёт подтверждённую ценность.
Раньше в крупных организациях мне встречалась негласная логика: хороший руководитель должен освоить почти весь утверждённый бюджет. Значительное недоиспользование воспринималось не как экономия, а как признак слабого планирования — деньги могли быть направлены в другую инициативу. В условиях высокой стоимости капитала этот аргумент особенно заметен.
Но целиться в расходование определённого процента бюджета так же ошибочно, как считать любую экономию успехом. Управленчески зрелый критерий включает качество исходной оценки, своевременность прогноза до завершения, объяснение отклонений и связь затрат с получаемым результатом.
Если проект финансируется заёмными средствами или связан с жёстким инвестиционным лимитом, бюджетное ограничение может стать критическим. Тогда необходимо учитывать не только общую сумму, но и календарь платежей, стоимость задержки, валютные и контрактные риски.
Спонсор должен получать не только факт понесённых расходов. Ему нужен прогноз полной стоимости: сколько потребуется до завершения, какие обязательства уже приняты и как изменение scope или срока повлияет на экономику.
Критерий 5. Совокупная эффективность основного и поддерживающего процессов
Пятый критерий для меня наиболее важен, потому что он переносит оценку за пределы ИТ-проекта. Автоматизация должна улучшить экономику или качество целевого процесса с учётом всех новых затрат, которые появились вокруг системы.
Можно сократить ручную работу в одном подразделении, но создать дополнительный ввод данных у поставщика. Можно ускорить продажи, но резко увеличить нагрузку на поддержку. Можно убрать несколько операций пользователя, но добавить дорогую интеграцию, постоянное администрирование и ручное исправление данных. Локально каждый участник покажет улучшение, а компания в целом получит более дорогой процесс.
В моей практике были случаи, когда автоматизация у получателя данных увеличивала количество рабочих мест у компании, предоставляющей услугу. Формально проект достигал цели одной стороны, но совокупная эффективность цепочки ухудшалась. Именно поэтому границы расчёта имеют принципиальное значение.
До запуска нужно зафиксировать базовое состояние: трудозатраты, длительность цикла, количество ошибок, стоимость поддержки, потери от задержек и другие релевантные показатели. После стабилизации измеряется новый процесс — основной и вспомогательный вместе.
Не каждый эффект легко перевести в деньги. Для систем контроля, безопасности или compliance ценность может выражаться в снижении риска, прозрачности и способности выполнить обязательное требование. Но даже в этом случае критерий должен описывать реальное изменение, а не факт установки программного продукта.
- стоимость выполнения основного процесса;
- трудозатраты и стоимость поддержки;
- длительность сквозного цикла;
- ошибки, возвраты и ручные исправления;
- новые расходы на лицензии, интеграции и данные;
- изменение риска или качества управленческой информации.
Как собрать критерии в единую систему
Пять критериев не нужно механически применять с одинаковым весом. Для каждого проекта спонсор выбирает комбинацию и определяет приоритет. В миграции критической системы дата перехода может быть жёстким ограничением. Для внутреннего аналитического решения важнее фактическое использование. Для автоматизации массовой операции — совокупная экономика процесса.
Я рекомендую разделить критерии на три уровня. Первый — обязательные условия: без них проект нельзя назвать успешным. Второй — целевые показатели, по которым оценивается качество результата. Третий — наблюдаемые эффекты, которые проверяются после периода эксплуатации.
Также важно развести оценку delivery и бизнес-эффекта. Руководитель проекта может отвечать за готовность системы, срок и бюджет, но не способен единолично обеспечить изменение поведения подразделения. Владелец процесса отвечает за регламенты, мотивацию, использование и достижение операционного эффекта. Спонсор обеспечивает решения и ресурсы.
На закрытии проекта часть критериев уже можно проверить, а часть необходимо передать в benefits review. Иначе команда либо ждёт месяцы ради формального закрытия, либо объявляет успех до появления данных о результате.
- обязательные функции и критерии приёмки;
- целевая дата бизнес-запуска;
- метрики adoption после стабилизации;
- утверждённый бюджет и прогноз полной стоимости;
- базовая и целевая эффективность сквозного процесса.
Что должен сделать заказчик до старта
Критерии успеха — не приложение к техническому заданию, которое проектный менеджер заполняет самостоятельно. Это решение заказчика и спонсора о том, ради чего компания инвестирует деньги и какой компромисс она готова принять.
До запуска я задаю руководству несколько вопросов. Какой результат нельзя потерять даже при дефиците времени? Какая дата имеет реальное бизнес-обоснование? Кто должен пользоваться системой и что изменится в его работе? Какие затраты нужно считать вместе? Кто подтвердит эффект после стабилизации?
Ответы оформляются коротко и проверяемо. Например: не «повысить эффективность продаж», а «все квалифицированные возможности ведутся в CRM, прогноз формируется из системы, а ручной реестр больше не используется». Конкретная метрика зависит от процесса и доступных данных.
Если на эти вопросы нет ответа, проект ещё не готов к утверждению. Команда может начать разработку, но у неё не будет основания выбирать между сроком, функциональностью и качеством внедрения.
Сильный ИТ-проект заканчивается не словами «система сдана». Он заканчивается доказательством того, что критический процесс работает, нужные люди используют решение, инвестиция контролируется, а совокупный результат соответствует решению, ради которого проект был запущен.