Проектный офис ПРОЦЕССЫ СЕМЁНОВ ИЛЬЯ ДИРЕКТОР ДЕПАРТАМЕНТА ИТ - презентация

1 ДИТ. Проектный офис ПРОЦЕССЫ СЕМЁНОВ ИЛЬЯ ДИРЕКТОР ДЕПАРТАМЕНТА ИТ

2 Проект Определение по ГОСТ Р : Комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений. Проект – это замысле, который характеризуется следующими факторы: однократность условий в их совокупности – речь идет об особом замысле. Он отличается от повседневных работ и не повторяется; наличие цели(ей) – ясных и измеримых, которые к концу проекта должны быть достигнуты; ограничениями: ограничение по времени – временной график выполнения проекта с обозначенным началом и концом выполнения работ; ограничения финансового, персонального или другого рода – бюджет проекта, этапы; отграничение от других замыслов – проект не повторяется и отличается от процессных работ; специфичная для проекта организация – в проект подбираются разные люди с разными ролями, включаются разные отделы, разные поставщики. В каждом проекте эти составляющие разные. 2

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

4 Руководитель проекта Лицо, которому поручается руководство проектом. Компетенции руководителя проекта регламентируются спецификой предприятия и проекта. 4

5 Команда проекта В проектном менеджменте важно понимать разницу между такими понятиями, как коллектив, команда, группа. Коллектив – группа людей, которая работает в одной компании, объединённая совместной деятельностью, общими интересами, идеями. Группа людей – объединяет людей по целям и интересам. Например, в клубе ИТ директоров собирается группа профессионалов, которых объединяют общие интересы. Команда – это группа людей, которая работает сообщая над какой-либо задачей или идеей. В общем смысле, команда – это частный случай группы, которая действует сообщая, целью которой является достижение результатов. В команде все нацелены на достижение результата, причем не индивидуального, а командного. Сила команды на много выше силы группы, хотя и ниже суммы всех сил каждого конкретного члена команды. В команде, как правило, раскрывается потенциал каждого члена команды за счет работы сообща, внутренней самомотивации, гибких и эффективных действий совместно с членами команды. Команда проекта может состоять из сотрудников отделов ДИТ: ОПР, ОАИС, 1С, ОСЭИС, ОТПП, а также сотрудников из других департаментов и представителей заказчика. 5

6 Проблемы в проектном управлении 6

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

8 Какая часть, деталь автомобиля - менеджер проектов? 8

9 Неправильное направление движения проекта 9

10 Основные причины неудач проектов Причина Вероятность Неясные цели, неясные требования 30% Отсутствие поддержки руководства 15% Неудовлетворительные методики и техника управления проектом 12% Недостаточные ресурсы 11% Неудовлетворительная квалификация, гибкость, активность 10% Политика, эгоизм отдельных подразделений, несоответствие уровней компетентности 8% Отсутствие контроля/мониторинга над проектом 8% Недостаточная коммуникация/отсутствие обмена информацией 6% Отсутствие управления изменениями 5% Наибольшая вероятность неудачи проекта – плохо определенные, неясные цели и требования. Именно поэтому в рамках управления проектом, необходимо четко определить и точно описать цели проекта. 10

11 Цели и задачи проекта Цель – это будущее состояние предметной области, к которому, в рамках проекта, стремятся, за счет выполнения активных действий, задач. Цели должны отвечать на вопрос что?. Что должны получить к концу проекта. Задачи должны отвечать на вопрос как?. Как мы должны действовать, чтобы достичь поставленных целей. Проекты могут иметь несколько целей и каждая цель набор задач. Каждая задача должны начинаться с глагола действия, например: подготовить, провести, разработать, создать, сделать, обеспечить, купить, установить, опросить и т.п. Это гарантирует измеримость задачи и возможность её контролировать. 11

12 Цель по SMART Достижение цели зависит от её формулировки, и первый шаг к успеху – правильно сформированные цели. Концепция SMART целей: Specific (конкретная) : Цель должна быть конкретной, т.е. описывать, что именно необходимо достигнуть. Например, повысить прибыль компании. Measurable (измеримая) : Цель должна быть измерима, т.е. описывать в чем или в каких единицах можно будет измерить результат. Например, повысить прибыль компании на 5%. Achievable (достижимая) : Цель должна быть достижимая. Описывается за счет чего достигается цель и при каких условиях. Например, повысить прибыль компании на 5%, за счет внедрения СЭД, автоматизации внутренних бизнес-процессов и сокращения штата сотрудников на 10%. Realistic (реалистичная) : Цель должна быть реалистичной. Означает, что достижение целей финансово и технически возможно. Технические и человеческие ресурсы должны присутствовать в достаточном объеме. Timely (ограниченная во времени) : Реализация цели должна иметь реалистичную оценку реализации по времени. Указываются ограничение во времени, по истечении которого все задачи должны быть выполнены и цель достигнута. 12

