Меня зовут Сергей Яковлев, я руковожу проектами в ИТ более 10 лет. Хочу поделиться историей о том, как мы сделали проект, который попал в статистические 31 % реализованных ИТ-проектов, и при этом выдержали все базовые показатели: содержание, сроки, бюджет, качество. Причём в начале у меня был минимум знаний в предметной области, команды не было вовсе, а сдать проект необходимо было через год. Здесь я постарался описать весь жизненный цикл проекта, чего я ни разу не встречал в книгах и методологиях, и то, с чем сталкивается руководитель проекта при создании продукта.

Акт первый. Запустить проект

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

 Контракт был разбит на четыре стандартных этапа:

1.     проектирование и дизайн системы с предоставлением отчёта и документации заказчику;

2.     разработка системы;

3.     интеграции со смежными системами;

4.     демонстрация и сдача продукта заказчику.

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

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

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

 Комиссию прошли успешно и выдохнули с облегчением. Дело было в декабре, следующий этап сдавать в июле, а весь проект — в октябре. Все ушли на новогодние праздники и успокоились. Но не я.

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

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

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

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

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

Сформировав пакет документов, выписав все высокоуровневые риски, я подготовил устав, или, как у нас он назывался, паспорт проекта, в котором зафиксировал все основные характеристики:

• суть проекта;

• сроки реализации;

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

• высокоуровневые риски;

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

• ограничения договорного и внебюджетного инвестирования;

• спонсоры и руководители проекта.

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

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

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

Акт второй. Реализация проекта

Согласовав паспорт, я подумал: «Ну всё, сейчас начнём работать, мне дадут людей в команду, и мы побежим формировать требования и пилить, пилить программное обеспечение!» Но этого не произошло. Сколько я ни обивал пороги кабинетов собственного и соседних подразделений, людей мне не дали, а также сообщили, что вакансий нет, и когда откроют — неизвестно. Я смог получить только одного бизнес-аналитика, хотя нуждался в трёх, и одного бэкенд-разработчика. Архитектор остался тот, что был.

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

 Пересобрав свой план управления коммуникациями по проекту, я назначил ежедневные планёрки с командой, которые сразу ограничил по времени до получаса. Правда, команда наша состояла на тот момент всего из четырёх человек, и длились эти собрания не более 10 минут. Я продолжал искать людей в команду, но их по-прежнему не давали. И тут я понял, как можно использовать Управляющий комитет, ведь в нём участвовало руководство компании, главы основных направлений бизнеса. Я снова отправился туда, вооружившись гистограммами с показателями по набору сотрудников, освоенными объёмам денег и прогнозами завершения проекта. Изучив мои отчёты, руководство компании всё-таки открыло необходимые мне вакансии. Казалось бы, вот оно, счастье, но нет. На дворе стоял февраль 2022 года, что было и плюсом, и минусом. Рынок вакансий и так разогрет, иностранные компании уходят из России, люди уезжают, большие ИТ-компании забирают их с рынка, а у тех, кто не уезжает, зарплаты растут. При этом наша организация платит в среднем по рынку, и на дополнительное финансирование шансов мало. Но нам повезло: мы успели взять главного системного аналитика, старшего аналитика и дизайнера. А вот требования ещё не сформировали, и пилить было нечего. Мы продолжили искать фронтендеров, так как, пересобрав архитектуру, поняли, что основная функциональность будет на web, а значит потребности в бэкенде ниже, чем ожидалось.

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

 В марте нужно было сделать сервис расчёта и построения маршрутов судов. К нему мы пока никак не могли подобраться, так как необходимо было проработать алгоритмы и на их основании разработать модуль, а специалистов, которых было бы возможно подключить у этому, не было. Как говорится, помощь пришла оттуда, откуда её не ждали: технический директор был заинтересован в сервисе построения маршрутов для других систем, и он предложил использовать команду из семи математиков для разработки алгоритмов. Таким окном возможностей нельзя было не воспользоваться, но был нюанс: коллеги писали только на Python, а у нас весь проект был на Java. Посовещавшись, решили: пусть сделают отдельный модуль на своём стеке, покажут через простой web–интерфейс, как у них это работает с использованием наших данных (погода, гидрометеорологическая обстановка, картография), и будем думать, как это интегрировать в общую систему.

 И вот уже май. У нас предварительно проработан один сервис, пришло ещё два отличных аналитика, есть архитектор, дизайнер и разработчик, но почему-то проект не летит, а ползёт. Аналитики тратят уйму времени, чтобы погрузиться в предметную область, почитать нормативку, сформулировать бизнес–потребность, которая прописана в техническом задании. Заказчик не консультирует, так как «вы же работаете в этой сфере, сами разберётесь». Я начал задумываться, как выйти из этой ситуации.

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

1.     Бизнес-аналитик описывает предметную область по данному сервису согласно нормативным документам.

2.     Аналитик описывает основные функциональные требования, а также основные бизнес-процессы, которые должен выполнять сервис.

3.     Проверяем требования, чтобы определить, что выполняем, а что выносим за рамки проекта.

4.     Окончательно корректируем требования.

5.     Прорабатываем дизайн web-интерфейсов.

6.     Прорабатываем архитектуру.

7.     Декомпозируем требования на задачи для команды разработки.

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

 После того как мы обо всём условились и описали процессы, всё должно было просто лететь. Команда росла, с февраля по июнь увеличилась до 17 человек, но и проблемы росли вместе с ней. Мы полностью выстроили весь процесс разработки; определили, как и где должны храниться документы; я пересобрал полностью план коммуникаций; обновил реестр заинтересованных сторон в связи с появлением смежников и подрядчиков по интеграциям. Вместо одного разработчика теперь было десять, появился DevOps и тестировщики. Команда разработки работала двухнедельными спринтами, мы проводили планирование спринтов, ежемесячное планирование и раз в месяц — ретроспективу, но продолжали отставать: время, потерянное с января по апрель, давало о себе знать. Модуль расчёта и построения маршрутов был готов, но необходимо было оптимизировать его работу и сделать интеграции, а сервисы, с которыми он интегрировался, ещё не были готовы.

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

 Наступил июль, и пора было показывать, что мы сделали с декабря. Согласно требованиям договора, мы должны были продемонстрировать часть работающей системы. Посовещавшись, решили, что покажем четыре работающих сервиса из восьми и часть имеющихся web-интерфейсов, так как основные интеграции переходили в следующий этап. Комиссию со стороны заказчика прошли, получили замечания, и мой руководитель договорился, как мы будем сдавать выполненную систему. А именно, мы согласовали, что будем сдавать работы через приёмо-сдаточные испытания (ПСИ) одному из подведомственных учреждений заказчика. На какое-то время напряжение внутри команды спало.

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

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

Акт третий. Сдача проекта

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

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

 На сами ПСИ я не попал. Их неоднократно переносили, и я оказался в учебном отпуске. Мне позвонили ребята и сообщили радостную новость: испытания мы прошли с первого раза. Теперь предстояло пройти комиссию, которая принимает решение о сдаче системы. Там её у нас не приняли. У членов комиссии возникли сомнения в готовности, и к нам направили ревизор. К его приезду в ноябре мы устранили наиболее критичные дефекты, которые могли привести к падению системы, и наша группа сдачи снова провела для него успешную демонстрацию работающих сервисов согласно сценариям приёмо-сдаточных испытаний.

Выводы и ретроспектива

Чтобы проект по созданию систем не растягивался на годы, а нужный результат был достигнут, важно заранее спланировать все работы и действия. Это поможет компании, в которой ты работаешь, избежать штрафов, репутационных потерь и прочих неприятностей. Как бы тривиально это ни звучало, всё начинается с сути или образа результата, а также целей, которые мы хотим достигнуть. И здесь стоит обратить внимание на PMBOK 6, хоть все и говорят, что это «тяжёлое» руководство, или IPMA ICB4 и Prince 2.

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

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

 Документация по проекту (база знаний) должна постоянно актуализироваться и поддерживаться как руководителем, так и командой проекта. Стоит сразу определить, в какой информационной системе вы это делаете и как вы её используете. При этом руководитель проекта должен не только это отслеживать, но и подавать пример всей команде. Как всегда, действует правило: «Если ты сам чего-то не делаешь, то и от других требовать не можешь».

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

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