Лекция посвящена последнему этапу работы над проектом, а именно его завершени. Часто случается так, что якобы выполненные проекты затягиваются на этапе сдачи. В этой лекции мы рассмотрим причины и возможные пути решения. Ссылка на текстовую версию: http://growandmanage.com/zavershenie-proektov/

1. ЗАВЕРШЕНИЕ ПРОЕКТОВ
Советы по успешному завершению проектов
Тимофей Татаринов, 2014
http://tatarinov.cc

2. ПРОБЛЕМА

3. ПРИЧИНЫ НЕУДАЧ И
ЗАТЯГИВАНИЯ ПРОЕКТОВ
• Низкая степень вовлечения заказчика или
пользователей в процесс разработки проекта
• Недостаточно определённые требования
• Недостаточная поддержка проекта топ
менеджментом
• Нереалистичные ожидания
• Недостаточно ясные цели
• Цель проекта перестала быть актуальной

4. ОСНОВНАЯ ПРИЧИНА
Проблема в коммуникации между менеджером
проекта и заказчиком и в том, насколько хорошо
совместно проработан этап “старта” проекта.

5. РЕШЕНИЕ

6. ЧТО ЖЕ НУЖНО ДЛЯ
УСПЕХА?
1.Общение между командой и клиентом
2.Тестирование на протяжении всего проекта
3.Четко определенные, ожидаемые клиентом
результаты в самом начале проекта и критерии
качества

7. ОБЩЕНИЕ МЕЖДУ
КОМАНДОЙ И КЛИЕНТОМ
•Определите и зафиксируйте основные принципы и
средства коммуникации.
•Фиксируйте результаты встреч, звонков и любого
личного общения и отправляйте всем участникам
по email.
•Узнайте и зафиксируйте, кто будет принимать
проект на стороне заказчика.
•Регулярно общайтесь с заказчиком, делайте апдейт
по статусу, узнавайте его мнение - все что
угодно. Главное оставайтесь “на связи”!

8. ТЕСТИРОВАНИЕ НА
ПРОТЯЖЕНИИ ВСЕГО ПРОЕКТА
Выпустите первую сборку проекта как можно
раньше, а потом как можно чаще обновляйте
ее. В этом случае вы:
• обкатаете процесс сборки и интеграции
различных компонентов системы;
• вы сможете подключить тестировщиков,
которые будут следить за качеством продукта;
• это позволит вам держать в курсе заказчика и
показывать ему прогресс по ходу работы.

9. ЧЕТКО ОПРЕДЕЛЕННЫЕ
РЕЗУЛЬТАТЫ РАБОТЫ
ПЕРЕД СТАРТОМ проекта нужно разработать
вместе с заказчиком документ, в котором
будут описаны его ожидания к результатам и
качеству проекта.

10. ДОКУМЕНТ ОЖИДАНИЙ
ЗАКАЗЧИКА
1. Определение потребности заказчика и
потребителя.
2. Критерии заказчика по приему продукта.
3. Требования заказчика.
4. Масштаб и границы проекта.
5. Критерии качества

11. ПОТРЕБНОСТИ ЗАКАЗЧИКА
И ПОТРЕБИТЕЛЯ
Вопросы, которы помогут выявить проблему:
!
1.
Как эта проблема влияет на бизнес?
2.
Из-за чего, по вашему мнению, она возникла?
3.
Исчезнет ли эта проблема, если мы реализуем
предложенное вами решение?
!
!
Если заказчик не является конечным потребителем
продукта, обязательно нужно определить этого
потребителя и повторить процесс выявления проблем и
потребности у конечного потребителя.

12. КРИТЕРИИ ЗАКАЗЧИКА ПО
ПРИЕМКЕ
Попросите заказчика назвать 3-4 основные
рабочие характеристики продукта.
!
Характеристики должны быть ИЗМЕРИМЫМИ:
!
"Процесс выполнения заказов должен быть
хорошо налажен".
"Заказ должен быть собран и упакован менее чем
за 60 минут".

13. МАСШТАБ И ГРАНИЦЫ
Масштаб - это описание конечного продукта и
гарантия, что вы произведете именно то, что
необходимо заказчику.
!
После определения масштаба вы должны
уточнить, что входит в проект, а что нет, т.е.
задать границы проекта.

