Лекция посвящена последнему этапу работы над проектом, а именно его завершени. Часто случается так, что якобы выполненные проекты затягиваются на этапе сдачи. В этой лекции мы рассмотрим причины и возможные пути решения.
Ссылка на текстовую версию: http://growandmanage.com/zavershenie-proektov/
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Курс Управления Проектами.
Лекция 1- 2 .
Содержание:
Вступление
Что такое Project Management
Кто такие менеджеры проектов в IT?
Должностные обязанности менеджера проектов.
Разница между Product и Project Manager.
Перспективы развития: горизонтальная и вертикальная карьерная лестница.
Типы IT компаний.
Разница между аутсорс, аутстафф и продуктовой.
Понятие юзабилити
● Работа с guidelines
● Особенности создания продукта/проекта
● Знакомство с юзабилити для e-commerce
● Знакомство с юзабилити для корпоративных сайтов
● Особенности юзабилити для форумов
● Особенности создания мобильных приложения
● Обзор языков программирования для IOS и Android
● Особенности разработки пользовательского интерфейса для
мобильных приложений
● Структура сборки приложения
● Обзор языков программирования:
● PHP
● .NET
● Python
● Ruby on Rails
● C#
Жизненный цикл разработки ПО (SDLC)
Этапы жизненного цикла разработки
Этап планирования
Этап разработки
Этап поддержки
Роли в жизненном цикле разработки ПО
Артефакты в жизненном цикле разработки ПО
Терминология
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Курс Управления Проектами.
Лекция 1- 2 .
Содержание:
Вступление
Что такое Project Management
Кто такие менеджеры проектов в IT?
Должностные обязанности менеджера проектов.
Разница между Product и Project Manager.
Перспективы развития: горизонтальная и вертикальная карьерная лестница.
Типы IT компаний.
Разница между аутсорс, аутстафф и продуктовой.
Понятие юзабилити
● Работа с guidelines
● Особенности создания продукта/проекта
● Знакомство с юзабилити для e-commerce
● Знакомство с юзабилити для корпоративных сайтов
● Особенности юзабилити для форумов
● Особенности создания мобильных приложения
● Обзор языков программирования для IOS и Android
● Особенности разработки пользовательского интерфейса для
мобильных приложений
● Структура сборки приложения
● Обзор языков программирования:
● PHP
● .NET
● Python
● Ruby on Rails
● C#
Жизненный цикл разработки ПО (SDLC)
Этапы жизненного цикла разработки
Этап планирования
Этап разработки
Этап поддержки
Роли в жизненном цикле разработки ПО
Артефакты в жизненном цикле разработки ПО
Терминология
Управление внедрением проекта
Разработка устава проекта
● 1. Описание работ (SOW)
● 2. Определение бизнес-ценности проекта
● 3. Определение высокоуровневых потребностей бизнеса
● 4. Определение допущений и ограничений проекта
● 5. Определение границ проекта
● 6. Определение списка заинтересованных сторон.
Модуль 14. Лекция 55-56. Управление релизами и развертыванием продуктаYana Brodetski
Управление релизами и развертыванием
продукта (Release and Deployment)
● Планирование управлением поставками
продукта
● Определение артефактов
● Формирование плана конфигурации поставки
продукта
● Определение и формирование плана релиза
продукта
Модуль 2: Лекция 7-8. Обзор моделей, методологий и фреймворковYana Brodetski
Обзор моделей, методологий и фреймворков
● Введение
● Определение модели
● Определение методологии
● Определение фреймворка
● Каскадная модель (Waterfall)
● Модель прототипирования (Prototype)
● Итеративная модель ( Iterative)
● Спиральная модель (Spiral)
● V-образная модель (V-model)
● Agile методология (Agile Methodology)
Модуль 9. Лекция 41-42. Управление человеческими ресурсами проектаYana Brodetski
Управление человеческими ресурсами проекта
● Развитие команды проекта:
● Входы
● Инструменты и методы
● Навыки межличностного общения
● Обучение
● Выходы
● Управление командой проекта
● Входы
● Инструменты и методы
● Выходы
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
* Классификация нефункциональных требований
* Шаблоны нефункциональных требований
* Численные значения нефункциональных требований
* Связи между нефункциональными и функциональными требованиями
* Влияние различных категорий нефункциональных требований друг на друга
* Атрибуты качества продукта и нефункциональные требования
* Роли в проекте, с которыми взаимодействует аналитик при выявлении и уточнении нефункциональных требований
Модуль 10. Лекция 43-44. Управление коммуникация проектаYana Brodetski
Управление коммуникация проекта
● Планирование управления коммуникациями:
● Входы
● Инструменты и методы
● Коммуникационные технологии
● Коммуникационные модели
● Методы коммуникаций
● Выходы
● Управление коммуникациями
● Входы
● Инструменты и методы
● Выходы
● Контроль коммуникаций
● Входы
● Инструменты и методы
● Выходы
По статистике, три из четырех проектов заканчиваются неудачей. Из-за нечетких целей, плохого планирования, недоучета рисков и так далее и тому подобное.
И есть еще одна причина.
Плохое управление людьми. Проекты делают люди, поэтому, все управление проектами – это управление людьми. А вовсе не вырисовывание красивых картинок в MSProject. Об этом вы поговорите с Олегом Вайнбергом, экс CIO и тьютором факультета менеджмента Открытого Университета Великобритании.
Управление внедрением проекта
Разработка устава проекта
● 1. Описание работ (SOW)
● 2. Определение бизнес-ценности проекта
● 3. Определение высокоуровневых потребностей бизнеса
● 4. Определение допущений и ограничений проекта
● 5. Определение границ проекта
● 6. Определение списка заинтересованных сторон.
Модуль 14. Лекция 55-56. Управление релизами и развертыванием продуктаYana Brodetski
Управление релизами и развертыванием
продукта (Release and Deployment)
● Планирование управлением поставками
продукта
● Определение артефактов
● Формирование плана конфигурации поставки
продукта
● Определение и формирование плана релиза
продукта
Модуль 2: Лекция 7-8. Обзор моделей, методологий и фреймворковYana Brodetski
Обзор моделей, методологий и фреймворков
● Введение
● Определение модели
● Определение методологии
● Определение фреймворка
● Каскадная модель (Waterfall)
● Модель прототипирования (Prototype)
● Итеративная модель ( Iterative)
● Спиральная модель (Spiral)
● V-образная модель (V-model)
● Agile методология (Agile Methodology)
Модуль 9. Лекция 41-42. Управление человеческими ресурсами проектаYana Brodetski
Управление человеческими ресурсами проекта
● Развитие команды проекта:
● Входы
● Инструменты и методы
● Навыки межличностного общения
● Обучение
● Выходы
● Управление командой проекта
● Входы
● Инструменты и методы
● Выходы
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
* Классификация нефункциональных требований
* Шаблоны нефункциональных требований
* Численные значения нефункциональных требований
* Связи между нефункциональными и функциональными требованиями
* Влияние различных категорий нефункциональных требований друг на друга
* Атрибуты качества продукта и нефункциональные требования
* Роли в проекте, с которыми взаимодействует аналитик при выявлении и уточнении нефункциональных требований
Модуль 10. Лекция 43-44. Управление коммуникация проектаYana Brodetski
Управление коммуникация проекта
● Планирование управления коммуникациями:
● Входы
● Инструменты и методы
● Коммуникационные технологии
● Коммуникационные модели
● Методы коммуникаций
● Выходы
● Управление коммуникациями
● Входы
● Инструменты и методы
● Выходы
● Контроль коммуникаций
● Входы
● Инструменты и методы
● Выходы
По статистике, три из четырех проектов заканчиваются неудачей. Из-за нечетких целей, плохого планирования, недоучета рисков и так далее и тому подобное.
И есть еще одна причина.
Плохое управление людьми. Проекты делают люди, поэтому, все управление проектами – это управление людьми. А вовсе не вырисовывание красивых картинок в MSProject. Об этом вы поговорите с Олегом Вайнбергом, экс CIO и тьютором факультета менеджмента Открытого Университета Великобритании.
В наше время неразумно начинать проект разработки программного обеспечения без предварительного всестороннего анализа. Начальным этапом любого IT проекта должно стать исследование. Это процедура сбора информации, которая дает понимание отрасли, для которой разрабатывается продукт, бизнеса Вашего заказчика и целевой аудитории.
Аналитика требований в разрезе управления проектамиГузель Рахимова
В презентации показано о том, как влияет правильно проведенный анализ на успешность проекта, как проводить анализ и как это встраивается в процесс управления проектами.
Как остаться в заданных рамках и выйти победителем
• Управление требованиями;
• Сохранение бюджета;
• Соблюдение календарного плана;
Переход от опытной эксплуатации к промышленной.
Презентация с третьего доклада нашей летней сессии посвящен юзабилити. В ней рассказывается о том, зачем юзабилити нужно нам, нашим клиентам и клиентам наших клиентов. Презентация и видео в посте.
www.astramg.ru
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
3. ПРИЧИНЫ НЕУДАЧ И
ЗАТЯГИВАНИЯ ПРОЕКТОВ
• Низкая степень вовлечения заказчика или
пользователей в процесс разработки проекта
• Недостаточно определённые требования
• Недостаточная поддержка проекта топ
менеджментом
• Нереалистичные ожидания
• Недостаточно ясные цели
• Цель проекта перестала быть актуальной
4. ОСНОВНАЯ ПРИЧИНА
Проблема в коммуникации между менеджером
проекта и заказчиком и в том, насколько хорошо
совместно проработан этап “старта” проекта.
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 - особые требования к совместимости между версиями приложений, между
различными приложениями и внешними подсистемами
18. ТРИ СПОСОБА РАЗВИТИЯ
НАВЫКОВ МЕНЕДЖМЕНТА
1.
Обучение на своих ошибках :-)
2.
Зачастую не менее эффективный способ -
обучение на ошибках других.
3.
Обучение на успешных решениях других.
19. ИТОГОВЫЙ ОТЧЕТ
1. Цели (цель проекта, критерий достижения, информация о
выполнении критерия)
2. Результаты (результат, дата план, дата факт, причины
отклонений)
3. Бюджет (название статьи, план, факт, причины отклонений)
4. Усвоенные уроки и опыт
•Какой положительный опыт вы бы хотели передать другим руководителям проектов?
•Какие ошибки были допущены в проекте?
•Привлекались ли к работе outsourcing (насколько эффективна работа с ними)?
•Ваше предложение по системе управления проектами.
5. Чек-лист (параметр проверки, отметка, примечание)
6. Ответы на контрольные вопросы.
20. КОНТРОЛЬНЫЕ ВОПРОСЫ
ДЛЯ ОЦЕНКИ ПРОЕКТА
1.
Получили ли вы искренние ответы от вашего заказчика, членов
команды и других участников проекта о произведенных
продуктах и о работе над проектом в целом?
2.
Полностью ли закончен итоговый отчет о результатах проекта?
3.
Все ли члены команды дали свою оценку проекта?
4.
Обсудили ли вы выводы, сделанные во время работы над
проектом, и составили ли их окончательный список?
5.
Пришла ли команда к единому мнению относительно
рекомендаций по улучшению работы в будущем?
6.
Поблагодарил ли лидер проекта членов команды за вклад в
работу?
7.
Отпраздновала ли команда свой успех?
21. ЧТО ЖЕ НУЖНО ДЛЯ
УСПЕХА?
1.Общение между командой и клиентом
2.Тестирование на протяжении всего проекта
3.Четко определенные, ожидаемые клиентом
результаты в самом начале проекта и критерии
качества