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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Отчеты по времени работы команды в разрезе требований и задач (план и факт). Их легко предоставить, выгрузив данные из трекинговых систем разработчиков.

• Отчет по использованию бюджета, особенно если проект не на пару недель.

• Информация о релизах: какие функции реализованы, какие планируются, какие остались, от каких отказались.

• Статус-письма на руководящий состав и заинтересованных лиц компании. Еженедельная рассылка размером в один экран о текущих задачах, проблемах, успехах. В таких письмах также можно эскалировать вопросы и проблемы, решение которых требует привлечения топ-менеджмента.

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

• Демонстрация готового функционала системы нужна на определенном этапе проекта раз в две-три недели. Не забудьте записать видео, чтобы передать заинтересованным лицам компании.

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

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

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

• Краткий статус проекта: что сделано, какие риски сработали, какие есть проблемы, бюджет и сроки

• Список задач в разрезе: запланировано, реализовано, не будет реализовано, с указанием причин и сроков

• План мероприятий и шагов для выхода из сложившейся ситуации.

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

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

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

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

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

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

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

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

Читайте также

• Как сделать потенциального покупателя - реальным. Составляем Customer Journey Map

• У нас плохие новости: смотрите, как на самом деле нужно было переходить на «удаленку»

• Разгрузите ваших менеджеров - 5 «вкусных рецептов» для CRM от фаната автоматизации