Joom

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как выглядят задачи у вас в команде?
Очень аккуратные и подробные — мы те еще зануды.
Всякое бывает, иногда и заголовку рады.
Показать результаты
Переголосовать
Проголосовать
{ "author_name": "Joom", "author_type": "editor", "tags": ["\u043f\u0440\u043e\u0434\u0443\u043a\u0442","joom"], "comments": 55, "likes": 34, "favorites": 319, "is_advertisement": false, "subsite_label": "joom", "id": 183131, "is_wide": true, "is_ugc": false, "date": "Wed, 02 Dec 2020 16:24:21 +0300", "is_special": false }
0
55 комментариев
Популярные
По порядку
Написать комментарий...
19

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

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

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

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

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

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

Ответить
2

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

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

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

Ответить
2

'исхожу из того, что продуктовая задача по дефолту про "сделать", а не "исправить"/"протестировать"'

Ну так продукт же развивается, часть функционала ломается, часть удаляется, часть добавляется. 
Никакого 'по-дефолту' тут нет. Если продукту лет 30 - у вас 99% беклога будет про 'исправить' а добавление чего-то нового будет по сложности напоминать полет на Марс.

'декомпозиция на более мелкие таски (1 задача = 1 день) остается на разработке'

Не может разработчик сам вот так просто оценивать сроки, это делает тимлид пополам с архитектором/РП/product owner.  Ну вернее может но результат будет из серии 'пальцем в небо'.

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

Ответить
0

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

Ответить
5

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

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

Ответить
0

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

Ответить
1

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

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

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

Ответить
0

логично, да

Ответить
0

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

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

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

Ответить
–1

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

Ответить
0

не удивляюсь, ведь они не срываются на более чем 3 дня уже 5 лет с разными командами :)

Ответить
0

Сергей, подскажите, есть ли методика оценки трудозатрат?

Ответить
1

все очень просто: есть продуктовая история, в ней есть definition of done и, если это очень важная история политически/экономически/инфраструктурно (допустим, для соблюдения SLA), то по ней еще прописана аналитика, чтобы чуть больше раскрыть разработчикам/тестировщикам, какой результат мы хотели бы получить. Если же не очень важная, то обычно хватает описания менеджером при учете, что это описание сделал хороший менеджер, а также налажена коммуникация с командой (это не всегда только общение - это и логическое, а также эмпатическое понимание менеджером, что нужно передать текстом команде для получения желаемого результата)

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

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

Менеджер также проводит ревью: насколько ему нравится такая оценка или же внезапно нужно сделать задачу быстрее, поэтому он может прописать, какие фичи готовы выбросить прямо сейчас для ускорения разработки. Я вдобавок еще технический менеджер, поэтому заодно проверяю, насколько разработчик понял основную историю/аналитику, приведет ли его путь к ее выполнению, и останусь ли я доволен результатом.

Почему именно разработчик декомпозирует историю:
1. в таком случае создается внутри команды атмосфера доверия и человечности (не менеджер с девлидом спускают "приказ" сверху, а мы, как команда, совместно идем к достижению цели, каждый участник которой чувствует себя важным звеном)
2. есть дополнительный бенефит для заказчика и менеджера, это психологический момент с коммитментом. Когда человек называет срок, он как бы морально под него коммитится и будет стараться в него попасть. Если человеку называют срок свыше без возможности выслушать его сторону, то он иногда с самого начала начинает думать о том, как бы "наказать" этого человека свыше, как правило, это сводится к факапу сроков :)
3. девлид перестает спускать приказы джуниорам с небес: улучшает каждого участника команды, при этом получая время на продумывание более важных и верхнеуровневых технических задач, которые он впоследствии отдаст менеджеру на приоритизацию

Побольше про не очень позитивное отношение к дроблению на атомарные задачи, описано тут: https://habr.com/ru/post/524678/

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

Ответить
0

Ну да, это все конечно замечательно но только дорого.   
Все это равноправие при работе на практике означает что компания собирается оплачивать все ошибки разработчиков за свой счет, всех разработчиков.

Могу для иллюстрации привести пример постановки задач в Гугле: там РП особо не волнует техническая реализация,  ставят задачу в общем виде, а инженер через полгода приносит результат в виде готового и работающего сервиса,приложения и тд. 
Все вплоть до выбора языка программирования, технологий, подходов и тд - на выбор инженера.  
Есть конечно гайдлайны, есть какие-то лицензионные ограничения и рекомендации - но суть неизменна: инженер выдает законченный результат.

Вообщем-то именно это и подразумевается под должностью 'Software Engineer'.
 
Но это также означает и соотвествующий уровень компетенций и уровень мотивации и отношение к своей работе - в Гугле не бросают проекты из-за того что 'устали' , 'потеряли интерес' и тд, инженеров такого уровня не нужно 'пасти', проверять статус работ, не нужно волноваться за то что они не справятся с какими-то техническими сложностями.

Если у вас есть специалисты такого уровня, еще и в одной команде - поздравляю, у вас теперь проблемы совершенно другого уровня чем соблюдение сроков или попадание в бюджет )

Ответить
0

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

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

Ответить
0

Извините но нет, весь мой опыт (а это 20+ лет в разработке) показывает что не могут простые разработчики ни разумно оценивать сложность и сроки ни делать разбивку задач.
С митингами, без митингов, с багажем на данном конкретном проекте  или пришедшие только что  - не важно. 
 Работает только практический опыт, только он дает возможность не ошибиться в сроках на порядок или подсветить сразу потенциальные проблемы.

Поэтому 'демократия' на проекте это инвестиции в чистом виде: в людей и команду, но точно не в немедленный результат.

Если ваша компания может себе это позволить и понимает что потом делать с 10тю взращенными из джуниоров программистами - как их загрузить и оплачивать - это замечательно, но так бывает не у всех )

Ответить
0

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

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

 Поэтому 'демократия' на проекте это инвестиции в чистом виде: в людей и команду, но точно не в немедленный результат.

Тут тоже абсолютно согласен, речь о тех проектах, которых планируется поддерживаться достаточно долго, и важнее качество, чем быстрое создание костылей ради ежемоментной прибыли - для этого у проекта существует продакт менеджер, который позволяет добиться долгосрочного результата в плане бизнесовой выгоды. А MVP для проверки гипотез делаются, как правило, малыми силами: либо кастдев, либо no-code, либо с минимумом разработчиков, если первые два способа не применимы

Ответить
0

'Именно поэтому у нас проводит ревью девлид, который поможет устаканить оценку, при этом делая это без какого-то давления, а логическими вопросами'

При команде в 6 человек и с разбивкой по задаче в день  на рабочую неделю это уже 30 задач, 15 минут на каждую задачу ( а это минимум для технического ревью ) это ~7 часов чистого времени  - целый день потраченный только лишь на техническое ревью.
И делать это надо раза два в неделю - чтобы был готовый беклог, были запланированные спринты на пару месяцев вперед.

А команда может быть и 10 и 20 человек - что тогда?

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

Ответить
0

вместо этого девлид бы сам декомпозировал задачи. Сами посчитаете, сколько времени это дополнительно? Сверх "потерянного" дня за неделю?

Ответить
0

Да, с описанным мною подходом где-то половина работы тех.лида это работа с задачами: постановка, распределение и контроль выполнения.  
Если тех.лид при этом еще сам пишет код - да, появится проблема тк он не будет успевать делать и то и другое.
 
Чудес нет.

Ответить
0

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

Ответить
0

Спасибо за такой развернутый ответ. Для начала прочту прилагаемую статью

Ответить
0

один из лучших вариантов: трудозатраты оцениваются поверхностно по Pert менеджером и экспертами, потом уточняются по Planning poker исполнителями

Ответить
0

Если оценивать поверхностно то сроков вообще ровно два: полгода - 'прототип/пилот/MVP/первый результат', год - работающая система в проде и с пользователями.

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

С результатом за год все еще банальнее: исчезающе мало у кого есть бюджет на более чем год разработки.
Да, можно растянуть надолго какие-то доработки но ключевой функционал разрабатывается все равно в течение года.

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

Ответить
0

Думаю должна быть, а вы как считаете? 

Ответить
0

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

Ответить
0

ну ладно, про 1 день я погорячился. но остается огромная проблема, что оставляют большие задачи, а потом вылезают вот такие перлы:
“Почему задача вместо 3х дней заняла месяц?”
"Разработчик через 2 месяца узнает, что задача уже не актуальна."
"Разработчик, на котором был важный функционал, уволился за день до релиза. Выкручиваться пришлось с помощью нескольких фрилансеров, которые за 20 часов сделали недостающую часть продукта."

как вы били, как отслеживали прогресс, что за х*?;%я...

Ответить
0

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

Ответить
–1

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

Ответить
0

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

Ответить
0

'грамотная "культура" это как единорог - мифическая сущность.'

Ну конечно нет,  с т.н 'инженерной культурой' все достаточно просто и банально. По-сути она состоит всего из двух вещей:
- работа со знанием
- работа с ошибками

'Работа со знанием' это например отсутствие 'темных пятен' в проекте, обязательная ротация внутри  ( т.е любой программист может работать в любой части системы в рамках проекта ), обязательный обмен знаниями - нельзя давать утаивать детали реализации или сборки. 

'Работа с ошибками' это использование ассертов, телеметрии, своих детальных сообщений об ошибках, валидации входящих данных, версионирование сборок и тд и тп.

Т.е по-сути хороший софт от плохого в техническом плане отличается только количеством поломок и их очевидностью.

А наличие/отсутствие ФП, каких-то новомодных технологий - вещь 10я уже.

Ответить
5

[Корзина] Скидка на карточке товара

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

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

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

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

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

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

Ответить
3

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

Ответить
4

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

Ответить
0

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

Ответить

Пестрый кавалер

4

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

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

Ответить
3

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

Ответить
1

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

Ответить
2

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

Ответить
1

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

Ответить
1

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

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

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

Ответить
1

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

Ответить
0

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

Ответить

Пестрый кавалер

Андрей
2

пиздить

Ответить
1

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

Ответить
–5

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

Ответить
1

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

Ответить
0

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

Ответить

Пестрый кавалер

Светлана
–1

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

Ответить
0

В этом плане соглашусь) Но если эту технику будут создавать по плохо поставленным задачам, то она будет постоянно ломаться и, соответственно, не справляться со своей функцией

Ответить
0

да, точно подмечено

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

да.

Ответить

Комментарии

null