Идеальная система управления проектами

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

Четкая иерархия

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

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

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

Потребности менеджера

  • Постановка задач
  • Календарный план
  • Отчеты и статистика для клиента
  • Контроль исполнителей
    • Что сделано
    • Что будет сделано
    • Что делается сейчас
  • Файлы
  • Ведение документации
  • Составление списков изменений, оценка сроков и стоимости изменений
  • Ответы на вопросы исполнителя
  • Фиксация ответов и комментариев клиента

Потребности исполнителя

  • Вопросы менеджеру
  • Получение задач от менедежера и управление ключевыми задачами
  • Постановка задач самим себе
  • Файлы
  • Чтение документации, рецензирование и дополнение
  • Получение и управление задачами по изменениям

Потребности клиента

  • Отчеты и статистика
  • Вопросы и ответы менеджеру
  • Просмотр календарного плана
  • Рецензирование документации
  • Постановка задач менеджеру
  • Внесение изменений

В целом потребности системы

  • Задачи (только ключевые)
    • По исполнителям
    • По этапам работы
  • Вопросы и ответы (по рубрикам)
    • Нерешенные
    • Решенные
    • Отложенные
  • Календарный план
  • Хранение файлов
  • Ведение документации
  • Команда и права доступа
  • Отдельные права для клиента
  • Чеклисты для типичных и полуавтоматизированных видов работ
  • Багтрекинг (работа с внесением изменений)

Коммуникации

В потребностях вы не увидели никаких каналов коммуникации, кроме задач и вопросов/ответов. Я считаю, что в системе управления не должно быть никаких коммуникационных сервисов. Причины две. Во-первых, нельзя создать некий универсальный сервис коммуникаций, который решит все вопросы. Такого не может быть. Это рамки и ограничения, которые будут постоянно мешать продуктивному общению. Во-вторых, наиболее эффективные коммуникации в разных случаях разные и выходят далеко за рамки онлайна. Встречи, телефонные/скайп переговоры, чаты, почта — все это применимо в различных ситуациях и в различных стадиях, типах проектов. Нельзя что-то отбросить или пренебречь. Поэтому ведение коммуникаций — это отдельная тема управления проектами.

Вопросы и ответы

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

Вместо полных воды и бесполезности логов чатов, записей скайпа — всего лишь: вопрос-ответ.

Хорошее форматирование вопросов и ответов, и поиск по ним, помогают повышать скорость получения информации о проекте в разы

Роль руководителя

Руководитель — это тот же клиент для рабочей группы. Поэтому его роль и потребности такие же как у клиента.

Руководитель-директор не должен вникать в детали проекта, мешать своими вопросами исполнителям. Все его взаимодействие происходит с менеджером проекта.

Взаимодействие отделов или команд

Если в компании несколько отделов или несколько команд, они также имеют иерархию: менеджер — исполнители.

  1. Допустим есть отдел разработки: во главе Менеджер проектов, исполнители: Дизайнер, Технолог, Программист. Это отдельная команда со своим набором проектов и задач.
  2. Также в компании есть отдел рекламы: во главе Менеджер по рекламе, исполнители: Дизайнер, Копирайтер, Сотрудник по работе с клиентами. Тоже отдельная команда со своим набором задач.
  3. Есть коммерческий отдел: во главе Коммерческий директор, исполнители: Бухгалтер, Экономист. Опять отдельная команда.
  4. Исполнители в командах не пересекаются. Пересечение может происходит только на уровне менеджеров. Например, команде разработки потребовалось написание текста и менеджер проектов передает это менеджеру по рекламе. Это позволяет избегать хаоса, дублирования работы и общей запутанности кто кому подчиняется и кто для кого что делает.
  5. У каждой команды могут быть в системе свои клиенты, но в тоже время они могут пересекаться с другими клиентами.

Задачи

В системе управления нужно отмечать только ключевые этапы и задачи. Подробные ветки задач каждый исполнитель должен записывать так и туда, куда ему удобнее: в DeskOffice, Megaplan, Redmine, Google Docs, Things, Omni Focus, Notes, Moleskine, Outlook, лист бумаги, доска на стене. Это один из важнейших моментов правильной системы. Во-первых, подробности задач никому не нужны кроме самого исполнителя. Для клиента и менеджера, часто это фактор риска уйти вглубь деталей и завязнуть. Во-вторых, для исполнителя записывать задачи в непривычный и неудобный инструмент (а универсальный задачник всегда будет неудобен) — это худший способ отнять время и потратить его наименее продуктивно.

Leave a Reply

Your email address will not be published.