Согласовать нельзя программировать. 11 «как» повысить вероятность успеха проекта автоматизации



Что не так с формальной стороной проектов атоматизации?


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


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


Как правило, если исполнитель ответственно подходит к проектированию и действительно пытается сперва согласовать ТЗ, проект через квартал-полгода-год приходит к состоянию «ничего не сделано, пишутся бумажки». При грамотном администрировании, ответственность за длительное проектирование частично может быть разделена с заказчиком, но кому от этого легче, если проект не двигается?


Некоторые исполнители задаются вопросом «что делать с ТЗ, которое никак не напишется и не согласуется» спустя полгода, некоторые, набившие шишки, задаются таким вопросом сразу. Все возможные варианты действий можно разделить на две стратегии

  • Согласовать, нельзя программировать - Нет уж, мы должны сперва все согласовать

  • Согласовать нельзя, программировать - Давайте поделаем систему, а потом как-то договоримся и подпишем бумажки

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


Согласовать, нельзя программировать


Причины неуспеха в этой стратегии обычно такие:

  • Заказчик психанул и выгнал за отсутствие результатов

  • Очень долго согласовывали и согласовали ТЗ. За это время изменились требования и состав проектной команды у заказчика

  • Напроектировали то, что на деле невозможно автоматизировать

  • Согласовали очень поверхностное ТЗ, в ходе реализации скоуп проекта вырос, сроки уехали


Согласовать нельзя, программировать


Причины неуспеха в этой стратегии обычно такие:

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

  • Начали делать без проработки концепции, в ходе реализации выяснилось, что нужно было делать принципиально иначе. Нужно все переделывать. Сроки уехали, бюджет кончился.

  • Менеджера проекта от исполнителя выгнали за отсутствие подписанных актов по проекту

  • За отсутствием ТЗ, заказчик не понимает всю сложность проекта, а конкурент рассказывает на конференциях что задача плевая. В итоге – заказчик психанул и закрыл проект



Что делать?11 «как» повысить вероятность успеха проекта автоматизации


Может показаться, что делать проекты – дело неблагодарное и лучше этим не заниматься. И вот что я скажу – это действительно во многом истинное утверждение. Рисков много, я знаю достаточно примеров, когда компании переключались на другие виды деятельности.

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


1. Не работайте с мудаками.


Работает в обе стороны. Если заказчик не договороспособен – не питайте иллюзий что он закроет проект, когда система начнет работать. Если исполнитель – это набор фиксиков, которые вчера узнали что такое ТЗ и проектная работа – не питайте иллюзий что они сделают проект вовремя и как следует.


2. Проверяйте гипотезу об адекватности участников проекта


Работает в обе стороны. Если можно сначала зайти не в большой проект, а в мелкий – сделайте это. Подпишитесь на обследование вместо комплексного проекта внедрения. На этом микропроекте стороны посмотрят друг на друга. Если уже запущен крупный проект – попробуйте пройти все стадии проектирования-согласования-внедрения на как можно более мелкой задаче. На ней вы узнаете, насколько исполнитель в состоянии достигать результат, а заказчик – участвовать в проектировании и приемке результатов.


3. Определите конъюнктуру проекта. Формальность или результат?


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


Учтите, что договоры на проект автоматизации, заключенные по 223ФЗ или 44ФЗ - допускают очень узкое пространство для маневра в части формальных артефактов проекта.



4. Стартуйте как можно раньше


Если есть возможность – бейте проект на этапы, на которых система запускается в ОЭ/ОПЭ/ПЭ как можно раньше. Это не только позволит закрывать работы поэтапно, но и позволит снизить риски «не той системы». Как только пользователи начинают работать с системой – вы сразу же узнаете, что они думаю о ней. И сможете скорректировать требования на последующих этапах работ. В рамках такого подхода часто используют термин MVP – минимальный жизнеспособный продукт.


5. Моделируйте


Проектировать в ворде – хорошо. Но лучше – проектировать наглядно. Особенно, если внедрение осуществляется на базе существующего «типового» продукта. Когда бизнес увидит, как будет выглядеть будущая система – он точнее сформулирует требования, ему проще объяснить нереальность части требований, он быстрее согласует ТЗ. Для моделирования может применяться как сама система, так и другие инструменты – Excel, инструменты для создания мокапов экранных форм.

