Менеджмент «Про бизнес» 14 мая 2020

Если язык айтишников для вас как шаманское заклинание — как понять друг друга в ИТ-проекте

В идеальном мире еще на старте автоматизации все участники понимают, какие задачи компании она решит. А в жизни? Чаще технические специалисты и бизнес говорят «на разных языках». Найти общий язык бизнесу и ИТ легко, если осознавать все нюансы работы над проектом. Дарья Касперова, заместитель директора по проектному управлению Invento Labs, делится опытом, как это сделать.

— Эти советы универсальны для всех руководителей бизнеса, заинтересованных в получении результатов от автоматизации: как от проектов по разработке сайта или портала магазина, так и по настройке CRM/ ERP-системы, постановке BI/BigData.

**Дарья Касперова**
заместитель директора по проектному управлению Invento Labs

Кто должен общаться с разработчиками и как их понять?

Вам нужен «переводчик» — человек, который четко понимает, чего ждет бизнес, и может донести эти ожидания до разработчиков. Обычно роль «переводчика» выполняет бизнес-аналитик и частично — проектный менеджер (PM).

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

Заведите глоссарий — «толковый словарь», в котором расшифровываются все незнакомые слова. Это обязательный раздел первичных документов проекта (технического задания, документа об образе и границах проекта). В нем могут быть:

Общепринятые аббревиатуры и сокращения
Специфические для проекта сокращения (ГО — «грузоотправитель» в одном проекте или «гражданская оборона» в другом)
Элементы процесса и методологии, роли и функции участников проекта.

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

Скачайте пример глоссария для ИТ-проектов

Какое участие требуется от руководителя?

Сейчас мы говорим о ключевых представителях компании, которая заказывает ИТ-проект: собственник, инвестор, СЕО, финансовый директор, главный бухгалтер — людях, которые принимают ключевые решения в компании.

Если вы читаете протокол по диагонали, то через полгода можете получить совсем не тот результат, на который рассчитывали. Мы часто слышим: «Держать руку на пульсе очередного проекта сложно», «У меня дел по горло, еще и вами заниматься», «У меня назначены ответственные за проект сотрудники, пусть они и погружаются…» Но ведь это ваш бизнес, вы тратите деньги и вот так безоговорочно подчиняетесь другим людям?

Для опытных менеджеров слова ключевого представителя заказчика «не шарю», «нет времени», «неинтересно», «не понимаю» — красные флаги и аналоги «перекладываю ответственность на вас».Что делать?

Если заказали разработку сайта, вовлекайтесь на старте: обсуждайте концепцию, идею, ключевой посыл. Далее задачу можно делегировать руководителям соответствующего подразделения или релевантному специалисту.
Если автоматизируете работу подразделения, контролируйте цели, задачи, критерии успешности проекта на старте и далее в ходе приемки ключевых этапов проекта. По желанию можно присутствовать на демонстрациях отдельных функциональных возможностей системы.
Если у вас крупный проект по постановке BI или настройке ERP-системы, уделите пристальное внимание. Здесь не хватит компетенций и уровня влияния руководителя среднего звена. Должна быть сформирована команда профессионалов из разных подразделений, а драйвером, как правило, выступает собственник или СЕО компании.

О чем договориться с разработчиками «на берегу»?

Это могут быть следующие договоренности:

Коммуникация: в каком формате, как часто и с помощью каких средств связи вы общаетесь. Можете отразить эти договоренности в «Реестре заинтересованных лиц», «Матрице коммуникаций», Уставе или Паспорте проекта
Ожидания: какие работы или задачи в какие сроки будут выполнены, как будете принимать результат
Дорожная карта, составленная, например, в диаграмме Ганта, Excel-таблице
Вовлеченность топ-менеджмента
Формат ведения проекта: роли и зоны ответственности, доступность и вовлеченность участников команд, порядок доставки и процесс тестирования, обязательные ритуалы и порядок приемки результата. Если это Scrum — все должны одинаково понимать роли и осознавать значимость ритуалов. Если это Канбан — важно сформировать ожидания по скорости разработки и доставки задач.

Какую отчетность требовать от разработчиков?

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

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

Что делать, если вы «выпали» из процесса?

Случается, что руководитель отвлекается, и ему надо срочно поднимать огромный массив информации. Начинается управление сбоку или «из окопа». Поднимайте белый флаг и выходите на переговоры. Запросите у подрядчика:

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

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

Подведем итоги

Скачайте примерный список документов для работы над ИТ-проектом

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

2. Доверьте роль «переводчика» бизнес-аналитику. Он поймет, чего ждет бизнес, и сможет донести суть ваших ожиданий и требований разработчику.

3. Со старта заведите глоссарий, в котором будут расшифрованы все непонятные слова и сокращения. Активно им пользуйтесь.

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

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