Делай сразу хорошо: MVP, KPI, OKR, SMART, STAR и многое другое

Привет! Меня зовут Аня, я отвечаю за маркетинг направления Битрикс24 в компании СофтСервис. А еще я пишу подкаст о менеджменте, где мы вместе с гостями обсуждаем новые и «попсовые» методики, делимся кейсами, разбираем ошибки и даем рекомендации, как их не допустить.

На прошлой неделе вышел первый выпуск подкаста, где мы поговорили о том, когда стоит начинать делать новый проект или любую большую задачу, как ее оценить, с чего начать, как сформировать минимальный жизнеспособный продукт (MVP), как его развивать на разных стадиях жизненного цикла, как ставить и контролировать выполнение целей по KPI и OKR, как ставить SMART-задачи правильно, контролировать работу по STAR, а также как масштабировать проект, когда это имеет смысл, а когда лучше оставить его в поддержке и переключиться на что-то новое.

Выпуски уже доступны на YouTube и Яндекс.Музыке, а для тех, кто любит читать, здесь я буду публиковать сокращенные по количеству знаков, но не по смыслу текстовые версии подкаста. А для тех, кто «любит глазами», есть инфографика, где все то, о чем мы говорим на подкасте, представлено в визуальном формате.

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

Гость первого выпуска подкаста – Андрей Приезжев. Андрей делает мобильные игры, часто работает сразу над несколькими проектами, с разными командами и руководит в горизонтали всей командой. В игры, над которыми работал Андрей успело поиграть 24 млн человек, и они принесли суммарно более 17 млн дохода.

Аня: Ты занимаешься больше оперированием либо же выпускаешь новые проекты с нуля?

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

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

Андрей: Я думаю можно начать с малого – постоянно проверять метрики. Какой продукт себя показывает лучше, какой хуже, смотреть динамику показателей. Приведу пример: у нас есть линейка продуктов, пять штук, они примерно одинаковые. С четырёх продуктов стоимостью 100 долларов каждый мы имеем конверсию 10%, а вот с пятого продукта стоимостью 50 долларов у нас конверсия 5%. В этом случае нам надо задуматься, почему, несмотря на более низкую цену на аналогичный продукт, конверсия на нем значительно ниже. Например, ценность пятого продукта для покупателей не соответствует их ожиданиям, или нам нужно пересмотреть состав этого продукта. В этой области и лежат наши проблемы и точки роста.

Аня: Получается, ты говоришь о том, что всё должно делаться для чего-то? То есть у всего должна быт какая-либо цель, и просто улучшения ради улучшений делать бессмысленно. Разумеется, может быть и такое, что какая-то идея без конкретной цели «выстрелит», но, мне кажется, что это не то что бы какой-то частый случай, который можно положить в систему.

Андрей: Я думаю, это очень просто объяснить как руководителю, так и подчиненному. Допустим подчиненный приходит к руководителю и просит увеличить зарплату, пусть в 2 раза. Соответственно, в глазах руководителя он должен делать в 2 раза больше и в 2 раза больше приносить доход. Тогда есть смысл повышать ему зарплату, а не нанимать нового сотрудника на эти деньги. С идеями работает тот же сценарий. И важно все мерять в деньгах. На мой взгляд, если мы увеличиваем, например, количество звонков, то я предлагаю и выдавать зарплату звонками. Понятно, что здесь я утрирую, и количество звонков – это тоже метрика, которая позволяет нам больше привлекать клиентов, которые помогут в будущем исправлять конверсию. Но, я думаю, мысль понятна: если мы делаем что-то, что делает наш продукт более классным, весёлым драйвовым, то мы и получаем как результат классность, драйвововсть и так далее.

