Если в начале проекта вы не знаете, как и когда он закончится, а только можете перекреститься, если после встреч с заказчиками вы обнаруживаете себя плачущим в туалете, если лучшие сотрудники уходят от вас так поспешно, что даже не передают дела - эта статья поможет вам (но это не точно). Главные причины расползания границ, бюджетов, сроков и отмены некоторых из 300+ проектов, в которых я принимал участие. Рекомендации, как сделать проект более управляемым и предсказуемым, чтобы избежать его провала.

Для кого: для всех, кто занимается реализацией ИТ-проектов.

Коротко обо мне: Меня зовут Власов Сергей, 12 лет я исполнял функции директора и менеджера проектов по цифровизации. Заказчиками выступали крупнейшие банки, региональные правительства, федеральные министерства, крупные промышленные предприятия. Самый большой проект, в котором я участвовал — порядка 35 000 человеко-дней.

Причина 1: Техническое задание (ТЗ) не проработано должным образом

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

В зависимости от Положения о закупках есть детали и нюансы в процедурах, но в целом:

Этап 1: Работа с заказчиком в момент формирования требований ТЗ, до публикации закупки

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

• Система должна обладать интерфейсом, максимально удобным для всех пользователей

• В системе должны быть все функции, необходимые пользователям при выполнении своих должностных обязанностей

• Система должна обладать достаточным для комфортной работы всех пользователей быстродействием

  (строчки из реальных ТЗ на 10-50 миллионов рублей)

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

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

Для здравой оценки объема проекта важно учитывать и дополнительные нюансы: написание всей документации проекта по ГОСТ или шаблонам заказчика, использование внешних организаций в качестве экспертных, требования дополнительных документов, на которые заказчик ссылается в своем ТЗ.

Не всегда получается «исправить» ТЗ, но даже попытки стоят затраченного времени. Как минимум, чтобы четко понимать риски проекта и нужно ли в него вообще идти.

Этап 2: Работа с ТЗ при подаче в закупку

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

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

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

Этап 3: Работа с заказчиком по детализации требований ТЗ после заключения контракта

Документы, создаваемые в рамках этого этапа, могут называться и оформляться по-разному — Технический проект, Частное техническое задание (ЧТЗ) , зависит от заказчика. Но общий смысл этапа не в том, чтобы расширить ТЗ текстовыми описаниями и добавить скриншотов интерфейса, а в том чтобы нарисовать картинку результатов проекта и внятно донести эту картинку всем стейкхолдерам.

Особенность ИТ проектов в том, что любой более-менее крупный и даже средний проект можно не принять по ТЗ и ЧТЗ, если такое желание есть у стейкхолдера. А суды с заказчиком — дело крайне неблагодарное. Формальный подход к написанию ЧТЗ, где руководитель проекта стремится силами аналитиков описать существующий продукт и выполнить требования по оформлению, а затем согласовать ЧТЗ как можно скорее, похоронило не один проект.

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

Существуют инструменты, способные помочь сформировать картинку проекта. Это всевозможные прототипы и опытные эксплуатации (часто на основе уже реализованных проектов) , детальные презентации для каждого стейкхолдера/группы стейкхолдеров, карты процессов, референс-визиты к реальным заказчикам со схожими проектами, с обязательной демонстрацией и обсуждением всего процесса. Выбор конкретного способа донесения картинки зависит не только от ваших возможностей, но и от состояния проекта — некоторые проекты требуется «допродать» уже после заключения контракта, по некоторым проектам просто нужно снять требования. Бывали случаи, когда в ходе формирования картинки заказчик понимал, что он представлял себе на этапе инициации конкурса в голове совсем другое. Неприятно, но лучше, чем узнать это на этапе сдачи проекта.

Итоговый документ должен быть внимательно прочитан всеми стейкхолдерами, но подписывающих должно быть максимум 4-5. Как известно, каждый дополнительный согласующий увеличивает число итераций кратно.

По моему опыту, нормально и даже правильно, если создание проектных документов и сведение требований заказчика и ваших возможностей составляет от 20 до 40% стоимости крупного проекта в целом, (что по-прежнему существенно дешевле, чем переделывать систему 5 раз) , вклад в результат проекта, по ощущениям, сопоставимый. Заказчику это говорить не нужно — реакция, как правило, резко негативная («я же объяснял целых 2-152 часа, что нужно, почему я должен платить за ваши внутренние бумажки») .

