Как в проекте идентифицируются, контролируются, изменяются процессы

Задача:

Описать проект, в котором вы участвовали.
Показать, как в проекте идентифицируются, контролируются, изменяются процессы, направленные на создание ценности.

Исходите из того, что вы выдвигаете ваш проект на премию по управлению проектами, который будет оценен асессорами.

Описание проекта
Наименование
Назначение программного комплекса
Цели создания программного комплекса
Команда проекта
Заказчик и заинтересованные группы
Совет директоров
Основная методология управления проектами в программных разработках компании
Анализ проекта с процессной точки зрения
- Как идентифицируются и управляются процессы проекта
- Как происходит применение и улучшение процессов ведения проектов
- Как осуществляется сохранение опыта, для использования в будущих проектах

Описание проекта

Наименование

Специализированный программный комплекс «Процессинговая система XX» (далее по тексту Процессинг).

Назначение программного комплекса

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

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

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

Цели создания программного комплекса

Выполнение работ по разработке программного комплекса Процессинга преследует цель построения процессинговой системы нового поколения, объединяющей достоинства имеющихся систем, лишённой их недостатков и значительно превосходящей их по производительности, в том числе:

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

Команда проекта

Команда проекта делится на следующие структурные единицы:

Команда back end разработки (ядро процессинга);
Команда front end разработки (портал);
Команда терминального программного обеспечения;
Команда тестирования;
Команда аналитики;
Дизайнер.

Итого: 15 человек

Заказчик и заинтересованные группы

В качестве заказчика выступает Генеральный директор компании.

Заинтересованные группы (в скобочках указано количество заинтересованных лиц внутри подразделения):

Внутренние:
- генеральный директор;
- технический директор;
- отдел программно-аппаратной разработки (3 человека);
- финансовый отдел (4 человека);
- отдел маркетинга (2 человека);
- отдел развития (2 человека);
- отдел терминальной сети (5 человек);
- отдел системного администрирования (2 человека);
- служба эксплуатации терминальной сети (8 человек);
- служба поддержки, call центр (5 человек);
- акционеры компании (7 человек).
Внешние:
- контрагенты с собственными сетями платёжных терминалов (10);
- провайдеры, предоставляющие услуги;
- физические лица.

Совет директоров

Совет директоров – структура компании, в обязанности которой входят следующие функции, связанные с проектом создания Процессинга:

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

Основная методология управления проектами в программных разработках компании

Назначение

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

Краткое описание

В Scrum каждая итерация называется Sprint. Длительность спринта назначается в его начале командой. Обычно составляет две недели.

Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу).

Роли в Scrum

В методологии Scrum всего три роли:

Scrum Master – тот, кто ведёт Scrum митинги и следит, чтобы при этом соблюдались все принципы Scrum;
Product Owner – (Владелец Продукта) – человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон.
Team – кросс-функциональная Команда, состоящая как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т.д. (при этом размер команды в идеале составляет 7±2 человека). Команда является единственным полностью вовлечённым участником разработки, и отвечает за результат как единое целое.

Жизненный цикл спринта

В начале каждого спринта проводится планирование. Обсуждается цель (Sprint Goal), список задач на итерацию (Sprint Backlog), оцениваются сроки. В спринте участвуют: менеджер проекта, команда, владелец (представитель заказчика, постановщик задач).

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

После того, как задачи на итерацию спланированы, определён срок разработки, начинается разработка. Во время спринта команда выполняет поставленные задачи (т.н. Sprint Backlog). На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать как заморозку требований (Requirements) во время спринта.

Анализ проекта с процессной точки зрения

1. Как идентифицируются и управляются процессы проекта

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

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

Идентификация вех процессов тесно связана с выбранной моделью управления проектами. Так, в нашей проектной деятельности, можно выделить следующие группы процессов управления проектами:

Старт проекта
- Сбор требований;
- Управления желаниями заинтересованных сторон.
Планирование работ;
- Управления временем проекта;
- Управление информационным обменом.
Исполнение;
- Управления ресурсами;
- Управления приоритетами проектов и подпроектов;
- Управления приоритетами задач в проекте;
- Управление развитием проекта;
- Управления изменениями;
- Установки вех;
- Управления рисками;
- Проектирования архитектуры системы, модулей, …;
- Разработки программного обеспечения;
- Тестирования ПО;
- Выпуска версий;
- Загрузки ПО на терминалы;
- Демонстрации промежуточных результатов;
- Подготовки документации;
- Мотивации сотрудников команды;
- Развития сотрудников.
Мониторинг и управление;
- Контроля проекта;
- Анализа процессов.
Завершение;
- Приёмка;
- Ретроспективы;
- Сохранения опыта, знаний;
- Реинтеграции сотрудников.

