Александр Бындю, Андрей Шапиро, Пять самых важных составляющих процесса выпус...ScrumTrek
Для создания ПО мы выбрали эмпирический подход и почти отказались от детерминистского. Опыт показывает, что нельзя просто взять и описать большой продукт в ТЗ, а потом реализовать его по описанию. Жизнь оказывается всегда шире, чем наше представление о ней. С другой стороны, эмпирический подход отражает постоянное углубление нашего понимания предметной области, бизнеса заказчика и изменений на рынке по мере создания и совершенствования продукта. Нам посчастливилось создать успешные продукты, которые приносят прибыль заказчикам. Продукты мы создаем на заказ в качестве аутстаф-команды. Предметные области самые разные: медицина, наружная реклама, госзакупки, налоги, логистика. Мы рассказажем про процесс создания таких продуктов и покажем, из-за какой такой магии у нас получается привести заказчика к успеху. Не претендуем на знание о самом совершенном процессе, который решает все проблемы, но конкретно этот подход работает, поэтому и делимся. После описания процесса мы возьмем реальный пример проекта, который прошел по такому процессу.
Тактическое управление продуктами: все еще недостающее звеноMaxim Gaponov
«Эти люди делают то, о чем я их прошу. Но в результате каждый раз получается не то, что мне нужно». Эта фраза, в той или иной форме, произносится каждым клиентом, с которым я работаю.
«У нас было все, что нужно. Требования, выборки, прототипы. В итоге не успели сделать и половину. А то, что сделали нежизнеспособно» — такое тоже встречается часто.
На каждой стратегической сессии выясняется, что реальный объем работ, которые необходимо совершить, в 4-5 раз превышает тот, который запланирован. И, что самое интересное, этот объем озвучивают сами участники, которые и являются авторами предыдущих нереалистичных планов.
Слушайте, с этим пора что-то делать :) Это же не магия какая-нибудь. Это ремесло. Ремесло о том, как системно сформировать и договориться о границах работ; ремесло, как закрепить за ролями ответственность; ремесло, как выстроить управление и коммуникации между разными уровнями доставки бизнес-ценности; ремесло, как оценивать текущую зрелость процессов и обеспечивать непрерывное улучшение.
В докладе я расскажу вам о своем опыте решения этих задач в разных компаниях.
Александр Бындю, Андрей Шапиро, Пять самых важных составляющих процесса выпус...ScrumTrek
Для создания ПО мы выбрали эмпирический подход и почти отказались от детерминистского. Опыт показывает, что нельзя просто взять и описать большой продукт в ТЗ, а потом реализовать его по описанию. Жизнь оказывается всегда шире, чем наше представление о ней. С другой стороны, эмпирический подход отражает постоянное углубление нашего понимания предметной области, бизнеса заказчика и изменений на рынке по мере создания и совершенствования продукта. Нам посчастливилось создать успешные продукты, которые приносят прибыль заказчикам. Продукты мы создаем на заказ в качестве аутстаф-команды. Предметные области самые разные: медицина, наружная реклама, госзакупки, налоги, логистика. Мы рассказажем про процесс создания таких продуктов и покажем, из-за какой такой магии у нас получается привести заказчика к успеху. Не претендуем на знание о самом совершенном процессе, который решает все проблемы, но конкретно этот подход работает, поэтому и делимся. После описания процесса мы возьмем реальный пример проекта, который прошел по такому процессу.
Тактическое управление продуктами: все еще недостающее звеноMaxim Gaponov
«Эти люди делают то, о чем я их прошу. Но в результате каждый раз получается не то, что мне нужно». Эта фраза, в той или иной форме, произносится каждым клиентом, с которым я работаю.
«У нас было все, что нужно. Требования, выборки, прототипы. В итоге не успели сделать и половину. А то, что сделали нежизнеспособно» — такое тоже встречается часто.
На каждой стратегической сессии выясняется, что реальный объем работ, которые необходимо совершить, в 4-5 раз превышает тот, который запланирован. И, что самое интересное, этот объем озвучивают сами участники, которые и являются авторами предыдущих нереалистичных планов.
Слушайте, с этим пора что-то делать :) Это же не магия какая-нибудь. Это ремесло. Ремесло о том, как системно сформировать и договориться о границах работ; ремесло, как закрепить за ролями ответственность; ремесло, как выстроить управление и коммуникации между разными уровнями доставки бизнес-ценности; ремесло, как оценивать текущую зрелость процессов и обеспечивать непрерывное улучшение.
В докладе я расскажу вам о своем опыте решения этих задач в разных компаниях.
Возможные причины неудачи внедрения проектного управления. Доклад Олега Вайнберга с конференции "Внедрение проектного управления. Успешный проектный офис 2016"
#pmoconf
Post Agile эра / Борис Вольфсон (HeadHunter)Ontico
Многие компании успешно используют Agile-методологии на протяжении многих лет. На данный момент некоторые из них переосмысливают понимание Agile, распространяя его за пределы конкретных методологий.
Я расскажу о том, как сделать компанию / подразделение по-настоящему гибкими, выстроив собственный Agile-фреймворк. Для создания такого фреймворка нужно понимать, из чего он состоит: от методологии управления проектами до организационной культуры.
Если вы уже успешно используете Scrum или Kanban и задумываетесь о том, что вам необходимо делать дальше - добро пожаловать на мой доклад!
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
Доклад предназначен для Design Team Leads, которые заинтересованы в развитии своих дизайнеров, настройке процесса обучения; и дизайнеров, которые хотят развиваться и расти в профессиональном плане.
Наш департамент вырос с 20 до 55 дизайнеров в короткие сроки. Стала актуальной задача по определению уровня конкретного дизайнера: чем отличается Middle от Senior, как выровнять эти уровни между СНГ, Британией и США. Как обучить такое количество дизайнеров, выстроить Personal Development Plan.
В докладе мы хотим рассказать, какие инструменты и методы мы разработали для этого, какие результаты это принесло.
Прикручивание колёс на ходу. Внедрение UX процессов в уже работающий продуктПрофсоUX
Доклад рассчитан на всех, кому интересна командная работа и дизайн-системы.
У себя в компании мы внедряем дизайн-систему «по-живому» — без отрыва от производства продукта. На конференции я расскажу, зачем мы на это пошли, как доказывали пользу изменений, что уже успели сделать и к чему планируем прийти.
Андрій Уманський: Роль розробника в продуктовій компанії. Product engineer – ...Lviv Startup Club
Kyiv Project Management Day 2016 Андрій Уманський: Роль розробника в продуктовій компанії. Product engineer – швидше, краще, дешевше
Сайт конференції: http://pmday.org/
Спільнота в мережі Linkedin: http://bit.ly/PMDayLin
Спільнота в мережі facebook: http://bit.ly/PMDayKyivFB
Twitter конференції: https://twitter.com/LvivPMDay
Практическое руководство для менеджеров компаний
Если вы решили развалить бизнес, то не стоит затягивать, сделайте это за месяцы, а не за годы. Чем раньше вы справитесь на текущем месте работы, тем быстрее перейдете на новое!
Внедрение It технологий для повышения управляемости компанийE-promo
Управляемость компании =
• Управление задачами/проектами;
• Управление продажами;
• Управление бизнес-процессами;
• CRM;
• Анализ эконом. эффективности
направлений бизнеса;
• Управление финансовыми
потоками;
• Анализ производительности
сотрудников.
Возможные причины неудачи внедрения проектного управления. Доклад Олега Вайнберга с конференции "Внедрение проектного управления. Успешный проектный офис 2016"
#pmoconf
Post Agile эра / Борис Вольфсон (HeadHunter)Ontico
Многие компании успешно используют Agile-методологии на протяжении многих лет. На данный момент некоторые из них переосмысливают понимание Agile, распространяя его за пределы конкретных методологий.
Я расскажу о том, как сделать компанию / подразделение по-настоящему гибкими, выстроив собственный Agile-фреймворк. Для создания такого фреймворка нужно понимать, из чего он состоит: от методологии управления проектами до организационной культуры.
Если вы уже успешно используете Scrum или Kanban и задумываетесь о том, что вам необходимо делать дальше - добро пожаловать на мой доклад!
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
Доклад предназначен для Design Team Leads, которые заинтересованы в развитии своих дизайнеров, настройке процесса обучения; и дизайнеров, которые хотят развиваться и расти в профессиональном плане.
Наш департамент вырос с 20 до 55 дизайнеров в короткие сроки. Стала актуальной задача по определению уровня конкретного дизайнера: чем отличается Middle от Senior, как выровнять эти уровни между СНГ, Британией и США. Как обучить такое количество дизайнеров, выстроить Personal Development Plan.
В докладе мы хотим рассказать, какие инструменты и методы мы разработали для этого, какие результаты это принесло.
Прикручивание колёс на ходу. Внедрение UX процессов в уже работающий продуктПрофсоUX
Доклад рассчитан на всех, кому интересна командная работа и дизайн-системы.
У себя в компании мы внедряем дизайн-систему «по-живому» — без отрыва от производства продукта. На конференции я расскажу, зачем мы на это пошли, как доказывали пользу изменений, что уже успели сделать и к чему планируем прийти.
Андрій Уманський: Роль розробника в продуктовій компанії. Product engineer – ...Lviv Startup Club
Kyiv Project Management Day 2016 Андрій Уманський: Роль розробника в продуктовій компанії. Product engineer – швидше, краще, дешевше
Сайт конференції: http://pmday.org/
Спільнота в мережі Linkedin: http://bit.ly/PMDayLin
Спільнота в мережі facebook: http://bit.ly/PMDayKyivFB
Twitter конференції: https://twitter.com/LvivPMDay
Практическое руководство для менеджеров компаний
Если вы решили развалить бизнес, то не стоит затягивать, сделайте это за месяцы, а не за годы. Чем раньше вы справитесь на текущем месте работы, тем быстрее перейдете на новое!
Внедрение It технологий для повышения управляемости компанийE-promo
Управляемость компании =
• Управление задачами/проектами;
• Управление продажами;
• Управление бизнес-процессами;
• CRM;
• Анализ эконом. эффективности
направлений бизнеса;
• Управление финансовыми
потоками;
• Анализ производительности
сотрудников.
Компания "Власта", или кто мы такие
Структура типографии
Наш путь к нормальной программе
Список документов для отдела логистики
Матрица грузчиков в Еxcel
Матрица расчета зарплаты водителей с формулами
Наша программа электронного расчета заказов ЛИМ
Это управление запасами через "Парус"
А это программа работы с клиентской базой "SaleExpert"
Сначала расчет МВО начинался красиво с помощью таблиц, разработанных мною же
Потом он был таким
Потом он преобразовался в упрощенную форму. Это таблица МВО на уборщиц
Почему систему управления мотивацией нельзя выстроить «на пальцах»?
Как начинался новый этап
Сложности первого этапа внедрения
Матрица системного администратора
Матрица менеджера по продажам типографских продуктов
Матрица продавца магазина
Люди любят деньги. Однако, большие деньги их портят. Не стоит полагаться на то, что изобретенная бонусная система сможет повысить продуктивность. Сотрудники всегда способны придумать 400 сравнительно честных способов максимизации бонуса. Прозрачность и понятность процесса сильно страдают.
Тем не менее в большинстве крупных компаний выстроены системы KPI для повышения финансовой заинтересованности в результате. Многим руководителям трудно представить, как можно управлять без этого инструмента. Безусловно, есть определенная доля правды. Это действительно удобный инструмент.
Приходите на доклад, мы разберемся, есть ли рациональное зерно в KPI и какими они должны быть в agile организации.
When you pool 50+ acting delivery managers in organization, you can find a lot of surprises HOW they understand Delivery Management role. This is definitely surprising you. How to treat results, what PAEI management model says and how to deal with this variety.
4 года работы по KPI-Мотивации: опыт компании “МФ Поиск”KPI - Drive
Структура компании
Этапы внедрения KPI-Drive
Предпосылка и цели внедрения
Исходные позиции при внедрении
Первые решения
Сложности внедрения
Примеры KPI-матриц сотрудников
Библиотека SMART-задач
Similar to Impact mapping: от пользовательских историй к роадмапу (20)
2. TL; DR
• Пользовательские истории (user story map)
пытается показать полную картинку реализации
сценария
• Эта картинка не показывает, как разные истории
влияют на бизнес-цели
• Чтобы сопоставить пользовательские истории
бизнес-целям и предлагается подход impact
mapping
3. План
• Напоминание про пользовательские истории
• Обзор Impact Mapping
• Детали по шагам процесса
• Применение:
• Роадмап
• Конвертации в пользовательские истории
• Итерации по роадмапу
7. Проблемы
пользовательских историй
• На карте нет стратегических целей.
• Задача выравнивания фич со стратегической
целью лежит полностью на бизнесе.
• Приоритизация делается (в основном) по
сложности реализации.
• На карте должны быть все шаги, начинает
проступать реализация.
10. Метод Impact Mapping
• Очень похоже на user story mapping
• Ключевая идея: сопоставление фич со
стратегической целью
• Основана на рисовании mind map-а
11. Структура карты
• Бизнес и технический персонал отвечает
последовательно на четыре вопроса:
• Зачем? Цель нашей работы
• Кто? Субъект, кто может помочь достижению цели
• Как? Влияние или действие, которое должен
делать субъект для достижения цели
• Что? Фичи, которые помогут субъекту лучше
делать действие
13. Зачем?
• Стратегическая цель нашей работы (на какое-то ближайшее время)
• Не “создать систему” а то, для чего эта система создается
• Цель должна быть S.M.A.R.T.:
• Specific - конкретной
• Measurable - измеримой
• Action-oriented - ориентированной на действие
• Realistic - реалистичной
• Timely - своевременной
14. Кто?
• Субъекты, которые участвуют в достижении цели
• Выделяют три типа:
• Первичные: чьи цели достигаются
• Вторичные: те что предоставляют услуги
• Внешние: не попавшие в первые два, например
те кто накладывают ограничения
15. Как?
• Влияние или действие, которое совершает субъект
• Не надо перечислять все действия, только те что
относятся к цели
• Лучше описывать как изменится действие по
сравнению с текущим
• Нужно учитывать как позитивные, так и негативные
(мешающие достижению цели) действия
16. Что?
• Это непосредственно фичи или организационные
задачи
• Самая незначительная часть карты
• Не надо деталей, высокоуровневые истории
20. Шаг 1: Подготовка
• Нужно определить реальные цели
• Выявить/придумать хорошие метрики
• Спланировать первую веху
21. Цели
• Результат общения бизнес людей с техническим
персоналом
• Если бизнес называет целью конкретные фичи,
то надо пойти выше и понять, зачем они нужны
22. Метрики
• Цель является только одной из метрик
• На этом этапе надо выделять метрики, которые конкретизируют цель
• Для каждой метрики нужно ответить на такие вопрос:
• Что мы меряем
• Как мы меряем
• Текущая ситуация
• Минимальный уровень, который мы хотим достичь
• Целевое значение
24. Планируем первую веху
• Итеративное развитие нужно и в части бизнес
целей
• Достижение целевых метрик разбивается на
несколько этапов
• После достижения первой вехи мы возвращаемся
к метрикам и планируем следующую
30. Метод проб и ошибок
• На сцену выходит метод пользовательских
историй
• Внутри одного “действия” истории
приоритизируются от простого к сложному
• Цель - валидировать что “действие” помогает
достижению цели
33. Роадмап
• С каждым бизнес-владельцем и его
сотрудниками мы рисуем роадмап на полгода:
• Подготовка: цель, метрики, первая веха
• Рисуем карту и выставляем приоритеты
34. Переход к
пользовательским историям
• Самые приоритетные фичи выделяются в
пользовательские истории
• При этом, по каждой системе нужно
поддерживать user story map
36. Итерация по роадмапу
• Каждый месяц мы собираемся с бизнесом и
смотрим на роадмап:
• Что изменилось в приоритетах
• Как мы продвигаемся по метрикам
• Через полгода мы делаем новый роадмап