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

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

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

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

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

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

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

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

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

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

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

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

• Декомпозиция задач на мелкие и независимые

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

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

• Регулярные встречи по всем вопросам запуска

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

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

• Только одно лицо, ответственное за результат

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

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

• Еженедельные звонки по продвижению по roadmap

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

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

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

• Приоритет скорости реакции, а не глобальной эффективности

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

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

• Овертаймы

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

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

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

• Проведите кик-офф встречу для синхронизации

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

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

• Наметьте ключевые точки, когда и что отдавать на ревью

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

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

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

• Сделайте план регулярных встреч

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

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

• Зафиксируйте ответственного с вашей стороны и со стороны подрядчика

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

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

• Решите, где будет хоститься проект — на вашей стороне или стороне исполнителя

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

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

• Обсудите, как будет происходить процесс раскладки и тестирования

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

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

• Заложите в roadmap согласование интеграций с внутренними сервисами компании

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

• Заложите в проект время на прохождение проверки от службы безопасности компании

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

• Заложите время на согласование контента сервиса с отделом маркетинга

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

• Узнайте, кто готовит контент для сервиса — тексты, видео, фото

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

• Определите процесс согласования проекта с руководством

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

• Зафиксируйте все договорённости

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

• Поймите, на каком домене будет расположен сервис

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

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

• Рассчитайте ожидаемую нагрузку на сервер

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

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

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

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