Как игра в «глухие телефоны» чуть не стоила нам крупного клиента

Сообщение от партнера, который узнал про ситуацию на проекте
Сообщение от партнера, который узнал про ситуацию на проекте

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

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

Иногда заказчику трудно сразу обозначить свои цели и четко сформулировать их. Тогда мы помогаем ему — задаем наводящие вопросы.

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

В таких случаях мы стараемся сэкономить ресурсы заказчика и время нашей команды: просим контакты собственников бизнеса и выясняем истинные цели проекта. Этот принцип мы выработали в процессе коммуникации с компанией «Витязь-Аэро».

Почему важна роль бизнес-заказчика в ИТ-проекте

«Витязь-Аэро» — это авиакомпания, которая выполняет пассажирские рейсы на вертолетах в отдаленные населенные пункты Камчатки. У них два ИТ-продукта: сайт и автоматизированная информационная система (АИС) для регистрации пассажиров, багажа, грузов. Первый — для клиентов, второй — для внутреннего пользования сотрудниками.

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

Кроме того, в системе изначально было много проблем в функционале: например, плохое изначальное проектирование и невыстроенная система тестирования и модификации кода. Со временем АИС перестала отвечать растущим потребностям компании.

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

Проблемы в коммуникации с клиентом

Не надо так
Не надо так

Коммуникация с клиентом складывалась непросто: на разницу в местонахождении и часовом поясе (+8 часов) накладывались и другие сложности. Например, с начала сотрудничества у нас не было прямого контакта с бизнес-заказчиками — собственниками, которые хорошо представляют цели разработки и желаемый результат. Мы связывались с ними через руководителя проекта. Это был сотрудник компании, который не мог знать столько же, сколько бизнес-заказчики, несмотря на проактивную позицию в работе. Из-за этого в нашей коммуникации появилось несколько проблем:

  • Менялись приоритеты, о чем мы поздно узнавали. Например, нам приходила задача, которую надо было выполнить срочно. Мы тратили на нее время, а по готовности оказывалось, что она уже не нужна.
  • Возникали недопонимания при постановке задач. Оказалось, что обсуждать задачу без прямого контакта с бизнес-заказчиком — сложно. Это было похоже на игру в «глухие телефоны»: собственник давал нам задание через руководителя проекта, а мы получали его искаженным или неполным. При этом не было возможности быстро уточнить, что значительно увеличивало сроки исполнения. В итоге при релизе демоверсии получалось, что с продуктом все не так — результат не совпадал с ожиданием бизнес-заказчика.

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

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

В итоге работа усложнилась на всех звеньях коммуникации. С нашей стороны — мы выполняли часть работы и останавливались, потому что ждали ответов на запросы о бухгалтерской отчетности, онлайн-кассе, требованиях к авиабилетам. Со стороны руководителя проекта — не было представления о статусе и проблемах проекта, а также возможности повлиять на работу подразделений и топ-менеджмента. А со стороны бизнес-заказчиков все выглядело так, будто мы затянули выполнение задачи на 2 месяца.

Момент оказался поворотным — мы решили организовать переговоры с непосредственными руководителями «Витязь-Аэро».

Переговоры и изменения в порядке работы

Из-за возникшей коллизии мы встретились с бизнес-заказчиками. В ходе переговоров мы:

  1. Воссоздали моменты нашей коммуникации с самого начала, чтобы проверить, кто какой информацией владеет.
  2. Обозначили проекты, которые мы ведем: поддержка и развитие АИС, поддержка существующего сайта «Витязь-Аэро» и разработка нового.
  3. Познакомили с нашей командой и рассказали об объеме задач у каждого сотрудника — чтобы клиент понимал, что в проекты вовлечено много человек.
  4. Презентовали результаты работы за последние 6 месяцев.
  5. Рассказали, на каких стадиях находятся поставленные задачи.
  6. Наметили будущие приоритеты и проблемы, из-за которых могут сдвинуться сроки.
Колесо проектного взаимопонимания
Колесо проектного взаимопонимания

Также мы проанализировали коммуникацию с «Витязь-Аэро» и предложили варианты, как предотвратить проблемы в будущем. Самым важным было подключить бизнес-заказчика к ключевым процессам разработки. Договорились о следующем:

  • Внедрили ежемесячные демо. Подключали руководителей и заинтересованных участников со стороны заказчика, чтобы совместно продемонстрировать и принять новый функционал в дев-окружении. Сбор обратной связи здесь и сейчас упрощал коммуникацию с двух сторон и позволил учитывать ожидания заказчика. Также это погрузило руководителей в процесс разработки и дало понимание, почему готовы или нет те или иные инструменты;
  • Договорились о стратегических совещаниях раз в 3–6 месяцев. Это помогло увидеть горизонт работы и определить приоритетные задачи в следующие 6–12 месяцев. Выделили несколько направлений: развитие и поддержка продукта, а также фиксация проблем в автоматизированной системе.

Выстроенная коммуникация позволила сохранить сотрудничество и быстрее выполнять задачи клиента. Объем работ многократно вырос, а time-to-market, время за которое идеи реализовывались и становились доступными для пользователей, сократилось в 2 раза.

Где участие бизнес-заказчика обязательно

Работа с «Витязь-Аэро» показала, что общаться только с руководителем проекта по поводу целей и результата сложно. При такой коммуникации мы упускали из виду приоритеты бизнес-заказчика, подолгу выясняли тонкости его работы и не получали адекватную обратную связь. В итоге понимание задач было неполным, они долго выполнялись — получалось, что бюджет компании тратился без видимого результата.

Это позволило синхронизировать бизнес и разработку
Это позволило синхронизировать бизнес и разработку

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

  • Формирование бэклога — определяемся со списком задач с описанием, оценкой и приоритетами;
  • Утверждение скоупа — согласовываем список задач, которые точно должны попасть в следующий релиз;
  • Тестовая эксплуатация — демонстрируем результат работы клиенту.

Если вам интересно, как эффективно выстроить работу с разработчиками — задавайте вопросы. Мы всегда готовы поделиться опытом или провести полноценный аудит вашего ИТ-продукта, чтобы по итогу вы получили обоснованные предложения по развитию и поддержке.

1818
3 комментария

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

Алексей, не всегда знать ≠ применять. В нашем случае в проектном офисе внедрен PMBoK где тоже есть управление стейкхолдерами, но это не помешало нам споткнуться :) PRINCE2 перечитаю на досуге, спасибо!

А про гибкие методологии и длинные проекты — это тема следующей статьи! И я скорее склонен отказаться от термина «длинный проект», чем от термина «гибкая методология», если мы говорим про разработку для малого и среднего бизнеса. В энтерпрайзе и госах, понятно, другие правила.

2

Cool статья!!.
У кого есть время можете ли вы оценить один из проектов моих?(в PlayMarket - Invest Clicker: Idle Tap Game).
Разработка шла в течение 1 месяца.
По стеку flutter+firebase(для лидерборда).!
Если есть пожелания или какие нибудь идеи ответьте пожалуйста!

https://play.google.com/store/apps/details?id=com.da.invest_clicker