Как оформлять продуктовые задачи для разработчиков
Покажите этот текст вашим джунам-продактам.
Есть много способов получить глубокие знания по продуктовому менеджменту: курсы, стажировки, книги, менторство. Про азы пишут гораздо реже.
Но базовые знания очень сильно влияют на качество работы. Вот пример: ставить задачи разработчикам нужно так, чтобы они точно понимали, с чем имеют дело. В этом материале директор по продукту Joom Анна Лазуткина делится полезной инструкцией для джунов (и не только).
Наш внутренний опрос показал, что 92% коллег страдают и работают менее продуктивно, если задачи плохо оформлены.
Перед инструкцией: зачем вообще нужны формальности при оформлении задач
Отвечаем: потому что все думают и работают по-разному
Старая добрая поговорка про лодку похожа на задачи для разработчиков: как ты таску опишешь, так она и делаться будет. Вот несколько примеров того, чем чревато плохое оформление задачи.
- Фича будет сделана не так, как задумывалось. Каждый поймет суть плохо описанной задачи по-своему. На выходе получим не теряющий актуальность мем про качели.
Да, предотвратить это должны эджайл и стендапы, рассинхрон должны заметить все участники процесса и потом должно случиться счастье. Но если эта небольшая и «очевидная» фича, то может получиться совсем не то, что ожидалось. Ведь все же было и так понятно, зачем лишний раз уточнять и обсуждать?
- Реализация фичи затянется. Если нам повезло, и задача недостаточно очевидна, нас поглотит поток вопросов. Сначала уточнит дизайнер. Потом у дизайнера уточнит разработчик, всплывет что-то еще, и они придут к продакту. Потом у разработчика уточнит тестировщик — ну вы поняли.
- Разработчики будут грустить. Или дизайнеры, или тестировщики. Описания задач — то, с чем они имеют дело каждый день. А с плохими инструментами работать неприятно.
На самом деле формальности экономят время, а не тратят его 🎉
— Почему? Ведь голосом обсудить будет гораздо быстрее!
Да, обсуждать задачи голосом важно и нужно. Но вот если не зафиксировать договоренности, через месяц их уже никто не сможет вспомнить.
— Нужно быстрее отдать задачу в разработку, ведь спринт начинается через час!
Да, и половина спринта в итоге уйдет на прояснение деталей, а вторая на переделку макетов. Начало спринта не должно быть дедлайном по заведению задач, ведь чтобы взять задачу в работу, ее стоит хотя бы обсудить и оценить.
Хорошо оформленная задача поможет не упустить детали, минимизировать вопросы и обсуждения в процессе разработки и доработки в результате этих обсуждений. А потом послужит отличной основой для оформления документации.
Надеемся, мы убедили вас в важности качественного оформления задач. Пора переходить к сути.
Базовые принципы описания задач
Есть несколько базовых принципов, которые важно держать в голове, когда вы формулируете задачу (а на самом деле — даже когда просто пишете кому-то сообщение).
1. Человек, который читает описание задачи, не находится в контексте и не проделал всю ту же мыслительную работу, что и вы.
2. Понимание предметной области у этого человека может быть не таким полным, как у вас.
3. У человека может не быть времени читать новый том «Войны и мира».
Поэтому мы должны помнить четыре слова, определяющие успех передачи информации:
• коротко,
• структурировано,
• полно,
• по делу.
Цифра 4 теперь будет с нами до конца статьи (даже у Будды было четыре истины, чем мы хуже).
Следующая четверка – составляющие задачи. У любой задачи есть:
- название,
- цель,
- описание сути,
- технические детали.
Конечно, можно выделить куда больше составляющих, и часто они определяются какими-то внутренними процессами, но вот эти — самые общие и присутствуют всегда.
Формулировка названия задачи
Когда мы пишем название задачи, мы всегда должны помнить, какую цель обычно выполняет название. В первую очередь оно помогает нам ориентироваться в происходящем: быстро находить нужное, «фильтровать» задачи в уме. Чаще всего название мы читаем по диагонали и нам критически важно легко улавливать его суть. Каким оно должно быть?
- Кратким, чтобы не требовать от читающего лишних усилий. Если какие-то слова не несут дополнительного смысла, их точно стоит убрать (так чаще всего происходит с глаголами и прилагательными).
- Отражающим суть — из названия сразу должен быть понятен основной смысл задачи, чтобы вы с легкостью смогли даже через полгода понять, что имелось в виду.
- Понятным всем — красивые метафоры точно лучше оставить для подписей фото в инстаграм.
- Акцентирующим важное — если в задаче есть ключевые моменты, они должны быстро считываться (платформа, направление работы, родительский проект).
Предположим, суть задачи сводится к тому, чтобы отобразить скидку на товаре в корзине в e-commerce приложении.
Формулировка цели задачи
Цель задачи нужна, чтобы синхронизировать понимание того, что нам важно, и зачем мы делаем ту или иную работу. Мы хотим, чтобы на каждом этапе разработки люди были вовлечены в процесс.
Когда мы формулируем цель, мы отвечаем на вопрос, зачем мы делаем эту задачу, с точки зрения бизнеса и/или нашего пользователя. Без этого понимания мы рискуем превратить процесс разработки в конвейер по превращению тикетов в код.
Контрольный вопрос, который можно задать себе: что получит пользователь от этого? Или: какую пользу получит наша компания? Если ответа на эти вопросы нет — велика вероятность, что что-то идет не так, и делать нужно что-то другое.
Важно понимать, что цель должна отражать то, куда мы идем, но не описывать при этом, как. Она должна озвучивать гипотезу, которая лежит в основе задуманного. Вернемся к нашему примеру со скидкой в корзине.
Подходим к самому главному — описанию задачи. Снова обратимся к великолепной четверке.
Пишем коротко, по аналогии с названием. Если вы проделали какую-то дополнительную полезную работу, например, исследовали конкурентов, лучше дать ссылку на подробности.
- Пишем структурированно. Лучше разбить описание на логические блоки и выделить перечни разделов, чтобы читающему было легко ориентироваться. Скорее всего, коллеги обратятся к описанию не один раз. Им будет гораздо удобнее мысленно отмечать разделы, к которым нужно вернуться, если они будут четко обозначены в тексте.
- Даем полное описание задачи. Оно должно покрывать весь путь пользователя от начала и до конца в последовательном порядке и пояснять, что нужно сделать в редких случаях. Часто бывает удобно расписать флоу пользователя по шагам, чтобы точно ничего не упустить.
- Пишем по делу. В описании должны содержаться все необходимые вводные, чтобы читающему не нужно было ничего додумывать. В том числе контекст: очень важно проверить, что вы не начали описывать задачу с полуслова. (Помните? Читающий ее человек не проделал всю ту же мыслительную работу, что и вы).
Отдельно хочется отметить, что почти все таск трекеры поддерживают маркдаун — разметку, с помощью которой вы сможете сделать текст структурированнее и аккуратнее. Не пренебрегайте ей, потому что аккуратная разметка сильно упрощает восприятие информации. Например, если вам нужно описать несколько групп эксперимента, добавьте таблицу и распишите различия, так человек сразу будет их видеть. Если в вашей задаче много небольших кусочков, используйте чекбоксы, с ними гораздо приятнее постепенно продвигаться по большой задаче и радостно ставить галочку, когда завершена какая-то часть. Ну а про пользу шрифтов разного начертания, буллет поинтов, многоуровневых заголовков и аккуратных ссылок, пожалуй, можно лишний раз не упоминать.
Технические подробности
Ну и последний блок — технические подробности. Важно всегда фиксировать детали в задаче, чтобы никому не приходилось превращаться в Шерлока Холмса в поисках доказательств. Вот примеры того, о чем стоит подумать:
- макеты или ссылки на них,
- детали эксперимента, если он планируется,
- аналитика,
- платформы, на которых реализуется фича,
- ссылки на дизайн-доки/API,
- связанные задачи.
В целом все это, конечно, сильно зависит от ваших внутренних процессов. Просто убедитесь, что вы выложили все, что было в вашей голове. И еще один совет: настройте шаблоны, которые отражают ваши внутренние процессы, чтобы они заставляли вас описывать все важное для реализации задач. Тогда вы точно ничего не упустите.
А в завершение вот наши четыре истины, которые ведут в мир четких и понятных задач.
- Не торопитесь.
- Сокращайте и систематизируйте.
- Всегда внимательно перечитывайте задачи (а лучше несколько раз). Отвлекитесь, вырвите себя из контекста, перечитайте задачу и спросите себя — все ли понятно? Достаточно ли вводных?
- Избегайте двойных смыслов. Переформулируйте и уточните все, что можно понять неоднозначно.