Как стать автором
Обновить
0

Как наладить взаимодействие с внутренним заказчиком: боли трансформации

Время на прочтение6 мин
Количество просмотров3.6K

Привет! Меня зовут Саша Зыкова, я Agile-коуч в Уральском Банке Реконструкции и Развития. На данный момент развиваю две команды: команду SAP СRM (отвечает за интеграцию каналов коммуникации с клиентами в банковскую CRM) и команду Корпоративных рисков (сопровождает и развивает техническую сторону департамента корпоративных рисков). Расскажу про наш опыт построения процесса взаимодействия с внутренним заказчиком.

Статья будет вам полезна, если вы задаетесь одним из вопросов:

  • Как подойти к работе с внутренним заказчиком?

  • Как можно улучшить взаимодействие?

  • Какие инструменты можно использовать для оптимизации контакта?

  • Какие у вас есть зоны роста в области коммуникаций?

  • Как легко вскрыть существующие проблемы и противоречия в общении с заказчиком?

У нас есть абсолютно чёткое понимание, что во многих современных компаниях этап отладки коммуникаций с заказчиками уже пройден. Связи налажены, процессы адаптированы под потребности и задачи. Однако в банковской структуре направление коммуникации с внутренним заказчиком часто становится “узким местом”, оказывается консервативным и неповоротливым. Банк — это сложная многоуровневая структура, где требуется четкость, внимательность и высокий уровень экспертизы, и люди, которые обладают указанными навыками, привыкли себя подстраховывать различной документацией. Отсюда и растут ноги у проблемы с коммуникацией, особенно, когда вы пытаетесь отладить процесс по agile, где люди и взаимодействие важнее процессов и инструментов, а сотрудничество с заказчиком важнее согласования условий контракта. Потихоньку мы эту ситуацию разруливаем, но работы ещё много.

Опыт, описанный в статье, мы с командой нарабатывали на протяжении 6 месяцев, и сейчас я хочу им поделиться с вами.

Сложности взаимодействия

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

  1. Неясные требования при постановке задачи. Задачи поступали в виде служебных записок через систему электронного документооборота (далее — ЭДО). Зачастую запрос формулировали без конкретики, необходимой для команды, поэтому тратилось время как на запрос дополнительной информации, так и на перенос задачи в Jira;

  2. Длительное ожидание ответа о принятии закрытия задачи после её выполнения. Когда завершалась работы команды над задачей, долгое время не поступал отклик от заказчика: можно ли задачу считать закрытой или требуются ещё доработки? Это мешало планированию при общей нагрузке команды, а также негативно сказывалось на общем показателе скорости её работы;

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

  4. Постоянное изменение требований и приоритетов. Заказчик мог прийти на встречу и сообщить, что сегодня в приоритете иная задача и её нужно взять в работу, или добавить внезапные требования к текущей задаче, а потом удивляться, что команда слишком долго работает;

  5. Большое количество каналов коммуникации. Задачи поступали из разных каналов: через ЭДО, почту, мессенджеры, на встречах. Команде приходилось тратить время, чтобы всё занести в Jira;

  6. Отсутствие обратной связи. Команда не знала, насколько заказчик удовлетворен работой, требуются ли какие-либо изменения или все устраивает.

Первые шаги

Опустим этап, на котором мы пришли к осознанию, что у нас есть проблемы, и перейдем сразу к действиям. Первое, что нам хотелось исправить, это принцип оформления задач. Мы хотели все их перевести на один канал их поступления — Jira. Для решения этой задачи мы собрали небольшую рабочую группу, которая состояла из пары Agile-коучей, пары менеджеров разработки команд с внутренними заказчиками и руководителя по развитию процессов. По итогам наших встреч у нас родился шаблон задачи, который должны были заполнять заказчики, когда направляют эту задачу в бэклог команды.

Основные пункты шаблона
Основные пункты шаблона

Параллельно с шаблоном появилась идея собрать обратную связь от заказчиков, чтобы выяснить, насколько они удовлетворены взаимодействием с командой. Было решено провести небольшой опрос среди заказчиков.

Вопросы к опросу
Вопросы к опросу

