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

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

Самый важный вопрос продуктовой разработки

Самый важный вопрос к любой задаче, возникающей в продуктовой разработке — “ЗАЧЕМ?”.

• Зачем мы делаем эту функцию?
• Зачем нам нужен редизайн?
• Зачем нам продвигаться в соцсетях?
• Зачем … и т. д.

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

В идеале вопросом “Зачем?” должны задаваться все члены продуктовой команды.

Если этого нет, то могут возникать следующие проблемы:

1. Механическое решение задач — что дали, то и делаю.
2. Отсутствие желания влиять на решение — есть менеджер, он и решает.
3. Отсутствие эмпатии к проблеме, которую решает задача.
4. Отсутствие ответственности — ты придумал решение, ты и отвечай.

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

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

Общий фреймворк постановки задачи

Фреймворк можно описать следующим образом:

1. Контекст — необходимо донести до исполнителя всё, что вокруг задачи: пользовательские истории, связанные с задачей; схожие проблемы, решаемые раньше; почему задачу не сделали прежде и т. п.
2. Цель — это наше “Зачем”. Зачем мы вообще решаем задачу: какую и чью боль хотим решить, когда её надо решить.
3. Решение — возможное решение или набор решений задачи. Формат изложения зависит от роли исполнителя. Важно донести, что на решение можно влиять. При этом влияние должно быть при ознакомлении с задачей, а не после реализации.

Укрупнённая структура описания задачи

Если вы ещё не выработали свою структуру постановки задач, то можно воспользоваться следующей:

1. Источники проблематики и контекст — детально описываем контекст задачи: какие были обращения, кто заказал, какие уже были подходы к решению и так далее.
2. Цель выполнения работ — какие боли в итоге должна решить задача.
3. Ожидания от результата — каким менеджер видит итог решения задачи.
4. Требования к работам — описание одного или нескольких вариантов решения задачи.
5. Взаимосвязь с существующими функциями — как отразится на существующих функциях, о каких связях не стоит забывать.
6. Какую документацию надо подготовить по итогам.
7. Как будет приниматься задача, тестирование итога.
8. Как будет проходить внедрение — возможно, нужны предварительные рассылки по пользователям или миграции содержимого БД, или ещё что-либо.

Работа с конкретными направлениями задач

В процессе разработки или развития продукта возникают задачи, решать которые предстоит разным командным ролям.

Аналитика и бизнес-исследование

Контекст

Формулировка гипотез и job stories по форме кто-что-зачем. Для того, чтобы поставить задачу, нужно:

1. Взять известную или нащупать новую незакрытую потребность.
2. Придумать, как её закрыть (идея возникает именно на этом этапе).
3. Запросить у аналитика определенные цифры и метрики для проверки потребности, а также дизайн эксперимента для проверки того, насколько реализация идеи закроет потребность. Зачастую этот этап продакт-менеджер проходит самостоятельно.
4. В случае успешного эксперимента начать реализовывать идею.

Цель

