Управление проектами
Проект Антона Витязя
Управление качеством проекта
Жизнь багов
03 years
by Антон Витязь
in Управление качеством проекта, Юмор
Взято с сайта http://happy-pm.com/
Реестры требований
13 years
by Антон Витязь
in Опрос, Управление качеством проекта
В LinkedIn группе опубликовал опрос коллег по поводу Реестра требований:
Коллеги, хотел с вами обсудить ведение реестра требований в проекте. Интересно ваше мнение по этому поводу и ваши практические замечания. Есть пару вопросов:
- Ведете ли вы реестры требований?
- Какую пользу вы видите от этого?
- Для каких проектов ведете а для каких нет?
- Кто занимает управлением реестром требований?
- С помощью какого инструмента вы управляете реестром?
- Что бы вы хотели улучшить в своей практике ведения реестра требований?
Список вопросов по проблеме
03 years
by Антон Витязь
in Книга по управлению проектами, Мониторинг и управление, Управление качеством проекта, Управление рисками проекта
Когда перед нами проблема нам стоит себе задать ряд вопросов:
Первый взгляд на проблему
- Эта проблема имеет отношение к проекту?
- Как влияет проблема на проект – как это влияет на стоимость, качество, график проекта?
- Как это влияет на еще не реализовавшиеся риски проекта?
- Стоит ли нам вообще как-то реагировать на проблему?
- Кого мы должны оповестить о возникновении проблемы?
Вопросы по решению проблем
- Кто займется проблемой? Когда?
- Кого мы должны включить в группу решения проблемы?
- Кто оплачивает решение проблемы?
- Проблема должны быть вынесена на уровень выше?
- Эта проблема застрахована?
Вопросы по анализу проблем
- В чем причина возникновения проблемы?
- Какой это был риск? Повторится ли он еще раз?
- Как мы можем быстро ликвидировать проблему?
- Как мы можем ликвидировать источник проблемы?
- Какие меры нам надо предпринять чтобы минимизировать влияние проблемы?
Меряем проблему
- Как это влияет на удовлетворенность клиента?
- Сколько нам стоит проблема?
- Кто оплатит расхода ны проблему, ее устранение и предотвращение? Один за все части или можем как то перераспределить затраты?
- Какой приоритет у этой проблемы по отношению к другим проблемам и задачам проекта?
Закрываем проблему
- Как мы определим что проблема решена?
- Кто должен принять решение о закрытии проблемы?
- Кого мы должны оповестить о решении проблемы?
Данная статья взята из материалов книги Наша книга по управлению проектами
Принято!
03 years
by Антон Витязь
in Исполнение, Управление качеством проекта, Управление поставками проекта
Какое приятное слово для руководителя проекта – Принято! Это слово звучит как праздник после очередного (особенно сложного) этапа проекта. Кроме, безусловно, качественно выполненной работы по требованиям и может быть даже в срок, выстроенных правильно ожиданий заказчика есть еще несколько важных моментов о которых я хочу поговорить в данной статье. Это процесс приемки (Acceptance).
Несмотря на то что приемка находится в конце этапа (а в небольших проектах и в конце проекта) – готовится к ней надо заранее и первый прогон надо делать несколько раньше – чтобы определиться с полнотой и качеством рабочего набора артефактов приемки, приучить к нему заказчика, заранее обнаружить возможные проблемы в приемочных тестах или в продукте.
Какие документы (артефакты) нам нужны:
- План приемочных испытаний – перечень того что включается в приемку. В идеале план должен быть согласован в проекте как можно раньше – в самом начале разработки когда есть согласованное ТЗ, проработана архитектура и согласован план проекта.
- Форма приемочного теста – описание того что и каким способом принимается. Содержит ссылку на требования. Если сослаться на другой источник – описания требований и тестовых кейсов – то форму можно слить с планом приемочных испытаний.
- Реестр приемочных замечаний – с первого раза обычно не выходит (не забудьте учесть это в плане проекта)
- Протокол приемочного тестирования – здал-прынял Может строиться как документ-шапка к плану приемочных испытаний.
Если приемочное тестирование подразумевает кроме тестирования качества еще и соответствие по денежным и временным показателям – то необходимо предоставить план-факт анализ выполнения работ по созданию переданных на приемочное тестирование результатов проекта.
О методах приемочного тестирования:
- Тестирование заказчиком самостоятельно – заказчик уходит в себя и выдает результат. Это рискованно в том плане что у заказчика может не быть профессиональных ресурсов, загрузка по текущим задачам может растянуть процесс приемки. При тестировании заказчик может “выбиться” из колеи – и уйти строить воздушные замки вместо тестирования по требованиям.
- Тестирование (Аудит) третьей стороной – для этого круто нанять специализированную компанию на тестировании или подписать договор с конкурентом вашего поставщика на оказание услуг аудита. Последнее жестко и рискованно – зато не даст никому расслабиться
- Совместное тестирование по сценариям с заказчиком – поставщик помогает готовить пакет материалов для приемочного тестирования, готовит команду заказчика к методичному приемочному тестированию, контролирует ход приемочного тестирования и сроки его выполнения. Присутствие инжинера по тестированию со стороны исполнителя поможет лучше зафиксировать расхождения, замечания и не дай бог выявленные дефекты.
Компоненты информационной среды управления проектами
03 years
by Антон Витязь
in MS Project, Sharepoint, Инструменты, Мониторинг и управление, Планирование, Управление интеграцией проекта, Управление качеством проекта, Управление человеческими ресурсами проекта, Управление коммуникациями проекта, Управление рисками проекта, Управление поставками проекта
Для более менее крупных проектов мы задумываемся о построении информационной системы для управления проектами. Прежде чем говорить – да у нас есть MS Project – и в северном варианте (Project Server) он будет очень классно покрывать все нужды – не спешите. Давайте рассмотрим основные компоненты такой среды и какие потенциальные компоненты могут подойти.
Коммуникации - сайт проекта, форум, рассылка, группы. Это может быть как сайт на SharePoint так и любая WiKi/Wordpress/LinkedIn группа. Для небольшого бизнеса вполне удобно создавать закрытые группы в социальных сетях и использовать их как готовые платформы для проектных коммуникаций.
Документы проекта – минимум файловый сервер. Лучше всего – сразу SharePoint или аналогичное средство с функционалом управления версиями. Если документы проекта будут готовиться исключить в веб форме – то вам также отлично подойдут Wiki системы. В них очень легко контролировать версии документов (но несколько сложнее научиться писать их с использованием внутренней разметки)
Записи проекта - это различные типы записей – структура работ, запросы на изменения, вопросы, дефекты, риски, требования, тесты, результаты выполнения тестов. Кроме фиксации самих записей важно чтобы работали хотя бы простые workflow по организации работы над записями – это даже крайне желательно. Для управления такого рода записями нужна система с удобным конструктором как новых записей так и процессов, удобными формами. SharePoint в базовой конфигурации для этого не очень хорошо подходит (но вполне терпимо для малых проектов). Хорошим кандидатом сюда – Microsoft Dynamics CRM 2010, SharePoint + Nintex + кастомные решения для организации документооборота. Также могут подойти ваши существующие ERP системы (в них легко создавать новые сущности и формы но менее просто решаются вопросы по автоматизации процессов)
Календарь проекта и Фактические данные – тут рулит Microsoft Project.
Управленческий учет – фиксация затрат, закупок, выставление счетов, поступление денежных средств, выплата заработной платы и компенсаций участником проекта). В проектах где мотивация персонала крепко связанна с их ежедневным вкладом в проект а их бонусы зависят от успеха проекта – крайне важно наладить прозрачную процедуру для перетока информации из записей проекта, плана проекта и фактических данных в управленческий учет.
6 углов проектного менеджера – уже не так железно
03 years
by Антон Витязь
in Методика, Управление содержанием проекта, Управление сроками проекта, Управление стоимостью проекта, Управление качеством проекта, Управление рисками проекта
Развитие концепции железного треугольника управления проектами- стоимость, время и содержание проекта – шестиугольник проектного управления.
В состав шестиугольника входят следующие дополнительные компоненты:
- Удовлетворенность клиента (Customer Satisfaction)
- Риск (Risk)
- Качество (Quality)
С моей точки зрения железный треугольник был действительно железным – меняя одну из составляющих мы неизбежно оказывали влияние на одну из двух других или обе. В случае с шестиугольником это уже не очевидно.
Удовлетворенность клиента – безусловно одна из важнейших составляющих проектного управления. Но в ней есть немало эмоционального контекста – и далеко не всегда она имеет прямые (железные) связи с изменением других компонент.
Аналогично риск. Сама природа риска такова что мы скорее не может полностью покрыть перечень рисков которым подвержен проект. В свою очередь точность измерения рисков также условна. Таким образом трудно утверждать насколько реально повлияло изменение одной из компонент на риск.
Сделать сделали, а передать то – забыли!
03 years
by Антон Витязь
in Внедрение, Завершающие, Инициация, Исполнение, Планирование, Управление интеграцией проекта, Управление содержанием проекта, Управление качеством проекта, Управление коммуникациями проекта, Управление рисками проекта
Среди ошибок проектных менеджеров при разработке новых ИТ сервисов встречается ошибка отсутствия блока необходимых работ по передаче сервиса в промышленную эксплуатацию.
Эта ошибка коренится в том что проектный менеджер забывает включить в перечень ключевых заинтересованных лиц ИТ менеджеров по операциям:
- менеджеров сервиса
- менеджеров по обслуживанию пользователей,
- техническая поддержка – контакт центр поддержки ИТ
Какие могут возникнуть риски? Масса!
Риск проблем с технической поддержкой. Уже во второй половине проекта часто начинается доносится тревожный звоночек – некоторые пользователи, которые участвуют в ознакомлении с первыми релизами продукта, вместо обговоренного контакта с менеджером проекта начинают по привычке звонить в техническую поддержку. Техническая поддержка может по разным причинам сделать следующее:
- Отказать пользователю в обслуживании – что создаст негативное впечатление о проекте
- Дать неверный совет по использованию ПО – что может привести к негативному впечатлению о продукте
- Дать обещание ответить пользователю и не выполнить обещание в срок – пока поддержка начнет искать кто реально может обслужить данный вопрос. Хуже всего если в технической поддержке просто забросят вопрос.
Конфликт с другим сервисом находящимся в промышленной эксплуатации. Хуже всего если это важный операционный сервис критичный для работы бизнеса. Данный конфликт может создать проблемы для текущих операций пользователей. Кроме всего прочего это может косвенно указать на архитектурные ошибки или ошибки в планировании развертывания – связанные с тем что не были учтены все сервисы работающие у конечных пользователей продукта.
Что необходимо сделать менеджеру проекта:
- Обязательно включить в перечень заинтересованных лиц менеджеров по ИТ операциям. Найти всех кто отвечает за работу с пользователями, техническую поддержку. Включить в перечень ключевых лиц в работу над архитектурой, развертыванием и тестированием. Обязательно в этап передачи в эксплуатацию и go live.
- Определить порядок приема в эксплуатацию. Какие внутренние стандарты приняты в компании по передачи ИТ сервисов в эксплуатацию?
- Вовлечь в работу и информировать. Делать рассылки о всех операциях в рамках проекта которые касаются конечных пользователей. Установить процедуру согласования подобных операций.
- Включить в план проекта работы по обучению технической поддержки и менеджеров по ИТ операциям на всех стадиях проекта – от ознакомительной на ранней стадии, совместной работы над архитектурой, планами по развертыванию и тестированию до конечного обучения.
Критичность закрытия фаз/итераций. Пример из практики
03 years
by Антон Витязь
in Анализ, Завершающие, Инициация, Исполнение, Мониторинг и управление, Планирование, Процессы, Управление интеграцией проекта, Управление содержанием проекта, Управление сроками проекта, Управление стоимостью проекта, Управление качеством проекта, Управление человеческими ресурсами проекта, Управление коммуникациями проекта, Управление рисками проекта, Управление поставками проекта
Очень важно в крупных корпоративных проектах закрывать фазы (этапа, итерации) согласованием пакета закрывающих документов.
Сам факт закрытия фазы позволяет:
- показать промежуточный результат в проекте
- согласовать с заказчиком понимание где сейчас находится проект
- отметить срез ключевых показателей проекта – по срокам, стоимости и объему работ
- определить легитимную основу для дальнейших действий
- снизить риски разногласий, проблем в понимании достигнутых договоренностей и результатов
- приучить заказчика к умению закрывать проект – приучать к этому нужно с ранних этапов, делать это системно по четко определенной процедуре
- выстраивать логическую связь от достигнутых результатов к запланированном на следующем этапе
Из практики отечественных проектов встречались ситуации когда в проекте на этапе зависли на согласовании несколько аналитических документов. Казалось бы согласованным в документах было около 80%. Команда проекта решила что необходимо двигаться к разработке и по ходе решить оставшиеся 20% требований. Однако в течении нескольких последующих месяцев это привело к тому что
- аналитический документ и зменился более чем на половину
- объем работ вырос в полтора раза
- было потеряно около трети времени на разработку в следствии кардинального изменения
- существенно изменились сроки проекта
- поставщик понес убытки на потерянном объеме работ
- клиент был недоволен что “его по-прежнему не пониманию и делают всякую ерунду”
- клиент наблюдая податливость в протягивании согласования аналитического документа позволял себе “пропихивать” новые изменения и расширять рамки проекта
Сертификационный тестировщик – программа обучения
03 years
by Антон Витязь
in Полезные ссылки, Управление качеством проекта
http://www.scribd.com/doc/56795254/Istqb-Ctfl-Syllabus-2011-Ru
Разрушительная сила низкого качества
04 years
by Антон Витязь
in Управление качеством проекта
Низкое качество продукта не только наносит ущерб удовлетворенности заказчика, имиджу поставщика продукта, создает дополнительные операционные затраты на обслуживание некачественного продукта, создает риск необходимости полной замены такого некачественного продукта – но больше всего оно разрушает людей. Веру людей в разработку качественных продуктов, разрушает проектную команду и мотивацию отдельных участников.
Next »