пятница, 14 июня 2013 г.

Обращения

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

Собственно, этот момент - это когда у заказчика появляется вопрос по задаче после того, как результаты ему переданы. В пашиной схеме три роли - Заказчик, Менеджер и Исполнитель. Начало схемки, расположенное в левой части, всех устроило. В принципе, там всё логично и не вызывает вопросов. Заказчик пишет менеджеру: "сделайте мне вот это", Менеджер показывает просьбу Исполнителю, тот задаёт дополнительные вопросы, и говорит свою оценку работы ("ну я это часа за три запрограммлю"). Менеджер тут работает посредником между Исполнителем и Заказчиком, потому что названные Исполнителем сроки и оценку надо умножить на Секретный Менеджерский Коэффициэнт, а некоторых вещей, которые разработчик может сказать, Заказчику вообще лучше не слышать и не знать.

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

Заинтересованная часть коллектива Гринсайта разделилась на два противоборствующих лагеря. Одни, назовём их условно "негры-альбиносы, думающие, что делают неимоверно сложную работу от рассвета до заката"... хотя нет, вторых можно назвать так же. Тогда так, одних назовём "разработчики", вторых - "менеджеры", это наиболее близко к правде :) Менеджеры полностью согласны с нарисованной Пашей правой частью схемы. Их аргументация:
  • я не хочу быть лишним звеном в цепочке коммуникаций и транслировать "а теперь работает?" и "нет, всё ещё нет" туда и обратно, у меня есть и другие дела;
  • я не хочу работать "испорченным телефоном" (некоторые добавляют: "я не секретарь у разработчиков");
  • лишнее время, потраченное на коммуникацию - потерянные деньги.

В принципе, они правы. Я сам пару раз просил у заказчика номер телефона и ник в скайпе, чтоб можно было мгновенно связываться. Ну например, заказчик сидит за VPN, у него IE нестандартной конфигурации, терминальный доступ служба ИБ заказчика внутрь не даёт, зато даёт жестокие правила внутреннего брендмауэра, а мне надо быстро выяснить, показывается картинка на сайте или нет. Но это единичные случаи. С другой стороны, точно такие же единичные случаи, когда у заказчика работают какие-то сумасшедшие истеричные люди, у которых вечно ничего не работает, и которые генерируют информационный понос тоннами в секунду (типа таких: "у меня коврик для мышки меньше по размеру, чем монитор, и я не могу подвести курсор к нарисованной вами кнопке, поэтому её надо сместить левее") - но, к счастью, таких крайне немного :) Между такими представителями заказчика и разработчиками надо ставить непроницаемый фаервол из менеджера и тщательнейшим образом фильтровать всё, что от них приходит. Наверное, Паша забыл, как пару лет назад отдел разработки был вынужден вводить "дежурных по инноебле" (смачное словечко, образованное от названия одного из бывших проектов, управление требованиями по которому было невозможно в силу в том числе и вышеописанных обстоятельств).

Разработчики не отрицают необходимости время от времени напрямую связываться с заказчиками, но против того, чтоб это было постоянной практикой. Их аргументация:
  • у меня полно другой работы, я не могу реагировать на запросы заказчика по той задаче, которой сейчас не занимаюсь, они меня отвлекают, производительность падает, а это - потерянные деньги;
  • если разработчики будут общаться с заказчиками, то зачем тогда вообще нужны менеджеры;
  • иногда для того, чтоб ответить на вопрос заказчика, надо планировать отдельную задачу, а у меня всё на две недели вперёд забито.

Все согласны с тем, что оставлять без внимания вопросы заказчика нехорошо и все согласны с тем, что надо что-то придумать, чтоб не было скандалов на пустом месте. Все говорят красивые слова типа "мы одна проектная команда, мы должны работать сообща" и всё такое. Однако, разработчики, видимо, полагают, что делают Очень Важные Дела И Зарабатывают Для Компании Деньги, поэтому ничего не хотят менять - пусть, стало быть, менеджеришка сам прочитает, что там заказчик пишет, и если надо, подойдёт и поговорит. Менеджеры, наверное, приходят в бешенство от таких рассуждений :)

Что касается меня, то я давно хотел написать пост об этом. Или, может быть, даже писал, но забыл. Мнение моё такое - нельзя давать заказчику писать напрямую разработчику. Разработчик хочет поговорить с заказчиком сам, чтоб выяснить какой-то технический вопрос - пожалуйста, но менеджер в копии писем. А заказчик может обращаться только к объекту под названием "проектная команда", и всё, что от него пришло, разбирает специальный человек. Пусть это будет аккаунт-менеджер. Заказчик в одном обращении может задать вопрос по оплате (разработчиков это вообще не должно касаться), сообщить о баге в сделанной задаче (разработчикам это надо транслировать) и поставить новую задачу (надо поставить разработчикам задачу, согласовать сроки и оплату).

Более того, я считаю, что передавать работу напрямую заказчику исполнитель тоже не должен. Менеджер проекта должен хотя бы одни глазком посмотреть на то, что получилось в итоге, тем более если эту задачу не рассматривал отдел контроля качества (тестировщики), если он вообще есть. В пашиной схеме этого нет, то есть участие менеджера сводится к тому, что он в начале умножает оценку разработчика на Секретный Коэффициент, планирует её (вешает бумажку на доску), а в самом конце подписывает акты.

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

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

Комментариев нет:

Отправить комментарий

Ублюдочный Гугл поломал форму комментариев. Извините.