Цель описывается гипотезами, job stories или user stories (подробнее тут: https://habr.com/ru/company/otus/blog/482066/). Все подвергается сомнению и приоритезации на уровне здравого смысла, опыта и понимания уже существующей аналитики по продукту.

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

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

Решение

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

Аналитика — всегда неопределенность. Данных есть от силы 40 %, из них достоверных — 10-15%, а вывод надо дать с "гарантией", что по крайней мере не будет не то, что противоположного исхода, а отклонения от текущей ситуации менее, чем наполовину.

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

1. Анализ изменений KPI по мере развития продукта.
2. Обнаружение и изучение аномалий.
3. Поиск «узких мест» и точек роста.
4. И прогнозирование, чего бы там теория не говорила — то, что и хотят получить часто, все остальное могут и не читать.

Продуктовый дизайн и проектирование

Контекст

Продуктовый дизайнер должен помогать менеджеру продукта определять, исследовать и подтверждать проблему, а также проектировать, создавать, тестировать и внедрять дизайн-решение проблемы. Чтобы действовать продуктово, дизайнер должен понимать, зачем вы решили создать продукт, и какие задачи тот будет решать.

Если дизайнер концентрирует своё внимание исключительно на UI (структура, цвета кнопок, расположении блоков и т. п.) и не часто задаётся главным продуктовым вопросом “Зачем?”, значит либо дизайнер не продуктовый, либо контекст и цели задач не донесены.

В дизайн-задачах контекстом являются:

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

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

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

Цель

Для демонстрации цели отлично подходят выкладки аналитики по проблемам и хорошим цифрам, CJM и другие описания сценариев действий пользователей. Также дизайнеру важно доносить, что будет критерием успеха нового продукта или фичи (по OKR, например).

Решение

Ранее мы писали, как правильно общаться с дизайнером — https://t.me/FreshProductGo/22. Максимально детально опишите требования к макету, который хотите получить. Если в макете присутствуют текстовые элементы (лендинг, email, баннеры и прочее) — обязательно предоставляйте вычитанные и финальные варианты текстов. Лично обсудите все требования с дизайнером, проработайте поступающие вопросы и зафиксируйте итоги обсуждения в требованиях к задаче. Также следует показать всю структуру решения (на MindMap, например), анализ конкурентов (референсы). Пригодятся комментарии от верстальщика.

Вёрстка (front end)

Контекст

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

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

Цель

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

Решение

Верстальщику важно понимать, как должны «вести себя» блоки сайта при добавлении/удалении текста. А менеджеру важно учесть, что изменение дизайна (а мы здесь картинку подвинем или классическое поиграйте со шрифтами) на стадии верстки повлечет за собой увеличение времени работы исполнителя.

Вопросы, которые должны быть закрыты при постановке задач:

1) как будут работать главные элементы?

2) как будут отображаться формы/списки/ссылки/кнопки/изображения и т. п.?

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

3) для каких устройств и в каких браузерах будет работать сайт и приложение?

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

4) Какие цвета / шрифты используются на сайте и приложении?

Дизайнер совместно с макетами сайта должен предоставить палитру используемых цветов и прикрепить используемые шрифты/иконки. Иначе верстальщик никогда не поймет, «что же хотел сказать художник».

Разработка (back end)

Чем структурированнее будет постановка, тем лучше и удобнее для разработчика.

Контекст:

1. Те же пользовательские истории, что для дизайнера и верстальщика.
2. Принципиальный механизм решения, если он есть.
3. Рисунок/схема с потоками информации от пользователей к системе и обратно (блок-схемы взаимодействия сервисов, сценарии пользователя).

Цель

Нужно рассказать, о чем проект и как им будут пользоваться:

1. Общее описание целей.
2. Какие задачи должен решать проект, какие показатели он должен изменить (технические).
3. На кого проект ориентирован (пользователи с какой квалификацией будут им пользоваться).
4. На каких платформах он должен работать.
5. С какими системами проект должен быть интегрирован (автоматически получать или передавать данные).
6. Требования к функциям проекта.
7. Требования к ролям пользователей.

Решение

При постановке задачи потребуется закрыть следующие вопросы (конкретика зависит от этапа развития — делаем новый продукт или развиваем существующий):

1. Версии продукта (веб-версия и другие).
2. Типы страниц и элементов страниц сайта (описание основных функциональных страниц и ключевых элементов).
3. Типы (роли) пользователей (структурированное описание всех ролей: пул возможностей и ограничений).
4. Пользовательские сценарии (User story: кто и каким образом взаимодействуем со всем функционалом сайта).
5. Структура данных (клиенты, субъекты инфраструктуры и прочее).
6. Перечень интеграций в рамках задачи.
7. Функциональные требования к сервисам.
8. Нефункциональные требования к сервисам.
9. Дизайн и верстка. Общее описание.
10. Требования к интеграциям.
11. Архитектура сервисов.
12. Эргономика и техническая эстетика (макеты визуальной составляющей системы и прочее).
13. Требования к тестированию.
14. Этапы работ по созданию сервиса.
15. Порядок контроля и приемки сервиса.
16. Дальнейшая поддержка продукта и дорожная карта внедрения.

В качестве вывода:

1. Лучше потратить больше времени на проработку и постановку задачи, чем потом тратить время на переделку результата.
2. Каждый участник продуктовой команды должен на бизнес-уровне понимать, зачем он делает текущую задачу.
3. В задачах крайне важен контекст и все знания, которые так или иначе относятся к причинам, по которым задача вообще появилась.

Статья подготовлена в соавторстве с Михаилом Грековым.