В идеальной ситуации ещё на старте автоматизации все участники команды одинаково понимают, какие задачи и сверхзадачи компании она решит. Часто технические специалисты и бизнес говорят на разных языках. Это грозит тем, что результат может не оправдать ожиданий. Найти общий язык бизнесу и IT довольно просто. Евгений Шишков, заместитель директора по продажам, и Дарья Касперова, заместитель директора по проектному управлению, советуют, как это сделать.
Для начала определите, с какой IT-командой вы идёте в проект. Это могут быть штатные разработчики, стартап или аутсорсинговая компания. В каждом из вариантов могут возникать свои камни преткновения между бизнесом и IT.
С самых первых шагов нужен "переводчик" — человек, который понимает, чего ждёт бизнес, и может донести суть до разработчиков на понятном им языке. Если область знаний специфическая, есть смысл привлечь узких экспертов, например, финансовых директоров. Обычно роль "переводчика" выполняет бизнес-аналитик и частично проектный менеджер (PM). Он организовывает взаимодействие, синхронизирует стороны по процессам и понятиям.
Бизнес-аналитик собирает, анализирует требования заказчика, формализует идеи и сопровождает проект до конца. Его главная задача — понять процессы, оптимизировать их и предложить лучшее решение по автоматизации. И что принципиально важно, аналитик знает, как "переводить" на язык разработчиков.
Чтобы коммуникации внутри проекта были прозрачнее и проще, бизнес-аналитик составляет глоссарий, своеобразный "толковый словарь" под конкретный проект, в котором расшифровывает все сокращения и незнакомые слова. Требования описываются в определённых нотациях, которые имеют свои стандарты. В зависимости от того, какие нотации понимает команда и заказчик, бизнес-аналитик жонглирует формой, чтобы доступно подать общую информацию.
На старте проекта обозначьте точки контроля и следуйте им. Вариаций может быть много, как правило, каждые две-три недели проводятся демонстрации и предоставляются отчёты. Если сроки "горят", переходите на ежедневный контроль. Кроме обязательных отчётов, еженедельно разработчик отправляет статус-письма. Это рассылка с новостями проекта, текущими нерешёнными вопросами или факторами риска. Таким образом рука клиента будет на пульсе.
Всегда помните про поставленную задачу и ожидаемый результат. IT-команда может самоуверенно думать, что понимает, в чём дело. Бизнес-аналитик опишет требования, разработчик формально сделает всё точно, а истинная проблема решена не будет. Именно поэтому нужны люди, которые докапываются до истины, задают заказчику правильные вопросы: как вы обходите эту проблему сейчас, что должно получиться в итоге. Бизнес-аналитик и команда заказчика должны решать задачи бизнеса, а не просто создавать программный продукт. В этом и есть ценность "переводчика": вся команда проекта говорит на одном языке и создаёт максимально эффективный продукт.
Заказчик должен быть готов к тому, что на старте на совместную работу с бизнес-аналитиком может уходить значительная часть времени. Аналитик подключается на этапе предпроектного исследования, углубляется в проект, осмысливает цели и задачи. Затем формирует общее видение системы, вместе с владельцем продукта расставляет приоритеты, дробит задачи на более мелкие, выясняет требования фокус-групп и работает с клиентом и командой.
После каждой встречи заказчик получает на согласование решения и идеи, которые были приняты. Если вы читаете протокол по диагонали, то через полгода можете получить совсем не тот результат, на который рассчитывали. Вникайте в процесс и избегайте формализма. Если необходимо, уточните, что именно имеет в виду IT-команда.
Чтобы IT и бизнес говорили на одном языке, а проект завершился максимально эффективно, следуйте простым советам:
