Скрытая цена расплывчатых задач в Jira
Расплывчатая задача в Jira редко кажется опасной с первого взгляда. Настоящая проблема приходит позже, когда разные люди по-разному понимают недосказанное, и несколько дней сосредоточенной работы оказываются потрачены не туда.
Почему расплывчатые задачи так долго живут
В понедельник утром разработчик берёт задачу. Заголовок вроде бы конкретный: «Добавить уведомления для пользователей об обновлениях заказа». В описании всего две строки и ссылка на обсуждение в Slack трёхнедельной давности. На первый взгляд этого достаточно. За три дня он собирает цепочку почтовых уведомлений, которая срабатывает при каждом изменении статуса заказа.
В четверг менеджер продукта смотрит изменения и говорит: «Я имел в виду не это. Нам нужны были только уведомления внутри приложения о событиях доставки, и у пользователя должна быть возможность отказаться». Никто не ошибался. Никто не ленился. Просто задача так и не вынесла наружу решения, которые в ней уже были спрятаны.
Никто не пишет расплывчатую задачу специально. Её набрасывают за пару минут между встречами, с мыслью потом вернуться и дописать детали. И не возвращаются. В момент написания у автора весь контекст ещё в голове. Он знает, какие события важны, какие каналы имеет в виду и каких пользователей это касается.
Но на страницу это не попадает, потому что кажется «и так очевидным». Нет, не очевидным.
Jira усугубляет это тем, что всё слишком просто создать. Нет обязательного поля, которое спросит, что явно не входит в задачу. Нет ограничения, которое не даст сохранить описание из двадцати слов. Можно ввести три слова в заголовок, оставить описание пустым и нажать «Создать». Jira не возразит. В этом и сила, и ловушка. Так и появляется список задач, полный карточек, которые выглядят законченными только на первый взгляд и показывают свою расплывчатость уже тогда, когда по ним начинают делать реальную работу.
Что вообще должно быть в плане, готовом к разработке
Большинство задач отвечают на один вопрос: что мы хотим сделать? План, по которому действительно можно работать, отвечает на шесть.
| Часть плана | На какой вопрос отвечает |
|---|---|
| Границы задачи | Что входит в работу, а что явно не входит |
| Ограничения | Что нельзя менять или ломать |
| Шаги | Что должно произойти и в каком порядке |
| Нестандартные случаи | Что делать, если привычный сценарий ломается |
| Зависимости | Что должно существовать заранее |
| Критерий готовности | Как команда поймёт, что работа действительно завершена |
Это не чек-лист для каждой крошечной правки в списке задач. Но всё, что идёт в спринт и почти наверняка съест больше пары часов времени, должно получить ответы на эти вопросы ещё до начала работы. Чаще всего команды пропускают именно границы задачи. Формулировать, что «не входит», кажется лишним, когда все сосредоточены на том, что входит. Но именно здесь очень часто и начинается переделка.
Ограничения — это тихие требования:
- Не ломать текущий поток почтовых уведомлений по заказам.
- Оставаться внутри уже существующего сервиса уведомлений.
- Не поднимать новую инфраструктуру в этом спринте.
Такие вещи редко записывают, потому что автору кажется, будто все и так это знают. Не знают. А критерий готовности — это граница между «мне кажется, всё готово» и «мы договорились, что это готово». Хороший критерий готовности можно проверить и наблюдать.
Сначала вопросы, потом структура
Почти в каждой Jira однажды происходит один и тот же цикл. Кто-то добавляет шаблон описания с разделами вроде «Кратко», «Критерии приёмки», «Технические заметки» и «Что не входит в задачу». Несколько недель люди честно его заполняют. А потом тот же расплывчатый язык, который раньше жил в голом описании, просто расползается по большему количеству подписанных блоков. Структуры стало больше. Ясности — нет.
Шаблоны не решают проблему, потому что проблема не в форме. Она в мышлении. Автор сам ещё не понимает, чего именно не хватает. Пустой раздел «Нестандартные случаи» не поможет человеку, который о них ещё не задумался. Помогают вопросы. Конкретные вопросы, которые вынуждают принять решение.
Особенно хорошо вытаскивают скрытые решения пять вопросов:
- Что именно меняется в поведении системы?
- Кто главный пользователь и чего он пытается добиться?
- Есть ли случай, когда это вообще не должно происходить?
- Что сломается, если мы это не выпустим?
- Это касается существующих пользователей, новых или всех сразу?
Эти вопросы работают потому, что на них можно ответить предметно, но при этом они подходят почти к любой продуктовой задаче. Само действие ответа на них и есть планирование. Шаблон — лишь место, куда потом ложатся ответы.
Полный пример
Вот как это выглядит на практике. Исходная задача крошечная: «Добавить уведомления для пользователей об обновлениях заказа». В описании только фраза о том, что пользователь должен получать уведомления при изменении статуса заказа, плюс пометка «свериться с дизайном по визуальному решению». Этого достаточно, чтобы задача попала в спринт. Но почти наверняка недостаточно, чтобы уверенно по ней строить работу.
Короткий круг уточняющих вопросов меняет всё:
| Уточняющий вопрос | Ответ |
|---|---|
| Какие статусы важны? | Только «отправлен» и «доставлен» |
| Какие каналы? | Только уведомления внутри приложения в этом спринте |
| Можно ли отказаться? | Да, по умолчанию уведомления включены |
| Что делать, если пользователь не в сети? | Поставить уведомление в очередь до следующего входа |
| Это касается уже существующих заказов? | Нет, только новых |
| Что делать, если отправка не удалась? | Один повтор, потом запись в журнал |
Через пятнадцать минут задача означает для всех одну и ту же вещь. В новой версии появляются реальные границы, реальные ограничения, упорядоченные шаги, настоящие нестандартные случаи и критерий готовности, который можно проверить. Задача та же. Ясность — совершенно другая. Разница не в более красивом шаблоне, а в небольшом, но осознанном круге вопросов до старта работы.
Где здесь помогает ИИ
ИИ не пишет задачи. Задачи пишут люди. Но ИИ очень полезен в одной конкретной точке процесса: после того, как намерение уже появилось, и до того, как структура окончательно зафиксирована. Языковая модель хорошо читает расплывчатое описание и спрашивает: «А что будет, если пользователь не в сети?» Она умеет брать разрозненные ответы из обсуждения в Slack и раскладывать их по границам задачи, ограничениям и шагам. Она умеет замечать, что в плане всплывает перенос данных, а среди зависимостей про нужную проверку вообще ничего не сказано.
Чего ИИ не умеет, так это принимать продуктовые решения за вас. Он может спросить, должно ли это быть письмо, мобильное уведомление или уведомление внутри приложения. Но он не знает, какой вариант правильный именно для ваших пользователей и именно в рамках этого спринта. Он может предложить правдоподобный критерий готовности, но только человек, который понимает продукт, знает, действительно ли этот критерий верный.
Логика здесь простая: люди решают, ИИ помогает навести порядок. Люди задают границы, ИИ подсвечивает пробелы. Именно по этому принципу — уточнить, спланировать, выполнить — и построен Just в Atlassian Marketplace. Тот же принцип работает и вручную. ИИ просто ускоряет цикл.
Три вещи, которые можно сделать уже сегодня
- Перед следующим спринтом возьмите самую расплывчатую задачу из списка и задайте к ней пять вопросов из этой статьи ещё до того, как кто-то напишет первую строку кода. Почти наверняка выяснится, что как минимум два важных решения всё ещё никто не принял.
- Запишите ответы не в отдельный документ, а прямо в задачу: что входит в работу, какие есть ограничения и по какому критерию команда поймёт, что всё готово.
- Считайте шаблон отправной точкой, а не стандартом. Подстраивайте его под язык своей команды, но не пропускайте вопросы. Если нужен более широкий контекст того, почему этот шаг с уточнением становится ещё важнее, когда расплывчатые задачи начинают напрямую отдавать ИИ, первая статья серии подробно разбирает проблему рассинхрона: Почему большинство ИИ-инструментов для Jira усиливают проблему рассинхрона, а не решают её.
