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