1.1. Как определяются процессы и их воздействие на проект

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

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

Все процессы управления проектами пересекаются друг с другом во времени на протяжении жизненного цикла проекта и являются исходными данными для других процессов.

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

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

Идентифицируем самые важные, создающие ценности, процессы. В компании по разработке ПО можно выделить следующие ключевые процессы:

Управление проектом или программной разработкой (если не внедрено первое);
Управление изменениями;
Управление качеством;
Управление итерациями, переходами из фазы в фазу.

Реализация этих процессов контролируется за счёт аудита системы, процессов и проекта в целом. Полученная обратная связь, вносит и оптимизирует последние.

Правила по управлению проектом дают инструмент по контролю проекта, позволяют направить проект в правильное русло.

Для контроля и координации рабочих шагов проекта в начале проекта и с определённой периодичностью в процессе выполнения проекта осуществляется согласование итераций, вех проекта в соответствии с фазами всего процесса разработки продукта в рамках проекта и в соответствии с требованиями клиента. Конец каждой фазы или вехи является контрольным пунктом поверки качества продукта, которое основывается на требованиях и пожеланиях клиента. Отдельный процесс проверки качества внутреннего программного кода продукта осуществляется в рамках ежедневной сборки продукта, который осуществляется ежедневно, например, в 24:00, и в рамках которого запускаются автоматические функциональные, интеграционные и другие типы тестов, проверяющие разработанный программный код продукта.

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

Отдел качества проводит контроль выполнения объёма работ по вехам или законченным итерациям. Незавершённые задачи включаются в следующую итерацию или переносятся на другие итерации или полностью исключаются при согласии клиента.

Руководители проектов проводят обзоры проекта, на которых выявленные слабые места планируются к улучшению.

По завершению проектной работы проводится мероприятие по обмену опытом и ноу-хау.

Итеративно проводятся мероприятию по анализу и пересмотру рисков и их соответствие реальному состоянию проекта.

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

1.2. Как на проект назначается руководитель, команда и выбирается тип проектной организации.

Компания не очень большая, поэтому руководителя проекта (РП) назначает генеральный директор.

РП определяет необходимое количество людей на проект.

Все проекты приоритезируются по степени важности.

Проект с наибольшим приоритетом имеет право привлечь необходимое количество людей в проект.

Проекты с меньшим приоритетом получают оставшиеся человеческие ресурсы в порядке приоритета.

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

1.3. Как осуществляется планирование

Процесс планирования можно разделить на следующие фазы:

начало проекта;
начало каждой итерации (или вехи) проекта;
ежедневные standup собраний команды;
завершение проекта, фазы, итерации;
кросс-проектных совещаний.

В фазе начала проекта определяются:

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

В фазе каждой новой итерации, которая может длиться от одной до 4-х недель. Итеративные этапы планирования включают:

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

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

В фазе завершения проекта, фазы, вехи или итерации проводится ретроспектива пройденного отрезка проекта, на которой:

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

В фазе кросс-проектных совещаний осуществляется:

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

Управление требованиями

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

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

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

Работа с матрицей требований осуществляется на протяжении всего жизненного цикла разработки продуктов.

Управление изменениями

Управление изменениями – существенный аспект планирования. Без него вся работа может оказаться напрасной: первоначально созданные планы, как бы хороши они не были, останутся статичными, со временем, неизбежно разойдутся с реальностью и станут бесполезными.

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

Изменения призваны обеспечить проекту «самонаведение» на цель (внося корректировки в «траекторию» – в состав работ).

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

Управление рисками

Управление рисками осуществляется в течение всего проекта, до его закрытия.

Работа ведется на основании реестра рисков. С его помощью:

отслеживаются триггеры риска и приводится в действие мероприятия по предотвращению риска силами «хозяев рисков»;
выявляются новые риски силами команды и прочих заинтересованных лиц;
переоцениваются старые риски силами команды.

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

1.4. Как осуществляется управление процессами проекта

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

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

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

За процесс тестирования отвечает руководитель отдела качества. Схематично процесс изображён на картинке:

