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

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

Я Гузель Хамидуллина, системный аналитик в Positive Technologies. Хочу поделиться с вами мыслями о том, насколько важно для команды разработки понимать ценность входящих задач.

В статье расскажу о том:

• Как определить цель и ценность задачи.

• Почему в продуктовой разработке важно критическое мышление.

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

Цель и ценность задач

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

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

Приведу несколько примеров. Когда я работала в компании, разрабатывающей медицинские сервисы, из-за большого объема входящих задач не все задачи могли проходить через аналитика. Бывали ситуации, когда команда брала задачи, предложенные продактами (заказчиками) и другими заинтересованными командами, не задумываясь: а для чего эта задача? какую проблему мы решаем? действительно ли она относится к нашему проекту? (всякое бывает). В итоге большинство таких задач со временем приходилось переделывать. Яркий пример такой ситуации: работа над сайтом онлайн-записи к врачу. Продакт пришел с задачей «переделать добивки врачей». Добивка врачей — это расширение списка на выдаче врачей. Например, если не хватает акушеров в Санкт-Петербурге, добивка может включать в себя добавление акушеров из близлежащих районов. То есть, например, если вы ищете врачей по метро Пионерская в Санкт-Петербурге и врачей для выдачи недостаточно, мы «добьем» список врачами с соседних станций метро. На вопросы: а зачем переделывать?, какая ценность этой задачи? продакт почему-то ответить не смог, но команда все равно взялась за нее и сделала. Все бы ничего, но эту задачу потом переделывали раз шесть за год, так как никто так и не дошел до сути проблемы, — в итоге получился «порочный круг».

Еще один пример, из проекта финтеха: мы создали продукт для оплаты в один клик. После создания минимально жизнеспособного продукта (MVP) мы быстро добавили всю функциональность, которую предложил наш продакт для MVP 2.0, не задаваясь вопросами: а для кого эта функциональность? действительно ли это нужно? Позже на одном из демо для наших пользователей нам сказали, что эта функциональность не нужна. Оказалось, фичи, которые мы создавали, были бы полезны для крупных компаний. А нашим продуктом пользовался преимущественно малый бизнес, которому эти фичи были не нужны.

Всех этих проблем можно было бы избежать на начальных этапах разработки.

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

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

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

Здесь вам может помочь пара методов:

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

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

  — Зачем?

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

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

  — Кто стейкхолдер? Что за функциональность? Где это влияет на бизнес? (например, влияет на всех пользователей во всех регионах) Когда надо брать в работу? Почему это важно? Как будем измерять достижение цели?

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

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

Постановка может состоять из следующих блоков:

• Цель.

• Проблематика.

• Задачи.

• Критерии приемки.

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

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

Какие вопросы можно задать при приемке задачи

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

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

2. Какую ценность она дает пользователям? Вероятно, эта функциональность повышает удобство использования интернет-магазина.

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

А разве это наша зона ответственности?

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

Приведу пример из личного опыта на проекте по разработке HR-портала. Я подключилась к работе на этапе дизайна макетов, которые уже должны были идти в разработку. Большим преимуществом было то, что я была новым игроком в команде. Изучая макеты одной функции, я не понимала, что мне нужно сделать как пользователю и для чего нужна эта функциональность. Как она облегчит жизнь пользователю, если в ней черт ногу сломит? Я принесла свои вопросы продакту, и это привело к ряду пользовательских исследований, которые подтвердили, что не мне одной не ясна ценность функциональности. Все это повлекло за собой полное изменение дизайна, была выделена ценность для пользователя и сформирован более четкий пользовательский путь.

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

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

Гузель Хамидуллина

Системный аналитик департамента управления данными, Positive Technologies