Кейсы по Coda

Трекинг задач при использовании гибридного подхода

Explore

Трекинг задач при использовании гибридного подхода

PM Logix

Скрины

Скрины перевод

Трекинг задач при использовании гибридного подхода. Часть 1: “Кто за что отвечает?!”

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

Потребность в таск-трекере возникла на одном крупном проекте в производственном холдинге. Мы заканчивали диагностику, согласовывали ее результаты и параллельно прорабатывали варианты решений проблем. Держать фокус внимания на обоих направлениях одновременно было сложно из-за небольшого размера команды (до 5 человек), к тому же заказчик периодически менял формат взаимодействия, что добавляло хаоса.

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

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

Для создания трекера выбрали

Coda.io⁠

, так как этот ноукод инструмент:

Обладает достаточной гибкостью в настройке типов данных (от текстовых до шкалы значений и возможности голосования) и форматов их представлений (таблица, календарь, канбан-доска, карточки).

Позволяет настроить несколько разных представлений на базе одной таблицы.

Имеет табличные представления похожие на Excel - с привычным интерфейсом и поддержкой использования формул.

Не требует программирования или сложного конфигурирования при настройке.

Подробнее о выборе сервиса для таск-трекера я писал в статье

Как мы настроили таск-трекер за 4 дня без кода (кейс применения coda.io)⁠

, а о преимуществах и недостатках ноукод инструментов в статье

Ноукод для проектного управления: преимущества и недостатки⁠

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

Coda.io⁠

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

Сегодня расскажу путь создания нашего таск-трекера, так как, используя ноукод сервис, вы можете легко создать уникальный, настроенный именно под ваши задачи инструмент.

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

⁠

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

⁠

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

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

Цель

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

Технология решения: планирование задач

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

Мы решили начать с минимального набора и затем уже определиться с тем, что еще нам может потребоваться. Таким образом, мы выделили для себя:

Наименование задачи

Статус выполнения задачи

Плановый срок выполнения задачи

Прогнозный срок выполнения задачи (мы объединили для удобства в одном столбце с фактическим сроком выполнения)

Величина отклонения прогнозного/фактического срока от планового (добавили для наглядности)

Ответственный за выполнение задачи

Соисполнители по задаче

Первые же дни использования таск-трекера показали, что, если мы хотим, чтобы задачи были понятны всем, команде необходимо договориться о правилах их формулировки. Мы сформировали для себя шесть правил изложенных ниже.

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

⁠

Правила формулировки задач

1.Четкое, конкретное и понятное действие - можно сразу начинать делать.

2. Формулировка задачи = первый шаг ее выполнения.

3. Формулировка задачи должна звучать как ответ на вопрос «что нужно сделать?»

4. Формулировка должна начинаться с глагола в форме инфинитива.

5. В идеале формулировка должна вызывать внутренний возглас: «Да это уже проще сделать, чем записать!».

6. Задачу можно выполнить максимум за несколько часов.

⁠

Примеры хороших формулировок задач:

1. Позвонить Васе, спросить, удобно ли ему встретиться в 12:00 в понедельник.

2. Написать Коле письмо с просьбой прислать свежее описание кейса клиента.

3. Позвонить в управляющую компанию, спросить телефон слесаря.

4. Напомнить Оле прислать замечания к договору.

⁠

Второй трудностью для нас стали статусы задач. Изначально мы выбрали три статуса:

Сделать - для не начатых задач.

В работе - для задач, которые выполняются.

Готово - для завершенных задач.

Практика быстро показала, что этого недостаточно, поэтому мы добавили статусы:

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

Приемка - согласование результатов выполнения задачи как заказчиком, так и внутри команды оказалось делом не быстрым, а статус “в работе” говорил, что исполнитель выполняет работу, а не о том, что уже ожидается приемка.

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

Отменено - задачи, которые в ходе проработки проекта потеряли свою актуальность. Чаще всего в этот статус переходят задачи из “бэклога”, но бывает, что и задачи находящиеся “в работе”.

Coda.io⁠

была создана таблица реестра задач. Реестр дополнялся ежедневно по итогам рабочих встреч команды и встреч с заказчиком, ответственными за организацию встреч и ведение протоколов. Исполнители по мере необходимости также могли внести в реестр свои задачи.

⁠

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

Постепенно мы сформировали для себя два дополнительных правила использования таск-трекера:

Скрыли задачи со статусами “готово” и “отменено”, чтобы освободить рабочее пространство.

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

С момента перехода задачи в статус “сделать” ответственность за ее выполнение нес ответственный за задачу. Он решал, когда переводить задачу “в работу”, а затем в приемку”, информировал команду о рисках, проблемах и предпринятых действиях. Самым сложным в этой процедуре оказалось привыкнуть ежедневно проверять статусы своих задач в таск-трекере перед встречей команды.

Чтобы упростить процедуру подготовки к встрече и сократить время на нее, на базе таблицы реестра задач были сформированы представления для каждого члена команды в формате канбан-доски. В представление отбирались задачи, в которых член команды являлся ответственным или соисполнителем, чтобы была возможность наглядно оценивать загруженность члена команды. Когда канбан-доска исполнителя оказывалась перегружена задачами в статусах “сделать” и “в работе”, он обращался к команде с просьбой о помощи или о перераспределении части задач. Таким образом, таск-трекер помогал выравнивать загрузку членов команды.

⁠

Лайфхаки, улучшившие наш трекер

Автоматическая рассылка уведомлений членам команды на электронную почту при создании новых задач или изменении старых, в выполнении которых они участвуют.

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

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

Вывод

Использование ноукод инструмента позволило создать базовую оболочку трекера за несколько часов. Его доработка проводилась нами сразу, как только команда решала, что конкретно необходимо изменить, и в сумме тоже занимала не более часа.

