Меня зовут Андрей Иванов. Когда я отвечал за развитие одного из внутренних продуктов компании NAUMEN, мне приходилось руководить командой аналитиков, разработчиков и тестировщиков. В нашей оргструктуре эти ребята относятся к разным функциональным командам, но делают один и тот же продукт. Поэтому мне было важно оставаться в курсе текущих задач каждой из них.
Чтобы распределять задачи и видеть, как движется процесс, мы использовали
За годы разработки мы сформулировали несколько принципов для продуктивной работы с досками. Разберу на примере
1. Не перегружать доску карточками
Идеально, когда доску можно посмотреть на одном экране. Если карточки не помещаются, теряется наглядность и сложнее управлять загрузкой команды.
В чем сложность. Бывают длительные проекты, например на два года. В таком проекте обычно сотни задач. Если все вынести на доску, легко запутаться.
Что сделать. Для сохранения наглядности мы создаем канбан-доски в рамках отдельных этапов проектов. Кроме того, выполненные задачи не отображаются на доске. Последний статус — это «В релиз», когда релиз готов к выпуску и задачи автоматически закрываются. Это значит, что работы по задаче завершены, проконтролированы и больше команда к ней не возвращается. Закрытые задачи убираются с доски, а в бэклог попадают активности из нового релиза.
2. Не дробить задачу на мелкие составляющие
Сохранить допустимое количество карточек помогает еще один принцип. Для планирования работы в команде нет необходимости видеть этапы каждой активности.
В чем сложность. Допустим, есть задача исследовать потребность клиентов в новой функциональности. В рамках этой работы нужно провести три встречи с пользователями, записать, расшифровать, составить ТЗ, поделиться с командой инсайтами. Если для каждого дела создать отдельную карточку, доска не будет наглядной.
Что сделать. Если в работе можно выделить отдельные блоки, то мы создаем задачи и подзадачи. Это вопрос декомпозиции активности для исполнителя, и с другими участниками команды делиться такими этапами неэффективно. Подзадачи удобно отслеживать на своей личной доске, а командную это перегружает.
3. Не перегружать карточку задачи
Помимо контроля наполнения доски важно управлять содержимым карточки. Это помогает сохранить допустимое количество объектов в фокусе внимания.
В чем сложность. Если добавим заказчика, список подзадач, описание задачи, то работать с таким объемом разных полей будет не очень удобно. Такая карточка сразу займет
Что сделать. Вынести на карточку только самые важные параметры задачи, которые помогают ее идентифицировать. Ведь вся дополнительная информация, необходимая для работы, содержится в самой задаче. Например, можно подробно описать план работы, приложить скриншот ошибки, макет интерфейса. Система позволяет добавлять изображения, видео, ссылки на дашборды, результаты отчетов, архивы. Возможности настройки не ограничены.
4. Использовать емкий заголовок
Чтобы быстро обсудить статус и переключиться на следующую задачу, членам команды важно с одного взгляда на карточку понимать, о какой активности идет речь.
В чем сложность. Зачастую название задачи длиннее, чем хотелось бы видеть на карточке. Те, кто создают задачи, используют это поле не просто для идентификации, а добавляют дополнительную информацию. Например, пишут дату или пояснение. В результате можем получить такой текст: «Реализация нового представления для отображения дат в сложных списках для мобильных устройств».
Что сделать. Для удобства всех участников мы вынесли на карточки два поля: номер задачи и краткое название. Так разработчик запоминает номер задачи, потому что пишет его по несколько раз за день в консоли системы контроля версий. Еще номер задачи нужен, т.к. он уникален и подходит для любых ссылок, отчетов, списков в разных системах. Аналитик, наоборот, часто не обращает внимание на номер задачи, он помнит ее
Когда мы использовали пробковую доску по старинке, поняли, что оптимальный вариант, когда название помещается в две строки. Далее это учли на
5. Визуализировать приоритеты
Чтобы эффективно работать над проектом, команде важно понимать, какие задачи в приоритете. Для этого срочные активности, которые требуют внимания в первую очередь, должны выделяться.
В чем сложность. Когда на доске много карточек и информации, сложно держать в фокусе ключевые задачи и не пропустить срок.
Что сделать. У нас приоритетность назначается при создании задачи. Возможности системы позволяют гибко настраивать цвета, количество и оповещения по задачам разных приоритетов. В своей команде используем такие значения:
- красный — блокер;
- розовый — критический;
- голубой — незначитальный;
светло-розовый — серьезный;- серый — тривиальный.
Кроме того, высокий приоритет устанавливается для задач, у которых подходит срок исполнения. Они дополнительно обозначаются визуальными индикаторами, которые помогают лучше ориентироваться. Например:
- огонь — для просроченных задач, у которых дедлайн уже прошел;
- восклицательный знак — для тех, где осталось меньше пяти дней до срока.
На доске не используются другие яркие элементы, поэтому такие индикаторы помогают сразу обращать внимание на важное.
Главное
- Выносить только активные задачи, по которым ведутся работы на определенном этапе проекта.
- Создавать карточки для крупных задач, которые необходимо обсуждать с командой, а подзадачи оставлять для личной доски.
- Выводить на стикере задачи только ключевую информацию, а детали поместить внутрь.
- Оставить поля, которые помогут всем членам команды без перехода в отдельную карточку понять, о каких работах идет речь.
- Визуализировать приоритеты, чтобы срочные задачи находить с одного взгляда.