Покажите этот текст вашим джунам-продактам.
Есть много способов получить глубокие знания по продуктовому менеджменту: курсы, стажировки, книги, менторство. Про азы пишут гораздо реже.
Но базовые знания очень сильно влияют на качество работы. Вот пример: ставить задачи разработчикам нужно так, чтобы они точно понимали, с чем имеют дело. В этом материале директор по продукту 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/
Был очень рад менеджерить проект, в котором работает автор этой статьи.
Ну да, это все конечно замечательно но только дорого.
Все это равноправие при работе на практике означает что компания собирается оплачивать все ошибки разработчиков за свой счет, всех разработчиков.
Могу для иллюстрации привести пример постановки задач в Гугле: там РП особо не волнует техническая реализация, ставят задачу в общем виде, а инженер через полгода приносит результат в виде готового и работающего сервиса,приложения и тд.
Все вплоть до выбора языка программирования, технологий, подходов и тд - на выбор инженера.
Есть конечно гайдлайны, есть какие-то лицензионные ограничения и рекомендации - но суть неизменна: инженер выдает законченный результат.
Вообщем-то именно это и подразумевается под должностью 'Software Engineer'.
Но это также означает и соотвествующий уровень компетенций и уровень мотивации и отношение к своей работе - в Гугле не бросают проекты из-за того что 'устали' , 'потеряли интерес' и тд, инженеров такого уровня не нужно 'пасти', проверять статус работ, не нужно волноваться за то что они не справятся с какими-то техническими сложностями.
Если у вас есть специалисты такого уровня, еще и в одной команде - поздравляю, у вас теперь проблемы совершенно другого уровня чем соблюдение сроков или попадание в бюджет )
при таком подходе потерь мотивации я еще не видел, потому что каждый участник команды ощущает себя частью процесса и тем самым поднимает эту самую мотивацию, чувствуя себя лучше в таком коллективе, а вот в дроблении на атомарные задачи - видел. Да, у нас не нужно "пасти" людей, никакого авторитаризма :) и дело даже не в уровне, я видел, как при таком подходе джуниоры вырастали в уверенных миддлов за не очень большой промежуток времени. Если же человек действительно вместо работы ничего не делает, либо делает проекты на стороне, это быстро вычисляется в разговорах 1 на 1, и если ситуация не исправляется, такой сотрудник не продолжает работу в проекте. Но я не вижу, как он может это скрыть, коммитясь под сроки сам, при этом с ревью лидом и менеджером
К тому же, я еще забыл уточнить - каждый участник команды при таком процессе гораздо больше вовлечен в продукт, чем когда ему сверху говорят (сейчас очень утрированно) в какой строке какого скрипта нужно удалить запятую :) это также имеет преимущества (учитывая знания инфраструктуры и кода, иногда разработчики предлагают более быстрые и выгодные для компании и заказчиков решения)
Извините но нет, весь мой опыт (а это 20+ лет в разработке) показывает что не могут простые разработчики ни разумно оценивать сложность и сроки ни делать разбивку задач.
С митингами, без митингов, с багажем на данном конкретном проекте или пришедшие только что - не важно.
Работает только практический опыт, только он дает возможность не ошибиться в сроках на порядок или подсветить сразу потенциальные проблемы.
Поэтому 'демократия' на проекте это инвестиции в чистом виде: в людей и команду, но точно не в немедленный результат.
Если ваша компания может себе это позволить и понимает что потом делать с 10тю взращенными из джуниоров программистами - как их загрузить и оплачивать - это замечательно, но так бывает не у всех )
Именно поэтому у нас проводит ревью девлид, который поможет устаканить оценку, при этом делая это без какого-то давления, а логическими вопросами. Впослдствии, с опытом, постепенно, приходит более точное понимание что декомпозиции, что оценки. Тут я и не спорил :) и не говорил, что джуниоры могут с первого дня декомпозировать и оценивать сложные фичи безошибочно (в целом, безошибочно и сеньоры-то не могут, все мы люди)
Поэтому 'демократия' на проекте это инвестиции в чистом виде: в людей и команду, но точно не в немедленный результат.Тут тоже абсолютно согласен, речь о тех проектах, которых планируется поддерживаться достаточно долго, и важнее качество, чем быстрое создание костылей ради ежемоментной прибыли - для этого у проекта существует продакт менеджер, который позволяет добиться долгосрочного результата в плане бизнесовой выгоды. А MVP для проверки гипотез делаются, как правило, малыми силами: либо кастдев, либо no-code, либо с минимумом разработчиков, если первые два способа не применимы
'Именно поэтому у нас проводит ревью девлид, который поможет устаканить оценку, при этом делая это без какого-то давления, а логическими вопросами'
При команде в 6 человек и с разбивкой по задаче в день на рабочую неделю это уже 30 задач, 15 минут на каждую задачу ( а это минимум для технического ревью ) это ~7 часов чистого времени - целый день потраченный только лишь на техническое ревью.
И делать это надо раза два в неделю - чтобы был готовый беклог, были запланированные спринты на пару месяцев вперед.
А команда может быть и 10 и 20 человек - что тогда?
Вообщем говорю же: то что вы описали есть, такое бывает но это не про аутсорс, не про типовую разработку и всегда про кого-то очень богатого.
Брать такую модель поведения за основу просто так - с моей точки зрения не очень разумно.
вместо этого девлид бы сам декомпозировал задачи. Сами посчитаете, сколько времени это дополнительно? Сверх "потерянного" дня за неделю?
Да, с описанным мною подходом где-то половина работы тех.лида это работа с задачами: постановка, распределение и контроль выполнения.
Если тех.лид при этом еще сам пишет код - да, появится проблема тк он не будет успевать делать и то и другое.
Чудес нет.