Благодаря созданному таск-трекеру мы получили несколько значимых результатов:

Фиксация всех задач

Понятность, единообразность и наглядность отображения информации по задачам

Площадка для командного обсуждения задач

Инструменты и процедуры распределения объема задач по временным периодам и исполнителям

Фиксация ответственности членов команды за конкретные задачи

Трекинг задач при использовании гибридного подхода. Часть 2: “Все ли задачи мы внесли?!”

Продолжу рассказ про наш таск-трекер для контроля оперативных задач, который начал в части 1: “Кто за что отвечает?!” .

Работа с таск-трекером оказалась настолько удобной, что постепенно туда переместились все задачи команды по проекту, в том числе сформированные для выполнения работ плана проекта.

Но это тут же привело к сбоям в командной работе.

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

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

Требовалось решение, которое бы позволило рассматривать связанные задачи в совокупности, сокращая время “включения” команды в контекст конкретной задачи. При этом небольшая длительность задач и наличие среди них большого числа несвязанных с планом проекта “поручений” делала неудобным использование классических инструментов управления взаимосвязями работ в проекте, например: иерархия работ проекта и установление последовательности выполнения работ на календарном графике (диаграмма Ганта).

Цель

Таким образом, целью модификации таск-трекера на этом шаге стало обеспечить возможность рассмотрения задач в контекcте.

Технология решения: группировка задач

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

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

⁠

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

⁠

В таск-трекер наименования ключевых результатов внесли в один столбец с задачами и добавили классификацию объектов по типам (задача и ключевой результат).

⁠

Такой подход оказался не очень удобен, так как настроить нужную нам последовательность отображения строк инструментами

Coda.io⁠

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

⁠

Ограничение

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

⁠

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

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

Тут же встал вопрос, кто должен добавлять задачи в тот или иной результат, оценивать их достаточность и в случае необходимости формировать дополнительные. Задачи, создаваемые по итогам совещаний и встреч, все также вносились ответственными за встречи и протоколы. Добавился только дополнительный параметр данных - ключевой результат. Ответственные исполнители следили за уже назначенными им задачами, командные встречи явно не были предназначены для проведения такого анализа из-за ограничений времени (не более часа).

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

⁠

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

Лайфхаки, улучшившие наш трекер:

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

Фиксация требований и комментариев, возникающих при обсуждении на встречах команды в отдельном столбце + чек-листы с автоматическим вычеркиванием пунктов после выполнения.

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

Вывод

Еще раз отмечу преимущества нашего решения использовать ноукод инструмент. В этот раз доработка таск-трекера заняла у нас около 2-3 дней. Мы перепробовали несколько разных способов ввода и отображения данных, каждый раз обсуждая результат с командой, пока не настроили удобное нам представление.

То есть, мы несколько раз изменили функционал таск-трекера, все это время параллельно продолжая решать основные задачи по проекту, фиксируя их и их исполнение в нем же, и при этом никакая информация не потерялась.

По итогам доработки нашего таск-трекера мы получили такие значимые результаты:

Создали условия контроля необходимости и достаточности задач в реестре и их взаимосвязи.

Синхронизировали реестр задач с планом проекта за счет:

Промежуточного звена планирования - ключевого результата.

Еженедельного совещания по планированию ключевых результатов.

Роли ответственного за ключевой результат.

Повысили качество и сократили время проведения ежедневных встреч команды.

Трекинг задач при использовании гибридного подхода. Часть 3: “Как повысить качество командных встреч?!”

Продолжаю рассказ про трансформацию нашего таск-трекера для контроля оперативных задач, который начал в части 1: “Кто за что отвечает?!” и продолжил в части 2 “Все ли задачи мы внесли?!”.

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

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

Цель

Целью модификации таск-трекера стало оптимизировать представление для встреч, чтобы фокусироваться на наиболее важных задачах.

Технология решения: представления для встреч

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

1. Приоритизация задач является распространенным инструментом и позволяет исполнителю определять те задачи, которые необходимо выполнять в первую очередь. Изначально мы использовали стандартные оценки приоритета (высокий, средний, низкий) и столкнулись с тем, что не можем уверенно сказать, какую оценку должна иметь конкретная задача, более того, мнения разных членов команды могли значительно отличаться. Поэтому основной мерой приоритетности мы выбрали включение задачи в протокол встречи с заказчиком. То есть, если встреча вносится из протокола, приоритет задачи высокий, если формируется командой самостоятельно - средний.

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

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

⁠

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

⁠

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

На мой взгляд, оставить человека с открытым вопросом один на один, на которые неизвестно где искать ответ - это прямой способ привести к невыполнению задачи и нарушению ее сроков, не говоря уже о влиянии на мотивацию члена команды. Поэтому в реестре задач мы ввели поле для фиксации открытых вопросов с привязкой к конкретным задачам. Его заполнение может происходить для задач во всех статусах кроме “готово” и “отменено”. Открытые вопросы по задаче могут возникать в разных ситуациях, но наиболее распространенными являются:

Обсуждение на совещании - тогда открытый вопрос из протокола переносится ответственным за встречу и протокол в реестр задач.

Выполнение задачи - тогда возникший открытый вопрос ответственный за задачу фиксирует в реестре.

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

⁠

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

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

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

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

Тогда мы использовали уже не раз апробированный на этом проекте подход с передачей ответственности членам команды. Для этого мы создали задачам отметку “Обсудить на стендапе”, благодаря которой ответственные за задачи и ключевые результаты могли отмечать задачи, которые они хотят обсудить с командой. А для ежедневных встреч сформировали представление, в которое попадали только задачи, имеющие отметку к обсуждению.

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

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

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

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.