Причина 2: Недостаточное понимание стейкхолдеров

Значительная часть разработчиков, технических руководителей проекта, системных аналитиков и иже с ними нацелены либо на создание «идеальной» системы, либо на идеальное исполнение написанного в проектных документах (плюс максимально экономное, если это есть в KPI) . Практически все проекты же, с моей точки зрения, больше про людей, их интересы и удовлетворение этих интересов. В конце-концов, изначальные требования ТЗ могут быть написаны под влиянием моды, быть взяты из чужих ТЗ, базироваться на ошибочных представлениях о способах реализации процесса, быть написанными за годы до публикации тендера. Поэтому:

Необходимо уделять достаточное внимание стейкхолдерам до начала проекта

Согласно определению PMBok, стейкхолдеры — лицо, группа или организация, которая может влиять, на которую могут повлиять или которая может воспринимать себя подвергнутой влиянию решения, операции или результата проекта.

Я бы существенно сузил для этой статьи понятие до лиц, счастье которых может существенно повлиять на факт сдачи проекта. И далеко не всегда это люди, подписывающие документы (проектная команда) .

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

Мне приходилось сталкиваться в реальных проектах с:

• Юристами, весь интерес к проекту которых был в выполнении KPI на число замечаний к документам (представьте себе ЧТЗ на 160 страниц, с документом с замечаниями и их обсуждением на 600 страниц; как минимум треть замечаний — к изначальному ТЗ, предоставленному заказчиком)

• Ключевыми функциональными заказчиками, которые были строго против модернизации системы, просто чтобы не работать по-новому

• Безопасниками, которые показывали свою незаменимость и были против любых элементов иностранного ПО в проектах (в том числе СПО-компонентов)

• Замруководителями, весь интерес в проекте у которых был в том, чтобы проект не получился и инициатор проекта показал себя дураком

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

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

В реальном мире можно сильно «подстелить соломку» и сократить риски и затраты за счет как можно более раннего:

• Выяснения списка стейкхолдеров и их зон ответственности, получения всех касающихся проекта документов (регламентов бизнес-процессов, правил эксплуатации ПО, требований по безопасности, стратегии цифровой трансформации, цифровизации, информатизации и так далее) . Помогает погуглить прошлое место работы ключевого стейкхолдера и изучить прикладной процесс там. Полезную информацию можно встретить в интервью и статьях стейкхолдеров

• Выявления сильного союзника — человека, которому нужен проект для целей прямой эксплуатации, желательно с высокими полномочиями и/или вхожестью в высокий кабинет. Идеально, если он же — руководитель проекта со стороны заказчика и имеет в своем KPI реализацию проекта ????

• Внимательного изучения информации о проекте из открытых источников — если системой занимается одна и та же компания последние 5 лет, а вам на первой встрече не говорят «мы хотим менять систему/подрядчика», высока вероятность, что вам попались очень вежливые люди, которые на самом деле вам не очень рады

• Достаточного количества предварительных встреч и показов системы и своих возможностей, в том числе в ходе организации референс-визитов, по аналогии с процессом подготовки ЧТЗ. А еще у представителей заказчика при определенном уровне выстроенного доверия можно просто спросить «что вы ожидаете от проекта» и «почему вы отказываетесь от старой системы», и услышать неочевидные (но важные!) для проекта ответы

• Банального выстраивания отношений со стейкхолдерами. Зачастую на шестой встрече, особенно под кофе, говорят то, что никогда не скажут на первой (в духе «вы уже третьи, кто сюда пришел, через пару показов вас попросят бесплатно дать попользоваться системой месяц и вы сольетесь, как и все прошлые»)

Необходимо уделять достаточное внимание стейкхолдерам в ходе исполнения проекта

Проекты имеют обыкновение обрастать дополнительными требованиями в ходе реализации и даже «расползаться» по срокам и границам из-за проблем с оборудованием, новых стейкхолдеров, изменений в политической конъюнктуре, появления новых нормативных документов. О реализации каких-то пунктов можно договориться после сдачи проекта, в рамках проектов развития системы и за отдельные деньги, какие-то придется реализовать за счет прибыли/рисков проекта, какие-то вещи можно уговорить не реализовывать взамен на дополнительный функционал. Где-то получится заключить дополнительное соглашение. В каждый момент времени каждый стейкхолдер с соответствующей зоной интересов должен быть в курсе текущего состояния, планов по реализации, рисков и проблем, которые возникают и по вине заказчика и по вине исполнителя.

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

