Проект, в котором привычные инструменты не сработали
У нас был проект, о котором мы внутри команды говорим: «Тот самый». Отклонение от плановых часов составило больше чем в два раза. Не 20%, не 50%, а почти в два раза. При этом у нас были и процессы, и метрики, и статус-встречи, и опытная команда. Но к дате X, когда мы все ждали результата, это просто не сработало.
Тогда мы подумали: «Может быть, мы применяем правильные инструменты не к тому типу проектов?»
В этой статье поговорим об особых технологических проектах и о том, почему иногда управление ими идет в темноте.
Наша компания всегда работала по модели «мы помогаем», то есть мы подключали специалистов к проектам наших заказчиков и партнеров. Но в последнее время также работаем в модели «мы решаем», когда полностью осуществляем проектный подход, берем на себя ответственность за результат и предоставляем собственные команды.
Что такое технологические проекты
В проектах наш фокус – не классическое внедрение ERP-систем, которые автоматизируют хозяйственную деятельность компаний. Мы сосредоточены на проектах и инструментах для управления данными.
В современной действительности компании накапливают терабайты данных в рабочих процессах. Многим знакомо выражение «данные – это новая нефть». Задачи качественной обработки, передачи, хранения и согласования данных становятся стратегическими для управления и масштабирования бизнеса.
Технологические проекты для нас – это интеграционные шины, корпоративные хранилища данных, MDM-системы и BI-системы. Все то, что встраивается в IT-ландшафт заказчика и связывает системы между собой.
Когда мы начали управлять такими проектами, то обнаружили их фундаментальное отличие от привычных ERP-внедрений. Классические методы управления проектами здесь попросту ломаются.
Разберем, почему технологические проекты – это другой мир, как классические методы ломаются на реальных кейсах нашей компании и как мы пришли к системному подходу к таким проектам.
Технологический и ERP-проект
Внедрение ERP зачастую похоже на строительство дома в чистом поле.
Архитектура проектируется целиком и сразу, просчитываются риски и сложности: коммуникации, дороги, инфраструктура. Каждый модуль может быть видимым результатом. Вот фундамент, вот заложенные коммуникации, стены и крыша. Прогресс очевиден заказчику. Он приезжает каждую неделю и видит, как растет дом и даже район рядом с ним.
При этом модули могут быть независимыми. Например, продолжением дома может стать большой спортивный комплекс или паркинг.
Технологический проект – это другое. Это ситуация, когда нужно встроить новое здание в центр города, где уже стоят десятки других зданий, проложены коммуникации и ходят люди. Результат мы увидим только тогда, когда застройщик согласует, что именно и как будет построено в текущей архитектуре и с текущими коммуникациями.
Другой пример – строительство станции метро. Под землей идут сложнейшие работы, но сверху весь процесс не виден. Когда станция запускается, жизнь людей и города становится гораздо лучше. Все меняется, хотя до самого запуска результат работы был практически незаметен.
Здесь мы приходим к пониманию скорости внедрения в зависимости от типа и архитектуры приложения.
Аналитическая компания Gartner предложила стратегию управления приложениями. Ее суть проста: все приложения делятся на три слоя в зависимости от скорости изменений и их роли в бизнесе.
Нижний слой – системы учета. Это тяжелые системы: ERP, производственные, кадровые. Они живут в компаниях десятилетиями и меняются редко. Главное, чтобы они работали надежно и точно.
Второй слой – системы изменений, или системы дифференциации. Это привычные нам B2B-порталы, CRM-системы, мобильные личные кабинеты, например приложения служб доставки или кабинеты клиентов интернет-магазинов. Все то, что помогает компании быть лучше и быстрее конкурентов.
Наверху находятся системы инноваций. Это эксперименты: чат-боты, пилоты, AI-решения. Они могут жить несколько месяцев. В основном это быстрая проверка гипотез для освоения новых ниш или решения совершенно новых бизнес-задач.
Важно, что приложения не привязаны к слоям навсегда. По мере созревания технология может спускаться сверху вниз: инновация становится стандартом.
Когда-то привычный мобильный банкинг был системой инноваций. Затем он стал системой дифференциации, а теперь это базовое приложение банка, гигиенический минимум и, по сути, система учета.
Где в этой структуре живут наши технологические проекты?
Наши проекты – это инфраструктура данных, которая заставляет разные слои работать вместе.
MDM находится на стыке первого и второго слоев. Такие системы создают золотую запись, чтобы системы учета не противоречили друг другу.
BI-системы пронизывают все три слоя. Внизу это может быть стандартная отчетность – операционная аналитика, которой мы пользуемся каждый день. В среднем слое – специфические дашборды для принятия стратегических решений в моменте. Наверху – предиктивная аналитика, где могут использоваться AI-инструменты вместе с BI-решениями.
ESB – это не отдельный слой, а инфраструктура между слоями. Интеграционная шина – те же дороги и трубопроводы нашего города.
Рассмотрим простой пример. Банк хочет запустить чат-бота для Telegram. Срок жизни гипотезы – один месяц. Задача тривиальная: проверить остаток по счету.
Без шины бот обращается напрямую к ERP. В результате одна гипотеза создает риск для ядра системы и угрозу для бизнеса.
В архитектуре с ESB и MDM мы можем использовать потоки, которые уже были реализованы в компании, и встраиваться в них. Бот обращается к шине, а шина безопасно забирает данные. Если гипотеза провалилась, мы просто отключаем и удаляем бота. ERP этого даже не замечает, и система учета не подвергается никаким изменениям.
Если сравнивать проекты внедрения систем учета и технологические проекты, различия заметны в основном фокусе, скорости изменений, степени кастомизации, ключевых рисках и даже на уровне инициатора проекта.
Главное отличие заключается в том, что технологические проекты создают умную инфраструктуру на основе данных. Она встраивается в существующие слои и связывает их.
7 типов связанности систем
Не так давно в электронной библиотеке коллег я нашел книгу Грегора Хопа – известного системного архитектора и одного из авторов книги «Шаблоны интеграции корпоративных приложений». Он описал семь типов связанности между системами. Это те самые невидимые нити, которые делают интеграцию сложной.
ESB решает первые четыре типа связанности.
Первый – связанность платформы, когда используются только определенные платформы.
Второй – связанность технологии, когда система зависит от отдельного протокола или стека.
Третий – связанность синхронизации, когда система А может работать только в связке с системой Б.
Четвертый – связанность формата данных.
ESB решает эти типы связанности и, по сути, говорит: «Нам неважно, на чем и как работает соседняя система. Данные будут переданы».
MDM и BI решают последние три типа связанности.
Первый из них – связанность типов данных и разный нейминг, который используется в учетных системах.
Второй – семантическая связанность. Это разная бизнес-логика, которая была заложена, например, в старой legacy-системе, в то время как мы внедряем новую ERP.
Третий – связанность идентификаторов, то есть ключей.
MDM говорит нам: «Этот контрагент – один и тот же во всех системах. Мы понимаем, как с ним работать». BI дает визуальную составляющую этой сложной связанности.
Все эти системы работают с невидимым слоем: семантическими несоответствиями и скрытыми зависимостями. Именно поэтому прогресс так трудно показать. Работа происходит там, где заказчик не видит привычного ему визуального результата.
Гремлины трансформации
Грегор Хоп описывает еще одну концепцию, которую он назвал «гремлинами трансформации». Это маленькие невидимые вредители, которые появляются в каждой серьезной интеграции корпоративных приложений.
Нефтяной кризис 1973 года положил конец эпохе больших американских маслкаров. Производители взялись создавать компактные и экономичные автомобили. Но все, что они умели, – строить большие машины.
Компания AMC решила задачу просто и быстро. Так появился AMC Gremlin. Снаружи машина выглядела компактной, но под ее огромным капотом помещался восьмицилиндровый двигатель V8. В линейке были и другие двигатели, но капот был настолько большим, что туда можно было поставить и V8.
Это был не компактный автомобиль, а большой автомобиль с укороченной задней частью кузова.
Немцы из компании Volkswagen, напротив, представили компактный автомобиль на новой платформе и использовали новый подход. Это была уже не уменьшенная большая машина. Volkswagen Golf 1974 года стал одним из самых долгоживущих автомобилей в истории именно потому, что команда начала с чистого листа.
Тезис Хопа звучит так: когда пытаешься трансформироваться, не отказываясь от старых ограничений, то создаешь гремлина. Снаружи система выглядит новой, а внутри работает как старая.
В технологических проектах есть свои гремлины. Назову самых опасных.
Первый – Legacy-гремлин. Это старые системы, которые нельзя просто так трогать. По ним нет документации, а разработчики, которые с ними работали, уже ушли из компании. При этом такая система остается единственным источником нужных данных.
Следующий – гремлин знаний. Вся архитектура находится в голове одного человека. База знаний не используется. Команда работает по принципу: «Сейчас сделаем быстро, а потом зафиксируем».
Гремлин зависимости – это скрытые зависимости между системами, которые обнаруживаются не до проекта, а уже в процессе работы.
Гремлин данных – это грязные данные. Вы строите красивую интеграцию, запускаете ее и обнаруживаете, что в источнике есть дубли записей и пустые поля. В итоге получаем мусор на входе и мусор на выходе. Это убивает любую аналитику.
Эти гремлины не исчезают, если их игнорировать. В начале проекта они молчат, а затем появляются в самый неподходящий момент – обычно за месяц до срока сдачи.
Как ломаются классические методы
Теперь рассмотрим, как все это выглядит на практике и как ломаются классические методы управления.
Мы привычно применяли на ERP-проектах три метода, а затем перенесли их на технологические проекты.
Первый метод связан со скоростью команды. В качестве инструмента используется диаграмма сгорания задач. Для нас это проверенный инструмент проектной деятельности, где каждый спринт дает независимый рабочий модуль.
Второй метод – автономность команд. Это базовый принцип масштабирования: параллельная работа команд позволяет оптимизировать сроки внедрения.
Третий метод – ставка на предсказуемость, то есть классическое управление ресурсами и рисками в предиктивном подходе.
Рассмотрим практические кейсы.
Кейс: Логистическая компания
У нашего клиента, крупной логистической компании, стояла задача заменить старую систему Oracle на 1С:ЗУП.
Со стороны заказчика у проекта был руководитель, который представлял задачу следующим образом: мы меняем одну старую систему учета на другую, новую.
Был выбран классический подход – Waterfall. Наша роль заключалась в том, чтобы выделенной командой во главе с техническим лидером связать новую 1С:ЗУП с остальным IT-ландшафтом через корпоративную шину данных.
Архитектурно Oracle выступала своеобразным промежуточным слоем, упрощавшим интеграционные потоки и загрузку данных. Через нее система обменивалась данными с другими источниками и системами.
Казалось, что в такой структуре и связке никаких подводных камней нет. Все приняли это видение.
У нас была красивая иерархическая структура работ, диаграмма Ганта и единый график для всех команд. Работу разработчиков разбили на спринты.
Ошибка заключалась в том, что построение интеграционной шины не рассматривалось как отдельный технологический проект со своими правилами. Работы по шине просто размазали по общему классическому графику, как будто это такой же модуль, как зарплата или кадры в 1С:ЗУП.
Мы запустили проект, и команды начали работу. Тогда появились уже знакомые нам гремлины.
Во-первых, Legacy гремлин. Старая система Oracle без документации содержала критически важные данные. Ее нельзя было трогать, но данные из нее были жизненно необходимы. Поэтому мы собирали доступные артефакты в виде документов.
Во-вторых, гремлин знаний. Единственный эксперт по старой системе был перегружен. К нему стояла очередь из обеих команд. Уникальные бизнес-процессы также затрагивали слои передаваемых данных.
В-третьих, гремлин зависимости. Мы зависели от скорости команды внедрения 1С:ЗУП, согласования маппинга полей и готовности API на их стороне. В плане эта зависимость не учитывалась.
У каждой команды были отдельные спринты и еженедельные статусы. Синхронизация происходила раз в неделю.
Мы двигались, закрывали задачи в Jira, фиксировали прогресс на диаграмме сгорания задач.
На очередном еженедельном статусе главный руководитель проекта посмотрел в отчет и сказал: «Коллеги из интеграции, у вас закрыто 60% задач. Давайте на следующей неделе покажем заказчику, как данные идут из Oracle в 1С:ЗУП».
Но на статусе заказчик мог увидеть только структуры JSON-пакетов из источника, открытые в редакторе.
Классический план проекта не видел текущей связанности.
Во-первых, связанности синхронизации – актуального состояния изменений, которые вносились в учетные системы.
Во-вторых, связанности данных – например, необходимости очистить дубли перед передачей.
В-третьих, связанности семантики – новой бизнес-логики, которую закладывали на стороне 1С:ЗУП.
Весь процесс не был рассчитан на работу между слоями и описание промежуточного результата интеграционного решения. Для 1С:ЗУП такой результат был зафиксирован сразу, а для интеграционного решения – нет.
Таким образом, у нас сломался первый метод – оценка прогресса.
Почему мы использовали диаграмму сгорания задач? Потому что на проекте внедрения 1С:ЗУП она работала и работала отлично. Закрыли нормативно-справочную информацию – справочники на месте. Закрыли учет персонала – модуль работает, его можно проверить.
Каждый спринт давал видимый результат, и заказчик к этому привык. Этот ритм он перенес на интеграционный проект. Но здесь была совершенно другая природа прогресса – невидимая до финальной сборки.
Тогда мы поняли, что диаграмма сгорания задач как инструмент показывает активность, а не результат.
Второе, что сломалось, – принцип автономности команд.
Классический план предполагал, что команда внедрения 1С:ЗУП и наша интеграционная команда могут работать параллельно и независимо, встречаясь только в контрольных точках.
В реальности включилась жесткая связанность синхронизации. Команда внедрения 1С:ЗУП постоянно меняла конфигурацию на лету. Они переделывали справочник или меняли тип поля, и наш маппинг в шине ломался.
На диаграмме сгорания задач был виден период, когда мы просто ждали. Затем сроки сдвигались, и мы переделывали интеграцию. Потом снова ждали. Они меняли 1С:ЗУП, мы переделывали шину, и сроки постепенно ползли вправо.
Кейс: Первый проект на новой отечественной КШД
Это тот самый проект, о котором я говорил в начале.
Мы впервые внедряли новую отечественную платформу, объединявшую ESB и MDM. Мы давно работали с вендором и его продуктами, прошли обучение и сертификацию. Были тесты в песочнице, но практика, как обычно, преподнесла сюрпризы.
К нам обратился клиент из сферы ретейла, которому требовалось внедрить эту платформу в свой IT-ландшафт.
Было несколько источников: разные системы 1С для учета остатков, загрузка из файлов, обмен с мобильными приложениями. Все это приводило к хаосу в структуре хранения золотой записи, внесении операций менеджерами, клиентском сервисе и обработке заказов.
Нужно было реализовать пилот в короткий срок, подключить несколько систем, а затем понять возможности масштабирования.
Если вспомнить слои Gartner, это был третий слой – слой инноваций. Новая платформа, первый опыт и высокая неопределенность. После этого система должна была спуститься на второй слой.
Что сделали мы? Спроектировали монолит на берегу по старым паттернам и на основе опыта работы с предыдущими версиями продукта.
Казалось, что все продумано. Мы задокументировали потоки, расписали маппинги, составили классический план и начали работу.
Результат уже известен: мы вышли за лимит часов больше чем в два раза. Задачи были решены, система работала, но цена оказалась совсем не той, которую мы планировали.
Здесь сломался третий метод – ставка на предсказуемость, управление ресурсами и рисками.
Мы столкнулись с реальностью: недокументированным функционалом и корректировкой архитектуры на лету. Старые архитектурные паттерны на новой платформе попросту не работали.
Кроме того, мы вспомнили о bus factor и ресурсном планировании. Главный архитектор по объективным причинам выпал из проекта на две недели. Тогда появился гремлин знаний.
Команда, конечно, не сидела без работы. Она писала обходные решения, но эти решения не вписывались в монолит, который был спроектирован в начале проекта.
Таким образом, мы накапливали технический долг. Затем возник каскадный эффект.
Если сравнивать с ERP, баг в зарплате не ломает модуль закупок. В нашем случае один баг в формате данных вызывал семантический сбой, который влиял на синхронизацию в целом. Это была уже не цепочка, а целая паутина.
Тогда мы поняли: если работаешь с новыми технологиями, нельзя строить монолит на берегу. Нужна короткая проверка концепции на реальных данных. Архитектор должен иметь возможность быстро скорректировать курс, пока цена ошибки еще невелика.
От хаоса к системе
После этих проектов и набитых шишек мы выбрали подход, который по своей природе является инкрементальным. Это разновидность гибкого управления: короткие итерации с работающим результатом на каждой из них. Но итерации здесь – не произвольные спринты, а четко определенные фазы с конкретными критериями готовности.
Фазовый подход включает четыре этапа. На каждом из них заказчик видит реально работающий результат технологического проекта.
Первая фаза – проверка концепции, или Proof of Concept. Она занимает от двух до четырех недель.
Задача – проверить, что выбранная архитектура работает в реальных условиях. Не на стенде и не в документации, а на данных заказчика и в его инфраструктуре.
Если архитектура не выдерживает, мы узнаем об этом через месяц, а не через полгода.
Вторая фаза – прототип. Это первый работающий результат.
Заказчик пока не пользуется продуктом, но уже может увидеть первую демонстрацию.
Для ESB, то есть шины данных, прототипом могут быть один-два работающих потока. Для BI – первый дашборд. Для MDM – демонстрация того, как данные превращаются в единый справочник. Проект перестает быть абстракцией.
Следующая фаза – MVP, минимально жизнеспособный продукт.
Система работает в продуктивной среде, и заказчик уже начинает пользоваться новым продуктом, хотя пока в ограниченном объеме. Он получает пользу от внедрения.
На этом этапе обычно проявляются проблемы с производительностью и масштабированием.
Последняя фаза – полноценный запуск, при котором работают все интеграции.
Ключевое преимущество каждой фазы – наличие точки принятия решения. Заказчик видит реальный результат и может скорректировать направление работы своей внутренней команды или команды подрядчика.
Кейс: BI-система
Рассмотрим еще один практический кейс.
Мы внедряли у себя 1С:Аналитику, BI-систему и корпоративное хранилище данных. В этом проекте мы одновременно были и заказчиком, и исполнителем. Проект начинался как задача первого слоя – консолидация данных в единой точке для быстрого получения сводной информации.
У нас были десятки разных систем: 1С:ERP, 1С:ЗУП, 1С:Документооборот, другие системы 1С, Bitrix, внешние HR-системы и Google Таблицы.
Формирование одного отчета, например БДР, занимало от трех до пяти часов. На выходе мы хотели получить быстрые дашборды.
Классический путь предполагал бы, что мы полгода проектируем идеальное хранилище и пытаемся предусмотреть все заранее. В таком случае мы действительно могли бы увязнуть в работе. Поэтому мы снова пошли по фазам.
На первой фазе не стали строить тяжелое хранилище. Было принято временное решение: за пару недель проверить, можем ли мы вообще забрать данные из ERP и других систем и свести их вместе.
Мы поняли, что можем. Но тут же обнаружилась зависимость: API внешней HR-системы был закрыт.
Мы написали вендору, договорились, и доступ был открыт. При классическом подходе мы могли бы узнать об этой проблеме через несколько месяцев. Здесь она проявилась уже на второй неделе.
На этапе прототипа появился первый дашборд на реальных данных, и сразу обнаружились проблемы с их качеством.
На уровне семантики выручка в CRM и ERP считалась по-разному. Менеджеры создавали тестовые сделки и не закрывали их.
Пришлось идти в источники и менять процессы ввода данных. На этапе прототипа это стоило обычного разговора с командой. В противном случае мы получили бы мусор на входе и мусор на выходе.
На этапе MVP доступ к системе получила определенная группа руководителей. Когда они начали пользоваться системой, она стала работать медленно и тормозить. Здесь проявилась связанность технологий и платформы.
На четвертом этапе мы осознанно переписали вызовы на быстрые веб-сервисы, масштабировали серверы и скорректировали архитектуру для дальнейшего внедрения шины данных.
Работа ETL-процессов позволила свести данные в единый справочник и сформировать DWH на этапе прототипа.
Затем мы перешли к полноценному запуску и развернули систему на всю компанию.
Пять часов на формирование отчета превратились в мгновенный доступ к дашборду.
Проект начинался как задача первого слоя – просто собирать данные. К моменту запуска он стал системой дифференциации: появились дашборды для быстрых стратегических решений, которых раньше в компании не существовало.
Система созрела и перешла из одного слоя в другой.
Ответы на классические методы
В результате мы нашли ответы на проблемы классических методов, которые не работали в нашей практике.
Вместо иллюзии прогресса мы ввели метрики по фазам.
На этапе проверки концепции метрика бинарная: архитектурная гипотеза подтверждена или нет. На этапе прототипа мы оцениваем, сколько запланированных интеграционных потоков действительно работает. На этапе MVP смотрим на процент данных без ошибок. После запуска оцениваем, готовы ли мы к масштабированию.
Вместо иллюзии независимости команд появились совместные контрольные точки.
Каждая фаза заканчивалась совместной приемкой. В проектной команде участвовали аналитики, разработчики и, что особенно важно, владельцы данных. Изменения процессов ввода данных блокировались в системах учета, пока дальнейшие шаги не были согласованы всей командой.
Связанность и синхронизация никуда не исчезли. Но мы перестали их игнорировать и начали ими управлять.
Вместо иллюзии контроля появилась запланированная эволюция.
Мы заранее знали, что архитектура на этапе проверки концепции будет временной, первый дашборд покажет грязные данные, а MVP вскроет проблемы масштабирования.
Вместо детального плана на полгода у нас появились короткие фазы с правом на осознанную переделку.
Итоги
Технологические проекты – это управление данными: тем, как они перемещаются, что означают и кому принадлежат.
Это другой тип систем. Они работают на разных слоях архитектуры, а зависимости между системами здесь не исключение, а норма.
Методы управления необходимо определять на старте. Если у вас есть аналогичный технологический проект, в котором все вроде бы идет по плану, но что-то не так, стоит довериться этому ощущению. Посмотрите на проект через призму связанности и спросите себя: «Инструментами какого слоя мы сейчас управляем?»
Фазовый подход позволяет на каждом шаге показывать заказчику работающую систему, а не оценку прогресса.
Каждая фаза становится точкой принятия решения. Каждая выявляет свой тип проблем, пока цена ошибки еще остается низкой.
Все описанное в этой статье – и провалы, и найденные решения – это общий реальный опыт нашей команды.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
