Завершение проектов
DESCRIPTION
Лекция посвящена последнему этапу работы над проектом, а именно его завершени. Часто случается так, что якобы выполненные проекты затягиваются на этапе сдачи. В этой лекции мы рассмотрим причины и возможные пути решения. Ссылка на текстовую версию: http://growandmanage.com/zavershenie-proektov/TRANSCRIPT
ЗАВЕРШЕНИЕ ПРОЕКТОВСоветы по успешному завершению проектов
Тимофей Татаринов, 2014http://tatarinov.cc
ПРОБЛЕМА
ПРИЧИНЫ НЕУДАЧ И ЗАТЯГИВАНИЯ ПРОЕКТОВ
• Низкая степень вовлечения заказчика или пользователей в процесс разработки проекта
• Недостаточно определённые требования • Недостаточная поддержка проекта топ менеджментом
• Нереалистичные ожидания • Недостаточно ясные цели • Цель проекта перестала быть актуальной
ОСНОВНАЯ ПРИЧИНА
Проблема в коммуникации между менеджером проекта и заказчиком и в том, насколько хорошо совместно проработан этап “старта” проекта.
РЕШЕНИЕ
ЧТО ЖЕ НУЖНО ДЛЯ УСПЕХА?
1.Общение между командой и клиентом 2.Тестирование на протяжении всего проекта 3.Четко определенные, ожидаемые клиентом результаты в самом начале проекта и критерии качества
ОБЩЕНИЕ МЕЖДУ КОМАНДОЙ И КЛИЕНТОМ
•Определите и зафиксируйте основные принципы и средства коммуникации.
•Фиксируйте результаты встреч, звонков и любого личного общения и отправляйте всем участникам по email.
•Узнайте и зафиксируйте, кто будет принимать проект на стороне заказчика.
•Регулярно общайтесь с заказчиком, делайте апдейт по статусу, узнавайте его мнение - все что угодно. Главное оставайтесь “на связи”!
ТЕСТИРОВАНИЕ НА ПРОТЯЖЕНИИ ВСЕГО ПРОЕКТАВыпустите первую сборку проекта как можно раньше, а потом как можно чаще обновляйте ее. В этом случае вы:
• обкатаете процесс сборки и интеграции различных компонентов системы;
• вы сможете подключить тестировщиков, которые будут следить за качеством продукта;
• это позволит вам держать в курсе заказчика и показывать ему прогресс по ходу работы.
ЧЕТКО ОПРЕДЕЛЕННЫЕ РЕЗУЛЬТАТЫ РАБОТЫ
ПЕРЕД СТАРТОМ проекта нужно разработать вместе с заказчиком документ, в котором будут описаны его ожидания к результатам и качеству проекта.
ДОКУМЕНТ ОЖИДАНИЙ ЗАКАЗЧИКА
1. Определение потребности заказчика и потребителя.
2. Критерии заказчика по приему продукта. 3. Требования заказчика. 4. Масштаб и границы проекта. 5. Критерии качества
ПОТРЕБНОСТИ ЗАКАЗЧИКА И ПОТРЕБИТЕЛЯ
Вопросы, которы помогут выявить проблему: !1. Как эта проблема влияет на бизнес? 2. Из-за чего, по вашему мнению, она возникла? 3. Исчезнет ли эта проблема, если мы реализуем предложенное вами решение? !
!Если заказчик не является конечным потребителем продукта, обязательно нужно определить этого потребителя и повторить процесс выявления проблем и потребности у конечного потребителя.
КРИТЕРИИ ЗАКАЗЧИКА ПО ПРИЕМКЕ
Попросите заказчика назвать 3-4 основные рабочие характеристики продукта.
!
Характеристики должны быть ИЗМЕРИМЫМИ: !
"Процесс выполнения заказов должен быть хорошо налажен".
"Заказ должен быть собран и упакован менее чем за 60 минут".
МАСШТАБ И ГРАНИЦЫ
Масштаб - это описание конечного продукта и гарантия, что вы произведете именно то, что необходимо заказчику. !
После определения масштаба вы должны уточнить, что входит в проект, а что нет, т.е. задать границы проекта.
КРИТЕРИИ КАЧЕСТВА
Создайте документ - “Лист качества”, в котором проработайте нефункциональные требования. !
Нефункциональные требования разделяют на: • Runtime - требования во время выполнения. • Designtime - требования к архитектуре.
RUNTIMEAvailability - требования ко времени непрерывной работы приложения, например, 24x7, минимальное время простоя и т.п. Reliability - поведение приложения при наступлении нештатных ситуаций, например, автоматический перезапуск, восстановление работы, дублирование важных данных, резервирование логики Durability - требования к долговременному хранению результатов работы приложения, например, использование базы данных, требования ко времени продолжительности хранения данных Scalability - требования к горизонтальному или вертикальному масштабированию приложения Usability - требования к удобству использования приложения с точки зрения использования, поддержки Security - требования к безопасности работы или использования приложения, связанные с разграничением доступа, работой с приватными данным, снижения подверженности рискам от внешних атак Configurability - требования к конфигурируемости работы приложения, взаимодействия и расположения компонентов Performance - требования к производительности решения, количество одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, скорости и пропускной способности каналов связи Restrictions - описание ограничений, накладываемых на объем доступной памяти, процессорного времени, дискового пространства, пропускную способность сети, при которых приложение должно эффективно выполнять возложенные на него задачи
DESIGNTIMEReusability - требования к повторному использованию реализации или компонентов приложения, а также реализация приложения с возможностью повторного его использования для различных задач Extensibility - требования к расширяемости приложения в связи с появлением новых функциональных требований Portability - требования к портируемости (переносимости) приложения на различные платформы Interoperability - требования к взаимодействию между компонентами решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия Supportability - требования к различным аспектам поддержки приложения, таким как дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе Modularity - требования к разделению приложения на модули Testability - требования к возможности автоматического и ручного тестирования приложения, наличие необходимого инструментария Localizability - требования к возможности и простоте локализации приложения, перечень языков, на которые предполагается локализация приложения Compatibility - особые требования к совместимости между версиями приложений, между различными приложениями и внешними подсистемами
ВЫВОДЫ
ТРИ СПОСОБА РАЗВИТИЯ НАВЫКОВ МЕНЕДЖМЕНТА
1. Обучение на своих ошибках :-) 2. Зачастую не менее эффективный способ - обучение на ошибках других. 3. Обучение на успешных решениях других.
ИТОГОВЫЙ ОТЧЕТ
1. Цели (цель проекта, критерий достижения, информация о выполнении критерия)
2. Результаты (результат, дата план, дата факт, причины отклонений)
3. Бюджет (название статьи, план, факт, причины отклонений) 4. Усвоенные уроки и опыт
•Какой положительный опыт вы бы хотели передать другим руководителям проектов? •Какие ошибки были допущены в проекте? •Привлекались ли к работе outsourcing (насколько эффективна работа с ними)? •Ваше предложение по системе управления проектами.
5. Чек-лист (параметр проверки, отметка, примечание) 6. Ответы на контрольные вопросы.
КОНТРОЛЬНЫЕ ВОПРОСЫ ДЛЯ ОЦЕНКИ ПРОЕКТА
1. Получили ли вы искренние ответы от вашего заказчика, членов команды и других участников проекта о произведенных продуктах и о работе над проектом в целом?
2. Полностью ли закончен итоговый отчет о результатах проекта? 3. Все ли члены команды дали свою оценку проекта? 4. Обсудили ли вы выводы, сделанные во время работы над проектом, и составили ли их окончательный список?
5. Пришла ли команда к единому мнению относительно рекомендаций по улучшению работы в будущем?
6. Поблагодарил ли лидер проекта членов команды за вклад в работу?
7. Отпраздновала ли команда свой успех?
ЧТО ЖЕ НУЖНО ДЛЯ УСПЕХА?
1.Общение между командой и клиентом 2.Тестирование на протяжении всего проекта 3.Четко определенные, ожидаемые клиентом результаты в самом начале проекта и критерии качества