{"id":14262,"url":"\/distributions\/14262\/click?bit=1&hash=8ff33b918bfe3f5206b0198c93dd25bdafcdc76b2eaa61d9664863bd76247e56","title":"\u041f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u0435 \u041c\u043e\u0441\u043a\u0432\u0435 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u044e \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u0435 \u0434\u043e 1,5 \u043c\u043b\u043d \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"726c984a-5b07-5c75-81f7-6664571134e6"}

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

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

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

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

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

Перед инструкцией: зачем вообще нужны формальности при оформлении задач

Отвечаем: потому что все думают и работают по-разному

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

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

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

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

На самом деле формальности экономят время, а не тратят его 🎉

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

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

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

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

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

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

Базовые принципы описания задач

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

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

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

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

Поэтому мы должны помнить четыре слова, определяющие успех передачи информации:

• коротко,
• структурировано,
• полно,
• по делу.

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

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

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

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

Формулировка названия задачи

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

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

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

Формулировка цели задачи

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

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

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

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

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

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

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

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

Технические подробности

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

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

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

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

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

Ну и, по традиции, — опрос

Как выглядят задачи у вас в команде?
Очень аккуратные и подробные — мы те еще зануды.
Всякое бывает, иногда и заголовку рады.
Показать результаты
Переголосовать
Проголосовать
0
55 комментариев
Написать комментарий...
Alex Chernyshev

Сейчас я буду как та бабка из Игры Престолов - ходить за вами и бубнить 'Позор! Позор!'

'Базовые принципы описания задач'
Самое важное не написали: каждая задача описывается из расчета быть сделанной одним человеком за один рабочий день, отсюда следуют все ограничения по объему и смыслу.

Текст задачи пишется так чтобы был понятен абсолютно обнуленному человеку - в пн после выходных народ имена свои забывает, не то что скоуп работы.  В идеале без привязки к контексту вообще, как будто для нового человека на проекте пишете.

Заголовок задачи содержит четкое указание к действию: исправить-добавить-реализовать и тд.
В идеале человек получив вашу задачу вообще дальше думать не должен - сразу брать и делать. Получается такое - не всегда )

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

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

Ответить
Развернуть ветку
Anna Lazutkina

Да, очень верные дополнения, спасибо! В статье фокусировалась больше на продуктовых задачах:
- исхожу из того, что продуктовая задача по дефолту про "сделать", а не "исправить"/"протестировать"
- декомпозиция на более мелкие таски (1 задача = 1 день) остается на разработке

Мы в Joom очень стараемся, чтобы люди на всех этапах были вовлечены в происходящее и продакт не декомпозировал все до мельчайших деталей (он и не сможет сделать это так, как будет удобно разработке)

Ну и примеры были утрированы и сокращены :) Для крайних состояний можно даже отдельный блок в шаблоне сделать, чтобы их не упускать (я, признаюсь, тут упустила и не обратила на это должного внимания в статье)

Ответить
Развернуть ветку
1 комментарий
Mercator

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

Ответить
Развернуть ветку
4 комментария
Sergei Zotov

о, не заметил коммент и расписал примерно то же самое в своем :)

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

Я для себя взял правило про "не более 3 дней", но оно тоже субъективно очень

Ответить
Развернуть ветку
22 комментария
Sergei Zotov
[Корзина] Скидка на карточке товара

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

В дополнение "[Корзина]" - это скорее либо лейбл/тег, либо вообще какой-то эпик.

Я хотел было сформулировать свой идеальный заголовок, но ваше описание тоже не до конца полное:

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

Отобразить скидку на товаре - это:
1. установить скидку в конкретном заказе конкретного клиента?
2. исправить визуальное отображение скидки?
3. разработать функциональность отображения скидки на товаре в корзине?

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

Ответить
Развернуть ветку
Mercator

Абсолютно согласна, что задача должна формулироваться в терминах действия. Что это за задача «скидка в корзине». Что «скидка»? Что с ней делать? Мама говорит ребенку «хлеб». Что хлеб? Купить? Порезать? Выбросить испорченный? Отличная постановка задачи. Я грущу.

Ответить
Развернуть ветку
Anna Lazutkina

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

Ответить
Развернуть ветку
Anton Z.

у меня глаза кровоточат. вы SMART до 4 пунктов урезали? а до базовых user stories/JTBD так и не дошли? ну хоть критерии приемки минимально  делаете, правда, похоже не знаете зачем...