Аня: Давайте я сейчас выступлю с короткой теоретической справкой, о том, как из проблемы сделать задачу. Здесь удобно использовать метод «5 Почему». Давайте возьмем глобальный пример, пусть проблемой у нас будет невыполнение плана продаж. С помощью метода «5 почему» мы можем декомпозировать эту проблему на составляющие, и понять, куда направить свои усилия. Работает это следующим образом: мы задаем первое «почему» к нашей проблеме, и получаем, что, например, у нас уменьшилось количество лидов. Почему у нас уменьшилось количество лидов? Здесь можно ветвить, можем дать на этот вопрос несколько вариантов ответов. Например, мы понимаем, что посещаемость сайта у нас не уменьшилась, просто стали меньше отправлять запросов. Причины здесь могут быть следующие: страницы сайта не прогружаются, форма где-то не понятно, где, поэтому до нее не доскролливают, контент, который мы даем не соответствует тому, что запрашивал пользователь в поиске, и так далее. Выбираем, какая причина у нас является наиболее вероятной и задаем к ней следующее почему. 5 – это условное количество, можно продолжать делать дальше, пока мы не придем к таким ответам, которые можно уложить в конкретные задачи.

Андрей: Здесь стоит оценить, сколько нам этот проект принесет денег и сколько будет стоить его реализация. На мой взгляд, это главная концепция, когда мы пытаемся делать бизнес: деньги на входе – деньги на выходе. Здесь нужно учитывать абсолютно все: фонд оплаты труда, затраты на маркетинг, техническое обеспечение всего этого, налоги и так далее. Если это физический продукт, учитываем сырье, дистрибуцию. Если это продукт для внутреннего пользования, учитываем также стоимость обучения сотрудников. Также здесь важно понимать, какие минимальные, средние и максимальные расходы мы будем нести. Под минимальными я понимаю не самый дешевый способ реализации, например, на самом дешевом оборудовании, а то, без чего мы не обойдемся, с учетом тех цен, за которые мы обычно это покупаем. Это оптимистичный прогноз. Средняя стоимость – это минимальная стоимость плюс основные риски, т.е. колебания рынка, волатильность валют и так далее. И максимальная стоимость – это то, сколько мы потратим денег, если все пойдет не так. Здесь у каждой компании уже есть своя методика, как считать, обычно просто добавляют 30% к средней стоимости. Со сроками это тоже работает.

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

Андрей: Я бы рекомендовал начать с минимального жизнеспособного продукта, или MVP. Это значит реализовать сначала только те функции, которые мы считаем наиболее важными. Определить, что войдет в MVP можно с помощью матрицы Эйзенгхауэра. Она представляет собой 2 оси – срочности и важности, которые на пересечении дают 4 области. То, что срочно и важно мы заносим в MVP и бросаем сюда значительный ресурс. То, что не важное, но срочное, мы тоже относим в MVP, но делегируем до самого низкого уровня, потому что это не требует большого качества. То, что попадает в область важного, но не срочного, мы откладываем до следующего релиза. И то, что не срочное и не важное мы помещаем в бэклог и смотрим, как оно у нас там обитает много лет. Или принимаем волевое решение отказаться от этого сразу.

Андрей: Чем в принципе полезен MVP – с его помощью мы можем протестировать идею без больших затрат на сам продукт. Так, если наш MVP «выстрелил», мы уже знаем, чем дополнять его и как развивать его дальше. Если нет – мы не потратили много денег на неинтересный рынку проект, и у нас остались ресурсы для работы над следующим.

Аня: Касательно MVP и его развития, хочу привести пример и наложить его на этапы жизненного цикла продукта. Далеко ходить не будем, возьмем пример этого подкаста. Первый этап жизненного цикла – зарождение. Здесь у нас формируется MVP, он умеет выполнять основные функции, которые на него возложены, справляется со своими задачами, при этом недорогой в производстве, потому что мы пока точно не знаем, на какие метрики мы сможем выйти с помощью этого продукта. Поэтому мы делаем подкаст на стадии зарождения минимальными ресурсами. Следующий этап – рост, где у нас за минимальное количество времени резко растет выручка. На этом этапе тоже не имеет смысл «докручивать» что-то дополнительное к продукту, потому что он и без этого имеет свою аудиторию, которая постоянно, быстро и значительно растет. Здесь имеет смысл бросить больше ресурса на маркетинг и продажи. Если у вас есть отдельная продуктовая команда, можете на это время ее «определить» на другие проекты, в этом будет больше смысла. Разве что на этом этапе вы можете делать то же самое, но больше, и чаще. В случае с подкастом, на стадии роста это может быть увеличение частоты выходов: больше тем и больше контента. За этапом роста следует этап зрелости, когда мы продолжаем расти по выручке, но уже не так стремительно, как на этапе роста, т.е. темп здесь у нас замедляется. Только здесь имеет смысл добавлять в продукт какие-то дополнительные опции, «наводить косметику» и так далее. В случае подкаста, например, это может быть увеличение количества видео-выпусков. И за этапом зрелости в классической модели, если мы сделали какие-то успешные дополнения мы идем дальше в еще одну стадию роста, если нет – в стадию спада.

