История О Менеджере Проектов В Банке И О Том, Как Он Решал Проблемы С Удаленным Подрядчиком

Жил-был менеджер проекта.

Он работал в банке.

Ему поручили сделать внешний продукт для этого банка.

Менеджеру нужно было найти удаленную команду разработчиков, которая бы сделала это за него.

Он нашел команду разработчиков и написал техническое задание.

Они начали работать вместе.

Поначалу работа шла хорошо.

Спринты были завершены вовремя, качество не пострадало.

А потом что-то случилось с подрядчиками.

Либо поменяли менеджера, либо перевели разработчиков в другой проект и оставили его с джуниорами, либо ещё что-то.

Процессы стали идти медленнее, сроки сдвинулись, а качество ухудшилось.

Менеджер стал думать, что случилось и как ему решить свою проблему? Он пошел к своему старому другу, чья компания занимается ИТ-аутсорсингом.

Он рассказал о своей проблеме.

А друг вспомнил, что недавно написал для своей команды документ, где описывал, как общаться с заказчиком, чтобы было эффективно и качество не страдало.

Он поделился документом с менеджером.

А менеджер это прочитал и с минимальными правками отправил письмо подрядчику.

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

В будущем это обязательно отразится на качестве выполнения задач и сроках, которые увеличатся.

В свою очередь, вы не будете рады тому, что мы заплатили за одно время, а вы потратили на задания совсем другое.

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

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

  1. Встаньте на сторону клиента.

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

    Мотивы могут быть очевидными, а могут быть скрытыми.

    Если вы чувствуете, что задача не содержит дополнительной информации для полного понимания, вам необходимо спросить об этом и записать это в исходном документе о задаче, который размещен на Google Диске.

    Все должно быть прозрачно и понятно.

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

      Клиент может говорить одно, иметь в виду другое и ожидать чего-то другого.

    • в остальном: ребятам разработчикам/дизайнерам тоже полезно перед началом работы над задачей представить себя заказчиком и понять его мотивы.

      Это такой простой и короткий мысленный эксперимент, который поможет вам глубоко и ясно понять проблему.

      Если вы получили задание и оно в принципе понятно, но вы не видите общей картины и не чувствуете, как это повлияет на процесс в целом, обязательно сообщите об этом ПМ.

  2. Честность, уважение и сдержанность.

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

      Никто не застрахован от ошибок, но их замалчивание расценивается как непрофессионализм.

    • уважение: у заказчика могут быть свои тараканы в голове, а иногда он может быть и глупым.

      Но раз он работает с тобой, это что-то значит.

    • сдержанность: старайтесь сдерживать свои эмоции в общении и переписке.

  3. Коммуникация! Коммуникация! Коммуникация! (Хотелось бы сразу отметить, что общение ни в коем случае не заподозрено в пустой болтовне и необдуманных переговорах).

    Ниже приведены выдержки из книги Remote, поскольку мы с вами работаем удаленно:

    • Часто рассказывайте клиенту, что было сделано по проекту.

      Это лучший способ избавить его от вполне естественного беспокойства.

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

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

      Но чтобы избежать постоянных звонков, НУЖНО работать над задачами в нашем инструменте — Truck: четко и структурировано:

    • Задача должна быть оформлена полностью по шаблону (что нужно сделать, как сделать, критерии готовности и т.д.).

    • В задаче должны быть отмечены все пункты (веха, плановая дата завершения, компоненты, номер релиза, дата и т. д.).

    • Задача должна иметь видимый прогресс, то есть если разработчик поставил задачу в статус inProgress и работает над ней, то я ожидаю увидеть, что он сделал по ней за день (это минимум 2 комментария к задаче в день, что наглядно раскроет суть проделанного).

    • Будьте предельно доступны.

      Поскольку у нас нет возможности встретиться лично, лучше вовремя перезванивать, отвечать на почту, отвечать в мессенджерах и так далее.

      Это основы деловой этики, и их значение возрастает в десятки раз при удаленной работе.

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

      Оставайтесь на связи, это в ваших интересах.

      Для того, чтобы плыть в одном направлении, теперь каждый день в 9:30 мы с вами будем проводить видеоконференцию (это будет стендап не более 10 минут, чтобы сверить часы, услышать проблемы и понять, куда мы идем) ).

      Присутствие всей команды обязательно.

    • Вовлекайте заказчика в работу, позвольте ему увидеть весь процесс.

      Пусть он почувствует, что это тоже его проект. Да, вас взяли на работу из-за вашего опыта, но и у него опыта достаточно.

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

      Я как заказчик понимаю, что такое прототип и на что не стоит обращать внимание, здесь важно базовое понимание работы, а детали есть детали.

В результате дела пошли хорошо.

И команда разработчиков была довольна этим регламентом больше, чем сам автор письма.

Без четких правил и дисциплины любой процесс взаимодействия разваливается.

Было бы неплохо, чтобы команды разработчиков имели эти правила внутри себя и придерживались их, а не ждали, пока это сделает заказчик.

Теги: #управление персоналом #управление проектами и командой #управление развитием #управление проектами #управление персоналом

Вместе с данным постом часто просматривают: