Статус проекта
Подготовка
Готовится на еженедельной основе руководителем проекта
Содержание
Содержит документы:
  • Отчет Руководителя проекта
  • Актуализированный план проекта
Контроль
Нормоконтроль содержания и контроль факта отправки выполняетс администратором проектов
Отчет руководителя проекта
Структура документа «Отчет руководителя проекта»
Актуализация плана проекта
Процедуры по контролю плана проекта
1
Контроль структуры плана проекта
  1. Управление
  2. Определение требований
  3. Системное проектирование
  4. Техническое проектирование
  5. Реализация
  6. Тестирование
  7. Ввод в действие
2
Контроль актуальности плана
1. Отфильтровать / выбрать задачи за текущий период/период контроля
2. Убедиться, что задачи актуализированы:
  • По задачам, которые находятся раньше текущей даты проставлено выполнение вплоть до текущей даты
3
Контроль наличия исполнителей
У всех задач должны быть проставлены исполнители:
  • Со стороны подрядчика – реальные фамилии сотрудников
  • Со стороны заказчика – ФИО сотрудника/роль/подразделение
4
Контроль загруженности ресурсов
1. Выбрать представление «График ресурсов»
2. Убедиться, что по ресурсам отсутствует недогруз и перегруз
5
Контроль наличия базового плана
1. Выбрать представление «Диаграмма Ганта с отслеживанием»
2. Проверить, что все текущие задачи имеют базовое планирование
6
Контроль вех релизов
1. [ В суммарной задаче «Ввод в действе» ] проверить наличие вех:
  • Выполнение предыдущего релиза
  • Наличие вех ближайшего релиза
7
Контроль задач подготовки требований
[ В суммарных задачах «Определение требований», «Системное проектирование» ] проконтролировать наличие задач подготовки требований (БТ, ТЗ )
8
Контроль задач реализации
[ В суммарных задачах «Реализация» ] проконтролировать наличие задач разработки
9
Контроль задач тестирования
[ В суммарных задачах «Тестирование» ] проконтролировать наличие задач тестирование релиза
10
Контроль задач приемки
[ В суммарных задачах «Ввод в действие» ] проконтролировать наличие задач
  • Выдачи релиза на приемку
  • Приемки релиза
  • [Руководств пользователя/Материалов обучения]
11
Контроль размещения в проектной библиотеке
План [и Отчет] размещены в требуемом разделе проектной библиотеки, и актуальной версии
Шаблоны документов
Скачать шаблоны документов «Отчет руководителя проекта», «План проекта» на странице: Артефакты и шаблоны
Статус-митинг
Регулярность
В зависимости от сложности и неопределенности проекта:
  • Ежедневно
  • Раз в два дня
  • Еженедельно
Длительность
  • 15-20 минут
  • Не должен превышать 30 минут
Участники
Все участники проектной команды
Правила проведения
1
Опрос участников
Ключевые участники проекта поочередно отвечают на три вопроса:
  1. Что сделано за прошедший период
  2. Что планируется сделать за предстоящий период
  3. Перечень возникших проблем
2
Фиксация проблем
Проблемы, которые возникли у участников в ходе проекта на статус-митинге не обсуждаются, а только фиксируются.

Для обсуждения проблем проводятся отдельные рабочие встречи.
Учет времени
Регулярность
Фиксация времени производится участниками в удобном для них режиме, но не реже 1 раза в неделю.
Формат
  • Разработчики учитывают затраченное время в инцидент-трекере
  • Остальные роли - в формате электронной таблицы
Подача
Высылается руководителем проекта заказчику, при необходимости
Формат отчета по затраченному времени
Актуализируется не реже чем 1 раз в неделю
Шаблоны документов
Скачать шаблон учета времени: Артефакты и шаблоны
Бизнес-требования
Экспресс-обследование
Перед разработкой бизнес требований проводится экспресс-обследование, в котором фиксируется текущее состояние заказчика
Содержание
Бизнес-требования - это описание бизнес-потребностей заказчика, - какие проблемы бизнеса необходимо решить. Бизнес-требования являются ключевым содержанием документа "Рамки проекта"
Формат
Полный формат бизнес-требований содержит три ключевых раздела:
  • Пользовательские истории
  • Формы интерфейсов
  • Сценарии работы