1.5. Как организуется контроль вех

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

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

Demo Meeting (Демонстрация):

Происходит в конце итерации (спринта).
Команда демонстрирует инкремент функциональности продукта всем заинтересованным лицам.
Привлекается максимальное количество зрителей.
Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).

Retrospective Meeting (Ретроспектива):

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

Анализ тренда вех:

анализа отклонений сроков, основанный на фактических и плановых значениях.

1.6. Как проходит проверка план-факт и вносится корректирующее воздействие

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

В рамках всего проекта, на уровне анализа тренда вех, проводится анализа отклонений сроков, основанных на фактических и плановых проектных значениях.

1.7. Как учитываются пожелания всех заинтересованных групп

Для учёта пожеланий всех заказчиков заводится журнал задач (project backlog).

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

Sprint backlog – содержит функциональность, выбранную владельцем проекта из project backlog. Все функции разбиты по задачам, каждая из которых оценивается scrum-командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения итерации.

1.8. Как осуществляется процесс улучшения процессов

На Retrospective Meeting (Ретроспектива) команда также делает обзор выполненной итерации с точки зрения процессов:

Все члены команды рассказывают своё отношение к ходу прошедшего спринта.
Отвечают на два основных вопроса, с точки зрения управления проектом и разработкой:
- Что было хорошо? Фиксируют удачные решения.
- Что надо улучшить? Пытаются решить, как это сделать.

1.9 Как контролируются процессы

Руководитель проекта проводит ежедневные короткие собрания (Daily Scrum Meeting)

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

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

В течение митинга каждый член команды отвечает на 3 вопроса:

Что сделано с момента предыдущего митинга до текущего?
Что будет сделано с момента текущего митинга до следующего?
Какие проблемы мешают достижению целей итерации? (Над решением этих проблем работает ScrumMaster. Обычно это решение проходит за рамками митинга и в составе лиц, непосредственно затронутых данным препятствием.)

1.10. Как информируется команда, заинтересованные люди об изменениях в процессах, как обучаются новым процессам

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

Обучение новым или изменённым процессам происходит на соответствующих собраниях.

1.11. Как измеряется удовлетворённость процессами команды, заинтересованных сторон

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

1.12. Как работает обратная связь участников проекта с оптимизацией процесса

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

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

Бережливая разработка программного обеспечения (Lean Software Development) — методология, использующая методы концепции бережливого производства.

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

Основная задача подхода – это устранять потери, возникающие во время разработки:

Золотая сервировка (перепроизводство);
Избыточные требования (излишние запасы);
Лишние шаги в разработке (излишняя обработка);
Трудности в поиске необходимой информации (ненужные перемещения);
Пропуск багов при тестировании (выпуск дефектной продукции);
Задержки из-за ожидания каких-либо решений, ожидания ответов от клиентов (ожидание);
Потери при передачи проекта, требований, знаний, развертывании системы (ненужная транспортировка).

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

Учитывая, что изменения во время работы над проектом меняются, мы используем в бережливой разработке две ключевые технологии, которые делают изменения простыми. Точно так, как бережливое производство встраивает проверку качества в производственный процесс для определения того, когда процесс нарушен, бережливая разработка должна «встраивать тесты» на различных стадиях процесса разработки. В случае, если происходят изменения во время разработки, необходимо использовать юнит и регрессионное тестирование. Если тесты не проходят удачно, программирование должно быть остановлено до тех пор, пока проблема не будет обнаружена и исправлена. Всеобъемлющее тестирование – лучший способ быть готовым к изменениям в течение процесса разработки.

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

Итого, используемые принципы Lean software development

Исключение затрат. Затратами считается всё, что не добавляет ценности для потребителя. В частности: излишняя функциональность; ожидание (паузы) в процессе разработки; нечёткие требования; бюрократизация; медленное внутреннее сообщение.
Использование всеобъемлющего тестирования.
Сокращение времени разработки.
Рефакторинг.
Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.
Предельно отсроченное принятие решений. Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов.
Предельно быстрая доставка заказчику. Короткие итерации.
Мотивация команды. Нельзя рассматривать людей исключительно как ресурс. Людям нужно нечто большее, чем просто список заданий.
Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.
Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. «Мыслить широко, делать мало, ошибаться быстро; учиться стремительно».

2. Как происходит применение и улучшение процессов ведения проектов

