Четкая и достаточно полная постановка задачи — ключ к ее успешному выполнению.
Привет!
Как Frontend-разработчик, я в одной из своих прошлых работ столкнулся с проблемой неэффективной постановки задач в моей команде. Это привело к потере времени, недопониманию и снижению качества работы. Например, однажды мы потратили целую неделю на разработку функциональности, которая в итоге оказалась не той, что ожидал заказчик из-за неполного описания требований. В другой раз из-за отсутствия четких критериев приемки мы трижды возвращались к доработке уже "готовой" задачи.
В этой статье я поделюсь результатами своего исследования и практическими рекомендациями по улучшению процесса постановки и ведения задач, которые мы начали применять в работе тогда и которые я использую теперь.
Шаблоны и примеры задач будут в конце статьи.
Описание задач
Цель описания
Предоставить максимальный контекст с минимальной сложностью. Чем проще описывать задачу, тем выгоднее это делать. Чем понятнее описание, тем ниже шанс допустить ошибки из-за недопонимания или потратить много времени на анализ.
Как сделать описание задач проще и понятнее для заполнения и для изучения? — Оформить шаблоны.
Типы задач
За основу я взял примеры описаний из гибких методологий и разделил их по типам:
-
Epic (Большая задача)
-
Feature (Новая функциональность)
-
Bug (Исправление ошибок)
-
Enhancement (Улучшение)
-
Refactoring (Рефакторинг)
-
Technical Debt (Техдолг)
-
Research (Исследование)
-
Docs (Документация)
Но простого разделения не достаточно: в каждый из типовых шаблонов нужно добавлять специфичное описание.
Например, вы не будете в "Feature" описывать "Ожидаемое поведение" и "Фактическое поведение", потому что это вероятно относится к типу "Bug". В то же время для "Feature" есть свои пункты, которые помогут гораздо лучше описать что и для чего исполнителю нужно сделать.
Шаблоны описания
Итак, нужно облагородить эти пустые шаблоны пунктами описания. Они должны подходить конкретно к этому типу и подталкивать инициатора задачи передать полный контекст. Кроме того, это поможет создателю задачи задуматься о дополнительных вопросах, которые не возникали изначально.
При этом простого добавления пунктов может быть не достаточно. Например, пункт "Окружение" каждый может понимать по-разному, но команде необходимы точные детали: версия приложения, версия ОС, браузер и т.д.
Поэтому будет отлично дополнительно добавить комментарий с описанием каждого пункта задачи (1-2 предложения должно быть достаточно).
Шаблоны с комментариями, которые я использую, будут в конце статьи.
Конечно, это не догматы. Не обязательно пользоваться всеми типами или такой же структурой описания, как написано в шаблонах.
Основная мысль: предоставить человеку простой инструмент, который подскажет ему, как передать достаточный контекст в зависимости от типа изменений. Как будет лучше — решать вам и вашей команде.
Зачем стараться?
Поставьте себя на место инициатора:
-
Я знаю что и почему нужно сделать.
-
Я знаю как это должно работать (с точки зрения бизнеса).
-
Я знаю приоритет и зависимости этой задачи (с другими задачами или командами). Конечно в реальности не все пункты инициатор будет обязательно знать, но я хочу чтобы вы уловили главную мысль: только инициатор на старте может передать максимально имеющийся контекст исполнителю и быть ответственен за это.
Теперь рассмотрим с точки зрения исполнителя, когда он получает пустой тикет:
-
Название я вижу, но что именно нужно сделать?
-
Как это повлияет на работу продукта/фичи и т.д.?
-
Какая срочность и приоритет?
-
К кому мне обращаться с вопросами? И что в результате? А в результате исполнитель вынужден идти и трясти инициатора.
Зачем тратить на это время? Не лучше ли исполнителю обращаться только с вопросами по конкретным пунктам в задаче, которые для него остались не ясны? На это будет потрачено гораздо меньше времени, нервов и "мыслетоплива".
Но бывают ситуации страшнее: даже после выяснения контекста задачи у инициатора (1t потраченного времени) вы уже вдвоем не дополняете задачу описанием, потому что вам обоим "И так понятно". А потом случается:
-
Вы отвлеклись на другую большую задачу, ушли в отпуск или заболели и потеряли контекст.
-
Вы передаете задачу другому исполнителю (QA на проверку или делегируете коллеге) и снова вынуждены передать полный контекст. В результате вы тратите 2t времени. Если эта цепочка будет продолжаться (Nt будет расти), то даже на небольшую задачу может уйти уйму времени и сил.
Ключевые моменты при описании задач
-
Инициатор задачи должен предоставить максимальный контекст.
-
Используйте шаблоны с комментариями для упрощения процесса описания.
-
Включайте всю релевантную информацию: цели, ожидаемые результаты, критерии приемки, требования, ограничения.
-
Явно указывайте зависимости и связи задач.
-
Фиксируйте возникающие вопросы вместе с ответами.
-
Добавляйте метки, приоритеты и сроки выполнения для упрощения поиска и приоритизации задач.
Ведение задачи
Хорошо, допустим, мы решили проблему "пустых тикетов". Следующей проблемой станет — "протухание" задач.
Важность актуализации
Обязательно нужно дополнять задачу в процессе выполнения и поддерживать ее актуальность. Относитесь к этому как к одному из важных и непрерывных процессов.
К примеру, как узнает ваш QA (или даже вы после отпуска) что:
-
Поменялись требования.
-
В процессе работы было затронуто что-то еще, что требует внимания.
-
Появились новые зависимости с другими задачами или командами. Никак, кроме как случайного озарения "ой, нужно рассказать". В противном случае чаще всего задача не будет выполнена полностью.
Ключевые аспекты ведения задач
-
Регулярно дополняйте описание: изменения в требованиях, новые зависимости и далее по пунктам.
-
Комментируйте все значимые изменения и почему они были затронуты.
-
Описывайте дополнительные условия, например, как проверить внесенные изменения (включить feature-флаги или ab-тесты).
Преимущества подхода
-
Экономия времени и ресурсов команды: Меньше затрат на прояснение требований и контекста, уменьшает необходимость в излишних уточнениях и согласованиях.
-
Улучшенное планирование и оценка задачи: Что способствует более качественному планированию спринтов и проектов.
-
Удобство работы с отложенными задачами: Можно быстро вернуться без долгого "погружения".
Потенциальные риски и проблемы
-
Важно не перегружать описание избыточными деталями, выделять главное.
-
Подробное описание требует времени, особенно на старте.
-
Это окупается меньшим количеством ошибок и недопониманий при реализации, а так же сокращением времени на повторную передачу контекста.
-
-
Сопротивление команды "А мне лень" или "У меня нет времени":
-
Выясните причины нежелания следовать процессу. Возможно процесс не совсем удобен для вас или в команде сейчас "потогонка". Эти вопросы стоит проработать и адаптировать процесс под нужды команды (либо отбросить и поискать что-то еще, что поделать).
-
В крайнем случае, если нет вразумительного ответа и причин непринятия процесса, а так же сопротивление скорее связано с отдельным сотрудником (при этом остальной команде все подходит) — задумайтесь о несоответствии сотрудника к требованиям команды. Я серьезно. Стоит избавляться от якоря, иначе нежеланием "тратить свое время" он будет тратить время всей команды многократно.
-
Заключение
Подводя итоги, хочу подчеркнуть, что эффективная постановка и ведение задач — это не просто формальность, а один из ключевых факторов успеха IT-проектов. Применяя предложенные рекомендации, мы сократили время на уточнение требований на 30% и уменьшили количество возвратов задач на доработку почти вдвое.
Надеюсь, следование предложенным рекомендациям позволит и вам повысить эффективность постановки и выполнения задач. Это приведет к экономии времени, повышению предсказуемости разработки и улучшению качества результатов.
Буду рад услышать ваш опыт и мнение в комментариях. Какие проблемы с постановкой задач вы встречали в своей практике? Какие методы оказались для вас наиболее эффективными?
Шаблоны задач с комментариями вынес для удобства в Notion.
Благодарю за то, что дочитали до конца. Это моя первая статья и я буду рад, если она окажется вам полезна.
Автор: maxxborer
