Skip to content
Кейсы по Coda
Трекинг задач при использовании гибридного подхода
More
Share
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
⁠
была создана таблица реестра задач. Реестр дополнялся ежедневно по итогам рабочих встреч команды и встреч с заказчиком, ответственными за организацию встреч и ведение протоколов. Исполнители по мере необходимости также могли внести в реестр свои задачи.
⁠
image.png
⁠
⁠
Все задачи просматривались командой на ежедневных рабочих встречах, уточнялся их статус, прогнозные сроки завершения, обсуждались проблемы и риски, если они возникали.
Постепенно мы сформировали для себя два дополнительных правила использования таск-трекера:
Скрыли задачи со статусами “готово” и “отменено”, чтобы освободить рабочее пространство.
Присвоили всем новым задачам статус “бэклог”. Член команды вносивший задачу в таск-трекер часто не мог объективно оценить ее сроки или затруднялся определить ответственного по ней, поэтому “бэклог” на ежедневных встречах рассматривался командой в первую очередь. Для него определялись ответственные и плановые сроки, оценивалась необходимость перехода в статус “сделать”: так мы исключили возможность просрочки.
С момента перехода задачи в статус “сделать” ответственность за ее выполнение нес ответственный за задачу. Он решал, когда переводить задачу “в работу”, а затем в приемку”, информировал команду о рисках, проблемах и предпринятых действиях. Самым сложным в этой процедуре оказалось привыкнуть ежедневно проверять статусы своих задач в таск-трекере перед встречей команды.
Чтобы упростить процедуру подготовки к встрече и сократить время на нее, на базе таблицы реестра задач были сформированы представления для каждого члена команды в формате канбан-доски. В представление отбирались задачи, в которых член команды являлся ответственным или соисполнителем, чтобы была возможность наглядно оценивать загруженность члена команды. Когда канбан-доска исполнителя оказывалась перегружена задачами в статусах “сделать” и “в работе”, он обращался к команде с просьбой о помощи или о перераспределении части задач. Таким образом, таск-трекер помогал выравнивать загрузку членов команды.
⁠
image.png
⁠
⁠

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

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

Вывод

Использование ноукод инструмента позволило создать базовую оболочку трекера за несколько часов. Его доработка проводилась нами сразу, как только команда решала, что конкретно необходимо изменить, и в сумме тоже занимала не более часа.
Благодаря созданному таск-трекеру мы получили несколько значимых результатов:
Фиксация всех задач
Понятность, единообразность и наглядность отображения информации по задачам
Площадка для командного обсуждения задач
Инструменты и процедуры распределения объема задач по временным периодам и исполнителям
Фиксация ответственности членов команды за конкретные задачи

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

Продолжу рассказ про наш таск-трекер для контроля оперативных задач, который начал в части 1: “Кто за что отвечает?!” .
Работа с таск-трекером оказалась настолько удобной, что постепенно туда переместились все задачи команды по проекту, в том числе сформированные для выполнения работ плана проекта.
Но это тут же привело к сбоям в командной работе.
Во-первых, трекер и процедуры работы с ним были рассчитаны на относительно небольшое количество задач, которое команда должна была успевать ежедневно обсуждать на получасовой рабочей встрече. Увеличение количества задач сначала привело к затягиванию времени встречи, а затем к тому, что задачи стали рассматриваться избирательно - часть из них оказались на грани просрочки.
Во-вторых, работы из плана проекта в трекере не отображались, а формулировки задач, созданных для их детализации, не всегда позволяли отнести их к конкретной работе. Команда тратила время на уточнение сути задачи и ее влияние на другие задачи реестра.
Требовалось решение, которое бы позволило рассматривать связанные задачи в совокупности, сокращая время “включения” команды в контекст конкретной задачи. При этом небольшая длительность задач и наличие среди них большого числа несвязанных с планом проекта “поручений” делала неудобным использование классических инструментов управления взаимосвязями работ в проекте, например: иерархия работ проекта и установление последовательности выполнения работ на календарном графике (диаграмма Ганта).

