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

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

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

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

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

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

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


Елена Черныш

Занимаюсь разработкой курсов 6 лет, спектр навыков - от обработки видео до написания сценариев. Неплохо знаю iSpring, Captivate, Storyline. Не люблю Курслаб. Зато люблю черный юмор.

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Похожие записи

Опыт

Симуляция ПО в Adobe Captivate

Среди электронных курсов особняком стоит целый класс симуляторов ПО. Это курсы, каждый слайд которых представляет собой скриншот с пояснениями и/или кликабельными областями, щелчки по которым имитируют работу в нужном ПО. Чаще всего такие курсы нужны Подробнее…

Мероприятия

«Добрий червень» з Unlimit Ukraine by the European Business Association та БФ «Таблеточки»

Проект підтримки мікро та малого бізнесу Unlimit Ukraine by the European Business Association та БФ «Таблеточки» розпочинають акцію «Добрий червень». Всі ми знаємо, що у великого бізнесу завжди є своя CSR (Corporate Social Responsibility) політика, Подробнее…

Blended learning

Кейс впровадження змішаного навчання в КПІ ім. І. Сікорського

23 січня в соціальній мережі побачив анонс I-ї Всеукраїнської конференції «Цифрові комунікації у глобальному просторі. Змішана освіта». Передбачувано, що в основному будуть доповіді та обговорення досвіду в академічному секторі. Наразі мені дуже цікаво спостерігати за Подробнее…