Как быстро запустить обучающую платформу в большой компании

Привет, это Максим Павлов из KTS. Мы занимаемся разработкой цифровых продуктов для бизнеса в EduTech.

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

Есть несколько вариантов, когда компании может понадобиться обучающая платформа.

Самый распространённый — вам нужно научить клиентов работать с вашим продуктом так, чтобы им было удобно. Именно от удобства во многом зависит то, воспользуются ли вновь они продуктом или нет.

Альтернативный вариант — вам нужна платформа, которая познакомит пользователей не со спецификой продукта, а со сферой в целом.

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

Создание полноценной обучающей платформы — крайне объёмная задача для пары месяцев и компании со сложной структурой.

Основной успех быстрого запуска кроется в том, что создаваться платформа должна на основе готовой LMS (Learning Management System), которую подрядчик готов кастомизировать под вас.

Серьёзные готовые LMS-ки есть сразу у нескольких студий разработки на российском рынке. Например, мы в KTS используем для этого нашу систему UClass. Готовый конструктор позволяет существенно сэкономить время, закрывая весь базовый функционал вроде конструктора страниц уроков, вебинаров и тестов.

Конечно, в качестве LMS можно и вовсе взять доступный любому человеку GetCourse, но делать проект там для большой компании — просто несолидно. Да и возможности кастомизации у GetCourse довольны малы — максимум вы сможете перекрасить интерфейс в фирменные цвета и настроить красивое доменное имя.

Помимо этого запускать образовательные продукты в сжатые сроки нам с клиентами помогают следующие шаги:

Важно регулярно следить за тем, чтобы задачи по проекту можно было выполнять независимо друг от друга: в таком случае подрядчик сможет подключить на проект сразу несколько разработчиков.

Такой шаг подразумевает дополнительное время, которое вам придётся потратить на планирование и дробление задач на совсем небольшие, но по факту эти действия значительно увеличивают скорость разработки.

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

Обсуждайте на ежедневных встречах не только статусы по задачам разработки, но и другие вопросы — например, юридические аспекты, выдачу доступов, готовность контента. Если нужно согласовать дизайн, зовите на одну встречу сразу всех ЛПР-ов, чтобы потом не тратить время на ожидание фидбеков от каждого. Чтобы на встречу все пришли подготовленными, перед ней заранее запросите у подрядчика ссылку на новую версию макетов.

Ситуация, когда один человек у вас в компании отвечает за контент, второй — за дизайн, третий — за технические вопросы, не работает в срочных проектах.

Должно быть только одно контактное лицо — конкретный человек, который будет оперативно решать абсолютно все вопросы и пушить команды. Раз вы читаете эту статью, вероятно, таким человеком и будете вы.

Если ежедневные созвоны — они про статусы, то еженедельные встречи должны быть посвящены сугубо закрытию целей по roadmap.

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

В roadmap проекта изначально заложите все этапы согласования, вплоть до итераций вашим топ-менеджментом.

Обычно большая часть правок перед запуском завязана на картинках и текстах, поэтому просите подрядчика вносить их в режиме реального времени, чтобы сразу посмотреть, как будут смотреться реальные страницы.

Для коротких правок сразу попросите подрядчика упростить стандартный процесс, когда сначала согласовывают дизайн-макеты, и только потом они отдаются разработчикам: придётся много править в продакшене, но это сильно ускорит работу.

Если сроки проекта несдвигаемые, нужно иметь в виду, что критические вопросы придётся решать во внерабочее время. И речь идёт не только про оплату овертаймов для подрядчика, но и про готовность вас включаться в работу и что-то согласовывать в выходные дни. К сожалению, выходные дни будут единственным временем, когда можно залатать дыры в проекте, а они обязательно возникнут.

Лучше на берегу договориться с подрядчиком, что для них проект приоритетный и они понимают, что в первую очередь нужно запуститься в срок, и только во вторую — сделать это в основное время.

Для тех, кто ещё не запускал проекты у себя в компании в сжатые сроки, мы делимся нашим чек-листом. Он поможет не забыть про важные вещи, не провалить проект и запуститься вовремя.

Первым делом соберите (и желательно очно) максимальное число заинтересованных лиц в проекте и обсудите ключевые моменты: кто у вас и у подрядчика за что отвечает, все ли готовы на овертаймы и понимают, что дедлайн невозможно передвинуть.

Такая встреча позволит настроиться на общий лад, понять реалистичную картину и что должно получиться в итоге.

В плане сразу отметьте дату запуска, даты согласований проекта с топ-менеджментом, даты предоставления доступов.

Чтобы всё удалось, нужно на самом старте понимать, какие дополнительные контрольные точки нужны, чтобы зарелизиться в срок.

Без контрольных точек все будут понимать, что проект должен быть запущен к какому-то числу, но никто не будет знать, что нужно делать прямо сейчас, чтобы к этому прийти.

Определите график встреч, кто на них нужен с вашей стороны и стороны подрядчика.

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

На проекте должен быть один менеджер и со стороны исполнителя, и с вашей стороны.

Если ответственный с вашей стороны — это вы, то убедитесь, что у вас достаточно полномочий для принятия большинства решений по ходу проекта без дополнительных согласований с кем-то ещё.

Если сервис раскладывается на вашей стороне, то у внешней команды обычно ограничены доступы, и нет полноценного доступа к централизованной системе мониторинга.

А значит надо заложить в проект время на дополнительные работы по раскладке системы и выстраивание процессов по решению инцидентов (нужно определить, как внутренняя команда будет взаимодействовать со внешней, когда будут происходить ошибки).

Если проект развертывается в вашей инфраструктуре, то есть определенный процесс, которого подрядчику придётся придерживаться.

Это может занимать дополнительное время. Зная это время, вы поймёте, сколько будет занимать раскладка срочных фиксов и релизов.

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

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

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

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

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

Сжатые сроки обычно не позволяют прописывать все детали работ в договоре, но важно договориться с подрядчиком на берегу, какие у вас есть ожидания, а у него — возможности. Важно не утонуть в детализации требований и их согласовании, но при этом описать все функции и работы, которые нужны для достижения целей бизнеса.

В вашей компании наверняка у каждого продукта или проекта есть доменное имя: они не должны пересекаться.

Уточнить домен для вашего сервиса лучше заранее, до того, как нужно будет развёртывать проект.

Крупные компании тратят большие бюджеты на промо новых сервисов. Если рекламная кампания будет успешной, то нагрузка на запускаемый сервис будет лавинообразной.

До релиза важно понять узкие места сервиса и ограничения инфраструктуры. В идеале вообще успеть провести нагрузочное тестирование.

Если я забыл ещё какие-то шаги, которые кажутся вам важными — поделитесь ими в комментах.

Сохранить чек-лист на будущее можно двумя способами: добавьте эту статью в закладки или скачайте удобный документ с котиками в формате pdf по ссылке.