Флексить задачи приходится не только для того, чтобы успевать в срок, но ещё и чтобы не делать лишнего. Какому бизнесу понравится платить зарплату программистам, которые делают фичи, не приносящие денег?
В английском языке аббревиатура HADI расшифровывается так: Hypothesis, Action, Data, Insights.
Самый хороший способ не делать лишнего — вместо больших проектов запускать короткие итерации на основе гипотез. В книгах для менеджеров это называется циклом HADI: Гипотеза → Действие → Данные → Выводы.
В английском языке аббревиатура HADI расшифровывается так: Hypothesis, Action, Data, Insights.
Скажем, вы работаете в интернет‑магазине, и вам пришла в голову прорывная идея — пора бы наконец, сделать отзывы пользователей на страницах товаров, как у конкурентов.
Можно сразу пойти ва‑банк — отдать дизайнерам и программистам задачу сделать хорошие отзывы. Но это большая инвестиция — для отзывов нужно много инфраструктуры: продуманный интерфейс, защита от спама, панель модерации, возможность оценивать полезность отзывов, админка.
Давайте, прежде чем вкладывать деньги, попробуем сформулировать, как мы будем их возвращать:
Если одни пользователи будут оставлять отзывы на товары, а другие — их читать, то конверсия у товаров с отзывами повысится, и мы заработаем на этом больше денег.
Неплохо, но составные гипотезы проверять сложно, поэтому давайте немного упростим:
Если на страницах товаров появятся отзывы, то конверсия у этих страниц повысится.
Звучит как понятная короткая гипотеза, а значит, у нас появилась первая часть цикла HADI. Теперь сформулируем максимально быструю задачу для второй части — действие:
«Давайте сделаем статичные отзывы на 5—10 товаров, разместим их на сайте и посмотрим, как изменится конверсия».
См. также
Теперь не нужно делать сложную систему вроде админки для отзывов — достаточно отрисовать и сверстать 5—10 ХТМЛ‑страничек. Мы флексим: радикально уменьшаем глубину проработки, чтобы быстро проверить гипотезу.
См. также
Как только странички с отзывами появляются на сайте, проводим АБ‑тест. Делим аудиторию на две группы: пусть одна видит наши отзывы, а другая — не видит. Через пару недель сравним конверсию. Начали ли люди, которые читали отзывы, покупать чаще, чем люди, которые вообще не видели отзывов? Ответ на вопрос и станет третьей частью цикла — данными.
Если мы доказали гипотезу, смело ставим в разработку задачу сделать полноценные отзывы — теперь мы уверены, что не зря потратим зарплату программистов.
Пока задача в работе — проверим другую часть гипотезы: «пользователи готовы оставлять отзывы». Вдруг от нашей аудитории не имеет смысла ждать отзывов, и нам придётся самим строить отдел, который будет тестировать товары? Прогоним его по циклу HADI:
Гипотеза: наши пользователи готовы оставлять отзывы;
Проверка: делаем кнопку «оставить отзывы», которая ведёт на гугль‑форму.
Данные: сколько отзывов появилось за неделю? А на тех страницах, где были другие отзывы?
Выводы: если отзывов много, то ставим задачу в разработку.
Если проверка не проходит, вернёмся к началу и попробуем выдвинуть другую гипотезу. Может, стоит сделать письмо, которое через пару недель после покупки будет догонять пользователя и предлагать ему оставить отзыв?
P. S. Это был совет об управлении разработкой. Хотите больше знать о планировании спринтов, управлении продуктом или о настройке инфраструктуры? Присылайте вопросы.