Параллельно шла работа непосредственно с самими заказчиками: на встречах мы рассказывали им про шаблон, почему мы просим его заполнять, просили заводить задачи в Jira, помогали им получить туда доступ, проводили для них обучение по работе в Jira (по запросу от самих заказчиков) и писали для них инструкции. Это дало первые плоды: мы локализовали канал, задачи перестали поступать через почту и систему ЭДО, коммуникация по задачам перешла в Jira. А ещё мы перестали долго ждать ответа о том, что задачу можно закрывать.

Дальнейшая трансформация взаимодействия 

У нас оставался ещё опрос, судьба которого пошла двумя путями.

На первом пути опрос был проведен среди заказчиков команды SAP CRM.

Отдельно стоит упомянуть о том, как именно мы просили заказчиков пройти опрос. В первую итерацию мы сделали массовую рассылку по заказчикам. Не взлетело, мы не получили ни одного ответа. Во вторую итерацию мы в письмо добавили не просто ссылку на форму опроса, а зашили ссылку в QR-код, чтобы опрос, при желании, можно было пройти с телефона. Здесь мы уже получили несколько ответов, но этого было недостаточно. И в третью итерацию мы сделали личную рассылку с тем же текстом, что и во второй итерации. И это сработало. Ответов пришло значительно больше. С ними уже можно было работать и делать выводы.

Проведя опрос, мы, наконец, увидели слабые точки взаимодействия. Для команды это оказалась работа над одним конкретным Проектом. Результаты опроса мы сразу обсудили с командой на ретроспективе и стали решать вопрос точечно. С представителями Проекта мы провели несколько встреч, на которых обговорили правила работы с их задачами. Там мы смогли защититься от того, чтобы брать задачи вне очереди, а в случае, если такое случается, от претензий к нашей скорости работы со стороны заказчика.

Сейчас мы готовимся повторить опрос по команде SAP CRM. Постараемся охватить ещё большую аудиторию наших заказчиков и, по результатам этого опроса, вновь разрабатывать план действий. Также мы решили в дальнейшем проводить такой опрос раз в квартал.

На втором пути мы провели опрос в команде Финансового мониторинга (сопровождает работу соответствующего отдела). В отличии от команды SAP CRM у команды Финансового мониторинга заказчик один. Проблема коммуникации была в том, что он  позиционировал себя не как часть команды, а как обособленный отдел.  После завершения опроса и на основании его результатов мы с командой провели  ретроспективу и пригласили сюда представителей от заказчика. Здесь стоит оговориться: мы сразу перед запуском опроса с заказчиком согласовали, что по итогам опроса проведём ретроспективу. Кроме того, опрос был проведен как среди заказчиков, так и среди членов команды, то есть оценку получили и команда, и заказчик.

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

С чем работаем сейчас

Сейчас мы продолжаем искать пути и подходы для дальнейшей отладки взаимодействия с заказчиком. При необходимости обучаем, как работать с jira, напоминаем, что есть инструкции и шаблон для задачи (изредка приходится заполнять его самим). В команде SAP CRM повторно запустили опрос заказчиков для сбора ОС -  в этот раз мы решили потратить на это больше времени и обзвонить заинтересованных лиц, это уже дало первые результаты. 

Также, по запросу от других команд разработки, мы начали рассказывать про наш опыт взаимодействия с заказчиком. Работа с ними теперь стала более системной, и коммуникация, основанная на обратной связи, взаимопонимании и единстве целей, стала отлаживаться во всем банке, а не в отдельно взятых командах. У нас в планах сейчас ещё ряд встреч, которые должны помочь синхронизироваться команде и заказчику по их целям.

Итоги нашей работы

На данный момент мы получили следующие результаты:

  • Инструмент оценки взаимодействия команды с заказчиком;

  • Работа с задачами переведена в один канал;

  • Показатель TTM снизился почти в два раза, с 80 дней до 40. Раньше задачи очень долго ждали отмашки заказчика, и старый показатель не отражал реальной картины. В пример привожу ТТM, так как именно эта метрика включает активную работу со стороны заказчика;

  • Ответы на вопросы получаем быстрее.

Что у нас в ближайших планах:

  • Опрос сделать регулярной практикой как для самих команд, так и для заказчика;

  • Ввести в привычку заполнение задачи по шаблону;

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

Теги:
Хабы:
Всего голосов 5: ↑3 и ↓2+1
Комментарии7

Публикации

Информация

Сайт
www.ubrr.ru
Дата регистрации
Дата основания
Численность
1 001–5 000 человек
Местоположение
Россия

Истории