Ответить
Развернуть ветку
Анна Максимовна

Поддерживаю. Стоило сначала исследовать существующие техники: User Stories, соответствующие INVEST-критериям, и Acceptance Criteria, по необходимости раскрытые в виде сценариев на Gherkin. US уже больше 15 лет 🤦‍♀️

Ответить
Развернуть ветку
Anton Lazovskiy

Плюсану, открыл почитать лафйхаки и посмотреть на лучшие практики, в итоге нашел поинты: пиши понятный заголовок и описание (да ладно?!) с абсолютно никакими (частично некорректными) примерами.
Ощущение, что теорию и ту автор не совсем хорошо знает и понимает...

Ответить
Развернуть ветку
Василий Степанов

как дополнение
https://vc.ru/marketing/72733-kak-pisat-pisma-s-armeyskoy-tochnostyu-praktika-amerikanskih-vvs

Честно бомбит насколько люди наплевательски относятся к постановке задачи/описанию возникшей проблемы не экономя ни свое время, ни время исполнителя.

Ответить
Развернуть ветку
Dmitriy Alekperov

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

Ответить
Развернуть ветку
Ирина Зиницина

Очень правильные вещи написаны, многие опытные менеджеры не делают описания к задачкам, что уж говорить про джунов :)

Ответить
Развернуть ветку
Sergei Zotov

Смело ставьте таким какой-нибудь Won’t fix или Incomplete или Rejected/Cancelled - что-то примерно такое, смотря что у вас в вашей системе управления проектами добавлено. Можно просто закрыть с комментарием о добавлении описания.

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

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

Ответить
Развернуть ветку
Юрий Сипаров

Хороший документ. Мне помог как методическое пособие. В компании много людей хотят получит персональные доработки к продукту. Приходится часто объяснять. А при наличии такого экспертного мнения хотя бы подумают как оформить свои хотелки

Ответить
Развернуть ветку
Андрей Гусев

Согласен что постановка задачи максимально упрощает понимание конечного результата. На моей практике попадались исполнители, которые получив подробное задание, выдавали совершенно не тот результат. Как быть с подобными индивидами? 

Ответить
Развернуть ветку
Василий Степанов

пиздить

Ответить
Развернуть ветку
Anna Lazutkina

Тут вопрос: вам с ними один проект сделать нужно или работать на постоянной основе? Если это разовая акция, может быть проще принять реальность и как раз разбивать все на небольшие куски, чтобы максимально быстро направлять на путь истинный. А если это ваша команда – надо разбираться, что пошло не так. Я всегда верю, что подход можно найти ко всем, просто кому-то нужно больше текста, кому-то больше картинок, а с кем-то просто лишний раз поговорить голосом.

Ответить
Развернуть ветку
Мехман Агаев

Ля , какая афуфенная статья! Огромное спасибо!!!

Ответить
Развернуть ветку
ivan krapivin

Показал джуну-продакту?

Ответить
Развернуть ветку
Светлана Ильиных

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

Ответить
Развернуть ветку
Василий Степанов

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

Ответить
Развернуть ветку
2 комментария
Dmitriy Alekperov

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

Ответить
Развернуть ветку
Befort Street

Странно.Но.Мы делали цепочку.Да.Нет.Если да.Если нет.Проговаривая ее мы уже на ТЗ понимали к чему идём.Далее ДизДок в котором шло полное описание.И если кто то выбыл,вновь пришедший быстро понимал - где что и как.Если результат был иным(бывало и так) - возвращались к цепочке и перебирали звенья.Очень часто - недостающее звено находилось,вносилось изменение в ТЗ и ДД,а после результат соответствовал.
Нынче же - манагер не в состоянии донести ни просто ни сложно до программиста то,чего он от него хочет.Он не в состоянии финализировать суть своего замысла.Впрочем и программисты также не в состоянии осознать суть того,что от них хотят.Отсюда регулярные патчи,апдейты и до бесконечности...мозг же непонимающему можно парить пока он в состоянии платить или пока не разберётся,что его дурят.И все тоже самое применимо к рядовому потребителю.

Ответить
Развернуть ветку
Michael Goor

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

Ответить
Развернуть ветку
Коля Петров

да.

Ответить
Развернуть ветку
52 комментария
Раскрывать всегда