Эффективная постановка и ведение задач в IT-проектах
Четкая и достаточно полная постановка задачи — ключ к ее успешному выполнению.
Привет, Хабр!
Как 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.
Благодарю за то, что дочитали до конца. Это моя первая статья и я буду рад, если она окажется вам полезна.
P.S. Если вам интересно узнать больше о разработке, ведении продуктов и построении процессов в команде, приглашаю вас подписаться на мой Telegram канал maxxborer.t.me, где я делюсь дополнительными материалами в формате коротких постов.