13 Этапы проекта В большинстве случаев проект, на протяжении времени жизни, делиться на пять этапов: Подготовки проекта; Структурирования проекта; Планирования проекта; Осуществления проекта; Завершения проекта. Смысл разделения на этапы заключается в том, чтобы тщательно проработать проект, задачи и последовательность шагов. Каждый этап – это частный процесс управления проектом, это временной отрезок проекта, отграниченный от других этапов проекта. 13

14 Этап «Подготовка», составление устава проекта Перед стартом проекта, необходимо получить от заказчика добро на реализацию. Этим будет гарантироваться, что: заказчик согласен с целями проекта; существует необходимые сотрудники для организации команды проекта; Есть необходимые технические средства или средства, которые можно приобрести; проект укладывается в финансовые ожидания заказчика. Устав является паспортом проекта. 14

15 Подготовка. План составления устава Сначала должны быть изложены проблемы, которые обуславливают появление нового проекта. Затем определяются цели проекта. Польза, которую получит Ваше предприятие от проекта, должна быть четко показана. Если имеются альтернативы по реализации проекта, то обязательно должно проводиться их сравнение. Необходимо указать на риски проекта. В заявке должен быть изложен проделанный анализ рисков. Необходимо назвать, по возможности, поименно, всех участников проекта (внутренних и внешних), их задания и ответственность в рамках осуществления проекта. Оценка расходов должна наряду с издержками на персонал содержать все возникающие издержки 15

16 Подготовка. Состав работ Цель проекта Задачи Результат Устав Ресурсы Заинтересованные стороны (Стейкхолдер) – лица или группы лиц, интересы которых отражает или затрагивает проект. Заказчик – лицо, ответственное за весь проект. 16

17 Этап «Структурирование» Матрица ЗПО - составление списка заданий, полномочий и ответственности участников проекта Матрица компетенций - В – кто отвечает за выполнение определённых видов работ. П – окончательная приёмка, принятие решений. Р – участие в принятии решения. К – должен участвовать, консультирует. И – должен быть проинформирован. Журнал обязанностей – список работ проектной команды Структурный план проекта (Project Structure Plan, PSP) Планирование сроков и хода работ - сетевой график по методу критического пути. Оценка затрат 17

18 Этап «Планирование» Структурный план проекта Рабочий пакет – атомарная задача в структурном плане проекта Сетевой график – изображение работ и зависимостей между ними, часто выражено в графическом виде 18

19 Этап «Осуществление» Контроллинг проекта – мониторинг работ по проекту, анализ результатов, контроль содержания проекта, его расходов и сроков выполнения. Принятие решений и управление изменениями. Анализ тренда вех Анализ тренда по затратам Анализ освоенного объема Треугольник целей Анализ тренда вех -метод анализа отклонений сроков, основанный на фактических и плановых значениях. Диаграмма сгорания. Ретроспективы. Планирование итераций. Демонстрации. Модерация совещания. Управление изменениями. Управление требованиями. 19

20 Контроллинг с помощью Треугольника целей Углы треугольника обозначаются, как: Сроки. Время на реализацию проекта. Расходы. Деньги, люди, бюджет. Объем работ. Цели, задачи, качество. Равносторонний треугольник с равными сторонами показывает плановые величины для: бюджета, срока, объема работ. Картинка меняется в зависимости от отклонения от базовых плановых значений. Результаты проекта меряться с определенной периодичностью. Сроки - измеряется затраченным временем на проект. Расходы - измеряются фактическими затратами. Объем работ - измеряется в процентном соотношении запланированных и выполненных работ. 20 Треугольник целей хорошо подходит для демонстрации, как промежуточных, так и в целом, результатов проекта.

21 Фаза «Завершение» Проектная отчетность Завершающие документы Анализ отклонений Презентация База знаний проекта 21

