Курс про Команду. Проектное управление. Классический проектный подход.
Это та история, когда на старте имеем жесткую фиксацию сроков\времени\содержания и пытаемся в них попасть. Причём так, чтобы ключевые люди были довольны.
Библия подхода - PMBoK - Project Management Body of Knowlege
Ключевые принципы подхода
Принцип яйца
На старте фиксируем неизменные границы (скорлупу), а содержание - достраиваем в процессе - по принципу набегающей волны
Принцип удава
Инициация -> Планирование\Мониторинг\Выполнение -> Закрытие
На стадии инициализации - обсуждаем - надо ли, можем ли - есть возможность отказаться, но после - уже работаем до конца.
При этом проектный менеджер - это такой Интегратор - тот, кто сводит вместе вообще всё происходящее - заказчиков, планы, команду...
Принцип командности и проактивности
Руководитель - не может и не должен быть экспертом вообще во всём, хотя и должен, конечно, иметь общее представление (уметь понимать каждого в разговоре).
Зато команда в целом - обладает экспертностью в каждой области.
Соответственно Командность в том, чтобы привлекать команду к планированию работ. Тут важно, что не каждый остаётся один со своей задачей, а все планируют вместе, понимая как задачи связаны между собой.
В частности - важно на митингах всем смотреть в общую доску\общий график с задачами, а не каждому только в свои. Во второй частности - включать камеры очень важно.
Проактивность - про работу наперёд. Предугадывание рисков, работа по их митигации - делать что-то, чтобы риск не случился, а не реагировать, когда уже "бахнуло".
Роли
- Спонсор - снабжает проект ресурсами (не всегда это деньги, могут быть и люди, или что-то ещё)
- Заказчик и пользователи - используют результат проекта
- Команда - выполняет работу на проекте (именно те, кто реально делает работу, а не все, кто на совещания ходит)
- Менеджер - отвечает за проект
- Другие - все, чьи интересы затрагивает реализация проекта (в том числе, например, конкуренты)
Кейз: Потенциальный клиент готов заплатить Х денег за работу. Директор фирмы просит Вас взяться за этот проект. Кто тут спонсор, а кто заказчик?
Ответ: Директор - спонсор, Клиент - заказчик. Почему? Потому что именно директор будет выделять средства Вам. (И вовсе не обязательно, что отдасть все Х. А может и не деньгами даст, а людьми или полномочиями...)
Менеджер и Команда - всегда "внутри" проекта.
Спонсор и Заказчик - всегда "снаружи" проекта.
Другие - могут быть и внутри и снаружи
Со спонсором согласовывали рамки.
Спонсор может интересоваться проектом и прогрессом, но не должен вмешиваться в процесс
Спонсор должен охранять границы проекта (например - не позволять кому-то забрать часть команды на другой проект)
Заказчика так же можно привлекать - спрашивать пожелания, показывать прототипы.. но он не участвует в процессе работы.
Процесс работы над проектом
Запуск проекта
Шаг номер НОЛЬ - определить заинтересованные стороны.
Составить "реестр заинтересованных сторон" - и обновлять его время от времени
Например с такими полями:
- ФИО
- Роль в проекте
- должность, отдел\департамент
- непосредственный начальник
- контактная информация
- предпочитаемый вид связи
- главные ожидания от проекта
- главные требования к проекту
- !! влияние на проект
- !! отношение к проекту
- !! интерес к проекту (на сколько готов уделять время)
Хорошо бы - всех этих людей держать в курсе. Но, если их слишком много - можно "фильтровать" при помощи матрицы Влияние-Интерес
Шаг номер ОДИН - Фиксируем устав проекта (скорлупу)
Менять устав нельзя!!! Если меняется - то это означает автоматическое закрытие старого проекта и начало нового.
Что в уставе?
- Цели - бизнес-цель проекта (Важно, не пишем в цели "сделать проект", пишем "сделать проект, чтобы ..... ЧТО?")
- Ограничения
- Сроки - можно с промежуточными вехами, в которые критично важно попасть.
- Деньги (ресурсы) - если это люди, то надо думать как писать (помним, что устав - неизменен. например, допустимо критичных людей указать по ФИО, а менее критичных - как-то иначе)
- Содержание (можно с уточнением результатов, KPI...) - пара абзацев текста.
- Заинтересованные лица (главные)
- Риски (терминирующие, неснижаемые) - то, что способно убить проект целиком. (например - изменения в законах или политике страны)
- Что-то ещё, если это критически важно зафиксировать
Устав - не больше 3х страниц, вне зависимости от размера проекта. Просто для больших - описание будет очень верхнеуровневым, а для маленьких - всё критично, так что описание будет подробным.
Подписывают устав - Спонсор и Менеджер.
Заказчик тут особо не нужен (особенно если есть разница в стоимости проекта и цене, которую он платит)
После подписания устава - проект стартовал и на Менеджера ложиться ответственность за его выполнение.
Содержание проекта
Требования - Концепция - ИСР
- Требования - собираем со всех ключевых заинтересованных лиц. По сути - наполняем "беклог" нашего проекта
- Концепнция (ТЗ) - анализ требований, компиляция, оформление их в "читаемом" виде - в документ, по группам - чтобы в беклоге не утонуть и ничего не потерять. Прописываем что Входит и что НЕ Входит в проект.
- ИСР - план по шагам - декомпозиция задач.
Правила формирования ИСР
- 1 уровень - главный результат проекта
- 2 уровень - даёт представление о проекте в целом (уже довольно подробно, просто "сделать хард и сделать софт" не подойдёт)
- Правило 100% - не забыть зафиксировать ВСЕ необходимые шаги и модули. Что забыли в ИСР - то и не сделали.
- Единообразие именований - идеально, если каждый шаг - существительным. но можно и с глаголами. (бывает, что название шага не подбирается - возможно это значит, что плохо разбили на шаги)
- Предел декомпозиции - принцип набегающей волны - первые шаги можно прописывать более детально, дальнейшие - допишем, когда к ним ближе будем
В реальном мире - рисуют не так, а "на плоскости", отмечая "вложенность" отступами.
Диаграмма Ганта
- Каждому пункту из ИСР присваивается уникальный номер задачи
- Затем каждой задаче прописывается "предшественник" - какую задачу нужно завершить, чтобы начать работать над этой? (может быть больше одного, какие-то задачи можно делать параллельно)
- Каждой же задаче прописываются ресурсы - кого\сколько понадобится, чтобы её сделать
- Потом - оцениваем продолжительность работ по каждой задаче
- Осталось проставить дату начала превой задаче - и все остальные даты просчитаются автоматически, в том числе - дата завершения проекта
(первая задача тут та, у которой нет предшественника)
Вот всё это вместе - и есть ДиаграммаГанта
Откуда взять Продолжительность?
- В базе - только "экспертным прищуром", увы.
- Экспертная оценка
- по аналогии (если найдёте аналог)
- параметрическая оценка (как вариант - перт - (O+3M+P)\6, где О, М и Р - оптимистичный, реалистичный и писсимистичный срок)
- мозговой штурм и его вариации (покер-планирование например)
- анализ рисков (сначала всё предыдущее, а потом "докинуть" на основе рисков)
Критический путь
Это самый длинный путь в сетевой диаграмми (колбаски на картинке), отражает минимальный срок, за который можно завершить проект.
Соответственно - любая задержка на критическом пути - повлияет на общий срок проекта
Задержки на не-критических этапах - в некоторых рамках допустимы
Вехи (Milestones)
Важные точки проекта.
Веха - это работа с нулевой продолжительностью (так удобнее строить графики в специальных системах)
Если идём на беседу со спонсорами или высоким начальством - им достаточно показать график вех - без детализации работ\задач
Бюджет
Считается ровно так же и теми же способами, что и время. (плюс пара уникальных - сами найдёте)
Отслеживание прогресса методом EVA (Метод совоенного объема)
Способ, когда всё переводим в деньги и в этой универсальной единице определяем - укладываемся ли в рамки.
Основные метрики такие:
- PV - Плановый объём - на какое количество денег должны были сделать работ к сегодняшнему дню
- EV - Освоенный объём - на какое количество денег (по плану!!!) сделали работ к сегодняшнему дню
- AC - Реальная стоимость - сколько реально стоили работы, завершенные к сегодняшнему дню.
Важно - метод не учитывает те работы, которые "в процессе" сейчас - только завершенные.
EV\PV = SPI - Schedule performance index - показывает, идём ли мы по графику в смысле сроков (в процентах)
EV\AC = CPI - Cost performance index - показвает, идём ли мы по графику в смысле ресурсов (в процентах)
- Если SPI \ CPI =1 - то всё супер, мы идём ровно по плану
- Если они <1 - то мы от плана отстаём \ перерасходуем бюджет
- Если они >1 - то мы звёзды и идём быстрее плана \ экономим бюджет
То же можно посчитать в абсолютных величинах
EV-PV = SV - Schedule variant
EV-AV = CV - Cost Variant
- Если < 0, то круто, мы экономим
- Если > 0 то плохо, протатились \ протормозили
- Если = 0, то огонь - строго по плану
Соответственно, чтобы это всё работало - надо каждой работе добавить ещё и стоимость - планируемую и реальную.
Вообще, метод большой и формул там сильно больше. Кому надо - гугл в помощь.
Управление качеством в проектном подходе
- ! Причинно-следственная диаграмма
- Блок-схема
- Контрольный листок
- Контрольная карта
- Гистограмма
- ! Диаграма Парето
- ! Диаграмма разбрасывания
В детали не полезем, сами читайте. Как вариант - книга Барабановой и Соавторов.
И другие планы...
- Помимо перечисленного, менеджер в классическом подходе занимается ещё
- мотивацией сотрудников
- коммуникацией со всеми и везде
- решением конфликтов
- работает с рисками
Риск - вероятностное событие, которое может случиться и повлиять на проект.
Задача - сделать так, чтобы 90% рисков не случилось.
Как это делать?
- Определить риски (записать все) и регулярно обновлять
- Анализ - на сколько вероятно, как сильно повлияет?
- План реагирования для каждого
- План А - что делать, чтобы этого не случилось
- План Б - что делать, если всё же случилось?
- Триггер - как мы поймём что оно уже вот-вот?
Закрытие проекта
- Сверяемся - удалось ли попасть "в треугольник", довольны ли ключевые люди?
- Сдача\Приёмка работ (сама процедура, оформление документов)
- Высвобождение команды (могло частично произойти раньше) - важно с командой отметить завершение проекта
- Сохранение "усвоенных уроков", пополнение "базы знаний" (ИСР, реестр рисков - многие блоки\пункты повторятся для следующих проектов - можно переиспользовать)