Записка про цели и ценность задач в разработке

У вас было такое ощущение как у участника команды разработки почему некоторые функции в приложениях не используются, а на их реализацию было заложено несколько спринтов? Испытывали при этом ощущение бессилия или бессмысленности своей работы? Или, напротив — у вас возникало желание сделать лучше? Или, может быть, вам сейчас приходится выполнять задачи, в которых вы сами не видите ценности для пользователя? Как избежать подобных ситуаций? Узнаете из записки про цели и ценность задач в разработке.

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

Цель — это то, чего стремится достичь заказчик. Ценность же определяет, что конкретно получит пользователь. Эти понятия могут различаться. Например, заказчик просит «разработать возможность самостоятельного оформления заказа гостем в ресторане без привлечения официанта». Его цель — разгрузить официантов в часы полной посадки в зале, увеличить конверсию покупок на определённое количество процентов. Ценность этой функциональности заключается в том, что определённой части клиентов будет удобно оформлять заказы через приложение без взаимодействия с официантом.

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

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

Важно дойти до самой сути! Пока вы не поняли зачем это нужно — задавайте вопросы. На этапе аналитики глупых вопросов не бывает!

Примените известный метод пяти «почему». Смысл в том, чтобы задать вопрос «почему?» как минимум пять раз, чтобы дойти до истины. В продуктовой разработке попробуйте заменить «почему» на «зачем».

Метод 5W1H — задавать вопросы «кто?», «что?», «где?», «когда?», «почему?» и «как?», чтобы понять и уточнить проблему:

— Нам нужно добавить функциональность Х.

Что за функциональность? Как это влияет на бизнес? Когда надо брать в работу? Почему это важно? Как будем измерять достижение цели?

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

Хорошей практикой является использование бизнес-заказчиками так называемых «постановок». Постановка — это документ, который приносит заказчик команде. По сути валидация задачи перед её представлением команде. Заказчики на этом этапе чётко определять все необходимые пункты.

Постановка задачи команде:

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

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

Как сформулировать необходимые вопросы при получении задач?

Почему даже при очень подробном тз в результате релиза может случиться факап и команде приходится откатываться назад и многое переделывать? Что больше влияет на результат — подробное ТЗ или погружение в боли пользователей?

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

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

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

Возвращаемся к постановке вопроса «Зачем?», которым должны задаваться все члены продуктовой команды.

Без обсуждения «Зачем?» следует:

Следующим шагом станут очевидные и в то же время необходимые вопросы:

Как сделать так, чтобы все участники команды критически мыслили и проникались задачами?

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