14. КРИТЕРИИ КАЧЕСТВА
Создайте документ - “Лист качества”, в котором
проработайте нефункциональные требования.
!
Нефункциональные требования разделяют на:
• Runtime - требования во время выполнения.
• Designtime - требования к архитектуре.

15. RUNTIME
Availability - требования ко времени непрерывной работы приложения, например, 24x7, минимальное
время простоя и т.п.
Reliability - поведение приложения при наступлении нештатных ситуаций, например, автоматический
перезапуск, восстановление работы, дублирование важных данных, резервирование логики
Durability - требования к долговременному хранению результатов работы приложения, например,
использование базы данных, требования ко времени продолжительности хранения данных
Scalability - требования к горизонтальному или вертикальному масштабированию приложения
Usability - требования к удобству использования приложения с точки зрения использования,
поддержки
Security - требования к безопасности работы или использования приложения, связанные с
разграничением доступа, работой с приватными данным, снижения подверженности рискам от
внешних атак
Configurability - требования к конфигурируемости работы приложения, взаимодействия и
расположения компонентов
Performance - требования к производительности решения, количество одновременно работающих
пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений,
скорости и пропускной способности каналов связи
Restrictions - описание ограничений, накладываемых на объем доступной памяти, процессорного
времени, дискового пространства, пропускную способность сети, при которых приложение должно
эффективно выполнять возложенные на него задачи

16. DESIGNTIME
Reusability - требования к повторному использованию реализации или компонентов
приложения, а также реализация приложения с возможностью повторного его использования
для различных задач
Extensibility - требования к расширяемости приложения в связи с появлением новых
функциональных требований
Portability - требования к портируемости (переносимости) приложения на различные
платформы
Interoperability - требования к взаимодействию между компонентами решения, между
внешними компонентами, использование стандартных протоколов и технологий
взаимодействия
Supportability - требования к различным аспектам поддержки приложения, таким как
дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа
ошибок и проблем в работе
Modularity - требования к разделению приложения на модули
Testability - требования к возможности автоматического и ручного тестирования приложения,
наличие необходимого инструментария
Localizability - требования к возможности и простоте локализации приложения, перечень
языков, на которые предполагается локализация приложения
Compatibility - особые требования к совместимости между версиями приложений, между
различными приложениями и внешними подсистемами

17. ВЫВОДЫ

18. ТРИ СПОСОБА РАЗВИТИЯ
НАВЫКОВ МЕНЕДЖМЕНТА
1.
Обучение на своих ошибках :-)
2.
Зачастую не менее эффективный способ -
обучение на ошибках других.
3.
Обучение на успешных решениях других.

19. ИТОГОВЫЙ ОТЧЕТ
1. Цели (цель проекта, критерий достижения, информация о
выполнении критерия)
2. Результаты (результат, дата план, дата факт, причины
отклонений)
3. Бюджет (название статьи, план, факт, причины отклонений)
4. Усвоенные уроки и опыт
•Какой положительный опыт вы бы хотели передать другим руководителям проектов?
•Какие ошибки были допущены в проекте?
•Привлекались ли к работе outsourcing (насколько эффективна работа с ними)?
•Ваше предложение по системе управления проектами.
5. Чек-лист (параметр проверки, отметка, примечание)
6. Ответы на контрольные вопросы.

20. КОНТРОЛЬНЫЕ ВОПРОСЫ
ДЛЯ ОЦЕНКИ ПРОЕКТА
1.
Получили ли вы искренние ответы от вашего заказчика, членов
команды и других участников проекта о произведенных
продуктах и о работе над проектом в целом?
2.
Полностью ли закончен итоговый отчет о результатах проекта?
3.
Все ли члены команды дали свою оценку проекта?
4.
Обсудили ли вы выводы, сделанные во время работы над
проектом, и составили ли их окончательный список?
5.
Пришла ли команда к единому мнению относительно
рекомендаций по улучшению работы в будущем?
6.
Поблагодарил ли лидер проекта членов команды за вклад в
работу?
7.
Отпраздновала ли команда свой успех?

21. ЧТО ЖЕ НУЖНО ДЛЯ
УСПЕХА?
1.Общение между командой и клиентом
2.Тестирование на протяжении всего проекта
3.Четко определенные, ожидаемые клиентом
результаты в самом начале проекта и критерии
качества

22. СПАСИБО
Тимофей Татаринов, 2014
http://tatarinov.cc