Цель

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

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

Перепробовав различные варианты, мы выбрали группировку задач по результатам проекта, ведь насколько бы оперативной не была задача она всегда возникает в контексте создания конкретного результата. Но оказалось, что результаты проекта для наших целей не подходят, потому что в краткосрочном периоде мы работали над одним, максимум тремя результатами и группы задач получались слишком большими и разнородными.
Тогда мы ввели понятие ключевого результата и ограничили его размер сроком получения - две недели. Таким образом, у нас появился переходный уровень между планом проекта и оперативными задачами.
⁠
Ключевой результат - внутренний промежуточный результат, который необходим для получения результата этапа или проекта в целом.
⁠
В таск-трекер наименования ключевых результатов внесли в один столбец с задачами и добавили классификацию объектов по типам (задача и ключевой результат).
⁠
image.png
⁠
⁠
Такой подход оказался не очень удобен, так как настроить нужную нам последовательность отображения строк инструментами
Coda.io
⁠
не получилось. Поэтому мы отфильтровали ключевые результаты в отдельный столбец, создали для каждой задачи связь с ключевым результатом и сгруппировали их, получив удобный для использования вид.
⁠

Ограничение

Если вы планируете использовать в своем трекере многосоставные фильтры задач, например одновременно по ключевому результату, статусу задачи и сроку, то мы рекомендуем изначально формировать ключевые результаты, как и другие типы самостоятельных данных, в виде отдельного столбца. Как показал опыт, формулы при использовании нашего сценария создания ключевых результатов значительно более трудоемкие.
⁠
⁠
image.png
⁠
⁠
Каждая задача в трекере теперь соответствовала ключевому результату и рассматривалась в совокупности с другими задачами относящимися к нему же. Мы получили возможность определять достаточность поставленных задач для достижения ключевого результата, быстро выявлять дублирующие задачи и задачи с пересекающимся содержанием. Кроме того, теперь было наглядно видно, на какой периметр задач может повлиять просрочка одной из них.
Но были и сложности. В первую очередь, требовалось выделить время для определения ключевых результатов на период, а включение этого вопроса в повестку ежедневных встреч опять приводило к их затягиванию, поэтому в практику было введено еженедельное получасовое совещание по планированию ключевых результатов. В рамках совещания оценивалась готовность ключевых результатов (статусы ключевых результатов остались те же, что и у задач) и формулировались новые ключевые результаты на период.
Тут же встал вопрос, кто должен добавлять задачи в тот или иной результат, оценивать их достаточность и в случае необходимости формировать дополнительные. Задачи, создаваемые по итогам совещаний и встреч, все также вносились ответственными за встречи и протоколы. Добавился только дополнительный параметр данных - ключевой результат. Ответственные исполнители следили за уже назначенными им задачами, командные встречи явно не были предназначены для проведения такого анализа из-за ограничений времени (не более часа).
Поэтому были назначены отдельные ответственные за ключевые результаты. Они же стали отслеживать получение ключевого результата, наличие рисков отклонений по нему и информировать об этом команду, а в случае необходимости координировать работу ответственных исполнителей. Таким образом, ежедневные встречи перешли в формат обсуждения статуса ключевых результатов, а конкретные задачи рассматривались, только если по ним возникали проблемы и риски. Для контроля за ключевыми результатами на базе таблицы реестра задач были сформированы отдельные представления для ответственных за ключевые результаты.
⁠
image.png
⁠
⁠
Следующей проблемой стало то, что “перспективным” задачам в статусе “бэклог”, в том числе и созданным на основе протоколов совещаний с заказчиком, мог не соответствовать ни один из имеющихся в двухнедельном периоде ключевых результатов. Если раньше на ежедневных встречах команда в первую очередь рассматривала эти задачи, то при переходе обсуждения на формат ключевых результатов возник риск, что задачи бэклога, не отнесенные к конкретному результату, просто потеряются. Поэтому один из ответственных за ключевые результаты был назначен ответственным за нераспределенный бэклог задач - ежедневно просматривал его, формировал предложения по формулировкам новых ключевых результатов. Предложения по новым ключевым результатам рассматривались на еженедельном совещании по планированию, а в случае возникновения срочных задач в бэклоге новый ключевой результат мог быть создан и в рамках ежедневной рабочей встречи.

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

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

