Как отслеживать несколько проектов без сложного программного обеспечения
Чтобы понимать, как продвигаются несколько проектов, создайте единый общий обзор. Он должен показывать ближайшую веху каждого проекта, текущий статус, подтверждение прогресса, следующее действие, ответственного и любые блокирующие факторы. Обновляйте его регулярно и используйте одинаковые определения статусов для всех проектов. Обычной маркерной доски, таблицы или простого документа вполне достаточно, если команда может поддерживать данные в актуальном состоянии и легко находить их. Это руководство предназначено для тех, кто координирует несколько активных проектов и кому нужно сразу видеть, где работа движется, где возникли риски, а где требуется решение или контроль. Основное внимание уделяется созданию удобного кросс-проектного обзора, а не детальному учету каждой отдельной задачи.
Начните с решений, которые вам необходимо принимать
Прежде чем выбирать формат, запишите вопросы, на которые должен отвечать этот обзор. Например: какие проекты укладываются в график до следующей вехи? Каким проектам требуется внимание на этой неделе? Ждет ли один специалист результатов другого проекта? Где требуется решение с моей стороны?
Эти вопросы помогают сфокусироваться на главном. Если вы начнете вносить туда каждую задачу, заметку и разговор, общая картина по всем проектам просто потеряется. Оставьте подробные списки задач там, где работа уже ведется; используйте обзор только для тех ключевых фактов, которые помогают координировать проекты между собой.
Это разграничение носит практический характер, а не является догмой управления проектами. В руководстве Atlassian по отчетам о статусе проектов рекомендуется фиксировать прогресс, предстоящую работу, а также сложности или блокеры. При работе с несколькими проектами полезно сделать эти поля достаточно унифицированными, чтобы их можно было легко просматривать и сравнивать бок о бок.
Создайте одностраничный обзор проектов
Выделите одну строку или карточку на каждый проект. В качестве основы используйте следующие поля:
Укажите название проекта и ожидаемый результат, его ближайшую наблюдаемую веху и целевую дату, текущий статус, свидетельство произошедших изменений, следующее действие и ответственного, любые блокировки или зависимости, а также дату последней проверки строки. Сохраняйте одинаковый порядок полей для каждого проекта.
Веха должна описывать то, что любой другой человек сможет однозначно признать завершенным, например: «черновик отправлен рецензентам» или «площадка мероприятия подтверждена». Формулировка «продвинуться по проекту» вехой не является. Выбирайте те контрольные точки, которые важны для принятия следующего решения или передачи результатов; длинный список мелких задач лишь затруднит восприятие обзора.
В руководстве Kanban University по методу Канбан визуализация работы и ее движения по рабочему процессу описывается как способ сделать скрытые рабочие процессы понятными и наглядными. Простой обзор применяет эту идею на уровне целых проектов: он показывает текущее состояние и этапы, на которых работа простаивает. При этом внедрять полноценную систему Канбан вовсе не обязательно.
Используйте статусы, понятные всем участникам одинаково
Цветовая маркировка полезна только тогда, когда все одинаково понимают ее значение. Напишите краткие определения рядом с обзором и применяйте их к ближайшей вехе, а не к смутному впечатлению о проекте в целом. Например:
В графике (On track): ближайшая веха ожидается к намеченному сроку, и в настоящее время нет нерешенных проблем, угрожающих ее срыву.
Внимание (Watch): возникли конкретные сложности, которые могут повлиять на веху, но следующий шаг по их устранению уже определен.
Заблокировано (Blocked): движение вперед невозможно, пока не будет решена конкретная проблема, принято решение или устранена зависимость.
Эти статусы — удобная рабочая договоренность, а не строгий стандарт. Согласуйте их с теми, кто будет обновлять обзор или использовать его. Если проекту присвоен статус «Внимание», укажите причину и действие, которое вернет его в категорию «В графике». Если проект «Заблокирован», назовите требуемую помощь и того, кто займется этим вопросом. Статус без пояснения стирает грань между серьезной проблемой и мелкой неопределенностью.
Не используйте процент выполнения как основной показатель для совершенно разнородных проектов. «80% готовности» могут означать принципиально разные вещи для дизайна, подготовки мероприятия и исследовательской задачи. Контрольная точка с четкой датой и наглядным результатом дает читателю гораздо более надежную основу для оценки. Это практический выбор для сопоставимости данных, а не утверждение, что проценты бесполезны вообще; они вполне могут работать внутри одного проекта, где объем задач можно измерить точно.
Установите необременительный график обновлений
Обзор приносит пользу только тогда, когда участники уверены в актуальности информации. Выберите ритм обновлений, соответствующий скорости изменений в проектах. Для большинства небольших команд хорошей отправной точкой станет еженедельная проверка, однако для более размеренных процессов обновления могут требоваться реже, а для быстро меняющихся — чаще. Компания Atlassian в своем руководстве также советует выбирать периодичность отчетов о статусе с учетом сложности проектов и потребностей заинтересованных сторон.
Во время каждого обновления просите владельца каждого проекта проверять четыре пункта:
1. Изменилась ли ближайшая веха, целевая дата или ответственный?
2. Какая конкретная работа была выполнена с момента прошлой проверки?
3. Появились ли блокирующие факторы, новые зависимости или нерешенные вопросы?
4. Каково следующее действие и когда оно будет проверено снова?
Фиксируйте дату обновления. Если строка давно не проверялась, пометьте ее как «не обновлялось» или уточните информацию у ответственного, прежде чем считать статус актуальным. Это убережет от ситуации, когда устаревшая метка «В графике» принимается за свежую оценку. При переносе даты обязательно кратко фиксируйте причину или решение, повлекшее изменения; иначе череду постоянных сдвигов сроков будет невозможно объяснить.
Если вы проводите встречи по статусу, посвящайте их только отклонениям и координации действий. Ознакомьтесь с записями заранее, а время встречи потратьте на обсуждение заблокированных задач, рисков срыва вех, зависимостей и решений, влияющих сразу на несколько проектов. Рутинный прогресс можно зафиксировать письменно, не пересказывая вслух каждую задачу. Это совет по повышению эффективности, вытекающий из назначения обзора, а не гарантия того, что регламент встреч подойдет абсолютно любой команде.
Выявляйте зависимости между проектами
Каждый проект по отдельности может выглядеть благополучным, но при этом они могут конкурировать за одного и того же сотрудника, решение руководства, помещение, оборудование или время согласования. Фиксируйте зависимость каждый раз, когда один проект ждет чего-то от другого; указывайте передающую и принимающую стороны, а также критическую дату или условие. Например: «Для запуска сайта нужны окончательные данные от проекта мероприятия до 12 мая».
Затем проверяйте обзор на предмет пересечения задействованных людей и дат. Если за одним человеком числится несколько срочных задач с одинаковым дедлайном или задержка решения в одном проекте сдвигает сроки другого, сделайте этот конфликт видимым и согласуйте приоритеты либо скорректируйте планы. В этом и заключается главное преимущество единого обзора перед разрозненными отчетами: он позволяет сопоставить обязательства и зависимости в одном месте. Процесс управления портфелем проектов Project Management Institute точно так же фокусируется на ключевых вехах, статусах и взаимосвязях проектов вместо заполнения общего реестра мелкими задачами; предлагаемый здесь компактный формат — это адаптация данного подхода для небольших команд.
Не считайте зависимость решенной только потому, что у нее назначен ответственный. Зафиксируйте ожидаемую передачу результатов и подтвердите факт ее выполнения, когда это произойдет. Если последовательность действий или срок вызывают сомнения, прямо укажите на это: открыто признанную неопределенность обсудить гораздо проще, чем необоснованное обещание.
Выбирайте самый простой формат, сохраняющий удобство
Используйте таблицы, если вам необходимы сортировка строк, фильтры по датам или компактный вид для большого числа проектов. Используйте маркерную доску, если команда работает в одном помещении и вам удобно физически перемещать карточки по этапам. Используйте общий текстовый документ, если отчеты представляют собой короткие письменные сводки, а самих проектов немного.
Это компромиссы между форматами, а не рекомендации конкретных программ. Выбирайте самый простой инструмент, к которому у команды есть доступ и который легко заполнять и понимать. Прежде чем внедрять новое ПО, спросите себя, в чем реальная проблема: сложно сравнить статусы? Отчеты запаздывают? Зависимости неочевидны? Новый инструмент может помочь с коммуникацией или напоминаниями, но он сам по себе не сделает размытые вехи четкими и не назначит ответственных.
Если проектам требуются специфические технические детали, ведите их в профильных рабочих системах, а в общем обзоре лишь давайте ссылку или краткое упоминание при необходимости. Кросс-проектный обзор должен оставаться компактным и легко читаемым. Если вам приходится раздувать его новыми колонками, подумайте, не дублируют ли они существующие поля и не место ли этим деталям в рабочих заметках конкретного проекта.
Пример использования
Предположим, координатор ведет три проекта: городское мероприятие, обновление веб-сайта и ежемесячную рассылку. Его обзор может выглядеть следующим образом:
Пример: Городское мероприятие в статусе «Внимание», поскольку две потенциальные площадки еще не забронированы; ответственный сравнит их доступность до 8 мая, чтобы успеть к вехе согласования площадки 12 мая. Обновление веб-сайта — «В графике», черновики страниц переданы рецензентам; комментарии ожидаются к 10 мая для проведения ревью 15 мая. Ежемесячная рассылка — «Заблокировано», так как финальный текст требует утвержденных деталей мероприятия; ответственный запросит их до 7 мая, чтобы успеть к вехе сдачи текста 9 мая.
Это лишь наглядная иллюстрация, а не реальные данные. Такой обзор сразу вскрывает зависимость: рассылка зависит от деталей мероприятия. Он также подсказывает правильное следующее действие: выяснить, удастся ли принять решение по мероприятию вовремя для рассылки, или же скорректировать график выпуска рассылки. Один только цвет статуса не показал бы ни истинную причину проблемы, ни требуемые шаги по координации.
Когда этому подходу требуется больше структуры
Одностраничного обзора может стать недостаточно, когда слишком много людей одновременно редактируют одни и те же данные, когда проекты имеют сложные графики или бюджеты, когда требуется строгое разграничение прав доступа или обязательное протоколирование решений и изменений. Вы по-прежнему можете сохранять лаконичную сводку по проектам, но для хранения детальной информации могут понадобиться более структурированная система и четкое распределение зон ответственности.
Для небольшого портфеля проектов начните с базового набора полей, согласуйте формулировки статусов и регулярно отслеживайте контрольные вехи. Если такой обзор помогает вам видеть проблемные места и координировать следующие шаги — он справляется со своей задачей. Если же он превращается в очередную формальную таблицу, которую заполняют не глядя, упростите его или пересмотрите вопросы, на которые он должен отвечать.