А потом с подрядчиками что-то случилось. Толи они поменяли менеджера, толи разработчиков перекинули на другой проект и оставили ему джунов, толи еще что-то. Процессы стали выполняться медленнее, сроки продалбыватся, качество стало хуже. Стал думать менеджер, что же случилось и как бы ему решить свою проблему? Пошел он к старому приятелю своему, у которого компания занимается ИТ аутсорсингом. Рассказал он о проблеме своей. И приятель вспомнил, что недавно он писал документ для своей команды, где расписал о том, как коммуницировать с заказчиком, чтобы это было эффективно и качество не страдало. Поделился он документом с менеджером. А менеджер прочитал его и с минимальными правками отправил письмо подрядчику.
Коллеги, здравствуйте
Не знаю как вам, но мне кажется, что мы сейчас рассинхронизированы и нынешнее положение вещей это только усугубляет. В перспективе это обязательно скажется на качестве задач, сроках которые будут увеличиваться. В свою очередь вы будете не довольны тем, что нами оплачено одно время, а вы затратили на задачи совсем другое. В итоге всё это может привести к нашему расставанию, что не выгодно для наших компаний.
Чтобы избежать все вышеизложенное, я подготовил небольшой список принципов и правил нашего с вами взаимодействия.
- Встать на сторону заказчика. Это значит, что нужно надевать на себя шапку заказчика и будучи в его шкуре представить мотивы его требований и задач. Мотивы могут быть очевидные, а могут быть и скрытые. Если чувствуете, что в задаче нет дополнительной информации для полного понимания – надо о ней спрашивать и фиксировать в исходном документе о задаче, который размещен на гугл диске. Все должно быть прозрачно ясно.
- для пээмов: если в процессе получения задачи или юзер стори вы чувствуете спорные моменты или что-то упускаете, то постарайтесь получить всю информацию, чтобы быть с заказчиком on the same page. Заказчик может говорить одно, подразумевать другое, а ожидать третье.
- для остальных: для ребят разработчиков/дизайнеров тоже полезно перед началом работы над задачей представить себя заказчиком и понять его мотивы. Это такой простой и недолгий мысленный эксперимент и он поможет вам глубоко и ясно понять задачу. Если же вы получили задачу и она, в принципе, понятна, но вы не видите общей картины и не чувствуете как она в целом повлияет на процесс – обязательно сообщите об этом пээму.
- Честность, уважение и сдержанность.
- честность: своевременно говорите о проблемах и о отставаниях, чтобы заказчик на своей стороне успел мобилизоваться. От ошибок никто не застрахован, но их замалчивание расценивается как не профессионализм.
- уважение: заказчик может быть со своими тараканами в голове, может иногда тупить. Но раз уж он работает с вами, это что-то значит.
- сдержанность: старайтесь сдерживать свои эмоции в общении и в переписке.
- Коммуникация! Коммуникация! Коммуникация! (хотелось бы сразу заметить, что под коммуникацией ни в коем разе не подозревается пустая болтовня и бездумные переговоры). Ниже приведу выдержки из книги Remote, так как мы с вами работаем удаленно:
- Почаще рассказывайте клиенту, что сделано по проекту. Это лучший способ избавить его от вполне естественной тревоги. Послушайте, он же платит вам приличные деньги, и некоторое беспокойство, которое он ощущает с момента расставания с авансом, вполне понятно. Так что показывайте ему то, за что он платит. Когда клиенты регулярно видят результаты ваших усилий, они гораздо лучше себя чувствуют. Но для того чтобы избежать постоянных созвонов, НУЖНО четко и структурированно вести работу над задачами в нашем инструменте – Трак:
- Задача должна быть оформлена полностью по шаблону (что нужно сделать, как это сделать, критерии готовности и прочее).
- У задачи должны быть проставлены все пункты (milestone, планируемый срок исполнения, компоненты, номер релиза, дата и прочее).
- У задачи должен быть виден прогресс, то есть если разработчик проставил задачу в статус inProgress и работает над ней, то я ожидаю увидеть, что он по ней сделал в течении дня (это минимум 2 комментария к задаче в день, которые понятно раскроют суть сделанного).
- Будьте подчеркнуто доступны для общения. Поскольку у нас нет возможности встречаться лично, лучше вовремя перезванивать, отвечать на электронную почту, отзываться в мессенджерах и так далее. Это азы деловой этики, и их важность десятикратно усиливается в случае удаленной работы. Если вы работаете удаленно, клиенты более подозрительно относятся к оставшимся без ответа звонкам и «потерянной» почте. Будьте на связи, это в ваших интересах. Для того чтобы плыть в одном русле теперь каждый день у нас с вами в 9:30 будет видеоконференция (это будет стенд-ап не больше чем на 10 минут, чтобы сверить часы, услышать проблемы и понять куда движемся). Присутствие всей команды обязательно.
- Подключайте заказчика к работе, пусть он видит весь процесс. Пусть чувствует, что это и его проект тоже. Да, вас наняли из-за вашего опыта, но и у него опыта хватает. Показывайте полусырой, еле двигающийся прототип или сервис, лучше на начальном этапе понять что не так и потратить меньше ресурсов и сил на переделку. Я как заказчик понимаю, что такое прототип и на какие вещи не стоит обращать внимание, здесь важно базовое понимание работы, а детали это детали.
В результате дела пошли хорошо. И причем команда девелоперов была довольна этим регламентом больше, чем сам автор письма. Без четких правил и дисциплины любой процесс взаимодействия разваливается. Хорошо бы эти правила командам разработчиков иметь внутри себя и придерживаться их, а не ждать пока это сделает кастомер.
Комментарии (12)
mmblsc
19.07.2017 09:17-1А мне письмо понравилось тем, что нет угроз, менеджер явно заинтересован в цели и мотивирует подрядчика. Сама же идея описывается в ряде книг, «Как пасти котов» и в руководствах по итерационным методикам разработки.
dklein
19.07.2017 09:26+2Детский сад какой-то. Такое ощущение, что писал человек без опыта работы (отправил магическое письмо и всё сразу разрулилось у него), который начитался литературы по теме и решил собрать воедино core-пункты. Да, да, все правила кровью написаны, мудрость поколений ПМ…
i360u
19.07.2017 09:41+4Встать на сторону заказчика.
Бред примерно того-же уровня, что и "посмотреть на продукт глазами пользователя". Нет никакого универсального сферического в вакууме "пользователя" или "заказчика". Приоритеты всегда видны только в области компетенций, а процессы оцениваются только в рамках собственного субъективного опыта. Все остальное — иллюзии, которые ни к чему хорошему никогда не приведут. Никто не сможет "залезть" в голову заказчику, не умеющему четко формулировать свои мысли.
Честность, уважение и сдержанность.
Не хватает слова "взаимная". Все имеют равные права на "тараканов в голове", как и право слать куда подальше мудаков, с которыми работать не комфортно. У хороших специалистов всегда есть выбор, проектные менеджеры должны четко это осознавать. Разработчик — не ваш личный психолог, и его работа вовсе не заключается в том, чтобы успокаивать заказчика. Это я к тому, что разработчики часто сталкиваются со сложными техническими ситуациями, которые могут давать довольно высокую психологическую нагрузку. Иногда люди, в такой ситуации, срываются, и совершенно не беспочвенно, стоит быть внимательными друг к другу обоюдно.
Коммуникация! Коммуникация! Коммуникация!
Бред. Перегибы с коммуникацией часто сильно вредят процессу. Хотя бы на том уровне, где для решения задач требуется высокий уровень сосредоточенности, и все внешние раздражители и переключения фокуса — очень нежелательны. В команде обязательно должен быть человек, ответственный за процесс, который может оградить исполнителей от лишнего формализма и излишних коммуникаций, способный самостоятельно предоставить заказчику необходимую актуальную информацию.
Вы, наверное, могли подумать, что все вышеизложенное — мнение вредного и несговорчивого разработчика? Но нет, я все это пишу именно с позиции менеджера, но имеющего технический бэкграунд.
prefrontalCortex
20.07.2017 16:31Никто не сможет "залезть" в голову заказчику, не умеющему четко формулировать свои мысли.
Перегибы с коммуникацией часто сильно вредят процессу.Вашими бы устами, да мёд пить.
i360u
20.07.2017 18:05А в чем проблема? Вы нашли какое-то противоречие в этих цитатах? Поделитесь какое именно?
ivan19631224
19.07.2017 10:05+2Сами же вначале сказали:
> А потом с подрядчиками что-то случилось. Толи они поменяли менеджера, толи разработчиков перекинули на другой проект и оставили ему джунов, толи еще что-то.
Так что, это "что-то" куда-то делось после письма? Если нет, то с чего бы "дела пошли хорошо"?
> Без четких правил и дисциплины любой процесс взаимодействия разваливается
Так каким же образом заказчик навязывает эти правила и следит их выполнением в данном случае? Одним этим письмом? А если домысливать, то получается это статья типа "Как нарисовать сову", т.е. ни о чём.
Helwig
19.07.2017 10:46+3«Заказчик может говорить одно, подразумевать другое, а ожидать третье.» — это лучше выяснять на старте и по возможности с такими товарищами не работать. Если у заказчика нет понимания, что собой представляет ЕГО продукт (подчеркну, не технических особенностей, а просто «что он должен делать»), то тут ничем не поможешь.
«Но раз уж он работает с вами, это что-то значит.» — значит только то, что компании в этот момент времени подвернулся этот заказ и он почему-то был признан выгодным. Поменьше «небожительства», пожалуйста.
msuhanov
19.07.2017 12:22+2сдержанность: старайтесь сдерживать свои эмоции в общении и в переписке.
Коммуникация! Коммуникация! Коммуникация!
habradante
19.07.2017 12:59+2Что-то попахивает микроменеджментом чужой команды. Видеть комментарии разработчика по таскам в трекере, да еще и не меньше двух, это вот оно самое «дайте поуправлять вашей командой, раз ваш менеджер не справляется». Стэнд-апы каждый день со ВСЕЙ командой — оттуда же. РМ (Project Manager) заказчика должен работать с РМ исполнителя, а не с разработчиками исполнителя.
Судя по всему, у исполнителя как раз и ушел РМ, и заказчик взял на себя эту функцию. Вам повезло, что команда не была занята на другой задаче, иначе аутстаффинг бы провалился. Иначе говоря, это не ваша заслуга, а просто везение.
EreminD
Что, одним письмом и процессы у подрядчика и качество продукта подтянул? Мощь…