Проект "Управление Проектами", фичи и приоритеты
Расскажу гипотетическую историю. Посмотрим как применять приоритезацию и функционально-ориентированную ("по-фичную") разработку к не-ИТ проектам. Получается очень интересно. Заодно расскажу, как одна компания ведёт работы по улучшению своих процессов.
Проблема на таких не-ИТ-проектах в их "воздушности". Т.е. если для разработки ПО есть некоторый, тоже виртуальный, но, всё же, воплощённый в коде и имеющий конкретную функциональность продукт. То, например, для проекта по "улучшению процессов разработки на проектах" это тяжелее, т.к. не совсем непонятно, что считать выходным продуктом, что считать требованиями и т.д. А сроки, как всегда, очень сжатые - всем хочется побыстрее прийти к светлому будущему =) Т.е. чётких дедлайнов нет, но есть жгучее желание упорядочить процессы, ввести контроль и т.д.
А что нас спасёт в случае сжатых сроков? Только приоритеты! =)
Итак, постановка задачи: "сделать, чтобы все проекты были успешными". Задача интересная и увлекательная =)
Давайте определимся с понятиями и ролями в таком проекте:
- Название проекта (а на самом деле это процесс): Управление Проектами.
- Заказчик: директор компании.
- Менеджер проекта: старший менеджер проектов.
- Команда: РМы компании.
Дальше, по-идее, нужно определиться с требованиями к проекту. Но тут есть проблема. Заказчиком, как всегда это бывает, озвучено только требование самого высокого уровня: "чтобы всё было круто!". Такое вот бизнес-требование. Хотя, это даже хорошо - больше свободы. А т.к. непосредственными пользователями системы будет сама компания, её сотрудники, а основными пользователями - менеджеры проектов. То, получается, что они - заказчики, они же и команда проекта. И они должны и требования поставлять... Немного путанно... Поэтому спокойно записываем данное требование как есть и копаем дальше.
В процессе переговоров о перспективах проекта (где, как всегда, менеджер проекта пытается выбить ресурсы, полномочия, бюджет и т.д. ;) ) выясняется, что у заказчика есть ещё одно существенное требование - ему нужно иметь инструмент контроля за проектами компании. Т.е. хочется иметь возможность быстро узнать о прогрессе на проекте, о укладывании в сроки, бюджет, когда придут деньги, сколько несём затрат и т.д.
Кладём это требование в систему управления проектами (СУП - Redmine, Mantis, MS Project и т.д.). При таком подходе проект-процесс "управление проектами" становится наравне с обычными проектами по разработке ПО и его можно вести в той же системе.
Т.о. у нас уже два высокоуровневых требования: "чтобы все проекты были успешными" и "инструмент контроля за ситуацией на проектах". Отлично - ситуация проясняется. Причем, Инструмент Контроля - более приоритетное требование, т.к., фактически, оно позволит оценить успешность самого проекта Управление Проектами. Не позволит ему стать "вечным" или пойти не по тому курсу. Ставим этому требованию "High" в СУПе =)
Что такое Инструмент Контроля мы уже примерно знаем - заказчик даже назвал параметры (прогресс, бюджет, сроки, даты прихода денег, затраты). Вопрос только - где их взять? Ведь на каждый проект "уникальный" со своим "уникальным" процессом и (!) своим уникальным СУПом. Хорошо ещё, что параметры достаточно общие и, по-идее, их можно найти в любом СУПе. Надеюсь...
Походу выяснения этого дела вспоминается, что в компании всегда был принцип "всё для заказчика". Соответственно, каждому заказчику тот СУП, который ему удобнее. И сейчас такой зоопарк разных СУПов, что каждому РМу придётся вручную заносить эти параметры в наш Инструмент Контроля. А где человеческий фактор там ошибки...
Может быть не всё так плохо? Действительно - оказывается, основных системы только три: старый добрый XPlanner, который был первым СУПом компании, JIRA - любимый СУП заказчика на одном из основных проектов, и Redmine, пришедший на смену XPlanner. Т.о. ближайшая цель - перенести проекты из XPlanner в Redmine. А потом написать какие-нить примочки, чтобы автоматически перекачивать данные из Redmine и JIRA в корпоративную ERP.
Отлично, т.о. требование Инструмент Контроля разбилось на несколько фич, каждая из которых получает свой приоритет:
- Highest - Организовать крутые и полезные отчёты в ERP.
- High - Организовать процесс заполнения ERP данными по всем проектам.
- High - Сделать все проекты успешными.
- Normal - Перенести проекты из XPlanner в Redmine.
- Normal - Написать примочку для перекачки данных из Redmine в ERP.
- Normal - Написать примочку для перекачки данных из JIRA в ERP.
Заметьте интересную вещь. Работать мы должны строго в порядке приоритета и доставлять наиболее полезные вещи первыми. "Сделать проекты успешными" имеет приоритет выше, чем всякие примочки и миграция. Может возникнуть соблазн поставить ему приоритет пониже. Но так делать нельзя, т.к. примочки и другая ерунда на самом деле всего лишь сделают Инструмент Контроля эффективнее, а время на их реализацию уйдёт. Нет, уж лучше мы позаполняем ERP вручную и будем параллельно работать над самими проектами разработки ПО, чем организуем крутой Контроль, который сам по себе мало даст. Как гласит принцип Бережливого Производства: нужно сначала немного упорядочить локальные процессы, а потом их склеить в общий. А упорядочивать какой-то один локальный процесс, если при этом другие менее эффективны - бесполезно!
Потому выпрашиваем аналитика для задачи с высочайшим приоритетом. А тем временем, свободные разработчики проекта назначают на себя задачу "Сделать проекты успешными". Начинаем думать - как это сделать проекты успешными? =)
И сразу начинаем видеть, что процесс работы проекта по разработке ПО состоит из множества процессов: процесса набора команды, процесса старта проекта, процесса аналитики, процесса работы команды на проекте и т.д. Каждый из них определённым образом влияет на проект. Ведь проект не висит в воздухе. Проект разработки ПО - это аккуратная и слаженная совокупная работа вышеописанных процессов. Например, как проект стартанёшь, какой договор заключишь, так потом и полетит. Или прилетит ;)
Далее пытаемся понять, какой из данных процессов где сбоит. Находим ряд проблем. Например следующую:
Каждый разработчик участвует одновременно в нескольких проектах. И тяжело планировать загрузку народа. Во-первых, не все заказчики просят фул-тайм разработчиков. Во-вторых, после окончания проекта обычно остаются какие-то доделки, мелкие и крупные импрувменты и т.д. Вообще, по-хорошему, любой проект по разработке ПО должен быть вечным. Это означает, что ваш продукт, результат ваших трудов, живее всех живых, растёт и развивается! Но тут проблема в том, что такие доделки сваливаются как снег на голову в произвольное время в произвольном объёме. И поэтому у любого разработчика есть активный проект, а есть проект, где он на поддержке. И на каждом таком проекте поддержки он не фиксированное количество часов, а плавающее - смотря будет работа или нет.
И вот вопрос - как планировать такую вот плавающую загрузку? А если разработчика поделили на два активных проекта и при этом у него ещё несколько "поддерживаемых" проектов? Засада одним словом!
Добавляем в Управление Проектами фичу "Проблема распределения народа по проектам". Другие проблемы - тоже. И выставляем приоритеты. Решать будем потом. Сначала нужно собрать проблемное поле.
А кроме проблем есть ведь ещё идеи! Вот начитается какой-нить РМ Деминга, Кента Бека, Тайити Оно и т.д. И с каждой прочитанной книгой в голове плодятся и плодятся ИДЕИ! =) И они требуют реализации, т.к. известно, что "большое знание - большая скорбь"! Мертвые знания вас только тяготят, а не приносят радости. Всё больше видишь несовершенство окружающего мира, а реализовать все идеи не успеваешь... Ну, это тема для отдельного топика ;)
Так вот - идеи тоже нужно класть в общий бэклог. Либо, если в бэклоге уже есть проблема, в решении которой может помочь некоторая идея, эту идею можно просто добавить в качестве комента к проблеме. Либо связать линками и т.д. И круто то, что любой сотрудник, в-принципе, может добавить свою фичу и попытаться выбить ей приоритет повыше.
Чего-то много написал и уже хочется подвести итог =)
В общем, имеем пул "фич", где фичей является
- Проблема сама по себе. И реализация фичи означает решение данной проблемы.
- Идея сама по себе. И реализация идеи означает приведение её в жизнь - в процессы фирмы.
И чем больше фича влияет на судьбу фирмы, тем выше приоритет она получает. Всё по классике - нужно смотреть соотношение полезность фичи/стоимость реализации.
Правда, оценивать это соотношение пока приходится интуитивно ;) Тут всё ещё сложнее, чем в проектах по разработке ПО - фик оценишь полезность и стоимость. Используйте метод парных сравнений или метод анализа иерархии! =)
Т.о. работая в порядке приоритета вы будете всегда доставлять наибольший результат первым. Если рук на всё не хватает - сосредоточьтесь на главном и действуйте!
P.S. Фичу "Проблема распределения народа по проектам" всё-таки запилили! =)