Сегодня мы попробуем разобраться и дать ответ на часто возникающий вопрос.
Как правильно создавать задачи?
Создавать одну задачу на всех участников процесса и вести ее по длинному рабочему потоку (work-flow)?
Здесь мы говорим про случай, когда над одной задачей работает несколько участников. Разные участники подключаются к задаче на определенном статусе. При этом, в один момент времени у задачи остается один исполнитель.
А может создавать каждому участнику свою задачу (подзадачу)? И все они будут проходить кратчайший путь, к примеру, ToDo — InProgress — Done?
В этом случае у задачи всегда будет один и тот же исполнитель.
Это достаточно «старый» спор. У сторонников обоих «лагерей» есть весьма весомые аргументы в пользу своего подхода. Сразу отметим, что оба подхода могут успешно применяться. Но начинающим командам, порой, трудно выбрать правильную стратегию, что может снизить общую продуктивность в команде или вовсе обесценить учет.
Перед тем, как мы разберемся в сути этого вопроса, необходимо вспомнить некоторые принципы ведения учета задач.
Что такое статус задачи?
Статус задачи в трекере — это индикатор текущего состояния выполнения задачи. Статус помогает понять, на каком этапе находится задача и какие действия необходимо предпринять в текущий момент. Вот примеры статусов задач у нас в METEOR:
New (Новое): Задача была создана, но работа над ней ещё не началась.
In Progress (В процессе): Задача выполняется. Этот статус указывает, что кто-то уже работает над задачей.
Closed (Закрыто): Задача полностью выполнена. Все требуемые действия завершены, и цели достигнуты.
On Hold (В ожидании): Работа над задачей временно остановлена. Задача не отменена, но выполнение приостановлено по какой-либо причине.
Rejected (Отклонено): Задача больше не актуальна и не будет выполнена. Она была удалена из активного списка задач.
Использование статусов помогает улучшить управляемость задач в проекте. Все участники команды могут быстро оценивать состояние задач и принять необходимые действия для их успешного завершения.
Про что нужно помнить при ведении задач
Определять ясные цели и задачи проекта: Перед началом работы важно чётко определить цели проекта и разбить их на более мелкие задачи. Каждая задача должна быть конкретной, измеримой, достижимой, релевантной и своевременной (рекомендуем применять подход "SMART").
Разбивать задачи на подзадачи: Если задача слишком объемная, её можно разбить на более мелкие подзадачи (декомпозировать). Это поможет лучше структурировать работу и упростит отслеживание прогресса.
Назначать ответственных: Для каждой задачи определите ответственного участника команды. Этот человек будет отвечать за выполнение задачи и координировать работу. О том как правильно выбирать ответственных чуть ниже.
Отслеживать прогресс: Регулярно обновляйте статус задачи в трекере, отмечая выполненные шаги и любые проблемы, с которыми столкнулись.
Почему ответственный и исполнитель иногда разные люди?
Ответственный и исполнитель задачи в некоторых случаях могут быть разными. Вот различия между этими ролями:
Ответственный: Это человек, который отвечает за задачу в целом. Он обычно назначается на задачу, определяет её приоритет, следит за её выполнением и обновляет статус в системе управления задачами. Ответственный за задачу может не обязательно выполнять её сам, но он отвечает за то, чтобы задача была выполнена успешно и в срок.
Исполнитель: Это человек, который фактически выполняет задачу. Он может быть назначен ответственным за выполнение конкретных шагов или подзадач, но не несёт общей ответственности за всю задачу. Исполнитель должен выполнять задачу согласно её требованиям и предоставлять необходимую информацию о прогрессе работы ответственному.
Разделение ролей ответственного и исполнителя может быть полезным в следующих случаях:
Крупные задачи: Если задача слишком большая или сложная для одного человека, то разделение на ответственного и исполнителя может помочь в её управлении и контроле прогресса.
Кросс-функциональные команды: В командах, где каждый член имеет свою специализацию, разделение ролей поможет определить, кто отвечает за управление задачей и кто её фактически выполняет.
В то же время, если задача короткая или простая, то ответственный и исполнитель могут быть одним и тем же человеком.
В Meteor мы поддерживаем возможность назначать и исполнителя, и ответственного.
Как выбрать ответственного за задачу
Вот принципы, которые помогут определить, кто должен быть ответственным по задаче:
Компетентность: Ответственный за задачу должен обладать необходимыми знаниями, навыками и опытом. Он должен понимать требования задачи и иметь возможность успешно решить её.
Доступ к ресурсам: Ответственный должен иметь доступ к необходимым ресурсам, включая информацию, инструменты, материалы и поддержку со стороны других участников команды.
Актуальность: Ответственный должен иметь возможность уделить достаточное количество времени и внимания для выполнения задачи. Он должен быть готов регулярно обновлять статус задачи и участвовать в обсуждениях, связанных с её выполнением.
Коммуникация: Ответственный должен быть готов взаимодействовать с другими участниками команды, отвечать на вопросы и принимать участие в обсуждениях, связанных с задачей.
Возможность принятия решений: Ответственный должен быть способен принимать решения и решать проблемы, связанные с выполнением задачи, даже если это требует консультации с другими участниками команды или руководством.
Обычно ответственный за задачу назначается на основе согласования внутри команды или проектной группы. Он может быть выбран в зависимости от его роли в проекте, уровня экспертности, загруженности другими задачами и других факторов.
В качестве ответственных за задачи часто выбираются (в порядке убывания приоритета):
аналитики,
тимлиды,
проектные менеджеры,
продакт менеджеры.
А теперь к сути вопроса...
Каждому по задаче
Когда стоит создавать отдельные задачи на участников?
1. Независимые задачи. Создание отдельных задач на каждого участника оправдано, когда работы по задаче могут быть легко разделены между участниками команды и не зависят друг от друга. Например, если проект включает в себя разработку веб‑приложения, один участник может быть ответственен за фронтенд, а другой за бэкенд. Другой пример, в «молодых» командах один исполнитель может брать на себя ответственность за выполнение какой‑либо фичи целиком — от проектирования до документирования и релиза.
2. Параллельные задачи. Если некоторые работы выполняются параллельно разными исполнителями, то стоит создать отдельные задачи.
Плюсы подхода "каждому по задаче"
1. Это просто. Не нужно выстраивать сложные процессы передачи задачи между исполнителями.
2. Четкое распределение ответственности. Легко контролировать, кто и за что отвечает.
3. Отслеживание прогресса. Легко увидеть, кто из исполнителей уже выполнил свои задачи. Это облегчит понимание общего прогресса.
3. Отслеживание простоев, задержек. Отследить общее время выполнения отдельной задачи проще, чем время нахождения задачи на том, или ином статусе. Это бывает необходимо, например, когда у проекта очень сжатые сроки.
4. Распределение нагрузки. Создание отдельных задач на каждого участника поможет более равномерно распределить нагрузку в команде, учитывая индивидуальные навыки и загруженность участников. Такая потребность очень часто возникает в молодых командах, где не до конца сформированы устойчивые правила работы. Например, в команде может не быть тестировщиков. Тогда задачи тестирования прехватываются другими участниками: аналитиками, тимлидами, или даже руководителем. Этот процесс нельзя назвать стабильным, поэтому создание отдельной задачи на тестирование может быть оправдано.
Минусы подхода "каждому по задаче"
1. Создание слишком большого количества мелких задач также может привести к избыточности и сложности управления проектом. Поэтому важно находить баланс между созданием отдельных задач и их уровнем детализации, учитывая особенности конкретного проекта и предпочтения команды.
2. Сложно и долго искать информацию по множеству разрозненных задач. Например, по вложенным файлам, комментариям, истории выполнения задач.
Одна задача на всех
Когда стоит создавать одну задачу на нескольких участников с "длинным флоу"?
1. В задаче четко прослеживается коллективная работа.
Если задача требует совместного участия нескольких членов команды, то создание одной задачи позволит объединить усилия и обеспечить эффективную командную работу. Например, в потоке проектирование‑разработка‑тестирование‑публикация несколько участников делают свою часть работы. Когда приступать к задаче тому, или иному участнику определяется статусом задачи, а возможность перехода из одного статуса в другой регламентируется настройкой рабочего потока (work‑flow). Трекеры, как правило, позволяют настраивать рабочий поток в виде диаграммы переходов между статусами. Вот как это сделано у нас в METEOR:
2. Взаимозависимые задачи.
Когда выполнение одной задачи зависит от выполнения другой, или несколько задач имеют общие элементы, создание одной задачи для нескольких участников может помочь с учетом этих взаимосвязей и координации работы. Здесь также уместен пример цикла: проектирование‑разработка‑тестирование‑публикация. Также важным условием является, что взаимозависимые задачи включают в себя работу в рамках одной и той же области ответственности или навыков (например, дизайн или разработка).
3. Последовательное выполнение.
Когда работа над задачей выполняется последовательно разными исполнителями для достижения общего результата. То есть не может быть такого, что в один момент над задачей работает несколько исполнителей. Это приведет к размытию ответственности, простоям и задержкам.
4. Выстроенные процессы.
У вас четко выстроен процесс работы с задачей — все участники знают, кто на каком этапе и при каких условиях должен подключиться к задаче, как зафиксировать в задаче результат своей работы и кому его передать, на какой следующий статус перевести задачу, что делать при возникновении сложностей. У вас есть понимание по ограничениям и условиям выполнения задачи.
5. Важно отслеживать всю историю работы над задачей
Например, в процессе обработки обращений клиентов важно контролировать процесс и быстро получать информацию на протяжении всего цикла работы с обращением.
Плюсы подхода «одна задача на всех»
1. Оптимизация использования времени и ресурсов.
Объединение нескольких задач в одну может помочь избежать избыточности и оптимизировать использование времени и ресурсов команды, особенно если задачи небольшие или взаимосвязанные. Например, вам важно анализировать time‑to‑market (полное время разработки до выхода в продакшн). Если вся команда нацелена на результат — «минимальный time‑to‑market», тогда комплексная задача на нескольких участников позволит повысить общую эффективность команды.
2. Вся информация по задаче в одном месте.
Вы можете отследить весь ход работы по задаче от момента постановки и до завершения, даже если над ней работало несколько исполнителей. Например, METEOR позволяет гибко настроить карточку задачи так, чтобы каждый исполнитель заполнял свой раздел в карточке задачи. Можно добавить кастомные поля различных типов для максимального соответствия вашему бизнес‑процессу. Все файлы с результатами работ прикреплены к одной карточке задачи. История изменений хранит всю хронологию событий по задаче. Очень легко найти нужную информацию или разобраться в возникшей проблеме.
Минусы подхода «одна задача на всех»
1. Сложно выстроить процесс.
Важно помнить, что создание одной задачи для нескольких участников требует хорошей координации и коммуникации в команде. Необходимо ясно определить роли и ответственность каждого участника, а также обеспечить прозрачность и обратную связь в процессе выполнения задачи. Зачастую можно столкнуться со сложностями технической реализации вашего бизнес-процесса в трекере. METEOR позволяет настроить бизнес-процессы любой сложности с помощью стандартных инструментов workflow и гибкой настройки карточки задачи. Также имеется мощный инструмент триггеров, которые помогут реализовать любые условия и проверки бизнес-процесса.
2. Сложнее отследить прогресс.
Необходимо хорошо знать последовательность статусов для данного типа задач, чтобы понять, насколько близка задача к завершению, кому и что еще необходимо сделать.
3. Сложнее отследить сроки, простои и задержки
Ведь задача имеет единый дедлайн, а в процессе работы сложнее отслеживать, кто из исполнителей в какие сроки должен выполнить свою часть работы. Для этого в трекере должны быть инструменты для отслеживания времени, которое задача находится на том или ином статусе. А также для назначения дедлайна для каждого статуса. METEOR позволяет видеть на доске информацию по сроку нахождения задачи в текущем статусе — например, 39 дней на картинке ниже. Также вы можете добавить кастомное поле для дедлайна текущего статуса.
Как быть, когда необходимо координировать работу двух и более команд?
Этот вопрос достаточно обширен. В большинстве случаев лучше сохранять изоляцию команд, выделяя задачи, передаваемые в другие команды как отдельные подзадачи. Но бывает и так, что между разными командами нужно перекидывать одну задачу. У нас по единой задаче в разных командах сработались команды разработки и поддержки. В остальных случаях мы изолируем задачи.
Мы будем рады, если вы поделитесь своим опытом организации учета задач. Ведь от того, как мы формулируем задачи и направляем их на участников во многом зависит, насколько будет слаженной работа всей команды.
Спасибо! Хороших вам задач и эффективной работы!
