Жил был проектный менеджер. Работал он в банке. Поручили сделать ему внешний продукт для банка этого. Нужно было менеджеру найти удаленную команду разработки, которая сделает его ему. Команду разработки он нашел, ТЗ написал. Начали они работать вместе. Работа в первое время шла хорошо. Спринты закрывались в срок, качество не страдало.

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

Коллеги, здравствуйте

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

1. Встать на сторону заказчика. Это значит, что нужно одевать на себя шапку заказчика и будучи в его шкуре представить мотивы его требований и задач. Мотивы могут быть очевидные, а могут быть и скрытые. Если чувствуете, что в задаче нет дополнительной информации для полного понимания – надо о ней спрашивать и фиксировать в исходном документе о задаче, который размещен на гугл диске. Все должно быть прозрачно ясно.
   • для пээмов: если в процессе получения задачи или юзер стори вы чувствуете спорные моменты или что-то упускаете, то постарайтесь получить всю информацию, чтобы быть с заказчиком on the same page. Заказчик может говорить одно, подразумевать другое, а ожидать третье.
   • для остальных: для ребят разработчиков/дизайнеров тоже полезно перед началом работы над задачей представить себя заказчиком и понять его мотивы. Это такой простой и недолгий мысленный эксперимент и он поможет вам глубоко и ясно понять задачу. Если же вы получили задачу и она, в принципе, понятна, но вы не видите общей картины и не чувствуете как она в целом повлияет на процесс – обязательно сообщите об этом пээму.
2. Честность, уважение и сдержанность.
   • честность: своевременно говорите о проблемах и о отставаниях, чтобы заказчик на своей стороне успел мобилизоваться. От ошибок никто не застрахован, но их замалчивание расценивается как не профессионализм.
   • уважение: заказчик может быть со своими тараканами в голове, может иногда тупить. Но раз уж он работает с вами, это что-то значит.
   • сдержанность: старайтесь сдерживать свои эмоции в общении и в переписке.
3. Коммуникация! Коммуникация! Коммуникация! (хотелось бы сразу заметить, что под коммуникацией ни в коем разе не подозревается пустая болтовня и бездумные переговоры). Ниже приведу выдержки из книги Remote, так как мы с вами работаем удаленно:
   • Почаще рассказывайте клиенту, что сделано по проекту. Это лучший способ избавить его от вполне естественной тревоги. Послушайте, он же платит вам приличные деньги, и некоторое беспокойство, которое он ощущает с момента расставания с авансом, вполне понятно. Так что показывайте ему то, за что он платит. Когда клиенты регулярно видят результаты ваших усилий, они гораздо лучше себя чувствуют. Но для того чтобы избежать постоянных созвонов, НУЖНО четко и структурированно вести работу над задачами в нашем инструменте – Трак:
   • Задача должна быть оформлена полностью по шаблону (что нужно сделать, как это сделать, критерии готовности и прочее)
   • У задачи должны быть проставлены все пункты (milestone, планируемый срок исполнения, компоненты, номер релиза, дата и прочее)
   • У задачи должен быть виден прогресс, то есть если разработчик проставил задачу в статус inProgress и работает над ней, то я ожидаю увидеть, что он по ней сделал в течении дня (это минимум 2 комментария к задаче в день, которые понятно раскроют суть сделанного)
   • Будьте подчеркнуто доступны для общения. Поскольку у нас нет возможности встречаться лично, лучше вовремя перезванивать, отвечать на электронную почту, отзываться в мессенджерах и так далее. Это азы деловой этики, и их важность десятикратно усиливается в случае удаленной работы. Если вы работаете удаленно, клиенты более подозрительно относятся к оставшимся без ответа звонкам и «потерянной» почте. Будьте на связи, это в ваших интересах. Для того чтобы плыть в одном русле теперь каждый день у нас с вами в 9:30 будет видеоконференция (это будет стенд-ап не больше чем на 10 минут, чтобы сверить часы, услышать проблемы и понять куда движемся). Присутствие всей команды обязательно.
   • Подключайте заказчика к работе, пусть он видит весь процесс. Пусть чувствует, что это и его проект тоже. Да, вас наняли из-за вашего опыта, но и у него опыта хватает. Показывайте полусырой, еле двигающийся прототип или сервис, лучше на начальном этапе понять что не так и потратить меньше ресурсов и сил на переделку. Я как заказчик понимаю, что такое прототип и на какие вещи не стоит обращать внимание, здесь важно базовое понимание работы, а детали это детали.

В результате дела пошли хорошо. И причем команда девелоперов была довольна этим регламентом больше, чем сам автор письма. Без четких правил и дисциплины любой процесс взаимодействия разваливается. Хорошо бы эти правила командам разработчиков иметь внутри себя и придерживаться их, а не ждать пока это сделает кастомер.

Автор:

Источник