Никита
25 декабря 2014

Николай, добрый день!

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

В этом отделе пять человек, которые контактируют со мной. Самый главный из них общается очень редко. Остальные четыре делятся на две группы. Каждая группа отвечает за один сайт. Из двух человек в группе, один главный. Главные отвечают за масштабные правки, подчинённые — за баги и обращения пользователей.

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

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

Как бы вы действовали в данной ситуации? Как лучше сделать, чтобы и клиенту было комфортно и мне спокойнее — оставалось бы время на другие проекты?



Никита!

Представляю себе диалог клиента и начальника отдела, отвечающего за сайт:

  • Клиент: А чё баги не исправили?
  • Начальник: Да фиг знает, ещё вчера им отправили.
  • Клиент: Понятно, позвоню им, блин. А вы не слезайте, пока не убедитесь, что задача взята в работу. Мы бабки за поддержку платим.
  • Начальник: Стараемся мы, стараемся. (Кричит) Толик, напиши ещё раз в скайп по вчерашним багам.

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

И клиента я понимаю. Отвратительно, когда мелкий баг висит неделями. Проще самому влезть в код и поправить, чем ждать.

Постройте новую систему взаимоотношений.

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

Если вам разрешат продолжить, опишите новую систему. Сложно посоветовать что-то конкретное, не зная деталей. Но вот, что мне пришло в голову:

  1. Договоритесь использовать только Джиру. При длительных отношениях, лучше, когда все смотрят в одно место. Не забудьте потравить леску, в прошлый раз Джира не сработала.
  2. Пообещайте реагировать на все замечания не позже следующего рабочего дня. Чтобы справляться, используйте принцип пустого инбокса.
  3. При работе с багтрекером пугает информационный вакуум. Представьте себя на месте клиента или его сотрудников: вы вносите важную задачу в трекер и… тишина. Чтобы придать уверенности сотрудникам клиента, настройте в Джире автоматическое уведомление:

    • Добрый день!

      Мы получили вашу задачу «Починить знак рубля для ИЕ8». Завтра мы возьмём задачу в работу или свяжемся с вами, чтобы уточнить детали или запланировать задачу на другой срок.

  4. Договоритесь, что скайп больше не является средством оперативного общения — ответ на сообщение с задержкой в 2—3 часа. То же с почтой. Для срочных вопросов — телефон.

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

P. S.
Это был совет об управлении проектами, людьми и собой. Присылайте вопросы.
P. P. S.

Я веду практический курс «Управление проектами, людьми и собой». Дата следующего курса пока неизвестна.

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

Поделиться

Комментарии

Лёша Захарченко
25 декабря 2014

Беспокойство клиента, наверно, возникает из-за слабой обратной связи в Джире, я бы поискал какой-нибудь плагин к ней для сортировки очерёдности топиков на календаре, что бы заказчикам сразу было видно, когда и к чему вы приступите, и к какой дате ждать результаты. И если вдруг вы ещё не используете статус «in progress» — очень рекомендую. Наглядность происходящего при его использовании очень увеличивается.

Алексей Червяков
26 декабря 2014

Если клиента не устраивает реакция на мелкие исправления, сократите время реакции (привет от кэпа) или травите леску и объясняйте клиенту, почему изменения невозможно внедрить так скоро, как он того ожидает.

Мы решили похожую проблему, когда поняли, что клиенту важна не скорость, а предсказуемость. Он хотел знать, над какой задачей мы работаем, все ли задания поставили в работу и когда завершим каждую из поставленных задач. Особенно страдал собственник бизнеса. Он уже не справлялся с объёмом работы сам и пока боялся делегировать полномочия подчинённым. Зато мог подойти сотруднику и спросить: «Как дела с новой промостраницей?». Если сотрудник не мог чётко ответить, получал минус в карму.

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

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

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

Никита
26 декабря 2014

Спасибо, Николай. Прочтя совет, ещё раз убедился, что все задачи легко решаются, когда ставишь себя на место клиента.

Vsevolod Tsurikov
27 декабря 2014

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

Изменения в процессе:
1) Исключите все каналы общения кроме основного. Если заявка поступает во время встречи или по телефону, под неё создаётся отдельная задача в основной системе учёта. Все просьбы и пожелания, не оформленные в виде заявки, не рассматриваются и не берутся в работу.

2) Все пользователи системы видят все заявки компании и их приоритет. Создавая новую заявку видно очередь (заявка будет рассмотрена %дата%). Пользователь может повысить приоритет заявки, но это сдвинет даты заявок с низким приоритетом.

3) Раз в неделю короткое (15—30 минут) совещание с «самым главным», или назначенным им управляющим. На встрече рассматривается, сколько заявок было закрыто за прошлый период и очередь.


Изменение в подходе (соответствует пунктам процесса):
1) Часто на встречах заказчик выражает пожелания «а вот хорошо бы улучшить» но никогда не оформляет заявку в работу. Через полгода опять всплывает, но с комментариями «мы же ещё полгода назад обсуждали». Т. к. оплата за поддержку в нашем случае почасовая, то работаем только с оформленными заявками.

2) Все пользователи системы имеют равный приоритет. Т. е. заявка от «самого главного» равна по важности любому другому запросу. Искореняйте подход, когда небольшая просьба от директора вытесняет мелкий багфикс — об этом изменении клиент забудет уже на следующий день.

3) На совещании определяется необходимость в ресурсах. Хаос в системе — нужен новый управляющий на стороне исполнителя. Нет времени на мелкие маловажные заявки — в проект подключается новый специалист.


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

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

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

Вот такой веб 2.0.

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




Недавно всплыло

4 Как сделать плавный переход от общения с администратором к директору? 1 Начальник считает, что перед встречей нужно обязательно разработать несколько вариантов предложений 6 2