Про госзаказы и тендеры есть два полярных мнения: одни говорят, что это очень просто, потому что есть чёткое ТЗ и вся документация, другие уверены, что это самые сложные проекты, которые только можно представить. Но ключевая особенность таких проектов в том, что они так или иначе влияют на жизни миллионов людей, и ошибка в них — это часто цена успешности реализации конкретной госпрограммы. Мы поговорили с Сергеем Ковтуном, генеральным директором digital-интегратора Notamedia о том, как на самом деле обстоят дела с госзаказами и что нужно учитывать каждому, кто хочет работать в этой области.
Что главное для успешной реализации проекта
Ключевой момент каждого успешного проекта — наличие продуктовой экспертизы на стороне заказчика. Это значит, что нужно не просто управлять своим проектом (или направлением, за которое отвечает менеджер), а чтобы в команде заказчика был человек, который понимает, как работает бизнес и как строятся информационные системы для развития этого бизнеса.
Дело в том, что агентство или интегратор (какими бы крутыми они ни были) чаще всего не в контексте этого проекта, не знают его настолько глубоко, как специалисты на стороне клиента. Конечно, в начале работ всегда есть этап погружения, но за ограниченное время просто невозможно учесть все нюансы и тонкости работы проекта. И тут как раз выходят на первый план знания сотрудников — они помогают увидеть слабые места и сделать конечный продукт лучше.
С нашей стороны мы всегда стараемся найти таких людей в проекте со стороны заказчика, наладить коммуникацию и поставить во главу угла успешность проекта. С опытом мы поняли, как устроена структура управления в госкомпаниях и крупном бизнесе, каких специалистов лучше привлечь — и это позволяет нам сразу решать большинство вопросов при реализации рабочих задач.
О продуктовой экспертизе, ответственности и формальном подходе
Есть два подхода к реализации крупных проектов — командный и формальный.
Командный подход проще всего показать на конкретном примере. Лучшая команда, с которой мы работали — это Департамент информационных технологий города Москвы. У них есть свои продакты, отвечающие за результат со своей стороны, а главное — никто не встаёт в позицию «заказчик-исполнитель». Вместо этого мы стали одной командой, которая работает как единое целое и отвечает перед функциональным заказчиком.
В командном подходе все понимают, зачем они делают этот проект. И здесь требуется даже большая ответственность исполнителя, чем на проекте без такого вовлечения со стороны заказчика. И это ответственность — не перед мэром или Администрацией Президента, а перед самими собой. Вся команда (исполнитель и заказчик) понимает социальную значимость того, что должно получиться в итоге, и все работают в едином порыве. Это — идеальный сценарий успешного проекта.
Но бывает и такое, что все начинают перекладывать ответственность друг на друга, и тут уже начинается формальный подход: вот ТЗ, вот договор, вот требования, а от подрядчика требуется техническая реализация. Исполнитель хочет выполнить свои KPI и закрыть всё актами, чтобы получить деньги, а заказчик хочет сэкономить бюджет. При этом какой и какого качества получится продукт — уже не очень важно, потому что на первом месте стоят формальные требования.
В таких условиях сделать крутой продукт почти нереально. Заказчику важно соблюсти все пункты договора и ТЗ, поэтому отбрасывается всё, что не предусмотрено документами, даже если это помогает сделать продукт лучше. В итоге получается, что формально всё сделано как написано, но по сути этим продуктом никто не будет пользоваться, потому что он сделан с ориентиром на документы, а не на людей.
Диалог с клиентом
Одна из самых сложных вещей при работе над госпроектами — общение с заказчиком.
Сейчас репутация работает на нас: мы приглашены на все рабочие встречи по проекту, потому что никто не переживает, что мы предложим что-то неуместное. Но чаще всего, в обычных ситуациях (особенно когда компания только начинает заниматься такими проектами), менеджер со стороны заказчика пытается всё замкнуть на себя.
Не редко такой менеджер — это типичный проджект-менеджер, который работает в MS Project, умеет строить диаграмму Ганта (или нет), план-графики и оформлять это в виде презентаций. У него вроде всё под контролем, но всё, на что он смотрит — это на цифры, отчёты и графики работ. Со стороны выглядит красиво, но работать так сложно: если у него спросить что-то, выходящее за рамки ТЗ, или как упаковать продукт, как устроен конкретный бизнес-процесс, то мы получим корпоративно выверенный, но зачастую бесполезный ответ.
Всё дело в том, что у такого проджекта зачастую нет понимания, каким образом и зачем считать продуктовые метрики. Например, в рамках проекта мы внедряем новую технологию, выполняем задачи, но какие вообще цели у конечного продукта? Чего мы хотим достичь, если говорить глобально, как это улучшит жизнь или работу других людей? Как мы поймём, что то, что мы делаем, приносит реальную пользу?
У такого проджект-менеджера главное — выполнить каждый раздел по ТЗ и чтобы диаграмма Ганта сошлась. Изначальная цель при этом может забываться или не достигаться в нужном объёме. По документам проект будет сдан, но в жизни им никто пользоваться не будет. Поэтому, если у вас коммуникация идёт именно с таким менеджером, нужно как можно скорее выходить на уровень выше и объяснять заказчику все риски такого подхода.
Проект и продукт
Всегда важно разделять проект и продукт. Проект может пройти замечательно, контракт закроется, приемочные испытания будут пройдены, а продукт всё равно получится плохим. Это значит, что главная цель любого проекта — получить хороший продукт. Да, есть ситуации, когда и самому заказчику по сути всё равно, что получится в итоге, главное — закрыть контракт, но это исключение из правил и, к счастью, встречается редко.
Если заказчик начинает подчёркнуто формально коммуницировать (и особенно, если он пытается давить на побуквенное выполнение ТЗ), то с большей долей вероятности получится проект с ожидаемо плохим результатом. При этом заказчик может даже не осознавать последствия такого подхода, поэтому задача исполнителя — помочь ему их увидеть и предложить решение в рамках действующих договорённостей.
Чтобы хороший проект не превратился в плохой продукт, нужно искать заинтересованных лиц и работать с ними. Налаживать контакт, общаться, рассказывать, как идут дела и посвящать их во внутреннюю кухню разработки. Поэтому, когда возникает ощущение, что из-за действий заказчика может получиться плохой продукт, крайне важно найти заинтересованного человека на стороне клиента, прийти к нему и сказать: «Слушай, у нас проблемы в проекте, давай что-то менять».
У нас был один случай в 2018 году, когда из-за некомпетентности менеджера со стороны заказчика проект превратился в то, что мы называем «техническое выполнение требований». Поиск заинтересованных лиц на стороне клиента занял у нас продолжительное время, за которое мы даже успели начать судебный процесс — настолько проект пошёл не по плану. В итоге, когда мы поговорили с клиентом и совместно нашли оптимальное решение, всё удалось уладить. Но до такой стадии лучше не доводить: всегда ищите того, кто болеет душой за проект, и обсуждайте всё, как только появились первые признаки тревоги.
Правило, которое мы вывели для себя за эти годы, на самом деле очень простое: нужно всегда говорить с руководством, которое хочет, чтобы проект получился хорошо. Не только формально по ТЗ, а ещё так, как задумывалось изначально. Такие руководители заинтересованы в выполнении, в продукте и в конечной ценности того, что делается.
Гибкость и стратегия риск-менеджмента
Другой вариант — работать по тщательно разработанному техзаданию, которое не допускает отклонений в трактовках формулировок. Но здесь есть неочевидный подводный камень: за то время, что готовится тендер, условия задания могут стать невыгодными или очень сложно реализуемыми. В жизни это выглядит так:
- заказчик составляет ТЗ, исходя из текущей ситуации в стране и на рынке в целом — на это обычно требуется от 2 до 6 месяцев;
- дальше идёт этап внутреннего согласования, который может занимать до полугода;
-
затем разыгрывается тендер — это ещё несколько месяцев.
В итоге исполнитель начинает работать по ТЗ, которое было составлено почти год назад в старых условиях и старых возможностях рынка. А к текущему моменту общая ситуация может кардинально поменяться, но сделать с этим уже ничего нельзя — процесс внесения изменений в техническое задание зачастую сложнее, чем расторжение контракта и заключение нового.
Чтобы справиться с такой ситуацией, исполнитель должен понимать эти риски и быть к ним готовым. Здесь мы приходим к риск менеджменту: выигрывая тендер (или готовясь к нему), компания должна иметь запас прочности как в команде, так и по остальным ресурсам, чтобы адаптировать, возможно, устаревшее ТЗ к новой ситуации на рынке. Если что-то пойдет не так (а что-то однозначно пойдет не так), то такой запас прочности поможет справиться со сложностями и довести проект до успешного финала.
По умолчанию нужно исходить из того, что во время работы над госконтрактом совершенно точно случится что-то непредвиденное. И это не должно быть сюрпризом, потому что если для руководителя со стороны исполнителя это нечто неожиданное, то значит он еще не готов работать на этом уровне.
Особенности крупного проекта
Крупный проект по объему заказов часто похож на государственный. Они решают задачи схожего масштаба, но у них есть одна важная особенность: всё можно переиграть, чтобы получить по-настоящему крутой и качественный продукт, который поможет многим людям.
Также не всегда стоит смотреть только на цену исполнителя. Часто цена — это единственное, на основании чего компании принимают решение о выборе подрядчика, но исходить только из фактора стоимости может быть опасно для проекта. Есть достаточное количество подрядчиков, которые пообещают сделать в 2-3 раза дешевле, но по итогу компания не достигнет своих проект-целей и может потерять миллионы рублей, которые могла бы заработать.
В ситуациях, когда подрядчик выбирается только по цене, в лучшем случае получится продукт, которым можно как-то пользоваться, но положительных изменений в проекте он не принесет. В отраслиразработки известно много ситуаций, когда компания в лучшем случае просто отбивает потраченные на проект деньги. Но обычно это превращается в трату денег и, главное, времени — никто не возместит компании этот год-полтора, потраченные на такую разработку.
Но если компания-заказчик со своей стороны закроет проблемные места качественной аналитикой и опытными менеджерами, которые будут вести проект и просто ставить задачи исполнителю — тогда да, это сработает. Но сил компания на это потратит много и к этому нужно быть готовым заранее.