Андрей: На мой взгляд, разницы в методике оценки между успешными и не успешными проектами быть не должно. Если мы получаем какой-то результат у него обязательно должны причины и предпосылки. И, если мы не можем объяснить, почему так произошло, это очень плохо, потому что мы не сможем повторить успех. Чтобы повторить успех, нужно декомпозировать все произошедшее: как сам продукт, так и причину его успеха. Также здесь отмечу, что если мы в результате увеличили не ту метрику, которую хотели, например, хотели конверсию, увеличили охват, это нельзя считать успехом, который можно повторить, т.к. гипотеза, которую мы ставили оказалась не верна.

Андрей: Здесь стоит поговорить о KPI и OKR. Думаю, все уже о них знают, поэтому хочется очень простым языком рассказать о том, как использовать на практике. Больше буду говорить об OKR, но KPI тоже затрону. В OKR всегда должна быть какая-либо большая цель. Это O – Objective. И она должна быть выражена каким-то количественным значением, например увеличить продажи на 20%. Чтобы ее достичь, нужно выполнить определенное количество key results, или KR. Здесь может быть увеличение количества лидов, увеличение конверсии и так далее. Они тоже должны быть выражены количественно. Таким образом мы дробим O (большую цель), на маленькие ключевые результаты (KR), и когда команда выполняет KR, это приближает на с O. При этом, если вы видите, что какой-то KR не приближает вас к O, имеет смысл убрать этот KR и вместо него использовать другой. Например, если в нашем случае увеличение количества звонков одним продавцом не увеличивает его продажи, не имеет смысл ставить такую же задачу его коллегам. Здесь стоит поискать другие пути достижения нашей глобальной цели. Относительно KPI, это, по сути, показатель эффективности сотрудников, который показывает, чем они занимаются в течение рабочего дня и хорошо ли справляются со своими задачами. Иными словами, KPI – это то, за что сотрудник получает зарплату, а OKR – то, за что получает премию.

Андрей: Я бы рекомендовал здесь воспользоваться методикой SMART, которая заключается в постановке задачи по следующим 5 показателям:

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

M – задача должна быть абсолютно измеримая конкретными величинами. Если мы не можем предложить линейку к этой задаче, значит это не SMART-задача. Например, нам нужно делать 100 продаж по 1 000 долларов.

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

R – задача должна быть актуальна здесь и сейчас. Мы не должны делать какие-либо задачи, которые будут нам полезны через 5 лет, через 10 лет или позавчера.

T – задача должна быть где-то расположена во времени. Например, сотрудник должен сделать ее в рамках этой недели, с третьего августа по одиннадцатое. Если у задачи нет сроков, нет и результата.

Аня: На самом деле, SMART – достаточно известная методика, однако в лучшем случае в реальности она выглядит как кое-как поставленная S, такая же M, причем в абстрактном виде «хорошо-красиво», и все выучили, что нужно обозначать сроки в T. Про A и R все забывают. И абсолютно зря, ведь прогоняя каждую задачу по A и R вы будете задавать себе вопрос, а не ерунду ли мы делаем, и, возможно, окажется, что задача не нужна и не достижима, и можно бросить ресурсы на что-то другое.

Андрей: Да, методика подразумевает комплексное использование всех 5 критериев, ничего из нее исключать нельзя. Если учтено не все, то это что угодно, но не SMART-задача.

Андрей: Здесь можно использовать методику STAR. Она используется не для оценки финального результата, а для того, чтобы разобраться, как сотрудник выполнял задачу. И, если что-то пошло не так, чтобы это починить и предотвратить в будущем такие ситуации. И наоборот, если имел место суперуспех, чтобы понять, что послужило причиной и использовать для других задач. STAR включает:

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