Экспресс-обследование
Разделы документа "Экспресс-обследование"
1
Организационная структура компании
Приводится организационная структура компании, описывающая структуру и подчиненность подразделений.
2
Бизнес-процессы
Описываются бизнес-процессы, компании, в автоматизируемой предметной области.
3
Типы документов
Перечисляются тип документов, используемые в автоматизируемой области:
  • Название документа
  • Назначение документа
  • Принцип кодификации
  • Где создается
  • Какими подразделениями и сотрудниками обрабатывается
  • Форма документа
  • Пример заполнения документа
4
Номенклатура дел
Приводится номенклатура дел автоматизируемой области.
5
Отчетные документы
Описывающие типы отчетов, существующие в рамках автоматизируемой области:
  • Название отчета
  • Назначение отчет
  • Подразделение, которое формирует отчет
  • Периодичность формирования отчета
  • Кому адресован отчет
  • Форма отчета
6
Программное обеспечение организации
Программное обеспечение, использующееся в настоящий момент в автоматизируемой области.
Рамки проекта
Структура документа "Рамки проекта"
1
Описание объекта автоматизации
  • Автоматизируемые бизнес-процессы
  • Автоматизируемые подразделения
  • Области изменения компании
  • Количественные характеристики
2
Бизнес-требования
  • Реализуемый бизнес-процесс
  • Требования к системе/пользовательские истории
  • Описание интерфейсов
  • Сценарии работы сотрудников
  • Требования к интеграции с другими системами
3
Архитектурные рамки проекта
  • Требования к оборудованию
  • Требования к платформе
4
Организационные рамки проекта
  • Требования к проектному офису
  • Требования к проектной команде
  • Требования к инфраструктуре
  • Требования к обучению
Шаблоны документов
Шаблоны документов "Экспресс-обследование", "Рамки проекта" смотрите в разделе: Артефакты и шаблоны
Приоритезация требований по технике MoSCoW
Цель
Приоритезация требований - основной инструмент управления объемами релизов и сроками
Акроним MoSCoW
  • Must Have - обязательны
  • Should Have - необходимы
  • Could Have - желательны
  • Won't Have this time - на будущее
Источник
Техника MoSCoW является практикой работы методологии DSDN Atern Agile Business консорциума.

Описание категорий требований
Must have (Обязательные)
Группа требований, без которых поставка не может быть осуществлена. Если в случае отсутствия требования проект не имеет смысла и должен быть закрыт, значит данное требование относится к группе "Обязательные". Если в случае не реализации требования может быть использован воркэраунд, даже если это ручные действия пользователя, значит данное требование не относится к группе "Обязательные".
Should Have (Необходимые)
Требования данной категории:
  • Важные, но не жизненно необходимые
  • Болезненно, если не будут реализованы, но альтернативные решения есть
  • Их отсутствие может потребовать воркэраунды, такие как, управление ожиданиями, неэффективность или ручная работа
Присутствие требования в данной категории не означает, что оно не будет реализовано, однако его реализация не гарантирована.
Could Have (Желательные)
Требования данной категории являются желательными или даже ожидаемыми, но менее необходимыми, чем требования категории Shold have, или отличающиеся меньшим влиянием на бизнес/пользователей.
Won't Have this time (На будущее)
К данной категории относятся требования, которые проектная команда согласилась отложить. Их перечень необходим, чтобы проектная команда и заказчик понимали общий скоуп проекта. Это помогает управлять ожиданиями пользователей, информируя их, что часть требований не будут реализованы, по крайней мере, сейчас.