22 Этапыпроекта Этапыпроекта 22

23 Scrum – итеративная разработка Каждая итерация – это мини проект Программирование Тестирование Документирование Планирование Анализ требований Проектирование 23

24 Проблемы Scrum 24

25 Процессы 25

26 Основной процесс - Процесс разработки продукта В него включается: работа с вехами; контроль рисков; Управление изменения; контроль качества; и другие работы. Процесс разработки и связанные с ним процессы с определённой периодичностью проходят аудит (Ретроспективы, Status митинги). 26

27 Анализ проекта с процессной точки зрения 1. Как идентифицируются и управляются процессы проекта? 2. Как происходит применение и улучшение процессов ведения проектов? 3. Как осуществляется сохранение опыта, для использования в будущих проектах? 27

28 1. Как идентифицируются и управляются процессы проекта Старт проекта Сбор требований; Управления желаниями заинтересованных сторон. Планирование работ; Управления временем (time m); Управление информационным обменом. Исполненние Управления ресурсами; Управления приоритетами проектов и подпроектов; Управления приоритетами задач в проекте; Управление развитием проекта; Управления изменениями; Установки вех; Итеративного управления рисками; Проектирования архитектуры системы, модулей, …; Разработки программного обеспечения (Scrum+Kanban); Тестирования ПО; Выпуска версий; Демонстрации промежуточных результатов; Подготовки документации; Мотивации сотрудников команды; Развития сотрудников. Мониторинг и управление; Контроля проекта; Анализа процессов. Завершение; Приёмки; Ретроспективы; Сохранения опыта, знаний; Реинтеграции сотрудников. Идентификация вех процессов тесно связана с выбранной моделью управления проектами. Так, в нашей проектной деятельности, можно выделить следующие группы процессов управления проектами: 28

29 Динамика процессов Суть практически всех процессов протекающих в компании заключается в их динамичности. Процессы работы должны периодически пересматриваться, для обеспечения возможности их улучшить. Факты и измеряемые параметры, получаемые в ходе работы над проектом, являются основанием для улучшения процессов работы. 29

30 Как осуществляется планирование Процесс планирования можно разделить на следующие фазы: A. начало проекта; B. начало каждой итерации (или вехи) проекта; C. ежедневные standup собраний команды; D. завершение проекта, этапа, итерации (ретроспекива); E. кросс-проектных совещаний. 30

31 A. Начало проекта Структурный план всего проекта; Финансовый план; Журнал распределения обязанностей; Структура отчётных документов. 31

32 B. Начало каждой итерации (или вехи) проекта Сбор требований (юзер истории); Определение объёма проекта (планирование спринта в scrum подходе. Обязательства по выполнению объёма проекта, за итерацию (спринт) принимает на себя команда; Создание структурного плана проекта (PSP), декомпозиция задач на пакеты задач. Оценка длительности выполнения задач. Каждая запись Product BackLog принятая к реализации разбивается на подзадачи, которые оцениваются в идеальных человеко-часах; Планирование итерации, последовательность выполнения задач. Обсуждается и определяется, каким образом будет реализован этот объём работ; Определение сроков проекта, вех (в проектах с гибким итеративным подходом назначении длины спринта); Верификация объёма проекта (обзор задач); Определение журнала распределения обязанностей (назначение задач); Контроль объёма проекта (backlog проекта). 32

33 C. Ежедневные standup собраний команды В фазе выполнения, на ежедневных standup собраниях, на которых оцениваются риски и за счёт которых могут вноситься какие-то коррективы в план проекта выполняемой итерации, вносятся изменения в план разработки. 33

34 D. Завершение проекта, этапа, итерации (ретроспекива) В фазе завершения проекта, фазы, вехи или итерации проводится ретроспектива пройденного отрезка проекта, на которой: Все члены команды рассказывают своё отношение к ходу прошедшего спринта. Отвечают на два основных вопроса (Что было сделано хорошо в прошедшем спринте? Что надо улучшить или не допускать в следующем?). Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения). 34

35 E. Кросс-проектных совещаний Обзор проектов; Выявления связей между проектами; Планирование задач по интеграции; Внесение задач в backlog проекта. 35

36 Управление требованиями Матрица требований позволяет фиксировать – когда обнаружено требование, кто автор (кто высказал), насколько данное требование важно (приоритетно). Также в матрицу целесообразно добавлять информацию о том, было ли требование выполнено в ходе реализации проекта, и не отменил ли его сам автор. Работа с матрицей требований осуществляется на протяжении всего жизненного цикла разработки продуктов. 36

