Грабли. Мазь от синяков
Эта заметка – о личном опыте. Предлагаемые решения разных сложностей в разработке курсов могут показаться очевидными, но про них забывают. С такими решениями я и поделюсь.
В самом начале, когда мы понимаем, что будем работать над новым курсом или курсами, команда вспоминает свой прошлый опыт. Это позволяет нам предусмотреть риски и не наступить на грабли, которые уже встречались на пути раньше. Сложности возникают практически всегда, и важно всегда быть готовым к ним.
Самые частые из них – эти:
- Нарушение коммуникации в команде
- Создание новых возможностей курса в середине пути
- Изменение объёма информации, которую нужно проанализировать и включить в курс
Рассмотрим каждый момент с позиции сложность-решение. Речь пойдёт о том, как предусмотреть сложности и не искать вместе с заказчиком способов увеличить сроки разработки.
1. Нарушение коммуникации в команде.
Как правило, каждый проект начинается с заряда бодрости – каждый участник хочет сделать курс эффективнее, интереснее, современнее и т.д. Но в какой-то момент любой проект превращается в рутину. Для кого-то раньше, для кого-то позже. Но каждый участник со временем это ощущает. Как результат – снижение продуктивности, которая была в начале, и нарушение коммуникации с другими, потому что «всем всё и так понятно (сейчас закончу свою часть и пойду домой)». И если первое следствие рутины – естественный процесс, то второе – сознательная прокрастинация или отсутствие менеджмента. Как раз второе и нужно предусмотреть в начале разработки.
На мой взгляд, умение работать с рутиной – это одно из ключевых качеств хорошего специалиста, и чтобы не допустить мысли «всем всё и так понятно», что приведёт к нарушению коммуникации, важно составить план, который все будут соблюдать.
Решение – это повторяющиеся собрания, на которых должны присутствовать все участники. И тут важна строгость: не можешь прийти – подключись по Скайпу; заболел – изучи лог собрания и попроси кого-нибудь из коллег рассказать, о чём договорились. Как ни странно, такая формальность помогает поддерживать ритм и делать одно общее дело. Если на собраниях сможет присутствовать и заказчик курса – это вдвойне полезно.
На собраниях каждый высказывается о своих трудностях, о новых идеях, о той же рутине (при этом часто находятся решения от коллег, как её избегать). Как показывает практика, на собраниях, где, вроде, «и обсуждать нечего», участники засиживаются ещё больше, предлагая новые пути достижения результата или корректируя процесс разработки. Короче говоря, главное правило – поддерживать регулярное проведение собраний команды. Как много времени нужно на каждое собрание – смотреть по ситуации, как правило, это 30-60 минут, раз в неделю.
2. Создание новых возможностей курса в середине пути.
Сделать глубокое адаптивное тестирование, создать проработанное интерактивное задание, добавить поиск по ключевым словам – это правильные задачи, но не в середине пути. Встречаются ситуации, когда заказчик или команда разработки решают, что в курсе чего-то не хватает, находят решение, и оно оказывается трудоёмким. Всякий раз, когда мы берёмся (чаще всего на азарте) что-то такое сделать, мы не замечаем, как намеченный план по разработке оказывается неактуальным. Дедлайн понемногу смещается всё дальше и дальше, а результата, который можно было бы запустить сегодня, нет – потому что новый функционал затрагивает всю структуру курса, и нужно корректировать всё до мелочей.
Решение в этой ситуации – выделять для себя, для команды и для заказчика время «на подумать». Как бы смешно это ни звучало, нам часто не хватает воли, чтобы спокойно решить: действительно ли то, что мы собираемся сделать, так важно сделать сейчас? Можно ли новую функцию сделать после того, как будет готов минимально работающий продукт, который мы запустим для фокус-группы?
Очень часто важно остановить движение творческой мысли – в тот момент, когда она выходит за рамки плана проекта. Опять же, тут связь с первым пунктом – собрания помогают держать участников в заданных рамках, при должном менеджменте.
3. Изменение информации, которую нужно проанализировать и включить в курс.
По разным причинам иногда в середине разработки курса оказывается, что уже разработанная часть – это устаревшая информация, которую нужно заменить на новую. А новая не подходит под тот формат, который был продуман для старой. А еще её в 2 раза больше. И не важно, по чьей вине это произошло: мы не задали вопроса об актуальности в самом начале пути или заказчик об этом не подумал – с этим нужно что-то делать.
Решение – это «резиновый скелет», на который можно надеть любое мясо – контент. В нашем случае это компоненты – утверждённые в самом начале элементы вёрстки, которые не меняются по ходу всего проекта. Бывают исключения, но они точечные.
Мы заранее знаем, что любой тип информации мы поместим в тот или иной компонент, и уверены, что с этим не возникнет сложностей. Вместе с заказчиком мы договариваемся, в каком формате будет представлена та или иная информация.
Мы заранее ставим себя в рамки определённого набора компонентов/интерактивов, и кажется, что это плохо – потому что всё будет одинаковым. По факту же выигрывают все: команда разработки быстро собирает курс или вносит коррективы, а заказчик сходу понимает, из чего он строится и каким он будет – демонстрация прототипов со всеми компонентами этому способствует. В сухом остатке, смысл в том, чтобы с самого начала договариваться о некоторых рамках разработки. То, что выходит за рамки, обсуждается отдельно.
Три сложности, о которых я рассказал, не исчерпывают весь список сложностей, с которыми мы сталкиваемся. Однако они так часто встречаются, что, уверен, с ними сталкиваются и наши коллеги из других компаний.
Если у кого-нибудь есть свои решения разнообразных сложностей в разработке, обязательно поделитесь. Будем помогать друг другу по мере возможностей.
P.s.
Безусловно, вещи, о которых я рассказал, закрываются разработкой по эджайл, и могут показаться сами собой разумеющимися. Однако опыт подсказывает, что эджайл в чистом виде – как написано в манифесте – очень часто неосуществим, его нужно подстраивать под собственный контекст. Сложности и решения выше – это наш контекст. Именно в нём мы, хочется думать, конструируем и собираем нужные и результативные обучающие продукты.
