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

Покажите этот текст вашим джунам-продактам.

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

Но базовые знания очень сильно влияют на качество работы. Вот пример: ставить задачи разработчикам нужно так, чтобы они точно понимали, с чем имеют дело. В этом материале директор по продукту Joom Анна Лазуткина делится полезной инструкцией для джунов (и не только).

Наш внутренний опрос показал, что 92% коллег страдают и работают менее продуктивно, если задачи плохо оформлены.

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

• Фича будет сделана не так, как задумывалось. Каждый поймет суть плохо описанной задачи по-своему. На выходе получим не теряющий актуальность мем про качели.
  

Да, предотвратить это должны эджайл и стендапы, рассинхрон должны заметить все участники процесса и потом должно случиться счастье. Но если эта небольшая и «очевидная» фича, то может получиться совсем не то, что ожидалось. Ведь все же было и так понятно, зачем лишний раз уточнять и обсуждать?

• Реализация фичи затянется. Если нам повезло, и задача недостаточно очевидна, нас поглотит поток вопросов. Сначала уточнит дизайнер. Потом у дизайнера уточнит разработчик, всплывет что-то еще, и они придут к продакту. Потом у разработчика уточнит тестировщик — ну вы поняли.
• Разработчики будут грустить. Или дизайнеры, или тестировщики. Описания задач — то, с чем они имеют дело каждый день. А с плохими инструментами работать неприятно.
  

— Почему? Ведь голосом обсудить будет гораздо быстрее!

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

— Нужно быстрее отдать задачу в разработку, ведь спринт начинается через час!

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

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

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

Есть несколько базовых принципов, которые важно держать в голове, когда вы формулируете задачу (а на самом деле — даже когда просто пишете кому-то сообщение).

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

2. Понимание предметной области у этого человека может быть не таким полным, как у вас.

3. У человека может не быть времени читать новый том «Войны и мира».

Цифра 4 теперь будет с нами до конца статьи (даже у Будды было четыре истины, чем мы хуже).

Следующая четверка – составляющие задачи. У любой задачи есть:

• название,
• цель,
• описание сути,
• технические детали.

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

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

• Кратким, чтобы не требовать от читающего лишних усилий. Если какие-то слова не несут дополнительного смысла, их точно стоит убрать (так чаще всего происходит с глаголами и прилагательными).

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

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

Цель задачи нужна, чтобы синхронизировать понимание того, что нам важно, и зачем мы делаем ту или иную работу. Мы хотим, чтобы на каждом этапе разработки люди были вовлечены в процесс.

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

Контрольный вопрос, который можно задать себе: что получит пользователь от этого? Или: какую пользу получит наша компания? Если ответа на эти вопросы нет — велика вероятность, что что-то идет не так, и делать нужно что-то другое.

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

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

• Пишем коротко, по аналогии с названием. Если вы проделали какую-то дополнительную полезную работу, например, исследовали конкурентов, лучше дать ссылку на подробности.

• Пишем структурированно. Лучше разбить описание на логические блоки и выделить перечни разделов, чтобы читающему было легко ориентироваться. Скорее всего, коллеги обратятся к описанию не один раз. Им будет гораздо удобнее мысленно отмечать разделы, к которым нужно вернуться, если они будут четко обозначены в тексте.
• Даем полное описание задачи. Оно должно покрывать весь путь пользователя от начала и до конца в последовательном порядке и пояснять, что нужно сделать в редких случаях. Часто бывает удобно расписать флоу пользователя по шагам, чтобы точно ничего не упустить.
• Пишем по делу. В описании должны содержаться все необходимые вводные, чтобы читающему не нужно было ничего додумывать. В том числе контекст: очень важно проверить, что вы не начали описывать задачу с полуслова. (Помните? Читающий ее человек не проделал всю ту же мыслительную работу, что и вы).

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

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

• макеты или ссылки на них,

• детали эксперимента, если он планируется,
• аналитика,
• платформы, на которых реализуется фича,
• ссылки на дизайн-доки/API,
• связанные задачи.

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

А в завершение вот наши четыре истины, которые ведут в мир четких и понятных задач.

• Не торопитесь.
• Сокращайте и систематизируйте.
• Всегда внимательно перечитывайте задачи (а лучше несколько раз). Отвлекитесь, вырвите себя из контекста, перечитайте задачу и спросите себя — все ли понятно? Достаточно ли вводных?
• Избегайте двойных смыслов. Переформулируйте и уточните все, что можно понять неоднозначно.

#joom #продукт