Как мы запускали проект, который невозможно было запустить. 

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

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

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

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

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

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

Не известно, как сложилась бы работа, но РП уволилась. На дворе август. До запуска 4 месяца. Продукта нет. Документации нет. Модели нет. Есть только картинки и неясные сроки окончания работ со стороны ИТ.

Пытаюсь понять, что сделано. Получается, что готово меньше половины, все то, что готово, не собрано, существует на макете в виде отдельных инструментов, которые между собой не состыкованы. Команда ИТ разрознена, сотрудники слабо синхронизированы. РП от ИТ не понимает вообще, что происходит и кто что делает. До окончания срока 4 месяца вместо 12. Срок сдвигать нельзя. Понимаю, что проект провален. При таких вводных запилить продукт невозможно.

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

Ну и плюс интересная сложная задача, которую мало кто вытащит.

Начинаем работы.

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

В процессе обсуждения сталкиваюсь с ситуацией, когда одна задача декомпозирована на несколько подзадач. Каждая подзадача отражает этап работ: анализ, приёмку в разработку, саму разработку и так далее. В итоге огромный список, который невозможно оценить. Сворачиваем всё, невзирая на недовольство коллег. Теперь каждая задача - это этап, по итогам которого рождается инструмент или дорабатывается существующий. Этап делится на спринт, отражающий тип работ: анализ, разработку, тестирование. Ещё важный момент: я отказывают коллегам в выделении спринта в виде "прием в разработку". Меня пытаются убедить, что после анализа разработчик ещё тратит время на прочтение требований и может не принять требования. На что я задаю простой вопрос: кто является ответственным за этап: разработчик или аналитик? Разработчик, говорят мне. Ну а раз так, то фиксируем этап разработки и всё, исходя из того, что аналитик готовит адекватный документ, который будет принят в работу. Почему я отказал в выделении этапа? Все просто: я жёстко зафиксировал последовательность спринтов, стандартизировав работу, что упростило мне анализ и управление.

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

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

Общение с командами ИТ я веду напрямую. РП от ИТ никак не участвует. К этому времени у меня уже стойкое понимание того, что сотрудник не погружен в проект, не понимает, что происходит и не общается даже с командой, так как ответить на вопрос о сроках, ответственных не может. По каждой задаче я ставлю ФИО, чтобы знать, к кому обращаться. Это экономит мне время, так как лишняя прослойка в управлении только тормозит работу. 

Таким образом, в течение недели я сворачиваю план работ и… отдаю в ИТ на оценку. Работы тормозит все, так как нет смысла разрабатывать то, что может не пригодиться. Нужно понять вначале, сколько мы успеем сделать. Это серьёзный риск, так как работы и так отстают. 

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

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

Работы перевожу на Agile. Времени на документацию нет. Часто с системными аналитиками и разработчиками собираемся группой и методологи объясняют принципы построения системы, требования к инструментам. Нередко используем Excel, чтобы моделировать сложные ситуации. 

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

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

Я лишний раз убеждаюсь, что при таких работах модель обязательно должна быть, с подробным описанием. Чем подробней модель, тем меньше ошибок будет допущено, тем проще будет разработчику и аналитиками понять, что от них требуется. Меньше времени на тест. А при высоко детализированной модели, можно и от теста отказаться в теории. 

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

У нас начинают появляться очертания продукта. 

Исходя из промежуточных результатов, ещё раз с командой обсуждаю сроки. Нам удаётся понять, сколько времени мы потратим на запланированный объём работ. Мы выставляем deadline, вторая декада декабря. В этот момент времени система должна быть собрана и мы должны запустить сквозное тестирование продукта в целом. 

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

Мой второй высоконагруженный проект обретает администратора и менеджера, я осуществляю оперативный контроль. На этом же проекте надо выкладываться. 

Вплоть до ноября работы идут строго по графику, без отклонений. При возникновении ошибок сотрудники ИТ работают сверхурочно, в выходные, чтобы исправление не повлияло на общие сроки. Возникает вероятность, что люди перегорят. Выхожу на руководство, официально согласовываю бюджет на премирование. Объявляю о премиях, прошу собраться, остаётся немного. Люди воодушевлены. Мне удаётся залить проблему деньгами. Знаю, что деньги слабый мотиватор на длительной дистанции, но мне-то надо чуть более месяца продержать людей в тонусе. Расчет оправдывается.

Руководство получает регулярно обратную связь. Отчётные встречи сохранились. Только теперь мы демонстрирует график в Project вместе с диаграммой Ганта. Все задачи объединены по направлению разработок: оцифровка договоров, оплаты, начисления и пр. Сразу видно, где какой блок и из чего он состоит.

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

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

В январе запускаем продукт в боевой базе. Самая напряжённая фаза проекта завершена. Можно выдохнуть. 

Вторая фаза проекта представляла уже доработки системы, второстепенные механизмы, отладку существующих, поэтому останавливаться не буду. 

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

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

  1. мы чётко определили цель проекта, задачи,

  2. задачи разделили, выделив критичные и второстепенные,

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

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

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

  6. мы правильно стимулирования команду. 

Какие выводы я сделал по итогам проекта:

  1. Agile хорош, но только с адекватными и ответственными заказчиками,

  2. Отсутствие вовлеченного в проект функционального заказчика ставит крест на успехе проекта,

  3. Отсутствие описания архитектурой модели влечёт за собой потери времени при сборке инструментов воедино,

  4. Чем подробней объяснишь принцип функционирования инструмента, тем больше шансов, что он будет сделан хорошо, 

  5. Качественный анализ - это более половины успеха в реализации задачи,

  6. Некачественный анализ - это провал и будущие множественные исправления ошибок.


Комментарии (1)


  1. klimkinMD
    28.11.2022 07:33

    Вы -- молодец!