ЗАВЕРШЕНИЕ ПРОЕКТОВСоветы по успешному завершению проектов

Тимофей Татаринов, 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.Четко определенные, ожидаемые клиентом результаты в самом начале проекта и критерии качества

СПАСИБО

Тимофей Татаринов, 2014http://tatarinov.cc