Как оформлять продуктовые задачи для разработчиков
Покажите этот текст вашим джунам-продактам.
Есть много способов получить глубокие знания по продуктовому менеджменту: курсы, стажировки, книги, менторство. Про азы пишут гораздо реже.
Но базовые знания очень сильно влияют на качество работы. Вот пример: ставить задачи разработчикам нужно так, чтобы они точно понимали, с чем имеют дело. В этом материале директор по продукту Joom Анна Лазуткина делится полезной инструкцией для джунов (и не только).
Наш внутренний опрос показал, что 92% коллег страдают и работают менее продуктивно, если задачи плохо оформлены.
Перед инструкцией: зачем вообще нужны формальности при оформлении задач
Отвечаем: потому что все думают и работают по-разному
Старая добрая поговорка про лодку похожа на задачи для разработчиков: как ты таску опишешь, так она и делаться будет. Вот несколько примеров того, чем чревато плохое оформление задачи.
- Фича будет сделана не так, как задумывалось. Каждый поймет суть плохо описанной задачи по-своему. На выходе получим не теряющий актуальность мем про качели.
Да, предотвратить это должны эджайл и стендапы, рассинхрон должны заметить все участники процесса и потом должно случиться счастье. Но если эта небольшая и «очевидная» фича, то может получиться совсем не то, что ожидалось. Ведь все же было и так понятно, зачем лишний раз уточнять и обсуждать?
- Реализация фичи затянется. Если нам повезло, и задача недостаточно очевидна, нас поглотит поток вопросов. Сначала уточнит дизайнер. Потом у дизайнера уточнит разработчик, всплывет что-то еще, и они придут к продакту. Потом у разработчика уточнит тестировщик — ну вы поняли.
- Разработчики будут грустить. Или дизайнеры, или тестировщики. Описания задач — то, с чем они имеют дело каждый день. А с плохими инструментами работать неприятно.
На самом деле формальности экономят время, а не тратят его 🎉
— Почему? Ведь голосом обсудить будет гораздо быстрее!
Да, обсуждать задачи голосом важно и нужно. Но вот если не зафиксировать договоренности, через месяц их уже никто не сможет вспомнить.
— Нужно быстрее отдать задачу в разработку, ведь спринт начинается через час!
Да, и половина спринта в итоге уйдет на прояснение деталей, а вторая на переделку макетов. Начало спринта не должно быть дедлайном по заведению задач, ведь чтобы взять задачу в работу, ее стоит хотя бы обсудить и оценить.
Хорошо оформленная задача поможет не упустить детали, минимизировать вопросы и обсуждения в процессе разработки и доработки в результате этих обсуждений. А потом послужит отличной основой для оформления документации.
Надеемся, мы убедили вас в важности качественного оформления задач. Пора переходить к сути.
Базовые принципы описания задач
Есть несколько базовых принципов, которые важно держать в голове, когда вы формулируете задачу (а на самом деле — даже когда просто пишете кому-то сообщение).
1. Человек, который читает описание задачи, не находится в контексте и не проделал всю ту же мыслительную работу, что и вы.
2. Понимание предметной области у этого человека может быть не таким полным, как у вас.
3. У человека может не быть времени читать новый том «Войны и мира».
Цифра 4 теперь будет с нами до конца статьи (даже у Будды было четыре истины, чем мы хуже).
Следующая четверка – составляющие задачи. У любой задачи есть:
- название,
- цель,
- описание сути,
- технические детали.
Конечно, можно выделить куда больше составляющих, и часто они определяются какими-то внутренними процессами, но вот эти — самые общие и присутствуют всегда.
Формулировка названия задачи
Когда мы пишем название задачи, мы всегда должны помнить, какую цель обычно выполняет название. В первую очередь оно помогает нам ориентироваться в происходящем: быстро находить нужное, «фильтровать» задачи в уме. Чаще всего название мы читаем по диагонали и нам критически важно легко улавливать его суть. Каким оно должно быть?
- Кратким, чтобы не требовать от читающего лишних усилий. Если какие-то слова не несут дополнительного смысла, их точно стоит убрать (так чаще всего происходит с глаголами и прилагательными).
- Отражающим суть — из названия сразу должен быть понятен основной смысл задачи, чтобы вы с легкостью смогли даже через полгода понять, что имелось в виду.
- Понятным всем — красивые метафоры точно лучше оставить для подписей фото в инстаграм.
- Акцентирующим важное — если в задаче есть ключевые моменты, они должны быстро считываться (платформа, направление работы, родительский проект).
Предположим, суть задачи сводится к тому, чтобы отобразить скидку на товаре в корзине в e-commerce приложении.
Формулировка цели задачи
Цель задачи нужна, чтобы синхронизировать понимание того, что нам важно, и зачем мы делаем ту или иную работу. Мы хотим, чтобы на каждом этапе разработки люди были вовлечены в процесс.
Когда мы формулируем цель, мы отвечаем на вопрос, зачем мы делаем эту задачу, с точки зрения бизнеса и/или нашего пользователя. Без этого понимания мы рискуем превратить процесс разработки в конвейер по превращению тикетов в код.
Контрольный вопрос, который можно задать себе: что получит пользователь от этого? Или: какую пользу получит наша компания? Если ответа на эти вопросы нет — велика вероятность, что что-то идет не так, и делать нужно что-то другое.
Важно понимать, что цель должна отражать то, куда мы идем, но не описывать при этом, как. Она должна озвучивать гипотезу, которая лежит в основе задуманного. Вернемся к нашему примеру со скидкой в корзине.
Подходим к самому главному — описанию задачи. Снова обратимся к великолепной четверке.
Пишем коротко, по аналогии с названием. Если вы проделали какую-то дополнительную полезную работу, например, исследовали конкурентов, лучше дать ссылку на подробности.
- Пишем структурированно. Лучше разбить описание на логические блоки и выделить перечни разделов, чтобы читающему было легко ориентироваться. Скорее всего, коллеги обратятся к описанию не один раз. Им будет гораздо удобнее мысленно отмечать разделы, к которым нужно вернуться, если они будут четко обозначены в тексте.
- Даем полное описание задачи. Оно должно покрывать весь путь пользователя от начала и до конца в последовательном порядке и пояснять, что нужно сделать в редких случаях. Часто бывает удобно расписать флоу пользователя по шагам, чтобы точно ничего не упустить.
- Пишем по делу. В описании должны содержаться все необходимые вводные, чтобы читающему не нужно было ничего додумывать. В том числе контекст: очень важно проверить, что вы не начали описывать задачу с полуслова. (Помните? Читающий ее человек не проделал всю ту же мыслительную работу, что и вы).
Отдельно хочется отметить, что почти все таск трекеры поддерживают маркдаун — разметку, с помощью которой вы сможете сделать текст структурированнее и аккуратнее. Не пренебрегайте ей, потому что аккуратная разметка сильно упрощает восприятие информации. Например, если вам нужно описать несколько групп эксперимента, добавьте таблицу и распишите различия, так человек сразу будет их видеть. Если в вашей задаче много небольших кусочков, используйте чекбоксы, с ними гораздо приятнее постепенно продвигаться по большой задаче и радостно ставить галочку, когда завершена какая-то часть. Ну а про пользу шрифтов разного начертания, буллет поинтов, многоуровневых заголовков и аккуратных ссылок, пожалуй, можно лишний раз не упоминать.
Технические подробности
Ну и последний блок — технические подробности. Важно всегда фиксировать детали в задаче, чтобы никому не приходилось превращаться в Шерлока Холмса в поисках доказательств. Вот примеры того, о чем стоит подумать:
- макеты или ссылки на них,
- детали эксперимента, если он планируется,
- аналитика,
- платформы, на которых реализуется фича,
- ссылки на дизайн-доки/API,
- связанные задачи.
В целом все это, конечно, сильно зависит от ваших внутренних процессов. Просто убедитесь, что вы выложили все, что было в вашей голове. И еще один совет: настройте шаблоны, которые отражают ваши внутренние процессы, чтобы они заставляли вас описывать все важное для реализации задач. Тогда вы точно ничего не упустите.
А в завершение вот наши четыре истины, которые ведут в мир четких и понятных задач.
- Не торопитесь.
- Сокращайте и систематизируйте.
- Всегда внимательно перечитывайте задачи (а лучше несколько раз). Отвлекитесь, вырвите себя из контекста, перечитайте задачу и спросите себя — все ли понятно? Достаточно ли вводных?
- Избегайте двойных смыслов. Переформулируйте и уточните все, что можно понять неоднозначно.
Сейчас я буду как та бабка из Игры Престолов - ходить за вами и бубнить 'Позор! Позор!'
'Базовые принципы описания задач'
Самое важное не написали: каждая задача описывается из расчета быть сделанной одним человеком за один рабочий день, отсюда следуют все ограничения по объему и смыслу.
Текст задачи пишется так чтобы был понятен абсолютно обнуленному человеку - в пн после выходных народ имена свои забывает, не то что скоуп работы. В идеале без привязки к контексту вообще, как будто для нового человека на проекте пишете.
Заголовок задачи содержит четкое указание к действию: исправить-добавить-реализовать и тд.
В идеале человек получив вашу задачу вообще дальше думать не должен - сразу брать и делать. Получается такое - не всегда )
Теперь про ваш пример:
'Предположим, суть задачи сводится к тому, чтобы отобразить скидку на товаре в корзине в e-commerce приложении.'
Самая большая проблема: никак не описаны крайние состояния, т.е максимальная скидка, минимальная скидка или ее отсутствие. А это важно тк эти же состояния должны быть дальше протестированы QA.
Разработчик который будет это реализовывать гарантированно этот момент пропустит, тестировщик - тем более.
о, не заметил коммент и расписал примерно то же самое в своем :)
про один рабочий день - увы, не всегда получается настолько мелко декомпозировать задачи. При этом иногда количество подобных задач будет настолько велико, что команда быстро взбунтуется и попросит хотя бы что-то объединить. Растет количество задач = растет и количество связей между задачами. Когда на проекте очень большой бэклог и команда, это все будет челмедведосвина и павлиноуткоежа напоминать.
Я для себя взял правило про "не более 3 дней", но оно тоже субъективно очень
декомпозиция в 1 день делается для того, что бы минимизировать просранное время разрабом, если он не правильно понял задачу, плохо оценил, наткнулся на новую проблему, которая требует помощи от других людей/стейкхолдеров и т.п. = минимизировать потери.
не удивляйтесь потом, что у вас сроки релизов срываются в разы.
не удивляюсь, ведь они не срываются на более чем 3 дня уже 5 лет с разными командами :)
Сергей, подскажите, есть ли методика оценки трудозатрат?
все очень просто: есть продуктовая история, в ней есть definition of done и, если это очень важная история политически/экономически/инфраструктурно (допустим, для соблюдения SLA), то по ней еще прописана аналитика, чтобы чуть больше раскрыть разработчикам/тестировщикам, какой результат мы хотели бы получить. Если же не очень важная, то обычно хватает описания менеджером при учете, что это описание сделал хороший менеджер, а также налажена коммуникация с командой (это не всегда только общение - это и логическое, а также эмпатическое понимание менеджером, что нужно передать текстом команде для получения желаемого результата)
Далее разработчик (!) декомпозирует историю на логические блоки: как именно он будет приходить к конечному результату. Также именно он сам оценивает каждую задачу, при этом есть условное правило про 3 дня, которое я описал раньше (за которое можно выходить, но оно должно хотя бы +- контролироваться при этом)
Девлид проводит ревью (инфраструктурно он может сказать, что, например, зачем брать Kafka, когда у нас уже есть RabbitMQ), а также примерно оценивает, насколько корректно сделана оценка по трудозатратам, и может посоветовать какой-то другой способ достижения результата, который вдобавок может быть и оценен в меньшее количество трудозатрат, - тогда декомпозиция возвращается на доработку.
Менеджер также проводит ревью: насколько ему нравится такая оценка или же внезапно нужно сделать задачу быстрее, поэтому он может прописать, какие фичи готовы выбросить прямо сейчас для ускорения разработки. Я вдобавок еще технический менеджер, поэтому заодно проверяю, насколько разработчик понял основную историю/аналитику, приведет ли его путь к ее выполнению, и останусь ли я доволен результатом.
Почему именно разработчик декомпозирует историю:
1. в таком случае создается внутри команды атмосфера доверия и человечности (не менеджер с девлидом спускают "приказ" сверху, а мы, как команда, совместно идем к достижению цели, каждый участник которой чувствует себя важным звеном)
2. есть дополнительный бенефит для заказчика и менеджера, это психологический момент с коммитментом. Когда человек называет срок, он как бы морально под него коммитится и будет стараться в него попасть. Если человеку называют срок свыше без возможности выслушать его сторону, то он иногда с самого начала начинает думать о том, как бы "наказать" этого человека свыше, как правило, это сводится к факапу сроков :)
3. девлид перестает спускать приказы джуниорам с небес: улучшает каждого участника команды, при этом получая время на продумывание более важных и верхнеуровневых технических задач, которые он впоследствии отдаст менеджеру на приоритизацию
Побольше про не очень позитивное отношение к дроблению на атомарные задачи, описано тут: https://habr.com/ru/post/524678/
Был очень рад менеджерить проект, в котором работает автор этой статьи.
Спасибо за такой развернутый ответ. Для начала прочту прилагаемую статью