Укрощение строптивых – о взаимоотношениях заказчика и подрядчика

Даже тигры поддаются дрессировке. Не говоря уже о кошках, собаках и прочей живности.

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

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

Итак, приступим к разбору.

Ситуация Кто виноват? Что делать?
В договоре зафиксированы сроки, но заказчик их не соблюдает. Например, вы задали заказчику вопрос по теме курса, а ответ от него пришел через неделю. Соответственно, вы задерживаете на неделю срок сдачи курса. В глазах заказчика всегда виноват разработчик. Особенно если конфликт выходит на уровень руководителя заказчика. Что ж, разработчик в данном случае виноват в том, что не предусмотрел строгого механизма контроля сроков. Во-первых, обязательно в договоре должен быть пункт о том, в какой временной интервал заказчик обязан вам ответить/принять работу/выслать замечания. Мало того, обговорите на встрече или в письме вопрос сроков с руководителем заказчика, который курирует данный курс. Используйте инструменты для фиксации времени – Ms Project и аналогичные программы – не только для внутренней работы, подключите туда заказчика. В этом случае вы сразу увидите сами и покажете заказчику, на каком этапе, кто и на сколько затянул сроки.
За один проект отвечает несколько человек – так называемая «экспертная группа» по принципу коммунизма, когда за проект отвечают все сразу и никто лично. Отсюда получаем сразу пучок проблем: разработчику высылают замечания/требования несколько заказчиков, и часто эти требования противоречат друг другу. Проблемы начинаются с цвета кнопочек и заканчиваются принципиальными вопросами типа использования персонажа и потребности геймификации. Да и договориться о соблюдении сроков с группой людей практически невозможно. Чаще всего такие «экспертные группы» встречаются в больших компаниях, стиль управления в которых сильно напоминает СССР. Зачастую руководители там – люди в возрасте, выросшие в другую эпоху. Что ж, если вы на предварительной встрече видите, что методы работы в компании-заказчике противоречат вашему пониманию бизнес-процесса, имеет смысл умножить цену на коэффициент вредности. Или вообще отказаться от такого заказчика. В договоре указывайте ответственное лицо со стороны заказчика и со стороны разработчика. В обязанности ответственного лица со стороны заказчика обязательно должны входить сбор и анализ замечаний от экспертной группы. Если вам прислали противоречивые замечания, отправьте их обратно заказчику, пусть ответственное лицо разгребет эту кучу и выдаст список требований/замечаний в заранее оговоренном формате. Эта система – ОДИН ответственный сотрудник – должна быть донесена до заказчика до начала работы. Это ответственность руководителя проекта (директора), а не исполнителя (разработчика курса).
Работа по проекту велась с одним заказчиком, который указан в договоре как ответственное лицо, но принимает проект совсем другой человек. По факту оказывается, что ответственное лицо – это неопытный/новый сотрудник, а принимает работу его руководитель. Даже если лично вам не придется общаться с руководителем новичка, то внезапно за день до плановой сдачи проекта вам пришлют стопицот замечаний. На вопрос «а почему сейчас, а не раньше, когда мы это обсуждали?» обычно ответ один: я заказчик, ты дурак. Такая ситуация, когда разработчик не знает, чего ему ждать от заказчика, возникает из-за недостаточного общения на этапе подписания проекта. Это зона ответственности руководителя проекта (хотя часто в e-learning руководитель проекта и разработчик курса – одно лицо). Проведите не одну, а две очные встречи перед подписанием договора. Познакомьтесь со всеми, кто будет косвенно принимать участие в разработке курса – сотрудники отдела персонала, эксперт в теме курса и его руководитель или коллега, администратор СДО. Составьте для себя карту компетенций всех сотрудников, которые как-либо могут повлиять на разработку курса. Обсудите с ответственным сотрудником (который указан в договоре), кто, на каких этапах и каким образом влияет на курс.
Заказчик не выдвигает требований к курсу. Чаще всего это звучит как «нам что-то надо, что обо было красивое, интересное, но быстро и дешево». В результате вы делаете курс по своему усмотрению, а заказчику все не нравится, потому что он представлял себе не то и не так. И вообще, вы же профессионал, сделайте мне красиво! Такая ситуация – явная недоработка разработчика. Если заказчик не ориентируется в конечном продукте, объясните, покажите, нарисуйте, спойте и станцуйте. Работу можно работать только тогда, когда вы уверенны, что вы и заказчик представляете себе один и тот же конечный продукт. Сделайте концепт курса. Пусть это будут 3-4-5 начальных слайдов будущего курса. Делайте в том редакторе, в котором будет курс. Нарисуйте плеер, подберите шрифт, выберите стиль текста, определите интерактивные элементы и типы заданий. Да, вы потратите на разработку концепта 1-2 дня, которые, возможно, не будут оплачены. Зато, если уж вы договоритесь с заказчиком на основании готового концепта, то работа войдет легко и все останутся довольны.

Резюме всего вышесказанного: фиксируйте все договоренности, обсуждайте процесс работы как можно детальнее. Заказчик не телепат, читать мысли не умеет. Если вы считаете, что работа должна строиться именно так, а не иначе, поделитесь своим взглядом на мир с заказчиком. И когда заказчик согласился с форматом работы, сроками и подписал договор с перечнем своим обязанностей, на каждом этапе требуйте соблюдения договоренностей.

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

Добавить комментарий