Коммуникация как часть архитектуры проекта автоматизации

Превью

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

________________________

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

Работая как внешний вендор, мы встраиваемся в структуру заказчика и помогаем решать самые разные задачи: автоматизировать процессы, усилить экспертизу внутренней команды, сократить time-to-market или достичь конкретных бизнес-показателей.

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

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

Есть несколько проблем, с которыми мы сталкиваемся особенно часто.

1. Непонятно, кто принимает решения

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

Проблема начинается тогда, когда участники проекта могут обсуждать решение, но ни у кого нет полномочий принять его окончательно.

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

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

Не всегда эту роль должен выполнять представитель C-level. Гораздо эффективнее, когда необходимыми полномочиями обладает менеджер, который непосредственно погружен в проект и может оперативно снимать возникающие блокеры.

2. Ответственность остается абстрактной

Еще одна распространенная ситуация — договоренности, в которых нет конкретного владельца.

Например: «API должен предоставить заказчик».

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

То же самое происходит с формулировками вроде «согласовать с безопасностью», «передать смежной команде» или «подготовить интеграцию».

Пока за задачей не стоит конкретный ответственный, договоренность существует только на словах.

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

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

3. У всех разное понимание слова «готово»

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

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

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

Если критерии готовности не определены заранее, расхождение обнаруживается слишком поздно — зачастую именно в тот момент, когда команда уже рассчитывает перейти к следующему этапу или запуску.

Поэтому единое понимание результата и критериев его приемки необходимо формировать еще до начала реализации.

Почему десять разработчиков не дают в десять раз больше результата

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

Но количество специалистов само по себе не гарантирует пропорционального роста скорости.

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

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

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

Роль технологического партнера — больше, чем разработка

Именно поэтому мы не рассматриваем роль внешнего вендора исключительно как предоставление разработчиков.

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

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

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

• Сможет ли эта команда встроиться в существующую структуру?

• Способна ли она синхронизировать работу нескольких участников?

• Готова ли инициировать сложные обсуждения, если без них проект не сможет двигаться дальше?

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

Поэтому коммуникация — не дополнение к архитектуре проекта. Это ее часть.