Вывод

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

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

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

Цель

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

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

В первую очередь, мы сформировали ряд инструментов, которые должны были упростить ответственным выделение важных задач и снизить риск возникновения проблем. В качестве инструментов для этого мы выбрали приоритизацию задач и формулирование открытых вопросов.
1. Приоритизация задач является распространенным инструментом и позволяет исполнителю определять те задачи, которые необходимо выполнять в первую очередь. Изначально мы использовали стандартные оценки приоритета (высокий, средний, низкий) и столкнулись с тем, что не можем уверенно сказать, какую оценку должна иметь конкретная задача, более того, мнения разных членов команды могли значительно отличаться. Поэтому основной мерой приоритетности мы выбрали включение задачи в протокол встречи с заказчиком. То есть, если встреча вносится из протокола, приоритет задачи высокий, если формируется командой самостоятельно - средний.
При обсуждении задач нам оказалось важно знать, когда сформирована задача, на каком совещании, кто был ее инициатором. Например, в проекте был ряд задач, поставленных заказчиком, которые в результате смены ключевого решения проекта потеряли актуальность, но их отмену нам нужно было согласовать с их инициатором, указав контекст ситуации, в которой они были поставлены. Поэтому вместо приоритета мы стали использовать источник, указывая встречу, в протоколе которой содержалась задача. Так мы одновременно отмечали задачи с высоким приоритетом и фиксировали документ, в котором могли найти информацию о причинах создания задачи.
2. Управление открытыми вопросами позволяет фиксировать ситуации, в которых оптимальный способ выполнения задачи не очевиден. Открытый вопрос не является риском, потому что мы не только не можем без дополнительных исследований оценить влияние выбранного способа выполнения задачи на результат, но и часто в принципе не можем определить способ выполнения задачи. Именно по этой причине открытые вопросы относят к области неопределенности проекта.
⁠
Открытый вопрос - ситуация в проекте, в которой возможны несколько вариантов действий или решений, и требуется выбор одного из них. Открытые вопросы возникают, когда неопределенность в проекте настолько высока, что определить варианты действий без дополнительного исследования затруднительно.
⁠
Члены команды обладают разными компетенциями и опытом , поэтому бывают ситуации, когда для одного члена команды способ выполнения задачи является открытым вопросом, а для другого существует очевидное решение. Не редки и ситуации, когда правильного решения для открытого вопроса в проекте не существует, и команда вынуждена проводить мозговой штурм, чтобы выбрать оптимальный способ действий.
На мой взгляд, оставить человека с открытым вопросом один на один, на которые неизвестно где искать ответ - это прямой способ привести к невыполнению задачи и нарушению ее сроков, не говоря уже о влиянии на мотивацию члена команды. Поэтому в реестре задач мы ввели поле для фиксации открытых вопросов с привязкой к конкретным задачам. Его заполнение может происходить для задач во всех статусах кроме “готово” и “отменено”. Открытые вопросы по задаче могут возникать в разных ситуациях, но наиболее распространенными являются:
Обсуждение на совещании - тогда открытый вопрос из протокола переносится ответственным за встречу и протокол в реестр задач.
Выполнение задачи - тогда возникший открытый вопрос ответственный за задачу фиксирует в реестре.
Ответственность за своевременное вынесение на обсуждение командой открытых вопросов лежит в первую очередь на ответственном за задачу, но если ответственный за ключевой результат долгое время не фиксирует действий по их решению, то инициатором рассмотрения открытого вопроса может выступить он.
⁠
image.png
⁠
⁠
Во вторую очередь, нами было сформировано представление для встреч, которое не позволяло бы выходить за рамки вынесенных на обсуждение вопросов и при этом содержало всю необходимую информацию для обсуждения.
Настраивая представление для ежедневных рабочих встреч мы сосредоточились на представлении там только тех задач, которые наиболее актуальны к рассмотрению.
Сначала мы использовали отбор задач по плановому сроку выполнения, отбирая задачи текущей недели. Но мы могли упустить важные задачи следующей недели, которые при этом не отображались.
Затем мы настроили фильтр на задачи со сроком выполнения в следующие 7 дней, оказалось, что в этом случае из-за небольшой длительности большинства задач слишком большое их количество попадает в рассмотрение на ежедневной встрече.
Тогда мы использовали уже не раз апробированный на этом проекте подход с передачей ответственности членам команды. Для этого мы создали задачам отметку “Обсудить на стендапе”, благодаря которой ответственные за задачи и ключевые результаты могли отмечать задачи, которые они хотят обсудить с командой. А для ежедневных встреч сформировали представление, в которое попадали только задачи, имеющие отметку к обсуждению.
Ответственные за задачи и ответственные за ключевые результаты ежедневно перед встречей просматривали статусы своих задач и отмечали те, которые требуют обсуждения. Мы не стали формировать отдельные правила вынесения задач на обсуждение, так как, на наш взгляд, оснований для этого множество.
Конечно, в большинстве случаев включение задачи в повестку коррелирует с наличием по задаче риска отклонения по срокам, открытых вопросов, блокированием ее другими задачами, но также на встречу команды может быть вынесена задача, которая долго находится в статусе “приемка” или которая, не выходя из статуса “бэклога”, потеряла актуальность, и требуется командное решение об ее отмене.
Мы считаем, что все члены нашей команды достаточно компетентны, чтобы выносить на обсуждение только действительно важные вопросы и, аналогично, если кто-то из членов команды выносит вопрос на обсуждение, то вопрос для него достаточно важен и следовательно требует обсуждения - это наши правила командного взаимодействия, и поэтому ограничений для включения задачи в повестку у нас нет.

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

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