6. Не отказывайтесь от согласования


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


7. Эскалируйте невозможность согласования


Очень часто исполнителя ставят в положение «вы ничего не умеете, потому херачьте так, а мы потом посмотрим что с вами делать». Такое положение ни разу еще не приводило к успешному закрытию проекта. Если исполнитель действительно не очень – зачем ждать, пока он потратит год жизни компании и уйдет ни с чем и со скандалом? Если же команда исполнителя может решать задачи создания системы – менеджер проекта должен бить в набат и кричать во всю мощь о том, что проект скоро войдет в штопор, это его прямая задача. Как правило, истина где-то посередине – исполнитель не смог донести внятно свои идеи, а заказчик не посчитал возможным вникнуть. Такая проблема решается на уровне проектного менеджмента и изменения подходов к проектированию. Чем дольше эту проблему не решают – тем дороже обходится обслуживание такого проекта, и рано или поздно приводит либо к прекращению проекта, либо к серьезному и глубокому разговору. Иногда такой разговор называют «ретроспектива проекта».


8. Не путайте согласование и документирование


Никогда. Слышите, никогда! Не отказывайтесь от документирования того, что происходит на проекте. Даже если не удается согласовать проект. Нужно помнить, что даже если сложилась такая страшная ситуация, что исполнитель выполнил много работы без согласования – нужно хотя бы знать, что сам исполнитель понимает и верит в то, что делает. А без документирования:

  • Невозможно воспроизвести состав и содержание работ, которые сделаны на проекте

  • Растет технический долг

  • Создается множество несогласованного функционала

  • Невозможно написать инструкцию к тому что сделано

  • Очень долго и дорого онбордить новых людей на проект

  • Команда проекта тонет в бесконечных переделках и хаосе

  • Всегда есть риск того, что сделано не то что нужно


9. Развивайте системы управления требованиями и задачами


Jira, Redmine, Trello, СППР и множество других систем – это мастхэв при работе на ИТ-проектах. Вся работа по управлению требованиями должна быть построена на базе хоть какой-то системы управления этими требованиями. В конечном счете, на базе этих требований можно составить word-документ и назвать его «ТЗ». MVP такой системы:

  • Трекинг статуса задач

  • Хранение постановок требований и вложений

  • Регламент по работе с требованиями для бизнеса, аналитиков, разработчиков

  • В т.ч. пункт про хранение всех договоренностей по задачам в системе

Просто примите как факт, что на проекте, который делается не «в одного», управлять содержанием работ только на базе вордовых и эксельных файлов – устаревшая технология, которая не имеет права на жизнь.


10. Управляйте проектом


Проект должен всегда иметь руководителя проекта с компетенциями именно управления проектом. Особенно для проектов на 1С, характерно назначать руководителем проекта самого талантливого аналитика или программиста. Что зачастую приводит к отсутствию управления. Иногда роль менеджера проекта совмещается с менеджером продукта, что не противоречит. MVP менеджера проекта:

  • Умеет ставить команде проекта задачи по SMART

  • Умеет предоставлять внятную информацию о статусе проекта, в т.ч. о плане работ, методах реагирования на риски

  • Умеет администрировать задачи

  • Умеет вести переговоры, аргументировать позицию

  • Умеет строить план работ, ресурсный план

  • Умеет готовить презентации

  • Умеет работать с договорными отношениями


11. Создавайте технологию автоматизации


С одной стороны – у вас есть множество готовых методик управления проектами по Scrum, PMBok, PRINCE, Kanban, ТКВ, ТБР и так далее.

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

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


Выводы

Значительная часть проектов -проваливается. Как правило, это заслуга всех участников.

Успех автоматизации зависит:

  • от зрелости заказчика

  • от его желания выполнить проект и способности принимать быстрые решения

  • от наличия отработанных технологий внедрения с обеих сторон

  • от наличия грамотного администрирования проекта

  • от наличия удобных инструментов для управления содержанием системы.

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







©2020 by wangoff