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

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

Для кого это руководство

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

Что вы получите

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

- Просмотры для конкретных ролей с четкими дальнейшими действиями.

- Надежный статус, основанный на записях, а не на собраниях.

Четко назовите единицы работы

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

Разработайте небольшой конечный автомат

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

Сделать зависимости и блокировщики видимыми

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

Дайте каждой роли необходимое представление

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

Получайте отчеты на основе событий рабочего процесса.

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

Проведите пилотный проект одного повторяемого типа

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

Частые вопросы

Какова минимальная модель данных для инструмента проекта?

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

Сколько состояний рабочего процесса должно быть?

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

Должны ли клиенты использовать тот же интерфейс, что и персонал?

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

Какие показатели полезны?

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