Rivalry2

HTML Diff

1 added 1 removed

Original 2026-01-01

Modified 2026-03-10

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

2 <h2>Самый важный вопрос продуктовой разработки</h2>

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

4 <ul><li>Зачем мы делаем эту функцию?</li>

5 <li>Зачем нам нужен редизайн?</li>

6 <li>Зачем нам продвигаться в соцсетях?</li>

7 <li>Зачем … и т. д.</li>

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

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

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

11 <ol><li>Механическое решение задач - что дали, то и делаю.</li>

12 <li>Отсутствие желания влиять на решение - есть менеджер, он и решает.</li>

13 <li>Отсутствие эмпатии к проблеме, которую решает задача.</li>

14 <li>Отсутствие ответственности - ты придумал решение, ты и отвечай.</li>

15 </ol><p>Как сделать так, чтобы все участники команды мыслили продуктово и проникались задачами?</p>

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

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

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

19 <ol><li><strong>Контекст</strong>- необходимо донести до исполнителя всё, что вокруг задачи: пользовательские истории, связанные с задачей; схожие проблемы, решаемые раньше; почему задачу не сделали прежде и т. п.</li>

20 <li><strong>Цель</strong>- это наше “Зачем”. Зачем мы вообще решаем задачу: какую и чью боль хотим решить, когда её надо решить.</li>

21 <li><strong>Решение</strong>- возможное решение или набор решений задачи. Формат изложения зависит от роли исполнителя. Важно донести, что на решение можно влиять. При этом влияние должно быть при ознакомлении с задачей, а не после реализации.</li>

22 </ol><h2>Укрупнённая структура описания задачи</h2>

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

24 <ol><li>Источники проблематики и контекст - детально описываем контекст задачи: какие были обращения, кто заказал, какие уже были подходы к решению и так далее.</li>

25 <li>Цель выполнения работ - какие боли в итоге должна решить задача.</li>

26 <li>Ожидания от результата - каким менеджер видит итог решения задачи.</li>

27 <li>Требования к работам - описание одного или нескольких вариантов решения задачи.</li>

28 <li>Взаимосвязь с существующими функциями - как отразится на существующих функциях, о каких связях не стоит забывать.</li>

29 <li>Какую документацию надо подготовить по итогам.</li>

30 <li>Как будет приниматься задача, тестирование итога.</li>

31 <li>Как будет проходить внедрение - возможно, нужны предварительные рассылки по пользователям или миграции содержимого БД, или ещё что-либо.</li>

32 </ol><h2>Работа с конкретными направлениями задач</h2>

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

34 <h3>Аналитика и бизнес-исследование</h3>

35 <h4>Контекст</h4>

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

37 <ol><li>Взять известную или нащупать новую незакрытую потребность.</li>

38 <li>Придумать, как её закрыть (идея возникает именно на этом этапе).</li>

39 <li>Запросить у аналитика определенные цифры и метрики для проверки потребности, а также дизайн эксперимента для проверки того, насколько реализация идеи закроет потребность. Зачастую этот этап продакт-менеджер проходит самостоятельно.</li>

40 <li>В случае успешного эксперимента начать реализовывать идею.</li>

41 </ol><h4>Цель</h4>

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

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

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

45 <h4>Решение</h4>

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

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

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

49 <ol><li>Анализ изменений KPI по мере развития продукта.</li>

50 <li>Обнаружение и изучение аномалий.</li>

51 <li>Поиск "узких мест" и точек роста.</li>

52 <li>И прогнозирование, чего бы там теория не говорила - то, что и хотят получить часто, все остальное могут и не читать.</li>

53 </ol><h3>Продуктовый дизайн и проектирование</h3>

54 <h4>Контекст</h4>

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

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

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

58 <ul><li>технические условия, в которых планируется эксплуатировать дизайн-решения: платформы, скорость интернета у пользователей, условия окружающей среды;</li>

59 <li>привычки и пристрастия пользователей, если они могут быть известны;</li>

60 <li>наличие функциональных особенностей у пользователей - например, ограничения по зрению, слуху;</li>

61 <li>языковые локализации, в которых планируется эксплуатировать решения;</li>

62 - <li>обращения в поддержку, отзывы и прочее, если они есть и связаны с решаемой з��дачей;</li>

62 + <li>обращения в поддержку, отзывы и прочее, если они есть и связаны с решаемой задачей;</li>

63 <li>аналогичные визуальные решения, тренды.</li>

64 </ul><p>Чем сильнее дизайнер сможет понять мотивации пользователя, его ограничения и способы взаимодействия с продуктом - тем более продуманное решение сможет выдать.</p>

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

66 <h4>Цель</h4>

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

68 <h4>Решение</h4>

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

70 <h3>Вёрстка (front end)</h3>

71 <h4>Контекст</h4>

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

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

74 <h4>Цель</h4>

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

76 <h4>Решение</h4>

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

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

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

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

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

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

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

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

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

86 <h3>Разработка (back end)</h3>

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

88 <h4>Контекст:</h4>

89 <ol><li>Те же пользовательские истории, что для дизайнера и верстальщика.</li>

90 <li>Принципиальный механизм решения, если он есть.</li>

91 <li>Рисунок/схема с потоками информации от пользователей к системе и обратно (блок-схемы взаимодействия сервисов, сценарии пользователя).</li>

92 </ol><h4>Цель</h4>

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

94 <ol><li>Общее описание целей.</li>

95 <li>Какие задачи должен решать проект, какие показатели он должен изменить (технические).</li>

96 <li>На кого проект ориентирован (пользователи с какой квалификацией будут им пользоваться).</li>

97 <li>На каких платформах он должен работать.</li>

98 <li>С какими системами проект должен быть интегрирован (автоматически получать или передавать данные).</li>

99 <li>Требования к функциям проекта.</li>

100 <li>Требования к ролям пользователей.</li>

101 </ol><h4>Решение</h4>

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

103 <ol><li>Версии продукта (веб-версия и другие).</li>

104 <li>Типы страниц и элементов страниц сайта (описание основных функциональных страниц и ключевых элементов).</li>

105 <li>Типы (роли) пользователей (структурированное описание всех ролей: пул возможностей и ограничений).</li>

106 <li>Пользовательские сценарии (User story: кто и каким образом взаимодействуем со всем функционалом сайта).</li>

107 <li>Структура данных (клиенты, субъекты инфраструктуры и прочее).</li>

108 <li>Перечень интеграций в рамках задачи.</li>

109 <li>Функциональные требования к сервисам.</li>

110 <li>Нефункциональные требования к сервисам.</li>

111 <li>Дизайн и верстка. Общее описание.</li>

112 <li>Требования к интеграциям.</li>

113 <li>Архитектура сервисов.</li>

114 <li>Эргономика и техническая эстетика (макеты визуальной составляющей системы и прочее).</li>

115 <li>Требования к тестированию.</li>

116 <li>Этапы работ по созданию сервиса.</li>

117 <li>Порядок контроля и приемки сервиса.</li>

118 <li>Дальнейшая поддержка продукта и дорожная карта внедрения.</li>

119 </ol><h2>В качестве вывода:</h2>

120 <ol><li>Лучше потратить больше времени на проработку и постановку задачи, чем потом тратить время на переделку результата.</li>

121 <li>Каждый участник продуктовой команды должен на бизнес-уровне понимать, зачем он делает текущую задачу.</li>

122 <li>В задачах крайне важен контекст и все знания, которые так или иначе относятся к причинам, по которым задача вообще появилась.</li>

123 </ol><p><em>Статья подготовлена в соавторстве с Михаилом Грековым</em>.</p>

124