Как писать success metrics запуска заранее...
... чтобы потом не спорить, получилось или нет
Знакомая ситуация: запуск прошёл, прошло две-три недели, и команда собирается обсудить результат — а вместо предметного разговора начинается спор о том, что вообще считать успехом. Кто-то доволен, потому что «студенты в целом довольны», кто-то недоволен, потому что «а вот retention так себе», и выясняется, что успех запуска никто заранее не определил в конкретных цифрах.
Success metrics — это не общие пожелания вроде «чтобы всем понравилось», а конкретные, измеримые показатели с числом и сроком, согласованные до запуска, а не после. Не «хорошая вовлечённость», а «не менее 60% студентов выполнят первое задание в течение 48 часов после старта». Не «программа должна быть успешной», а «completion rate не ниже 70% к моменту выпуска первой когорты».
Почему это работает лучше, чем кажется на первый взгляд: когда цифра и срок зафиксированы заранее, в письменном виде и до того, как результат стал известен, у команды нет соблазна задним числом подвинуть планку под то, что получилось. Разговор после запуска превращается не в спор о мнениях, а в сверку с документом, который все видели и одобрили заранее.
Практический совет: success metrics стоит формулировать вместе с планом запуска, а не отдельно и не в последний момент — и явно проговаривать их со всей командой, а не держать в голове у одного человека. Тогда после запуска остаётся один вопрос — достигли цифры или нет, — а не бесконечный спор о том, что вообще имелось в виду под успехом.