Худшее, что может случиться с точки зрения хода проекта — формализация требований в рамках ЧТЗ, его подписание и уход на три месяца на разработку. С новостью для заказчика в конце срока о том, что разработка не успевает и будет задержка еще на пару месяцев. «Ну, вы же сами попросили добавить две кнопки, мы думали, что вы понимаете, что еще какое-то время потребуется».

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

Необходимо уделять достаточное внимание стейкхолдерам после исполнения проекта

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

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

С другой стороны, я видел проекты с хорошим потенциалом, которые были заброшены через полгода после внедрения с причиной вида «у нас порушились все бекапы, не было времени поднимать сервис, мы ушли обратно в Excel». Одна крупная компания, которая как-то купила 6 разных систем для автоматизации бизнес-процессов за 3 года для разных департаментов, в результате ушла обратно в электронную почту и Jira.

Причина 3: Низкая мотивация сотрудников

Даже если вы хорошо понимаете потребности стейкхолдеров, имеете идеальную техническую документацию, хорошо оценили и запланировали проект, заниматься разработкой, внедрением, опытной эксплуатацией, обучением, гарантийной поддержкой будут ваши аналитики, инженеры и разработчики. Один сотрудник, вовремя не отработавший замечание или возражение заказчика на одной встрече, может послужить причиной изрядных (больше его годовой зарплаты, а то и зарплаты за десять лет) затрат на переработку системы. Присутствовать на всех встречах и читать всю переписку руководитель проекта не может физически. Единственный вариант — быть уверенным в мотивации каждого.

На тему мотивации написаны сотни статей и научных публикаций. Если говорить конкретно о моем опыте:

• Сотрудник должен получать хотя бы среднюю зарплату по его квалификации; хороший вклад в проект должен качественно повышать его доход за счет бонусов

• Сотрудник должен видеть и чувствовать, что его работа имеет значение и для компании и для заказчика; скорость выгорания на бесполезных проектах кратно выше. Любой проект приводит к фундаментально лучшим результатам, если сотруднику действительно не все равно, если он не ограничивается должностными инструкциями (и, кстати, если он налаживает отношения с заказчиком со своей стороны) . Отмахиваться от инициатив сотрудника недопустимо

• Сотрудник должен четко понимать, что документы и софт — это инструменты удовлетворения потребностей заказчика, повышения удобства и качества работы (в прекрасном мире) . Я видел много проектов, где аналитик не задерживался на встрече на 20 минут, потому что «ну какая разница, они могут говорить часами ни о чем». «Синдром советской продавщицы» действительно присутствует в реальных проектах на десятки миллионов рублей и способствует их заваливанию. Иногда — даже со стороны собственников и генеральных директоров. Даже если клиент будет доволен софтом, но не доволен качеством сервиса, это сильно повлияет и на сдачу текущего проекта и на будущие проекты

• Переработки возможны и даже неминуемы, особенно при сдаче нескольких проектов сразу, но сотрудник должен видеть, что его переработки вносят существенный вклад в успех проекта; он должен знать о них заранее

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

• Бороться с выгоранием сильно помогает четкое разделение ролей в команде. Продавец или аккаунт-менеджер защищает интересы клиента, менеджер проекта — интересы своих сотрудников. Это касается и новых требований заказчика, и переработок, и подъемов по ночам «у нас все сломалось, немедленно чините». Если ваши сотрудники получают нагоняй — получайте вместе с ними. Если перерабатывают — сидите вместе с ними. Если осталось сделать только настройки — носите кофе.

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

Лучший способ делать проекты, который я нашел для себя за 12 лет — чтить PMBok и проектные документы, но помнить, что проекты — это про людей и их интересы и со стороны заказчика и со стороны исполнителя.

Хочется завершить этот учебный материал про ошибки и ИТ проекты диалогом из чудесного фильма После прочтения сжечь (2008); Режиссер: Джоэл Коэн, Итан Коэн:

– Мать твою за ногу… чему мы научились, Палмер?

– Не знаю, сэр.

– Я тоже… Научились больше этого не делать.

– Да, сэр.

– Еще бы знать, что мы сделали.

– Да, сэр, это сложно сказать.

Титры ????