Контент устаревает тише, чем ломаются процессы
Когда говорят о пересмотре образовательного продукта, чаще всего имеют в виду процессы сопровождения или интерфейс. Контент программы — сами уроки, задания, кейсы — почему-то реже попадает в поле зрения для регулярного пересмотра, хотя устаревает он не менее реально, просто менее заметно.
Проблема в том, что контент не «ломается» явно, как сломанная кнопка или зависший процесс — он просто постепенно теряет актуальность: технология, о которой рассказывает урок, меняется, пример из практики перестаёт быть узнаваемым, отраслевой контекст, на который ссылается задание, устаревает. Ничего не сигнализирует об этом громко, пока студенты не начинают массово жаловаться — а к этому моменту разрыв между содержанием курса и реальностью уже успевает стать заметным. И как человек, который является первой линией и лицом компании для студента, невозможно не согласится, когда жалоба касается контента.
К контенту стоит с содержанием так же, как с любым другим процессом, который требует планового обслуживания, а не только реакции на жалобы: заранее заложенный график пересмотра каждого модуля (например, раз в год или раз в два выпуска когорты), а не «обновим, когда кто-то заметит проблему». Для программ программирования или искусственного интеллекта стоит делать анализ программы каждый квартал, так как данные сферы меняются с неимоверной скоростью. Отдельно полезно закладывать в сам контент опору на принципы и логику, а не только на конкретные инструменты и примеры текущего момента — тогда естественное устаревание идёт медленнее.
Хорошая практика — заранее назначить владельца за актуальность каждого крупного модуля, чтобы вопрос «а не пора ли это обновить» не оставался ничьей зоной ответственности до тех пор, пока не станет проблемой.