37 Управление изменениями Изменения призваны обеспечить проекту «самонаведение» на цель (внося корректировки в «траекторию» – в состав работ). Важно организовать работу с изменениями по определенным правилам. Один из возможных подходов: использование матрицы требований в качестве основы. Члены команды дополняют матрицу новыми позициями в течение проекта, а руководитель проекта производит периодическую ревизию списка. Рано или поздно, каждое требование должно быть отклонено или включено в состав работ по проекту. 37

38 Управление рисками Управление рисками осуществляется в течение всего проекта, до его закрытия. Работа ведется на основании реестра рисков. С его помощью: отслеживаются триггеры риска и приводится в действие мероприятия по предотвращению риска силами «хозяев рисков»; выявляются новые риски силами команды и прочих заинтересованных лиц; переоцениваются старые риски силами команды. 38

39 Управление рисками Организационные риски Отсутствие общего видения модели проектного управления среди топ-менеджеров компании. Отсутствие управления изменениями. Слабая поддержка проекта со стороны высшего руководства компании. Отсутствие необходимых человеческих ресурсов. Риски человеческих ресурсов Обеспечена ли мотивация участников проекта? Достаточен ли уровень квалификации сотрудников? Возможно ли выбытие ключевых персон в ходе проекта? Финансовые риски Достаточен ли бюджет для выполнения проекта? Технические ИТ риски Риски предметной области Технологические риски Риски внешнего окружения 39

40 Как осуществляется управление процессами проекта В задачи и ответственность руководителя проекта входит контроль над выполнением процессов управления проектом. РП выполняет следующие задачи: Контроль соблюдения процессов; Регистрация и управление отклонениями; Регулярное доведение информации о процессах до участников проекта. 40

41 Процесс разработки 41

42 Процесс тестирования Кто отвечает за тестирование? 42

43 1.5. Как организуется контроль вех (Спринт) Наступление вехи инициализирует следующие управленческие процессы: демонстрация, ретроспектива, контроль проделанной работы (анализ тренда вех). Анализ тренда вех: анализа отклонений сроков, основанный на фактических и плановых значениях. 43

44 1.6. Как проходит проверка план- факт и вносится корректирующее воздействие Контроль план факт происходит по принципу ежедневного отслеживания тренда-задач. Все задачи (post-it тикеты) в процессе выполнения вешаются на пробковую доску. Диаграмма Burnup & Burndown показывает количество выполненной и оставшейся работы текущей итерации. В рамках всего проекта, на уровне анализа тренда вех, проводится анализа отклонений сроков, основанных на фактических и плановых проектных значениях. 44

45 1.7. Как учитываются пожелания всех заинтересованных групп Для учёта пожеланий всех заказчиков заводится журнал задач (project backlog). Project backlog – это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются «пожеланиями пользователя» ( user story ) или элементами резерва ( backlog items ). Резерв проекта открыт для редактирования для всех участников scrum процесса. Sprint backlog – содержит функциональность, выбранную владельцем проекта из project backlog. Все функции разбиты по задачам, каждая из которых оценивается scrum-командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения итерации. 45

46 1.8. Как осуществляется процесс улучшения процессов На Retrospective Meeting (Ретроспектива) команда также делает обзор выполненной итерации с точки зрения процессов: Все члены команды рассказывают своё отношение к ходу прошедшего спринта. Отвечают на два основных вопроса, с точки зрения управления проектом и разработкой: Что было хорошо? Фиксируют удачные решения. Что надо улучшить? Пытаются решить, как это сделать. 46

47 1.9 Как контролируются процессы Руководитель проекта проводит ежедневные короткие собрания ( Daily Scrum Meeting ) Цель митинга – поделиться информацией. Он не предназначен для решения проблем в проекте. В течение митинга каждый член команды отвечает на 3 вопроса: Что сделано с момента предыдущего митинга до текущего? Что будет сделано с момента текущего митинга до следующего? Какие проблемы мешают достижению целей итерации? (Над решением этих проблем работает ScrumMaster. Обычно это решение проходит за рамками митинга и в составе лиц, непосредственно затронутых данным препятствием.) 47