Вывод

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

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

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

Цель

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

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

Как я уже говорил, инструменты
Coda.io
⁠
позволяют настраивать разные представления на базе одной таблицы, и представление для встреч с заказчиком мы формировали также на основании таблицы реестра задач: так мы могли использовать уже внесенные данные, а не дублировать их вручную, а их актуализация в представлении происходила автоматически.
В первую очередь, для отбора в представление актуальных задач мы воспользовались ранее опробованным фильтром на задачи со сроком выполнения в следующие 7 дней и аналогичным фильтром на задачи со сроком выполнения в предыдущие 7 дней, так как на повестке встреч стояли планирование задач на недельный период и отчет за предыдущую неделю.
Во-вторых, мы убрали из представления задачи со статусами “бэклог”, как еще не переведенные в работу” и “отменено”, так как их выполнение больше не планировалось, оставив задачи со статусом “готово”, так как заказчик хотел видеть объем выполненных работ.
В третьих, мы оставили в представлении только те данные, которые интересовали заказчика:
Наименование задачи.
Статус.
Плановый срок выполнения.
Прогнозный или фактический срок выполнения.
Отклонение от планового срока выполнения.
Блокировка.
Ответственный исполнитель.
И последнее, не сложное, но трудоемкое действие, мы создали новую характеристику задачи - “Направление” и определили ее для каждой задачи проекта на основании списка направлений, который нам предоставил заказчик. После заполнения данных мы сгруппировали задачи и получили новое представление. Ключевые результаты мы при этом из представления полностью скрыли.
Основная трудоемкость создания представления пришлась на заполнение дополнительного поля для всех задач проекта, а их на тот момент было более 500, чтобы исключить задачи, не группируемые по направлениям.
⁠
image.png
⁠
⁠

Вывод

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

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

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







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.