Все что описано ниже это лишь мой опыт и мое мнение. Более того, поскольку управление проектами моя основная специальность, я знаю, что нет универсальных решений. Есть ряд систем и методов, которые работают. Для каждой команды набор этих методов, принципов и систем уникален, так как зависит от качеств команды, ее задач, типов проектов и условий работы.
Четкая иерархия
Основной человек менеджер проектов, во что-то иное я не верю. Плоские системы управления — подходят для уникального опыта и экспериментов. Всегда должен быть человек, который является связующим звеном между клиентом и исполнителем, человек ответственный за конечный результат, заинтересованный в результате и успехе проекта. Менеджер проекта — тот кто может видить всю картинку с позиции клиента и исполнителя. Независимый, действующий по определенной системе в стратегическом плане, но способный тактически на интуитивные решения, на оценку ситуации и быстрое принятие решений.
Конечно, главным человек все равно останется клиент, ведь без него проект не состоялся бы вовсе. Но когда работа началась все внимание и вся ответственность на менеджере, его действия способны довести проект до конца или разрушить работу.
Исполнитель никогда не должен обсуждать с клиентом рабочие моменты, а также отчитываться и получать напрямую от него задачи . Все только через менеджера. Да, исполнитель (дизайнер, программист и кто-то иной) может присутствовать на встречах при обсуждении проекта в целом, чтобы понимать суть и цели изнутри. Но не более того. Причины такой строгой позиции в простых вещах: исполнитель никогда не может самостоятельно и точно оценивать свое время, затраты и текущее положение дел. Когда мы своими руками делаем работу, мы завышаем или занижаем стоимость, с невероятным оптимизмом предсказываем результаты и сроки. Человеку со стороны, в данном случае менеджеру проектов, все видно чуть лучше, без эмоций и с трезвой оценкой. В критической ситуации мы лишь в самый последний момент признаем неправоту и что сроки вышли. Опытный менеджер увидит проблему раньше, сообщит о ней клиенту и тем самым спасет проект от краха. А еще исполнитель катастрофически теряет свое время, если ему нужно самому составлять отчеты перед клиентом. Между прочим исполнитель не должен вообще составлять отчеты ни перед кем, даже перед менеджером. Отчеты и анализ — это работа менеджера. Исполнитель лишь дает краткие маркеры: что сделано, что делается сейчас, что будет сделано.
Потребности менеджера
- Постановка задач
- Календарный план
- Отчеты и статистика для клиента
- Контроль исполнителей
- Что сделано
- Что будет сделано
- Что делается сейчас
- Файлы
- Ведение документации
- Составление списков изменений, оценка сроков и стоимости изменений
- Ответы на вопросы исполнителя
- Фиксация ответов и комментариев клиента
Потребности исполнителя
- Вопросы менеджеру
- Получение задач от менедежера и управление ключевыми задачами
- Постановка задач самим себе
- Файлы
- Чтение документации, рецензирование и дополнение
- Получение и управление задачами по изменениям
Потребности клиента
- Отчеты и статистика
- Вопросы и ответы менеджеру
- Просмотр календарного плана
- Рецензирование документации
- Постановка задач менеджеру
- Внесение изменений
В целом потребности системы
- Задачи (только ключевые)
- По исполнителям
- По этапам работы
- Вопросы и ответы (по рубрикам)
- Нерешенные
- Решенные
- Отложенные
- Календарный план
- Хранение файлов
- Ведение документации
- Команда и права доступа
- Отдельные права для клиента
- Чеклисты для типичных и полуавтоматизированных видов работ
- Багтрекинг (работа с внесением изменений)
Коммуникации
В потребностях вы не увидели никаких каналов коммуникации, кроме задач и вопросов/ответов. Я считаю, что в системе управления не должно быть никаких коммуникационных сервисов. Причины две. Во-первых, нельзя создать некий универсальный сервис коммуникаций, который решит все вопросы. Такого не может быть. Это рамки и ограничения, которые будут постоянно мешать продуктивному общению. Во-вторых, наиболее эффективные коммуникации в разных случаях разные и выходят далеко за рамки онлайна. Встречи, телефонные/скайп переговоры, чаты, почта — все это применимо в различных ситуациях и в различных стадиях, типах проектов. Нельзя что-то отбросить или пренебречь. Поэтому ведение коммуникаций — это отдельная тема управления проектами.
Вопросы и ответы
Вопросы и ответы — это удобный способ лаконично, емко и информативно записывать обсуждения проекта, протоколы совещаний, тонкости проекта, сложные или спорные моменты.
Вместо полных воды и бесполезности логов чатов, записей скайпа — всего лишь: вопрос-ответ.
Хорошее форматирование вопросов и ответов, и поиск по ним, помогают повышать скорость получения информации о проекте в разы
Роль руководителя
Руководитель — это тот же клиент для рабочей группы. Поэтому его роль и потребности такие же как у клиента.
Руководитель-директор не должен вникать в детали проекта, мешать своими вопросами исполнителям. Все его взаимодействие происходит с менеджером проекта.
Взаимодействие отделов или команд
Если в компании несколько отделов или несколько команд, они также имеют иерархию: менеджер - исполнители.
- Допустим есть отдел разработки: во главе Менеджер проектов, исполнители: Дизайнер, Технолог, Программист. Это отдельная команда со своим набором проектов и задач.
- Также в компании есть отдел рекламы: во главе Менеджер по рекламе, исполнители: Дизайнер, Копирайтер, Сотрудник по работе с клиентами. Тоже отдельная команда со своим набором задач.
- Есть коммерческий отдел: во главе Коммерческий директор, исполнители: Бухгалтер, Экономист. Опять отдельная команда.
- Исполнители в командах не пересекаются. Пересечение может происходит только на уровне менеджеров. Например, команде разработки потребовалось написание текста и менеджер проектов передает это менеджеру по рекламе. Это позволяет избегать хаоса, дублирования работы и общей запутанности кто кому подчиняется и кто для кого что делает.
- У каждой команды могут быть в системе свои клиенты, но в тоже время они могут пересекаться с другими клиентами.
Задачи
В системе управления нужно отмечать только ключевые этапы и задачи. Подробные ветки задач каждый исполнитель должен записывать так и туда, куда ему удобнее: в Google Docs, Things, Omni Focus, Notes, Moleskine, Outlook, лист бумаги, доска на стене. Это один из важнейших моментов правильной системы. Во-первых, подробности задач никому не нужны кроме самого исполнителя. Для клиента и менеджера, часто это фактор риска уйти вглубь деталей и завязнуть. Во-вторых, для исполнителя записывать задачи в непривычный и неудобный инструмент (а универсальный задачник всегда будет неудобен) — это худший способ отнять время и потратить его наименее продуктивно.