48 1.10. Как информируется команда, заинтересованные люди об изменениях в процессах, как обучаются новым процессам База знаний компании содержит всю информацию обо всех процессах. База знаний это wiki подобная система, на любую страницу в которой можно подписаться. Все подписавшиеся получают на почту уведомления об изменениях. Таким образом, команда и заинтересованные лица информируются об изменениях. Обучение новым или изменённым процессам происходит на соответствующих собраниях. 48

49 1.11. Как измеряется удовлетворённость процессами команды, заинтересованных сторон На каждой ретроспективе, каждый имеет право высказать своё мнение по процессам управления проектами и программной разработки. Измерение удовлетворённости субъективное, многие могут не высказать своё мнение, но в большинстве случаев ценить отношение к процессу можно путём диалога со всей командой. 49

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

51 1.13. Как сокращается доля ненужных действий, которые не добавляют ценность к создаваемому продукту. Бережливая разработка программного обеспечения (Lean Software Development) методология, использующая методы концепции бережливого производства. Основная задача подхода – это устранять потери, возникающие во время разработки: Золотая сервировка (перепроизводство); Избыточные требования (излишние запасы); Лишние шаги в разработке (излишняя обработка); Трудности в поиске необходимой информации (ненужные перемещения); Пропуск багов при тестировании (выпуск дефектной продукции); Задержки из-за ожидания каких-либо решений, ожидания ответов от клиентов (ожидание); Потери при передачи проекта, требований, знаний, развертывании системы (ненужная транспортировка). 51

52 2. Как происходит применение и улучшение процессов ведения проектов 2.1. Как в проекте выбираются методы управления проектами, с учётом рамок – ограничений, объёма работ, гибкости 2.2. Как в проекте соблюдается использование проектной методологии (стандарт pmbook, ipma, din и т.п.) 2.3. Какие используются программные среды для ведения проекта, методы визуализации 2.4. Как проходит модерация совещаний, коммуникация и др. методы управления проектами 2.5. Как ведётся проектная документация 2.6. Как внедряется философия проектного управления, как она изучается 2.7. Как фиксируются эффективные методы проектного управления 2.8. Как осуществляется проектный контроллинг 52

53 3. Как осуществляется сохранение опыта, для использования в будущих проектах 3.1. Как фиксируются новые данные, знания 3.2. Как систематизируются знания, информация 3.3. Какие используются системы 3.4. Как обеспечивается надёжность полученного опыта 3.5. Как передаётся опыт – семинары, доклады, статьи 53

54 Обмен информацией по методам управления проектами Обмен информацией по методам управления проектами происходит раз в месяц в рамках круглых столов по управлению проектами, на которых руководители проектов знакомятся с новыми методами и процессами, обмениваются опытом. По завершению проектной работы проводится мероприятие по обмену опытом и ноу-хау. 54

55 Проблемы мотивации 55

56 Мотивация. Теория ожиданий 56

57 Мотивация программистов Люди, которые хорошо себя чувствуют, добиваются хороших результатов 57

58 Итак, Менеджер проекта - это человек, который, как паук на паутине, чувствующий любые колебания проекта и процессов, улавливающий любые нюансы проекта. проактивные люди задающие направление движения и темп проекта. 58

59 Заключение. Мудрые высказывания Руководить - это значит не мешать хорошим людям работать. Петр Леонидович Капица В искусстве управления всегда остаешься учеником. Кристина, королева Швеции У начальника все пальцы на руках указательные Леонид Крайнов-Рытов Чтобы вести людей за собой, иди за ними Лао Цзы, китайский философ 59

60 Ещё немного афоризмов Управление компанией напоминает управление воздушным змеем, когда он, с опозданием повинуясь руке, повторяет заданное движение. Владимир Костельман По большей части сотрудники уходят от начальников, а не из компаний. Роберт Саттон Не имеет смысла нанимать толковых людей, а затем указывать, что им делать. Мы нанимаем толковых людей, чтобы они говорили, что делать нам. Стив Джобс Каждый вечер 95 процентов всех активов моей компании разъезжаются на машинах по домам. Моя задача - создать такие условия труда, чтобы на следующее утро у всех этих людей возникло желание вернуться обратно. Креативность, которую они приносят в компанию, создает конкурентное преимущество. Джеймс Гуднайт 60

61 Спасибо! Материалы используемые в презентации взяты из: Этапы проекта: Процессы: Делитесь информацией, только так вы будете развивать себя сами. 61