Эффективная постановка и ведение задач в IT-проектах

Четкая и достаточно полная постановка задачи — ключ к ее успешному выполнению.

Привет!

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

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

Шаблоны и примеры задач будут в конце статьи.

Описание задач

Цель описания

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

Как сделать описание задач проще и понятнее для заполнения и для изучения? — Оформить шаблоны.

Типы задач

За основу я взял примеры описаний из гибких методологий и разделил их по типам:

• Epic (Большая задача)

• Feature (Новая функциональность)

• Bug (Исправление ошибок)

• Enhancement (Улучшение)

• Refactoring (Рефакторинг)

• Technical Debt (Техдолг)

• Research (Исследование)

• Docs (Документация)

Но простого разделения не достаточно: в каждый из типовых шаблонов нужно добавлять специфичное описание.

Например, вы не будете в "Feature" описывать "Ожидаемое поведение" и "Фактическое поведение", потому что это вероятно относится к типу "Bug". В то же время для "Feature" есть свои пункты, которые помогут гораздо лучше описать что и для чего исполнителю нужно сделать.

Шаблоны описания

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

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

Поэтому будет отлично дополнительно добавить комментарий с описанием каждого пункта задачи (1-2 предложения должно быть достаточно).

Шаблоны с комментариями, которые я использую, будут в конце статьи.

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

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

Зачем стараться?

Поставьте себя на место инициатора:

• Я знаю что и почему нужно сделать.

• Я знаю как это должно работать (с точки зрения бизнеса).

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

Теперь рассмотрим с точки зрения исполнителя, когда он получает пустой тикет:

• Название я вижу, но что именно нужно сделать?

• Как это повлияет на работу продукта/фичи и т.д.?

• Какая срочность и приоритет?

• К кому мне обращаться с вопросами? И что в результате? А в результате исполнитель вынужден идти и трясти инициатора.

Зачем тратить на это время? Не лучше ли исполнителю обращаться только с вопросами по конкретным пунктам в задаче, которые для него остались не ясны? На это будет потрачено гораздо меньше времени, нервов и "мыслетоплива".

Но бывают ситуации страшнее: даже после выяснения контекста задачи у инициатора (1t потраченного времени) вы уже вдвоем не дополняете задачу описанием, потому что вам обоим "И так понятно". А потом случается:

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

• Вы передаете задачу другому исполнителю (QA на проверку или делегируете коллеге) и снова вынуждены передать полный контекст. В результате вы тратите 2t времени. Если эта цепочка будет продолжаться (Nt будет расти), то даже на небольшую задачу может уйти уйму времени и сил.

Ключевые моменты при описании задач

1. Инициатор задачи должен предоставить максимальный контекст.

2. Используйте шаблоны с комментариями для упрощения процесса описания.

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

4. Явно указывайте зависимости и связи задач.

5. Фиксируйте возникающие вопросы вместе с ответами.

6. Добавляйте метки, приоритеты и сроки выполнения для упрощения поиска и приоритизации задач.

Ведение задачи

Хорошо, допустим, мы решили проблему "пустых тикетов". Следующей проблемой станет — "протухание" задач.

Важность актуализации

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

К примеру, как узнает ваш QA (или даже вы после отпуска) что:

1. Поменялись требования.

2. В процессе работы было затронуто что-то еще, что требует внимания.

3. Появились новые зависимости с другими задачами или командами. Никак, кроме как случайного озарения "ой, нужно рассказать". В противном случае чаще всего задача не будет выполнена полностью.

Ключевые аспекты ведения задач

1. Регулярно дополняйте описание: изменения в требованиях, новые зависимости и далее по пунктам.

2. Комментируйте все значимые изменения и почему они были затронуты.

3. Описывайте дополнительные условия, например, как проверить внесенные изменения (включить feature-флаги или ab-тесты).

Преимущества подхода

• Экономия времени и ресурсов команды: Меньше затрат на прояснение требований и контекста, уменьшает необходимость в излишних уточнениях и согласованиях.

• Улучшенное планирование и оценка задачи: Что способствует более качественному планированию спринтов и проектов.

• Удобство работы с отложенными задачами: Можно быстро вернуться без долгого "погружения".

Потенциальные риски и проблемы

• Важно не перегружать описание избыточными деталями, выделять главное.

• Подробное описание требует времени, особенно на старте.

  • Это окупается меньшим количеством ошибок и недопониманий при реализации, а так же сокращением времени на повторную передачу контекста.

• Сопротивление команды "А мне лень" или "У меня нет времени":

  • Выясните причины нежелания следовать процессу. Возможно процесс не совсем удобен для вас или в команде сейчас "потогонка". Эти вопросы стоит проработать и адаптировать процесс под нужды команды (либо отбросить и поискать что-то еще, что поделать).

  • В крайнем случае, если нет вразумительного ответа и причин непринятия процесса, а так же сопротивление скорее связано с отдельным сотрудником (при этом остальной команде все подходит) — задумайтесь о несоответствии сотрудника к требованиям команды. Я серьезно. Стоит избавляться от якоря, иначе нежеланием "тратить свое время" он будет тратить время всей команды многократно.

Заключение

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

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

Буду рад услышать ваш опыт и мнение в комментариях. Какие проблемы с постановкой задач вы встречали в своей практике? Какие методы оказались для вас наиболее эффективными?

Шаблоны задач с комментариями ^[1] вынес для удобства в Notion.

Благодарю за то, что дочитали до конца. Это моя первая статья и я буду рад, если она окажется вам полезна.