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

в 14:16, , рубрики: документация, задачи, исследование, постановка задач, продукт, шаблоны

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

Привет!

Как 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% и уменьшили количество возвратов задач на доработку почти вдвое.

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

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

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

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

Автор: maxxborer

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js