Кескинов Николай Николаевич
Руководитель направления методологии учета и отчетности
Компания АО «Тандер»
В статье представлено описание порядка запуска высокорискованного проекта в крайне сжатые сроки, что было обусловлено ошибками предыдущего руководителя проекта.
Началось все в далёком 2020 году. Правительство выпустило новый стандарт по ведению бухгалтерского учета договоров аренды. Абсолютно новые принципы ведения учёта потребовали серьёзных доработок инструментов бухгалтеров.
Моя команда методологов, изучив нормативный акт, подготовила инструкцию, описывающую порядок бухгалтерского учёта в компании, а затем на основании инструкции разработала документ, который фиксировал принципы построения учёта с точки зрения информационных систем. Важно отметить, что документ готовился на основании вводных, полученных от бухгалтеров и бизнеса. В компании было множество видов договоров аренды, у каждого из которых были свои нюансы, и которые следовало бы учесть. Всё это нашло отражение в нашем пространстве на Confluence.
Итак, документы готовы, переданы в подразделение, которое выделило руководителя проектов. Началась работа.
Проект изначально стали продвигать по принципам waterfall: все шаги согласовывались со всеми стейкхолдерами, работа не двигалась до тех пор, пока все согласования не были получены. Каждую неделю отчетное собрание с руководителями подразделений, функциональными заказчиками, на котором демонстрировались картинки графиков работ, нарисованные в Excel.
Самое удивительное в этих совещаниях заключалась в том, что они не давали ощущения целостности проекта. Не было понимания того, где находятся работы, когда будет продукт, когда будет описание. Совещания сводились к обсуждению конкретных стримов: кто и что не передал, кто кому не ответил. Также в ходе проекта мои подчинённые, методологи, были привлечены к анализу и проверке технических заданий, формируемых ИТ.
Получив первые ТЗ, я задал логичный, как мне казалось вопрос: а где описание архитектурной модели? Я понимаю, что наше описание принципов функционирования системы было не совершенным, предложенные решения были пересмотрены ИТ, но как должна выглядеть система в итоге надо было зафиксировать на основании выработанных решений. На мой запрос ИТ ответили, что система выстраивается в процессе работ и каждый инструмент прорабатывается по мере очередности.
Мы строили систему с нуля, но при этом никто не понимал, как она должна работать целостно. Каждый делал что-то своё, что затем пытались состыковывать. Описания архитектуры не было, и я предупредил, что подобный подход приведёт к сбоям, невозможности проводить отладку и доработку, инструменты будут мешать друг другу. Мои опасения были проигнорированы всеми, и команда продолжила увлечённо что-то пилить.
Не известно, как сложилась бы работа, но Руководитель проекта уволилась. На дворе август. До запуска осталось 4 месяца. Продукта нет. Документации нет. Модели нет. Есть только картинки и неясные сроки окончания работ со стороны ИТ.
Пытаюсь понять, что сделано. Получается, что готово меньше половины: все то, что готово - не собрано, существует на макете в виде отдельных инструментов, которые между собой не состыкованы. Команда ИТ разрознена, сотрудники слабо синхронизированы. РП от ИТ не понимает вообще, что происходит и кто что делает. До окончания срока 4 месяца вместо начальных 12. Срок сдвигать нельзя. Понимаю, что проект провален. При таких вводных запилить продукт невозможно.
Однако я решаю рискнуть. И прошу отдать проект мне. Почему? Тут есть несколько факторов. Самое главное: у меня есть понимание, как должен выглядеть продукт в итоге, какой должен быть функционал у продукта, наличие методологии. Твёрдой уверенности в реализации задачи нет, но опыт вытаскивания кризисных проектов за плечами присутствует. Ну и плюс интересная сложная задача, которую мало кто вытащит. Желание самоутвердиться сыграло не последнюю роль...
Полную версию статьи Николая Кескинова читайте в журнале Управление Проектами https://pmmagazine.ru/editions/3-4-2022/