В презентации представлен методологический подход и опыт автора по комбинированному использованию иерархических (водопад, набегающая волна) и гибких (Scrum, Agile) подходов для разработки, выпуска, сопровождения и развития программных продуктов и приложений для мобильных устройств.
В презентации представлен методологический подход и опыт автора по комбинированному использованию иерархических (водопад, набегающая волна) и гибких (Scrum, Agile) подходов для разработки, выпуска, сопровождения и развития программных продуктов и приложений для мобильных устройств.
Проектирование интерфейсов: Процесс+Команда=Продукт (2015)Yaroslav Perevalov
Конспект обзорной лекции на зимнем интенсиве по UI / UX в Британке (2015), описаны:
* Процесс-проектирования
* Роли в юзабилити-команде
* Организация взаимодействия ю-команды с командой проекта
* Виды требований к успешному продукту
Понятие юзабилити
● Работа с guidelines
● Особенности создания продукта/проекта
● Знакомство с юзабилити для e-commerce
● Знакомство с юзабилити для корпоративных сайтов
● Особенности юзабилити для форумов
● Особенности создания мобильных приложения
● Обзор языков программирования для IOS и Android
● Особенности разработки пользовательского интерфейса для
мобильных приложений
● Структура сборки приложения
● Обзор языков программирования:
● PHP
● .NET
● Python
● Ruby on Rails
● C#
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Опыт применения метода ATAM для оценки архитектурыCUSTIS
Выступление Игоря Беспальчука, нашего руководителя проектов дирекции архитектуры, на заседании русского отделения INCOSE (9 ноября 2016 года, Москва).
Видеозапись выступления:
https://vimeo.com/190918892
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаYana Brodetski
Определение стейкхолдеров
Кто такие стейкхолдеры (Stakeholders)
Способы идентификации стейкхолдеров
Анализ вовлеченности стейхолдеров
Способы коммуникации на проекте
Проект
Структура проекта
Управление проектом
Система ограничений
Организационная структура
Целеполагание
Успешный проект
Competency Model (HR API conference, Russian language) Irina Leshchuk
В докладе представлен опыт разработки, внедрения и использования модели компетенций для сотрудников компании. В нем говорится о том, как удалось подготовить решение, которое одновременно отвечает запросам со стороны бизнеса и используется для оценки и развития сотрудников в компании Grid Dynamics.
Кажется, что доклад будет интересен руководителям подразделений, менеджерам команд, HR специалистам и всем, кто интересуется вопросами оценки и развитием сотрудников внутри компании.
Целевой аудиторией, прежде всего, являются компании, в которых работает больше 100 инженеров и особенно актуально для тех, где есть распределенные команды в разных городах. Для компаний небольшого размера или стартапов содержание презентации будет интересно, скорее, с познавательной точки зрения, чем с практической.
Проектирование интерфейсов: Процесс+Команда=Продукт (2015)Yaroslav Perevalov
Конспект обзорной лекции на зимнем интенсиве по UI / UX в Британке (2015), описаны:
* Процесс-проектирования
* Роли в юзабилити-команде
* Организация взаимодействия ю-команды с командой проекта
* Виды требований к успешному продукту
Понятие юзабилити
● Работа с guidelines
● Особенности создания продукта/проекта
● Знакомство с юзабилити для e-commerce
● Знакомство с юзабилити для корпоративных сайтов
● Особенности юзабилити для форумов
● Особенности создания мобильных приложения
● Обзор языков программирования для IOS и Android
● Особенности разработки пользовательского интерфейса для
мобильных приложений
● Структура сборки приложения
● Обзор языков программирования:
● PHP
● .NET
● Python
● Ruby on Rails
● C#
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Опыт применения метода ATAM для оценки архитектурыCUSTIS
Выступление Игоря Беспальчука, нашего руководителя проектов дирекции архитектуры, на заседании русского отделения INCOSE (9 ноября 2016 года, Москва).
Видеозапись выступления:
https://vimeo.com/190918892
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаYana Brodetski
Определение стейкхолдеров
Кто такие стейкхолдеры (Stakeholders)
Способы идентификации стейкхолдеров
Анализ вовлеченности стейхолдеров
Способы коммуникации на проекте
Проект
Структура проекта
Управление проектом
Система ограничений
Организационная структура
Целеполагание
Успешный проект
Competency Model (HR API conference, Russian language) Irina Leshchuk
В докладе представлен опыт разработки, внедрения и использования модели компетенций для сотрудников компании. В нем говорится о том, как удалось подготовить решение, которое одновременно отвечает запросам со стороны бизнеса и используется для оценки и развития сотрудников в компании Grid Dynamics.
Кажется, что доклад будет интересен руководителям подразделений, менеджерам команд, HR специалистам и всем, кто интересуется вопросами оценки и развитием сотрудников внутри компании.
Целевой аудиторией, прежде всего, являются компании, в которых работает больше 100 инженеров и особенно актуально для тех, где есть распределенные команды в разных городах. Для компаний небольшого размера или стартапов содержание презентации будет интересно, скорее, с познавательной точки зрения, чем с практической.
- Кто есть кто? Или немного о ролях.
- Project менеджер VS Product Owner
- Характеристики PO
- Взаимодействие с командой, Scrum Master-ом, заказчиками
- Масштабирование роли PO
- Основные ошибки
Разработка тиражируемого продукта: преимущества бизнес-моделиGeorge Barkan
Мы рассмотрим процесс перехода от заказной разработки к продуктовой модели, преимущества и возникающие при этом сложности.
* Основной экономический фактор перехода – сокращение издержек за счет тиражируемого продукта. Изменение бизнес-модели, необходимость инвестиций, рыночные риски.
* Создание тиражируемого продукта на базе существующих разработок для корпоративных заказчиков – наиболее естественный путь. Часто сложный процесс внедрения сдерживает полный переход к продуктовой модели.
* Рыночное позиционирование продукта и управление требованиями. Две модели работы с рынком: pragmatic marketing и market development.
* Перестройка корпоративной культуры. Ответственность владельца продукта. Почему внутренний заказчик продукта – плохая схема. Коммуникации с каналом продаж, маркетингом и поддержкой. Политическая воля менеджера продукта.
* Необходимость автоматизации процессов разработки и поддержки.
* Введение элементов платформенной функциональности в продукте и развитие партнерской экосистемы – перспективные направления рыночной экспансии.
григорьев андрей, юмисофт, основные ошибки ведения It проектов - от документа...New Business Idea
Основные ошибки ведения IT-проектов - от документации до коммуникаций.
* Сбор и формирование требований к продукту;
* выработка стратегии;
* начальное проектирование;
* документирование процесса;
* построение схемы ролей и коммуникаций;
* дизайн проекта;
* программирование;
* примеры из жизни.
Презентация он-лайн программы обучения управления продуктамиDmitry Bezuglyy
Это базовый курс Онлайн программы обучения управлению продуктами.
Основная задача курса сформировать единую картину задач решаемых при создании продукта, основанную на комплексном понимании жизненного цикла продукта.
http://www.system-approach.ru/edu/on-line-pm/
SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...Yury Vetrov
Мастер-класс Юрия Ветрова "Контроль качества интерфейсных решений на всех этапах процесса проектирования и разработки" на пятой конференции SQA Days 2009.
Стандарт OMG Essence - в чем польза для аналитика?Yury Kupriyanov
"Режиссерская версия" слайдов к докладу "Стандарт OMG Essence - в чем польза для аналитика?" на ЛАФ'2013. Полностью приведены чеклисты для стадий альф: стейкхолдер, возможность и требования.
Слайды к лекции о поведении пользователей и usability для будущих мультимедийных журналистов, факультет медиажурналистики ВШЭ. Использованы некоторые слайды Алины Зотовой, http://ergogames.pbworks.com/
5. У нас отличный проект.
Все уже есть.
Нужно только ТЗ написать.
И архитектуру спроектировать.
И выбрать подрядчика.
И интерфейсы.
Дизайн нам сделают, но потом.
Только фирменного стиля еще нет.
А еще нужно обосновать
и защитить бюджет!
Нам нужен
Product Owner↓
6. 1. Расчет и планирование бюджета разработки, защита бюджета перед спонсорами, резервирование и
финансовое планирование;
2. Контроль платежей, отработка реализовавшихся фин.рисков;
3. Поиск и подбор персонала (всех людей, которые участвуют в проекте - от контент-менеджеров до
руководителя проекта, программистов, тестировщиков и т.д.), прием на работу;
4. Выбор субподрядчиков, контрактация, разрулирование вопросов по расчетам с подрядчиками
(субподрядчики: UX, дизайн, три команды разработки, переводчики, тех.писатели, и т.д.);
5. Коммуникация со стейкхолдерами: организация коммуникации, планирование, реагирование на запросы и т.д.
6. Высокоуровневое планирование (роадмэп), синхронизация с роадмэпами смежных систем, защита и отчеты по планам;
7. Операционное планирование (по спринтам), контроль и отчетность по планам;
8. Микропланирование (по отдельным тикетам), организация ежедневных стендапов;
9. Синхронизация работы нескольких команд субподрядчиков;
10. Внедрение методологии разработки;
11. Анализ и улучшение продуктивности команды разработки;
12. Выбор и внедрение инструментов проектной работы;
+ решение текущих операционных проблем (помочь найти информацию, придумать решение технической проблемы, свести нужных людей друг с другом);
13. Формирование отчетности для спонсоров проекта, защита отчетов;
14 приемка работ субподрядчиков;
15. Сдача работ заказчикам и спонсорам;
16. Организация службы поддержки пользователей, разработка методики работ службы, SLA;
17. Участие в разработке и согласование юридических и нормативных документов, регламентирующих работу системы;
18. Обеспечение требований нормативных документов, в т.ч. - По защите персональных данных;
19. Разработка функциональной архитектуры системы;
20. Разработка требований к отдельным частям системы и системе в целом;
21. Проектирование пользовательских интерфейсов или организация такого проектирования;
22. Разработка формальной проектной документации по ГОСТ 34, согласование;
23. Написание и редактирование текстов для интерфейса системы;
24. Организация работ по созданию пользовательской документации;
25. Прием и обработка запросов пользователей, стейкхолдеров, принятие решений по ним и постановка в план разработки;
26. Анализ статистики использования продукта, разработка требований по улучшению продукта;
27. Контроль выполнения формальных KPI продукта;
28. Организация сообществ пользователей продукта;
29. Представление продукта на публичных мероприятиях, организация и участие в конференциях и семинарах с пользователями;
30. Подготовка материалов для переговоров с потенциальными клиентами, рекламных материалов;
31. Приоритезация разрабатываемых функций продукта;
32. Планирование и выпуск релизов и обновлений продукта.
7. 1. Расчет и планирование бюджета разработки, защита бюджета перед спонсорами, резервирование и
финансовое планирование;
2. Контроль платежей, отработка реализовавшихся фин.рисков;
3. Поиск и подбор персонала (всех людей, которые участвуют в проекте - от контент-менеджеров до
руководителя проекта, программистов, тестировщиков и т.д.), прием на работу;
4. Выбор субподрядчиков, контрактация, разрулирование вопросов по расчетам с подрядчиками
(субподрядчики: UX, дизайн, три команды разработки, переводчики, тех.писатели, и т.д.);
5. Коммуникация со стейкхолдерами: организация коммуникации, планирование, реагирование на запросы и т.д.
6. Высокоуровневое планирование (роадмэп), синхронизация с роадмэпами смежных систем, защита и отчеты по планам;
7. Операционное планирование (по спринтам), контроль и отчетность по планам;
8. Микропланирование (по отдельным тикетам), организация ежедневных стендапов;
9. Синхронизация работы нескольких команд субподрядчиков;
10. Внедрение методологии разработки;
11. Анализ и улучшение продуктивности команды разработки;
12. Выбор и внедрение инструментов проектной работы;
+ решение текущих операционных проблем (помочь найти информацию, придумать решение технической проблемы, свести нужных людей друг с другом);
13. Формирование отчетности для спонсоров проекта, защита отчетов;
14. Приемка работ субподрядчиков;
15. Сдача работ заказчикам и спонсорам;
16. Организация службы поддержки пользователей, разработка методики работ службы, SLA;
17. Участие в разработке и согласование юридических и нормативных документов, регламентирующих работу системы;
18. Обеспечение требований нормативных документов, в т.ч. - по защите персональных данных;
19. Разработка функциональной архитектуры системы;
20. Разработка требований к отдельным частям системы и системе в целом;
21. Проектирование пользовательских интерфейсов или организация такого проектирования;
22. Разработка формальной проектной документации по ГОСТ 34, согласование;
23. Написание и редактирование текстов для интерфейса системы;
24. Организация работ по созданию пользовательской документации;
25. Прием и обработка запросов пользователей, принятие решений по ним и постановка в план разработки;
26. Анализ статистики использования продукта, разработка требований по улучшению продукта;
27. Контроль выполнения формальных KPI продукта;
28. Организация сообществ пользователей продукта;
29. Представление продукта на публичных мероприятиях, организация и участие в конференциях и семинарах с пользователями;
30. Подготовка материалов для переговоров с потенциальными клиентами, рекламных материалов;
31. Приоритезация разрабатываемых функций продукта;
32. Планирование и выпуск релизов и обновлений продукта.
10. Заказ и сопровождение исследований,
разработки, выпуска; сопровождение продаж
продукта
Определение продукта, управление дизайном и
требованиями к продукту
Создание и управление планом развития
продукта
Координация работы подразделений при
производстве, выпуске и продаже продукта
Разработка бизнес-планов, ценовой политики и
11.
12. Внезапно Scaled Agile 50+ человек
Открытое
образование
(команда
интеграции)
Команда edX
Команда
каталога
курсов
Команда
SSO
Команда UX
Команда
видео-
менеджера
Переводчики
Дизайнеры
Авторы
курсов
SCRUM
SCRUM
???
???
SCRUM,BUTT
???
??????
SCRUMBAN
Cross-functional team
Cross-functional team
Non cross-
functional team
14. Product Manager vs Product
Owner«Лицом к рынку/ потребителю».
Ближе к бизнесу/маркетингу.
Владеет: концепцией, дорожной
картой, бэклогом программы,
ценами, лицензиями, ROI и
другими показателями продукта.
Приоритезирует и принимает
фичи продукта.
«Лицом к команде и
решению». Ближе к команде.
Владеет бэклогом команды.
Определяет, приоритезирует
и принимает
пользовательские истории.
15. Что должен делать Product Manager
(SAFe)
Понимать потребности потребителей.
Понимать параметры портфеля проектов (бюджет и бизнес-
стратегию).
Разрабатывать концепцию (Vision) и дорожную карту.
Держать через бэклог программы. PM определяет DoD фич.
Планировать и определять состав релизов (всей программы).
Участвовать в демо и оценивать метрики продукта в
эксплуатации.
16. Что должен делать Product Owner (SAFe)
Уточнять истории, готовиться и участвовать в планировании
релизов
Исполнение итерации:
Уточнять бэклог команды
Планировать содержание итерации
Принимать истории
Участвовать в демо и ретро
17. LeSS: Large Scaled Scrum
← remove obstacles and improve
↑ same as in one-team Scrum
18. Head of product group:
remove obstacles and improve
Сбор команды, найм, контроль выплат
Помещения, оборудование, инструменты
Отчеты «наверх», «KPI»
Внедрение и улучшение методологии
разработки
19. Product owner team:
PO (один на все команды)
Area product owner (APO)
PO – связующее звено команд с
потребителями, а не их представитель
Определение фокуса продукта происходит
магическим образом (Systems Thinking)
20. Виды Product Owner (LeSS)
Продуктовая разработка
По инициативе бизнес-подразделения
PO – представитель бизнеса
По инициативе продуктового департамента (!!!)
PO – один из менеджеров продукта (ЧТО?!)
Внутренняя (продуктовая) разработка
PO – представитель бизнеса
Проектная разработка (аутсорсинг)
PO – представитель заказчика
21. Когда PO пора размножаться?
1 PO на 2 команды (max) – SAFe, LeSS
1 APO на 200 PBI (элементов во всех
бэклогах команд) на итерацию – LeSS
22. Как получилось у меня
Менеджер
продукта
«Мини-PO»
UX-lead
Системный
аналитик
Контент-
координатор
Дизайнеры
Авторы курсов
Команда
каталога курсов
Команда edX Команда SSO
Команда видео-
менеджера
Переводчики
Команда
интеграции
Команда UX
→ Уточнение элементов бэклога (всех команд)
Маркетинг и
SMM
23. Варианты роли
«Мини-CEO» (отвечает за ВСЁ! Границы нет!)
PM (SAFe) / МП (проф.стандарт) – отвечает за
успешность продукта – ЧТО и КОГДА должно
быть выпущено. Не отвечает за разработку.
Product Owner (LeSS, SCRUM и др.) – отвечает
за бэклог (поставка ценности в каждой итерации).
Руководитель портфеля проектов / программы, операционный директор,
руководитель разработки, директор по технологиям и т.п.
24. Стратегия для вариантов ролей
Мини-CEO: собрать команду и делегировать
Нужен отдельный PM или PO!
PM (SAFe), МП: держать видение, управлять планом
развития и координировать работы. Отказываться от
всего, что не про продукт.
PO (LeSS): управлять приоритетами в бэклоге и
value/ROI
Другие роли: не обманывать себя! См. «Мини CEO»
25. Запросы рынка (hh.ru, 53 вакансии)
Сбор и анализ требований, формирование
ТЗ
Проектирование, прототипирование, UX
Постановка задач разработке, планирование
и контроль планов
Разработка документации
Разработка и анализ метрик продукта
27. А есть ли у вас продукт?
Массовая аудитория
Есть альтернативы
Использование добровольно
Входной финансовый поток зависит от
успешности продукта
(показатель успешности определен и измерим)