Правила приоритизации
1
Согласование содержания категорий
Правила назначения приоритетов и содержания категорий согласуются между проектной командой и заказчиком до начала сбора требований. Категория Must (Обязательные) неизменна - это минимальный набор требований, поставка которых гарантирована.
2
Мапинг бизнес потребностей
Все требования категорий Must (Обязательные) и Should (Необходимые) в обязательном порядке должны закрывать конечный перечень бизнес - потребностей заказчика. С этой целью, на каждое требование данных категорий готовится один или несколько бизнес-кейсов, закрывающих конкретные бизнес-потребности заказчика.
3
Эскалация разногласий в оценках приоритетов
Каждое требование категории Must (Обязательные) должно быть тщательно взвешено Консультантом. Если принадлежность требования к данной категории не очевидна - эскалация.
Уровни эскалации (Бизнес-партнер -> Менеджер по стратегии бизнеса -> Спонсор проекта) и критерии эскалации/принятия решения на каждом уровне согласуются в начале проекта.
4
Декомпозиция
Декомпозиция требований - один из основных инструментов разрешения противоречий при определении категорий, к которым следует отнести то или иное требование.
  • Уверенность в том, что все или большинство требований относятся к категории Must (Обязательные) является первым признаком недостаточной декомпозиции.
  • Верхнеуровневые требования категории Must (Обязательные) обычно содержат подтребования, которые можно разнести по нескольким категориям.
  • Если верхнеуровневое требование относится к категории Must (Обязательные), а детализированное – к категории Should (Необходимые), то верхнеуровневому требованию приоритет должен быть понижен.
5
Пересмотр приоритетов
По окончанию каждой итерации разработки все требования должны быть пересмотрены и их приоритизация подтверждена или изменена в свете новой итерации разработки. Часть требований могут переместиться из одной категории в другую, часть - выйти за рамки проекта.
6
Объем категорий
  • На требования категории Must (Обязательные) должно приходиться не более 60% объема проекта
  • Категории Should (Необходимые) и Could (Желательные) совместно должны занимать 40% объема проекта (по 20% каждая).
7
Ожидания
  • Требования категории Must (Обязательные) будут реализованы безоговорочно.
  • Требования категории Should (Необходимые) включены в планы проекта, но проектная команда не уверена, что может гарантировать их поставку.
  • На типовые риски проекта закладывается 20% от всего объема работ - требования категории Could (Желаемые).
  • На риски проекта с учетом нештатных ситуаций закладывается 40% от всего объема работ - требования категорий Should (Необходимые) и Could (Желательные).
Оценка бюджета и сроков
Предварительная оценка
Выполняется по описанным бизнес-требованиям/рамкам с целью получить примерный объем бюджета.
Пересмотр оценки
При уточнении требований, на этапах "системное проектирование", "техническое проектирование", "реализация" производится переоценка сроков и бюджета.
Финальная оценка
Выполняется по фактическому отработанному времени и ставкам специалистов.
Порядок выполнения оценки
1
Формулирование бизнес-требований
Консультант формулирует бизнес-требование или набор бизнес-требований (рамки проекта).
2
Проектирование
Архитектор, по каждому требованию кратко описывает предполагаемую реализацию (проектное решение) и оценивает в человеко-днях предполагаемую трудоемкость реализации.
3
Планирование
Руководитель проекта совместно с Ведущим консультантом и Архитектором составляют план проекта/ресурсный план с целью оценки сроков проекта и требуемых ресурсов.
4
Бюджетирование
Руководитель проекта на основании требуемых ресурсов, сроков их привлечения и ставок специалистов составляет бюджет проекта.
5
Пересмотр приоритетов
Руководитель проекта готовит документ Техническое коммерческое предложение (ТКП), в которое включается:
  • Бизнес-требования
  • Проектное решение
  • Описание проектных ролей
  • Необходимые проектные ресурсы
  • Ставки специалистов
  • Сроки работ
  • Бюджет
ТКП отправляется на согласование заказчику.

