{"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.
   
Разработчик который будет это реализовывать гарантированно этот момент пропустит, тестировщик - тем более.

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

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

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

Это крайне непопулярный источник под названием 'собственный опыт', не могу сослаться на какого-то модного автора увы. 

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

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

пфф, за один день не всегда VPN-туннель тебе из внешней системы организуют. А потом, зачем спрашивать результат, если задача на один день, и у неё за сутки должен случиться переход 0->1

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

'за один день не всегда VPN-туннель тебе из внешней системы организуют'
Вообще если что-то из условий внешней среды не готово перед выполнением задачи ( рабочее место, тестовый стенд, доступ куда-то типа описанного вами) - задача просто в разработку не берется.

'А потом, зачем спрашивать результат, если задача на один день'

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

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

логично, да

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