Как стать автором
Обновить

Особенности управления большим проектом

Время на прочтение4 мин
Количество просмотров6.1K
На большом проекте приходится отходить от методов и инструментов, которыми привык пользоваться на проектах меньшего масштаба. Поделюсь собственными наблюдениями, сделанными на проекте внедрения 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 возможно, но может вызвать вопросы со стороны службы безопасности.


Буду благодарен за комментарии и рекомендации.
Теги:
Хабы:
Всего голосов 9: ↑7 и ↓2+5
Комментарии7

Публикации

Истории

Работа

Ближайшие события