Как не провалить ИТ-проект: заметки менеджера с 12-летним опытом
Если в начале проекта вы не знаете, как и когда он закончится, а только можете перекреститься, если после встреч с заказчиками вы обнаруживаете себя плачущим в туалете, если лучшие сотрудники уходят от вас так поспешно, что даже не передают дела — эта статья поможет вам (но это не точно). Главные причины расползания границ, бюджетов, сроков и отмены некоторых из 300+ проектов, в которых я принимал участие. Рекомендации, как сделать проект более управляемым и предсказуемым, чтобы избежать его провала.
На картинке вы как бы читаете мои откровения (После прочтения сжечь (2008); Режиссер: Джоэл Коэн, Итан Коэн)
Для кого: для всех, кто занимается реализацией ИТ-проектов.
Коротко обо мне: Меня зовут Власов Сергей, 12 лет я исполнял функции директора и менеджера проектов по цифровизации. Заказчиками выступали крупнейшие банки, региональные правительства, федеральные министерства, крупные промышленные предприятия. Самый большой проект, в котором я участвовал — порядка 35 000 человеко-дней.
Причина 1: Техническое задание (ТЗ) не проработано должным образом
У заказчика в проекте есть определенные ожидания, их важно понять, подсветить и зафиксировать в юридически значимом документе. Практически всегда у заказчика не хватает компетенций и времени, чтобы грамотно сформулировать требования, помочь ему в легальном поле — святая обязанность потенциальных исполнителей.
В зависимости от Положения о закупках есть детали и нюансы в процедурах, но в целом:
Этап 1: Работа с заказчиком в момент формирования требований ТЗ, до публикации закупки
Первое взаимодействие с заказчиком может происходить в ходе предварительного смотра рынка, рассылки ТЗ для получения коммерческих предложений (для формирования начальной цены контракта) , в ходе знакомства на выставке или конференции. Если вы заинтересованы в проекте, нужно начинать прорабатывать ТЗ как можно раньше, чтобы избавиться от невыполнимых строчек вида:
Система должна обладать интерфейсом, максимально удобным для всех пользователей
В системе должны быть все функции, необходимые пользователям при выполнении своих должностных обязанностей
Система должна обладать достаточным для комфортной работы всех пользователей быстродействием
(строчки из реальных ТЗ на 10–50 миллионов рублей)
На картинке планируется демонстрация абсолютно восхитительного ТЗ, но по факту это ээээ…(После прочтения сжечь (2008); Режиссер: Джоэл Коэн, Итан Коэн)
Помимо принципиально невыполнимых строчек ТЗ, бывают и требования в духе «все элементы управления должны быть желтыми и располагаться справа», хотя прикладной смысл таких требований может быть непонятным и заказчику. От подобных пунктов полезно избавляться, иногда предлагая дополнительный, уже реализованный у вас функционал, повышая лояльность.
Все «шероховатости» ТЗ должны быть по возможности отработаны до публикации тендера, при этом измененные пункты должны быть отдельно проговорены со стейкхолдерами. Если заказчик принципиально не хочет менять ТЗ, даже в каких-то отдельных и ошибочных требованиях, то, вероятнее всего, эти пункты добавлены под конкретного исполнителя.
Для здравой оценки объема проекта важно учитывать и дополнительные нюансы: написание всей документации проекта по ГОСТ или шаблонам заказчика, использование внешних организаций в качестве экспертных, требования дополнительных документов, на которые заказчик ссылается в своем ТЗ.
Не всегда получается «исправить» ТЗ, но даже попытки стоят затраченного времени. Как минимум, чтобы четко понимать риски проекта и нужно ли в него вообще идти.
Этап 2: Работа с ТЗ при подаче в закупку
С момента публикации тендера у вас сильно сокращаются возможности повлиять на ТЗ, разве что есть некоторые шансы на отмену закупки по причине неявки всех участников или из-за желания самого заказчика исправить технические ошибки.
Однако подача в тендер — это тот самый момент, когда у вас начинают появляться юридические обязательства перед заказчиком.
Необходимо еще раз перепроверить ТЗ на предмет реализуемости, внимательно посмотреть на планируемые трудозатраты, взвесить риски, получить юридически значимые коммерческие предложения от своих субподрядчиков (перед этим проверить, что субподряд возможен) . В большинстве случаев к заказчику можно обращаться за разъяснениями по ТЗ, практически во всех тендерах есть возможность приложить свое технико-коммерческое предложение, которое часто в дальнейшем станет приложением к договору и будет подписано с двух сторон. Это слабая, но защита от двойных трактовок положений ТЗ.
Этап 3: Работа с заказчиком по детализации требований ТЗ после заключения контракта
Документы, создаваемые в рамках этого этапа, могут называться и оформляться по-разному — Технический проект, Частное техническое задание (ЧТЗ) , зависит от заказчика. Но общий смысл этапа не в том, чтобы расширить ТЗ текстовыми описаниями и добавить скриншотов интерфейса, а в том чтобы нарисовать картинку результатов проекта и внятно донести эту картинку всем стейкхолдерам.
На картинке абсолютно счастливый заказчик, когда он понял, что он получит в результате внедрения (После прочтения сжечь (2008); Режиссер: Джоэл Коэн, Итан Коэн)
Особенность ИТ проектов в том, что любой более-менее крупный и даже средний проект можно не принять по ТЗ и ЧТЗ, если такое желание есть у стейкхолдера. А суды с заказчиком — дело крайне неблагодарное. Формальный подход к написанию ЧТЗ, где руководитель проекта стремится силами аналитиков описать существующий продукт и выполнить требования по оформлению, а затем согласовать ЧТЗ как можно скорее, похоронило не один проект.
В идеальном проекте стоит убедиться в концептуальном принятии вашего варианта реализации, продемонстрировать пример такой реализации, затем детально описать ее в составе проектных документов, и только затем приступать непосредственно к разработке или внедрению. В реальности нас обычно поджимают сроки.
Существуют инструменты, способные помочь сформировать картинку проекта. Это всевозможные прототипы и опытные эксплуатации (часто на основе уже реализованных проектов) , детальные презентации для каждого стейкхолдера/группы стейкхолдеров, карты процессов, референс-визиты к реальным заказчикам со схожими проектами, с обязательной демонстрацией и обсуждением всего процесса. Выбор конкретного способа донесения картинки зависит не только от ваших возможностей, но и от состояния проекта — некоторые проекты требуется «допродать» уже после заключения контракта, по некоторым проектам просто нужно снять требования. Бывали случаи, когда в ходе формирования картинки заказчик понимал, что он представлял себе на этапе инициации конкурса в голове совсем другое. Неприятно, но лучше, чем узнать это на этапе сдачи проекта.
Итоговый документ должен быть внимательно прочитан всеми стейкхолдерами, но подписывающих должно быть максимум 4–5. Как известно, каждый дополнительный согласующий увеличивает число итераций кратно.
По моему опыту, нормально и даже правильно, если создание проектных документов и сведение требований заказчика и ваших возможностей составляет от 20 до 40% стоимости крупного проекта в целом, (что по-прежнему существенно дешевле, чем переделывать систему 5 раз) , вклад в результат проекта, по ощущениям, сопоставимый. Заказчику это говорить не нужно — реакция, как правило, резко негативная («я же объяснял целых 2–152 часа, что нужно, почему я должен платить за ваши внутренние бумажки») .
Причина 2: Недостаточное понимание стейкхолдеров
Значительная часть разработчиков, технических руководителей проекта, системных аналитиков и иже с ними нацелены либо на создание «идеальной» системы, либо на идеальное исполнение написанного в проектных документах (плюс максимально экономное, если это есть в KPI) . Практически все проекты же, с моей точки зрения, больше про людей, их интересы и удовлетворение этих интересов. В конце-концов, изначальные требования ТЗ могут быть написаны под влиянием моды, быть взяты из чужих ТЗ, базироваться на ошибочных представлениях о способах реализации процесса, быть написанными за годы до публикации тендера. Поэтому:
Необходимо уделять достаточное внимание стейкхолдерам до начала проекта
Согласно определению PMBok, стейкхолдеры — лицо, группа или организация, которая может влиять, на которую могут повлиять или которая может воспринимать себя подвергнутой влиянию решения, операции или результата проекта.
Я бы существенно сузил для этой статьи понятие до лиц, счастье которых может существенно повлиять на факт сдачи проекта. И далеко не всегда это люди, подписывающие документы (проектная команда) .
Для каждого проекта существует уникальный перечень стейкхолдеров, при этом интересы каждой персоналии (группы) могут фундаментально отличаться от прекрасного «сделать быстро, за бюджет и в срок, максимум функционала и чтобы было даже удобнее, чем мы смогли придумать в проектных документах».
Мне приходилось сталкиваться в реальных проектах с:
Юристами, весь интерес к проекту которых был в выполнении KPI на число замечаний к документам (представьте себе ЧТЗ на 160 страниц, с документом с замечаниями и их обсуждением на 600 страниц; как минимум треть замечаний — к изначальному ТЗ, предоставленному заказчиком)
Ключевыми функциональными заказчиками, которые были строго против модернизации системы, просто чтобы не работать по-новому
Безопасниками, которые показывали свою незаменимость и были против любых элементов иностранного ПО в проектах (в том числе СПО-компонентов)
Замруководителями, весь интерес в проекте у которых был в том, чтобы проект не получился и инициатор проекта показал себя дураком
«Как, вы работаете не за идею?» (После прочтения сжечь (2008); Режиссер: Джоэл Коэн, Итан Коэн)
Из-за подобных конфликтов интересов, даже не связанных напрямую с проектами, проекты откладывались на годы, отменялись или же становились убыточными для стороны исполнителя.
В идеальном мире хотелось бы понимать интересы основных стейкхолдеров до принятия решения об участии в проекте, чтобы отказаться от принципиально нереализуемых проектов.
В реальном мире можно сильно «подстелить соломку» и сократить риски и затраты за счет как можно более раннего:
Выяснения списка стейкхолдеров и их зон ответственности, получения всех касающихся проекта документов (регламентов бизнес-процессов, правил эксплуатации ПО, требований по безопасности, стратегии цифровой трансформации, цифровизации, информатизации и так далее) . Помогает погуглить прошлое место работы ключевого стейкхолдера и изучить прикладной процесс там. Полезную информацию можно встретить в интервью и статьях стейкхолдеров
Выявления сильного союзника — человека, которому нужен проект для целей прямой эксплуатации, желательно с высокими полномочиями и/или вхожестью в высокий кабинет. Идеально, если он же — руководитель проекта со стороны заказчика и имеет в своем KPI реализацию проекта