В ходе согласования уточняются рамки проекта, на основании которых корректируется сроки и бюджет проекта/релиза.
Шаблоны документов
Шаблоны документов "Экспресс-обследование", "Рамки проекта" смотрите в разделе: Артефакты и шаблоны
Аттестация пользователей
Подготовка
Для каждого пользователя готовится набор заданий на экземпляре системы, предназначенном для обучения
Проведение
Проводится после этапа обучения, с учетом роли каждого пользователя.
Сертификация
По итогам успешного прохождения пользователям выдаются сертификаты
Порядок проведения аттестации
1
Выпуск приказа/распоряжения по предприятию
Аттестация является заключительным этапом обучения пользователей.
Факт проведения аттестации закрепляется в распорядительном документе по предприятию, описывающем порядок обучения пользователей и запуска системы в эксплуатацию.
2
Подготовка аттестационных заданий
Консультанты готовят теоретические вопросы по правилам работы в системе и практические задания на стенде обучения для каждого аттестуемого сотрудника.
Для систем с последовательной обработкой документов/данных готовятся сквозные сценарии работы, предусматривающие последовательную работу пользователей - передачу результатов работы от одного пользователя к другому.
3
Подготовка групп пользователей
Сотрудники компании разбиваются по группам. Для каждой группы назначается время проведения аттестации.
4
Аттестация
В учебном классе, по группам, сотрудники отвечают на теоретическую часть аттестационного задания, а на рабочих местах, с которых есть доступ к стенду обучения, выполняют практические задания.
5
Подведение итогов
Консультанты проверяют правильность ответов сотрудников и результаты выполнения практических заданий.
Результаты прохождения аттестации передаются руководителям подразделений.
Сотрудникам, успешно прошедшим аттестацию, выдаются сертификаты.
Шаблоны документов
Шаблоны и примеры документов по проведению аттестации смотрите в разделе: Артефакты и шаблоны
Письмо о завершении этапа
Назначение
Формализованная передача заказчику результатов работы по этапу
Исполнение
Направляется на фирменном бланке компании с регистрационным номером, за подписью уполномоченного руководителя
Содержание
Содержит информацию о выполнении очередного этапа проекта и комплект отчетных документов/артефактов этапа
Ценность
Фиксация факта завершения этапа/проекта
Подготовка, подписание и отправка письма заказчику с комплектом отчетных документов свидетельствует о готовности проектной команды отчитаться об окончании этапа и предоставить результаты этапа заказчику для приемки.
Финализация документов/артефактов этапа
Необходимость отправки письма о завершении этапа, включающего комплект отчетных документов/и артефактов мотивирует проектную команду актуализировать и подготовить окончательные версии документов/артефактов этапа.
Фиксация факта приемки этапа
Получение письма о завершении этапа/проекта формализует приемку этапа заказчиком и мотивирует заказчика предоставить перечень причин, по которым этап не может быть принят, в случае неудовлетворительной оценки им результатов работы проектной команды.
Отчетность для проверяющих органов
Письмо о завершении этапа/проекта с комплектом отчетных документов четко фиксирует факт, срок и качество исполнения контрактных обязательств по договорам, заключенным между заказчиком и исполнителем, и предоставляется проверяющим организациям, выполняющим аудит расходования средств.
Шаблоны документов
Пример письма о завершении этапа/проекта смотрите в разделе: Артефакты и шаблоны
Архивация этапа
Цель
Подвести ретроспективное осмысление этапа/проекта с целью улучшения работы в будущем
Проведение
После завершения очередного этапа проекта, до начала следующего этапа, с участием всех членов проектной команды
Формат
Структурированное обсуждение и изложение как позитивных, так и негативных аспектов и событий, произошедших в процессе работы по этапу
Результат
Фиксируется в виде документа, отражающего следующие аспекты
Что удалось
Каких значимых результатов удалось достигнуть?
Чему начились
Что было нового, чему научилась проектная команда, участники в результате работы над этапом проекта?
Отрицательные эмоции
Какие отрицательные эмоции возникали у проектной команды и ее участников при взаимодействии, выполнении работы?
Положительные эмоции
Какие положительные эмоции возникали у проектной команды и ее участников при взаимодействии, выполнении работы?
Метафора
Короткая фраза , которой можно охарактеризовать завершенный этап.
Улучшить в будущем
Какие аспекты хотелось бы улучшить в будущем?
Шаблоны документов
Пример результатов архивации этапа/проекта смотрите в разделе: Артефакты и шаблоны