Управление IT-проектом: лайфхаки и командный дух

Максим КОЗИН, директор направления ООО «Платформа», делится лайфхаками управления сложного государственного IT-проекта для ФАС России.

Объекты российского ЖКХ, энергетики и целого ряда других значимых отраслей страны регулируются разветвленной системой тарифов, рассчитываемых по сложным формулам и сильно разнящихся по территориям, изношенности инфраструктуры и т. п. Регулирует тарифы Федеральная антимонопольная служба (ФАС) и региональные органы исполнительной власти в сфере тарифного регулирования. До финального утверждения на федеральном уровне предприятия, снабжающие нас теплом, водой, электричеством и другими коммунальными услугами, формируют тарифные заявки, которые утверждаются по большей части на уровне региона. Типы всех процедур исчисляются десятками и задействуют тысячи участников. До нашего проекта весь этот документооборот осуществлялся частично на бумаге, частично — онлайн, причем с помощью целого зоопарка ИТ-решений.

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

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

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

История наших взаимоотношений с Федеральной антимонопольной службой включает разные периоды, в том числе и “конфетно-букетный”. Как это часто бывает в отношениях, партнеру было важно понять, что мы собой представляем. Чтобы убедиться в уровне наших компетенций, нас попросили реализовать функциональный прототип будущей системы - модель MVP (Minimal Viable Product). Мы выполнили это задание весьма успешно и в сжатые сроки. Правда, потом эта модель нам почти не пригодилась, но мы все равно рассматриваем ее в качестве важной части подобных комплексных проектов и разумной инвестиции в будущее сотрудничество.

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

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

Определившись с задачами и приоритетами,мы приступили к подбору команды, в которой у каждого есть своя роль и определенный функционал. Этот процесс продолжается до сих пор: штат доукомплектовывается после каждой новой интеграции. Если три года назад наша команда состояла из 5-6 человек, то сейчас у нас работает уже 70 специалистов, и мы понимаем, что это не предел. Чем больше становится штат, тем сильнее мы нуждаемся в управленческих кадрах - руководителях подразделений, которые возьмут на себя ответственность за различные блоки и процессы. Но как бы не росла команда, ключевым сотрудником все равно остается разработчик - профессионал, который понимает все нюансы своей работы и степень её значимости в общем результате. Чтобы ощущать себя частью команды, людям очень важна обратная связь. У нас она осуществляется через практику релизов: каждые две недели команды рассказывают, над чем они сейчас работают, какой запрос есть от заказчика. Благодаря этой системе все наши сотрудники всегда понимают, куда мы движемся.

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

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

Для самих задач мы создали стандарт описания: они у нас типизированы и структурированы.

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

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