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

До этого у меня был весьма разнообразный опыт руководства проектами, но такого масштаба не было. Команда более 100 человек, 13 функциональных групп, очень требовательный заказчик и нереально сжатые сроки.
Из предыдущего опыта я вынес четко определившиеся подходы по организации работы проектной команды. Дабы не утомлять, постараюсь их сформулировать очень коротко:
  • Делегирование и распределение ответственности между руководителями групп
  • Интенсивные личные коммуникации со всеми участниками
  • Использование централизованной вики для информирования и обмена между участниками проекта
  • Высокоуровневый календарный план в MS Project для управления сроками проекта и определения контрольных точек
  • Централизованная система управления задачами для подневного планирования
  • Еженедельное информирования Заказчика с помощью лаконичных отчетов, которые я готовлю лично
  • Максимально возможное вовлечение Заказчика в работы проекта

На этом проекте мои взгляды претерпели некоторую трансформацию. Отчасти это результат масштаба, отчасти субъективных факторов, связанных с составом участников проекта.
  1. График проекта в MS Project в качестве инструмента управления практически не используется. Он есть, и на его поддержание в актуальном состоянии тратится время, но по назначению — нет. Детальный график в таком проекте сделать очень сложно. Как я уже говорил, есть субъективные причины, о которых мы здесь не говорим, и есть объективные:
    — Сжатый график диктует необходимость делать многие работы параллельно (по крайней мере так выглядит на высокоуровневом графике). Нельзя полностью написать проектные решения, потом спецификации, и после этого начать разработку. Как только одно проектное решение готово, сразу запускается вся цепочка последующих работ. Чтобы изобразить эти последовательности в графике со связями нужно опуститься до самых деталей. Если попытаться сделать целиком весь план проекта в таких деталях, это будут многие тысячи строк, и работать с ним будет невозможно. И дело даже не в количестве строк, а в объеме ежедневных обновлений.
    — Значительная степень неопределенности трудоемкости, длительности и производительности по всем задачам. Не накоплено статистики по производительности команды, не понятно сколько будет заказчик согласовывать документы, как будут корректироваться требования к результатам работы. Есть плановая дата, к которой должно быть все готово, и под это меняется количество людей в команде, увеличивается длительность рабочего дня, снижается качество (тсссс, никому не говорите!).
    В итоге, график из инструмента управления превращается в картинку и носит чисто иллюстративный характер.
  2. Реальный трекинг выполнения работ делается с помощью метрик. Для каждой группы задаем некоторых набор показателей, которые они должны достигнуть в определённый момент времени, и на периодической основе (еженедельно или ежедневно), отслеживаем значение показателя. Например, нужно выпустить столько-то документов. Разбиваем готовность документов на стадии, каждой стадии приписываем вес. Как только эта стадия пройдена, группа получает некоторое кол-во условных баллов. И так по каждой ключевой задаче. В результате мы имеем сумму баллов, которая интегрально показывает, где находится группа. Есть план по этому интегральному показателю, и в сравнении с этим планом можно примерно понять, в графике группа или нет. Инструмент грубый, но оказалось, что это проще, чем заставить группы вести собственные детальные графики в Project.
  3. Безумное количество всяческих списков и реестров. Реестры, требований, разработок, документов, замечаний, открытых вопросов, решений, поручений, рисков, проблем, межпроектных зависимостей — насчитываются десятками. Чтобы их поддерживать в актуальном состоянии, приходится тратить значительное количество времени и сил на консолидацию и выверку.

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

Часть списков вынесли на SharePoint. Перечисленные сложности уходят, но интерфейс и близко не приближается к возможностям Excel. Участники проекта неохотно работают с SP.

Чего бы хотелось. Я представляю себе систему, похожую на Excel, но в онлайн, и удовлетворяющую следующим требованиям:
  1. Возможность создавать таблицы произвольной структуры, чтобы в любой момент можно было быстро добавить необходимое поле, определить его тип, задать или изменить набор значений для отдельных полей.
  2. Возможность связывать таблицы, чтобы можно было в одной таблице иметь ссылку на запись в другой. Например, чтобы связывать таблицу открытых вопросов с поручениями, которые по каждому из них необходимо предпринять.
  3. Многопользовательский доступ к таблицам, с блокировкой только одной записи при редактировании пользователем.
  4. Создание фильтров, отчетов, построение сводных таблиц и графиков. Сохранение набора таких отчетов в виде дашбордов для общего использования. В идеале — много дашбордов для разных целей и аудиторий.
  5. Удобный пользовательский интерфейс — интуитивно понятный, на русском языке, много полей умещается на экране…
  6. Встроенный спеллчекер. Даже в списках Excel безумное количество ошибок и опечаток.
  7. Установка внутри корпоративной сети. Использование SaaS возможно, но может вызвать вопросы со стороны службы безопасности.


Буду благодарен за комментарии и рекомендации.

Комментарии (7)


  1. P0WERMIC
    17.12.2015 09:50

    Возможно, с такой-то матери, это Office 365 online?


    1. dantipov
      17.12.2015 10:18

      Честно говоря не рассматривали. У заказчика этого нет, и покупать лицензии на 500-700 участников проекта… И самое главное — это за периметром корпоративной сети.


  1. BloodJohn
    17.12.2015 14:03

    Мы пользуемся Jira + GoogleDoc + Skype

    Оба в облаке, увы.

    > Интенсивные личные коммуникации со всеми участниками

    какая цель у таких коммуникаций?


    1. dantipov
      17.12.2015 19:19

      Целей у коммуникаций множество:
      1. Интеграция и координация. Чтобы ничего на попало в межящичное пространство.
      2. Информирование. Когда все понимают, что происходит, и зачем те или иные действия, вовлеченность и результативность выше.
      3. Выявление проблем и рисков. Как правило важные вещи говорят между прочим.
      Вообще, больше половины времени РП уходит на коммуникации.


  1. enjoykaz
    17.12.2015 17:26

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


    1. dantipov
      17.12.2015 19:16

      Давайте обсудим. Мой скайп dantipov


  1. dantipov
    24.12.2015 19:06

    Посмотрел еще раз Smartsheet. Хороший инструмент, просто отличный. Но в облаке. При других требованиях к безопасности, можно было бы закрыть этим потребность.