Была разработана модель действий с передачей завершённых этапов в последующие фазы. Клиент может требовать доработки на стадии сдачи-приёмки этапе. Это свидетельствует о систематичности работы.

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

2.1. Как в проекте выбираются методы управления проектами, с учётом рамок – ограничений, объёма работ, гибкости

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

Для более мелких и неопределённых проектов, используются методы, основанные на гибких методологиях.

Метод выбирается согласованно с руководителем проекта и рядом заинтересованных лиц.

2.2. Как в проекте соблюдается использование проектной методологии (стандарт pmbook, ipma, din 69900 и т.п.)

В компании используется гибридная схема управления проектами, которая включает в себя следующие методологии:

Scrum
Kanban
XP
Бережливое производство
DIN, PMBOK, Prince2

2.3. Какие используются программные среды для ведения проекта, методы визуализации

Confluence – система хранения проектной информации, процессов.

Jira – система постановки задач, багов.

Project Plan – задачи, последовательность, вехи, сетевая диаграмма, диаграмма ганта.

2.4. Как проходит модерация совещаний, коммуникация и др. методы управления проектами

Используемые правила:

Соблюдается структура совещания.
Модератор управляет процессом проведения совещания.
Назначенный сотрудник, фиксирует результаты встречи.
Заранее делается рассылка со структурой совещания, её целями, задачами, которые нужно решить. Указываются участники и докладчики. Прикрепляются необходимые материалы, ссылки.

Структурно совещание можно разделить на три части:

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

Эффективность совещания обеспечивается за счёт:

возможности всем высказаться.
РП не вмешивается в сферу заданий своей команды и не принимать за неё решения. За исключением какой-либо опасности, которая может возникнуть из-за неправильного решения.

2.5. Как ведётся проектная документация

В системе Confluence ведётся проектная документация:

ТЗ;
Функциональные требования;
Требования, пожелания клиентов;
Описание интерфейсов, логики работы;
Архитектура системы;
Описание программных модулей;
Инструкции по установке, администрирования;
Описания работы АРМ;
Проектная отчётность;
И т.п. документы.

2.6. Как внедряется философия проектного управления, как она изучается

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

Рассмотрим преимущества самоорганизующихся команд:

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

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

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

2.7. Как фиксируются эффективные методы проектного управления

В базе знаний компании, в разделе проектного управления.

2.8. Как осуществляется проектный контроллинг

Проектный контроллинг осуществляется следующим образом:

Диаграмм Burnup & Burndown показывает количество выполненной и оставшейся работы текущей итерации.
В рамках всего проекта, на уровне тренда вех, проводится анализа отклонений сроков, основанных на фактических и плановых проектных значениях.
Отчёт о продвижении проектных работ.
Отчёт о статусе проекта.
Анализ рисков проекта.
Управление изменениями.
Тестирование продукта.

3. Как осуществляется сохранение опыта, для использования в будущих проектах

Единственная настоящая ошибка – не исправлять своих прошлых ошибок. Конфуций

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

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

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

3.1. Как фиксируются новые данные, знания

Заносятся в Confluence, в соответствующий раздел.

3.2. Как систематизируются знания, информация

Все знания и информация систематизируется, классифицируется и структурируется в базе знаний. Для систематизации информации используются определённые форматы документов.

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

3.3. Какие используются системы

Confluence – wiki система.

3.4. Как обеспечивается надёжность полученного опыта

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

3.5. Как передаётся опыт – семинары, доклады, статьи

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

Для передачи опыта, используется процесс по излечению уроков (ИУ), информации завершённого проекта. Обычно содержит следующую информацию:

Что было? Информацию о произошедшем событии.
Как повлияло на проект? Какое влияние это событие оказало на проект.
Что делать? Рекомендации на будущее.

Данный процесс позволяет осуществить сбор, анализ и применение в последующих проектах извлечённых уроков.

В рамках проектной деятельности компании осуществляется:

Учёт исторической информацию из ИУ. При старте и планировании нового проекта.
При завершении проекта (фазы проекта) обязательно формировать ИУ.
Ведётся база знаний по ИУ.

Документ «Извлечённые уроки», готовится по окончании проекта. Документ обязателен для заполнения. Структура документа:

Профиль проекта;
Взаимодействие с подрядчиками;
Взаимодействие с внешними организациями;
Отрицательные уроки;
Положительные уроки.

Кроме того, на уровне разработки программных систем:

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

Share and Enjoy:

Tags: pm, Процессы