К книге
Настольная книга эксплуататора. Всё, что вы хотели знать о повседневной жизни датацентров, но боялись спроситьГлава 11 Работа с проектами
53%
Глава 11 Работа с проектами
16

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

Причины, по которым следует что-то менять, почти всегда появляются из какого-то уже заранее известного источника. Например, такими источниками могут быть:

• регулярный эксплуатационный аудит (внутренний или внешний);

• аудит состояния сооружений и территории (строительный);

• аудит пожарной безопасности объекта;

• аудит физической безопасности;

• внешние аудиты заказчиков и специальные (PCI DSS[29] и т. п.);

• инвентаризация;

• реестр инцидентов за прошедший период;

• окончание срока полезного использования оборудования;

• запросы на развитие (например, переход на новые типы ИБП);

• введение нового процесса в отделе.

Наладить сбор информации довольно просто: для начала достаточно составить регулярный календарь по каждому из аудитов и определить окна поступления информации по другим источникам, если это возможно. За аудит должен быть назначен ответственный, который готовит программу и координирует организационную часть. Важно понять, что после каждого аудита обязательно необходима итоговая встреча, на которой не только обсуждается перечень несоответствий и замечаний (для которых есть такой интересный термин, как near-miss[30]), но и обязательно утверждается план дальнейших действий с указанием ответственных и сроков. Вот этот отчет с пларом действий и становится входным документом для проектов.

Проекты в свою очередь тоже объединяются в конечный список – реестр проектов. Его можно вести в Excel, в трекинговой системе или сделать частью CMMS – важно, чтобы выбранный формат был удобен и понятен всем участникам процесса, иначе они будут испытывать неприятие к использованию инструмента, отказываться от него и таким образом снижать эффективность процесса.

Основной частью работ с проектами является управление реестром, выражающееся в проведении регулярных встреч всех заинтересованных сторон, похожих на встречи по анализу инцидентов. На встречах по проектам выслушиваются отчеты ответственных за каждую строчку (за каждый отдельный проект). Этот отчет принципиально ничем не отличается от методов PMBOK и в общем случае содержит следующие пункты:

• стадия, на которой сейчас находится проект;

• возникшие новые обстоятельства (опционально);

• план по срокам (укладываемся в прогноз или меняем что-то);

• план по бюджету (включая распределение затрат по кварталам);

• следующий шаг и контрольная точка – для синхронизации на следующих встречах.

Для поддержания исторических данных выполненные проекты удалять не следует – лучше переводить их в состояние «завершен» и скрывать для регулярного обозрения.

Конечно, само ведение реестра проектов – это важная задача, требующая аккуратности, поэтому необходимо определить ответственного за реестр, который будет его поддерживать в актуальном состоянии и выполнять функцию секретаря на регулярных встречах.

В реестр проектов можно также добавить подходящие метрики, чтобы следить за эффективностью процесса в целом. Однако здесь следует быть достаточно осторожным, так как, например, сравнение разнородных проектов по скорости выполнения почти всегда бесполезно. А вот определение отклонения от намеченного дедлайна или бюджета – вполне разумная величина.

Из реестра проектов достаточно легко получать регулярные (например, ежеквартальные) обновления по освоению бюджета. Выгрузка будет являться одновременно прогнозом на использование денег в следующем периоде и объяснением изменений в перераспределении средств прошедших периодов.

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

Итого, в общем случае процесс управления проектами может быть описан так:

Давайте также рассмотрим, какие этапы может проходить каждый из проектов и какие параметры упростят сортировку и классификацию.

Этапы:

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

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

• Сбор данных и нахождение решения. Этот процесс может быть довольно долгим, порой до нескольких месяцев, наполненных ожесточенными дискуссиями, а может и пропускаться, если решение очевидно.

• Проектирование. Если для достижения результата требуется привлечение проектной команды.

• Закупка. Если проект подразумевает поставку услуг или материалов контрагентами. Чтобы не плодить лишних статусов, процедуру тендера можно отнести сюда же.

• Реализация. Основная часть проекта.

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

• Закрытие. Перевод проекта в архив.

Параметры:

• дата создания;

• источник изменения;

• принадлежность к подсистеме;

• локация (если процесс работает на несколько площадок);

• ответственный;

• бюджетная оценка по периодам и фактические данные;

• плановый (первоначальный) срок завершения;

• текущая оценка срока завершения.

Подобных параметров можно подобрать много, в зависимости от того, какая аналитика понадобится. Однако хочется предостеречь от добавления ненужных признаков, если реальной работы по ним не ведется. Это усложнит заполнение форм и отчетов, а пользы не принесет никакой.

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

Предыдущая главаГлава 16 из 30Следующая глава