T – саму задачу. Как она ставилась, как ее понял сотрудник. Это оказывает значительное влияние и на работу, и на результат.

A – действия, предпринятые сотрудником, для того чтобы выполнить эту задачу. Сюда тоже максимально подробно «напихиваете», что он делал, как он подходил, какой порядок он выбрал для решения, как он её для себя декомпозировал, кого привлекал в процессе. Может отказаться, что он задействовал при этом своего лида всю неделю по 8 часов в день, и результат хоть и получился отличный, но очень дорогой. Нам такое не подходит.

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

Андрей: Здесь используем KPI и OKR, о которых говорили выше. Хочу отдельно сказать, что, пока идёт работа, цели меняться не могут. Если цель необходимо поменять в процессе, мы все «стопаем» и ставим новую задачу с новыми целями. Чтобы проанализировать, почему у нас так получилось, используем STAR, которую тоже описывали выше. Давайте разберем ситуацию. Есть продавец, у него 3 месяца на выполнение OKR – 150 000 выручки. Он продал уже 140 за 1 месяц, планирует закрыть цель намного раньше и поехать отпуск с семьей на премию. И тут его цель повышают до 170 000. Он плюет, мирится с этим и идет к этой цели. Когда он достигает 169 000, ему снова повышают план. Разумеется, в этом случае он понимает, что, как ни старайся, руководитель все равно будет двигать план, и в итоге останется недоволен. Соответственно в этой ситуации он скорее всего просто перестанет стараться.

Аня: На самом деле, это ситуация, в которой сотрудники «горят, как спички». И если такое изменение плана имеет место постоянно, это рано или поздно приведет к серьезным кадровым изменениям и большой «текучке» в целом. От себя хочу добавить, что, если вы изначально поставили цель в одной метрике, например, это охват, никогда, ни в какой момент времени она не должна трансформироваться в цель с конверсией. Цель с конверсией – это уже следующая цель, которая исходит из предыдущей цели с охватом.

Андрей: Здесь все звучит просто, но это достаточно большая работа. Необходимо посчитать, сколько мы денег получили на выходе относительно плановых, и почему так произошло. И, опять же, если мы в результате видим, что мы планировали увеличить охват, а увеличили выручку, это означает только то, что наша гипотеза не рабочая и ее нужно переформулировать. Мы можем, с одной стороны, продолжать делать этот проект, поскольку он показывает результат, но нам необходимо понимание, почему такое происходит. То же самое касается неудач. То есть, по сути, нам не важно, плюс или минус. Касательно ситуаций, когда расхождение плановых и фактических метрик не такое очевидное, смотрим на бюджет и прогнозируем, сколько еще нужно потратить на следующий шаг, и планируем к нему как правило отдельный маркетинговый бюджет.

Андрей: Тут очень близко к unit-экономике, попробую коротко в нескольких словах. Есть такое понятие, как стоимость поддержки продукта, и, соответственно, стоимость, которую платят за неё покупатель. Здесь нужно сравнить, если у нас значительно увеличивается доход, и не сильно растет стоимость поддержки, можно масштабировать. Приведу пример. Допустим, у нас есть какой-то сервис, и для его поддержки нужен ресурс. Например, один бизнес-аналитик может поддерживать 5 клиентов. Для каждого 6-го нужен новый бизнес-аналитик. Рано или поздно при масштабировании мы придем к тому, что для всех собравшихся у нас бизнес-аналитиков нужен руководитель или Lead. Это еще одна штатная единица. Потом с ростом мы поймем, что для Lead-аналитиков нужен Head, что тоже поднимет стоимость поддержки. Таким образом бюджет на это все у нас будет постоянно расти. Важно понять, в какой точке он уравняется с выручкой от продукта, дальше уже масштабировать нельзя. Здесь имеет смысл просто оставить продукт на поддержке и не привлекать в него новых пользователей.

Ура! Вы добрались до конца этого лонг-лоргрида :)

Пожалуйста, поделитесь обратной связью, как вам материал. А если вы хотите послушать подкаст или посмотреть всю инфографику, мы выходим на YouTube, Яндекс.Музыке и Spotify, где о описании есть ссылка на графический материал. Подкаст называется «Пока деньги капают».

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

Спойлер: количество букАв будет сильно короче :)