Как принять курс у разработчика и выжить?

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

Я хорошо понимаю, насколько это может быть трудно. Много задач, все загружено, ожидаешь готовый результат, а тут - сюрприз. Написать правки для курса в 40 слайдов, да еще собрать их у пары экспертов - это несколько часов работы. И комментарии могут быть очень значительными, сразу написать сложно. Сроки получения курса поджимают, нужно назначать обучение. И стресс часто подталкивает к конфликту.

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

- Для начала нужно п**равильно подготовиться к самому процессу разработки курса**. Это займет время: на старте, в процессе создания сценария и графики, на этапе согласования. Если вы начинаете разработку, то нужно себе время спланировать. У любого проекта по разработке есть хотя бы какой-то график, на него можно опираться. В среднем на часовой курс от вас точно нужно будет около 15 часов вовлечения. Больше курс - больше вашего внимания нужно. Без вас курс не сделает даже самый профессиональный разработчик.
- Разработчику нужно много деталей. И ответы на все вопросы. Не стоит этим пренебрегать. Потому что в итоге незнание чего-то важного приводит к тому, что курс совсем не похож на то, что вам нужно.
- Обязательно найдите примеры и анти-примеры. Не ждите их от разработчика, найдите то, что вам нравится. Разработчик покажет то, что хочет сделать и создаст тоннельность вашего восприятия. Вам нужно найти примеры курсов, примеры текстов (это особенно важно) и примеры графики (если вы ее создаете под заказ). Чем точнее вы покажете то, что вам нравится, тем больше шансов получить нужный курс.
- Примите, что у разработчика есть несколько клиентов. И каждый раз, когда вы ушли писать правки, он занимает время другими проектами. И если правки приходят позже запланированного времени, то вам скорее всего придется ждать их внесения. Или цена за проект будет астрономической. Иначе просто невозможно выжить на рынке.
- Если вам что-то не нравится или не понятно, говорите про это сразу. Само не пройдет и исчезнет. Одна незначительная недомолвка может привезти к системной ошибке во всем курсе и к большим сложностям с приемкой этого курса.
- Если результат вам совсем не нравится, то нужно сначала подумать, почему. Может быть задачу можно было и правда было решить несколькими способами и предложенный вариант не плох, просто он отличается от вашего. И спросите у разработчика, почему именно так - может быть там все же рациональное зерно.

И еще один очень важный момент. Аппетит часто приходит во время еды, а понимание того, что вы хотите получить в качестве курса - ближе к концу разработки. И зачастую так получается, что уже получив почти готовый продукт заказчик понимает, что хотел что-то совсем иначе. Это новое представление часто выдается за правки, хотя по сути - это новое видение, которое пришло в процессе. Делайте частями - это помогает на небольшом объеме все скорректировать. Принимайте как есть, если это не мешает обучению, но отличается от нового видения. Главное - не пытаться сделать в время приемки курс, который никто не делал и не знал, что так нужно делать.