понедельник, 7 октября 2013 г.

Alfa, Beta и Стоп-кран! Подход к повышению качества курсов.

Автор: Павел Безяев
Наверное, многие из тех, кто разрабатывают курсы сталкивались (или обязательно еще столкнуться) с тем, что или Заказчик сам не понимал до конца цель электронного курса или эксперта назначил такого, что увёл совсем не в ту сторону… Особенно ярко проявляется ситуация, когда вроде и с заказчиком несколько раз Цель прояснили и с экспертом концепт проработали и сценарий согласовали со всеми, а когда сделали первую версию курса всех словно «прорывает» — дали не то и не тем, не так и не тогда и «вообще, мы поняли теперь что хотели». Если вы работаете с внешним заказчиком, то такая ситуация может означать конфликт с заказчиком, затягивание сроков сдачи, работу себе в убыток и штрафные санкции. Если это внутренний заказчик, то это может, например, ударить по доходам разработчиков, когда производительность жестко зашита в KPI (или планы отдела). Понятно, что такие ситуации не очень хорошо сказываются и на мотивации команды. Инстинктивное желание сделать всё, что бы обезопасить себя – не делать лишних шагов (самой разработки), пока цели, задачи и сценарий не согласованны на 150%. Многие так и делают – формализуют отношения с заказчиком, через хитро продуманные заявки на разработку, протоколирование интервью, регламентированные согласования. Спору нет – такой подход поможет доказать, что курс сделан в соответствии с договорённостью, но не гарантирует, что это тот курс, что нужен в данный момент целевой аудитории и заказчику. Почему? Потому что есть ситуации, когда что бы увидеть Цель ясно надо начать двигаться, даже если есть большая вероятность, что движешься не совсем в идеальном направлении. Мне сегодня привели хороший пример – например, ты находишься в огромной захламленной комнате и совершенно не представляешь где выход, можно сколько угодно планировать, как выйти из этого лабиринта, но все это будет лишь гипотезой, пока ты не сделаешь несколько шагов и случайно не увидишь комнату с такого ракурса, который покажет направление к выходу. Вот и с курсами – можно сколько угодно применять красивые методы для выявления потребностей заказчика и продумывать методические подходы для реализации, но первый же просмотр или пилот может показать «дверь» совсем в другом направлении. Если у нас «прикрыты тылы», то можно конечно оставить всё как есть, но мне видится что глобальная Цель того, кто делает Настоящие Курсы не в этом. Варианты? Пока мы придумали схему, как действовать с внутренними заказами (при условии, что нет чрезмерно сжатых сроков – чей-то «пожар» это отдельная тема). Необходимо ввести систему Alfa и Beta версий курса. Alfa версия это некий набросок курса, который увидит узкий круг людей – заказчик, эксперты, методисты, коллеги и который может открыть совершенно отличный путь или даже показать несостоятельность заданной Цели. Разработчики уже знают, что это будет не их провал и выполненная заря работа, а очень важный этап в создании действительно ценного курса. Beta версия это версия которая выходит на пилот – на небольшую группу представителей целевой аудитории, которые дают первую обратную связи и позволяют определить чего не хватает для полноценного релиза или подтверждают полную готовность курса.   И тогда в плане отдела дистанционного обучения уже можно указывать не просто количество курсов, которое надо сделать за месяц (или квартал), а количество версий курсов. Кажется это уже мелочь, но как это всё меняет. Например, мы хотим сделать идеальный курс по продажам, включаем его в планы, а после на пилоте понимаем, что ушли не туда (сами понимаем, но легко можем убедить заказчика). Вариантов у нас два – оставить все как есть и получить премии, но недовольных сотрудников (что всегда вернётся, но чуть позже) или остаться без премий и еще два месяца «доделывать» курс, как некий долг отдела. Получается некрасивая история со всех сторон, но уверен, что во многих компаниях часто так и выходит. А если мы бы сразу договаривались о версионности и закладывали в план на месяц сначала Alfa, а потом уже Beta версию и релиз, то вся история гораздо интереснее для всех. При этом никто не отказывается от идеального варианта, когда Alfa-версия становится релизом, но при этом без вынужденного обмана.
Кстати, на поиск этой идеи я вдохновился после очередного участия в клубе «Хорошее время читать». И снова впечатлила книга о Японских подходах к менеджменту, но на этой раз докладчиком был не я.  В книге «Дао Тойота» рассказывается об основных принципах менеджмента ведущей компании Мира. Есть там принцип №5 — «Сделай остановку производства с целью решения проблем частью производственной культуры, если того требует качество». Этот подход позволяет любому (любому!) сотруднику остановить весь конвейер, когда он замечает какой-то брак (у них есть для этого специальные копки). Для нас это может звучать дико – как можно доверить остановку производства субъективному мнению одного человека, а если ему просто показалось? Но практика показала, что это гораздо выгоднее, чем выпустить целую партию бракованных изделий, пока вопрос об остановке будет согласовываться с руководством. Есть и другие плюсы, но это отдельно. В общем, вчера я понял, что нажму «Стоп-кран» и остановлю «конвейер» по производству интерактивных курсов пока не поправлю вопрос качества. Остановил, подумал, посовещался, услышал идеи и теперь можно запускать снова, но уже совсем другой конвейер! :)
Удачи в поиске качества!
Источник

4 комментария:

  1. Павел, идея хорошая. А не думаете, что лучше где-то посередине быть? И версии - удобно и понятно, и цели/задачи - правильно. С одной стороны партий "бракованных изделий" показывает, что работа была выполнена и вот она. Но с др. стороны к цели эта партия может долго вести.

    ОтветитьУдалить
    Ответы
    1. Полностью согласен, что цели и задачи надо правильно выявлять. Но пока прихожу к пониманию, что не так много таких заказчиков и экспертов, кторые могут сразу чётко понять что им надо даже если их правильно интервьюировать, но все меняется, как только они могут "пощупать" некий продукт вместо абстракнтых концептов и сценариев.

      Удалить
    2. А вообще, у меня большое желание продумать стандарты (в хорошем смысле этого слова) по взаимодействию с заказчиками и экспертами. это должны быть не формальные заявки и документы, а что-то действительно повышающее возможность верно понять друг друга и достичь реальной Цели... пока такой стандарт не выкристаллизовывается :)

      Удалить
    3. Поняла о чем вы) очень дипломатично в отношении понимания цели

      Удалить