Quality of the product team
I will share with you the quality management system, born in our team for a project being the company business core. Step by step we will follow the value system, processes, development practices, solutions for various complicated situations and learning on our own errors process – including all difficulties and backflashes on the way to the set aim.
So, what about you? Do you know the signs of the mature team and product, the same as the moves which will keep you afloat? Let’s verify!
Audience: any not indifferent teammates of any team.
Давайте пофантазуємо щодо ідеального релізу фічі? Який життєвий цикл, етапи, точки прийняття рішень? Як знизити ризики? Які корисні практики дозволяють усунути пляшкові горлечка? Якою повинна бути команда? Що можна застосувати у вашому проекті/продукті вже зараз?
На всі ці питання я спробую відповісти, ґрунтуючись на власному багаторічному досвіді швидкої розробки складних і великих проектів/продуктів.
Яким би досвідченим не був менеджер проекту чи продукту, яку б з топ-3, 5, 10 моделей керування пріоритетами він не використовував, бізнес (замовник, інвестор, ідеолог,..) каже “треба” - менеджер іде і робить, інженери кажуть “не можна” - менеджер сумує і не отримує. Технічний борг, відсутність problem/solution fit, втрачені можливості, вигорання - це основні наслідки нерозумного керування очікуваннями, цілями та вимогами. Я хочу поділитися власним досвідом виживання в аутсорсингу, стартапах та продуктових компаніях і власним мікро фреймворком керування цілями, пріоритетами, очікуваннями та прийняття рішень, за допомогою якого було створено декілька крутезних продуктів.
Останні 11 років я працюю з продуктами, які агрегують багато різних сервісів - банки, телекоми, е-ком і т.д. Хочу поділитися історіями моїх фейлів в комунікаціях та архітектурі взаємодії та потоків даних.
Quality of the product team
I will share with you the quality management system, born in our team for a project being the company business core. Step by step we will follow the value system, processes, development practices, solutions for various complicated situations and learning on our own errors process – including all difficulties and backflashes on the way to the set aim.
So, what about you? Do you know the signs of the mature team and product, the same as the moves which will keep you afloat? Let’s verify!
Audience: any not indifferent teammates of any team.
Давайте пофантазуємо щодо ідеального релізу фічі? Який життєвий цикл, етапи, точки прийняття рішень? Як знизити ризики? Які корисні практики дозволяють усунути пляшкові горлечка? Якою повинна бути команда? Що можна застосувати у вашому проекті/продукті вже зараз?
На всі ці питання я спробую відповісти, ґрунтуючись на власному багаторічному досвіді швидкої розробки складних і великих проектів/продуктів.
Яким би досвідченим не був менеджер проекту чи продукту, яку б з топ-3, 5, 10 моделей керування пріоритетами він не використовував, бізнес (замовник, інвестор, ідеолог,..) каже “треба” - менеджер іде і робить, інженери кажуть “не можна” - менеджер сумує і не отримує. Технічний борг, відсутність problem/solution fit, втрачені можливості, вигорання - це основні наслідки нерозумного керування очікуваннями, цілями та вимогами. Я хочу поділитися власним досвідом виживання в аутсорсингу, стартапах та продуктових компаніях і власним мікро фреймворком керування цілями, пріоритетами, очікуваннями та прийняття рішень, за допомогою якого було створено декілька крутезних продуктів.
Останні 11 років я працюю з продуктами, які агрегують багато різних сервісів - банки, телекоми, е-ком і т.д. Хочу поділитися історіями моїх фейлів в комунікаціях та архітектурі взаємодії та потоків даних.
Хочу поделиться любимыми факапами, связанными с управлением требованиями. Веселые и грустные истории про оутсорсинг и продукты, заказчиков и бизнес-аналитиков, а также про требования и их жизненный цикл.
Модно говорить о необходимости развития Product Mindset для команды, причем не только продуктовой, но и аутсорсинговой. Что это такое этот mindset в весёлых картинках, простых терминах и аналогиях, как его очертить для команды и как развивать? Хочу на поделиться 10-летним опытом взращивания и трансформации продуктовых команд.
Модно говорити про необхідність розвитку Product Mindset для команди, до того ж не тільки продуктової, але і аутсорсінгової. Що це таке ций mindset в веселих картинках, простих термінах і аналогіях, як його окреслити для команди і як розвивати? Хочу поділитися 10-річним досвідом плекання і трансформації продуктових команд.
Когда команда переходит к разработке продукта, лидер (или менеджер) сталкивается с типовыми проблемами. В течение многих лет построения и трансформации команд кажды лидер создает наборы или даже целые фреймворки практик, которые позволяют достичь успеха.
Я хочу поговорить про типовые проблемы трансформации команды и их решения: про product mindset и design thinking, про менталитет и наследние, эволюцию и революцию процессов, архитектуру и рефакторинг, тестирование и доставку, кодирование и поддержку, метрики и психологию.
When the team is shifting to product development style, leader (or manager) faces typical problems. And for many years of building and transforming teams, each leader compose sets or frameworks of practices that allow him to succeed. I want to talk about typical problems and practices of their solutions: about product mindset and design thinking, about mentality and legacy, about evolution or revolution of development processes, about architecture and refactoring, about testing and delivery, coding and support. With each of these areas the leader lives every day in “cheek to cheek” mode and solving transformation problems. Hope my experience will helpful for you.
Domain Driven Design (DDD) – зачем он нужен и с чего начать?Dmitriy Yefimenko
Про DDD и его достоинствах не слышал только ленивый, но на каждой пицце возникают вопросы – что это такое, зачем он нужен и как его начать применять в токсичных или не очень условиях устаревшего кода, архитектуры и устоявшихся процессов.
В чем заключается DDD, основные понятия и принципы, практики и примеры, истории внедрения и использования, где эта парадигма может помочь, а где навредить? Как начать, какие риски возникают, что можно взять полезного из DDD, если у вас нет возможности его использовать?
2017 03-28 управление требованиями на agile проектах-web academyDmitriy Yefimenko
-Что такое требования?
-Какие риски управления требованиями?
-Какие практики управления рисками предлагают различные подходы к разработке?
-Как требования тестировать и зачем?
-Как управлять требованиями?
-Как убедиться, что требование нужно реализовывать?
-Какие практики нужно применять, чтобы не потеряться в требованиях на этапе анализа и не потерять требования при разработке и внедрении?
Представляете себе идеальный релиз фичи? Какой процесс необходимо построить? Как организовать жизненный цикл? Как принимать решения о переходе фичи из одного статуса в другой? Как снизить риски и как избежать "узких мест"? Какой должна быть система ценностей команды? Что вы можете изменить в своем проекте или продукте уже прямо сейчас?
про практики проектирование жизненных циклов, процессы разработки, про продуктовое мышление и как сделать релиз безболезненным.
версия 2я, показана и рассказана на Lviv Project Management Day (http://lv.pmday.org/) 26 ноября 2016
приветствуются отзывы и критика :)
Let’s imagine a perfect release of feature(s)? What development process is needed? How organize life-cycle stages in terms of decision-making points? How to reduce risks and bottle necks impact? What about the team properties? What can you change in own project or product right now?
I will try to answer for all these questions. All answers based on my long-year development (sometimes rapid :) experience of complex fintech projects/products.
Адаптована для Lviv Project Management Day 2016 Spring
(http://pmday.com.ua/) доповідь про антіпаттерни.
Тема доповіді: “Produсtonomicon. Antipatterns”
Тези доповіді:
Вбийте ваш продукт з мінімальними зусиллями! Найкращі практики та рішення в керуванні, командотворенні, продажах, архітектурі та кодуванні!
Аудиторія: небайдужі розробники продуктів.
Смешные и грустные истории совершенных ошибок в процессах анализа, проектирования и оценки, разработки и тестирования, выкладки и мониторинга с выводами и решениями.
Ссылка на конфу: https://www.facebook.com/events/900458203396899/
Ссылка на исходник презентации: https://dl.dropboxusercontent.com/u/10586120/Rake-driven-development.pptx
Produсtonomicon. Antipatterns.
Kill your product with minimal efforts! Best practices and solutions are to be applied to your management, sales, team, architecture and code approaches ever.
Audience: any not indifferent developer of any product.
особенности построения процессов тестирования в продуктовой компании. agileba...Dmitriy Yefimenko
Очень кратко (20 минут) попытался рассказать о накопленном опыте организации процессов тестирования в продуктовой разработке софта. Постарался дать обоснование, почему были приняты именно такие решения.
Хочу поделиться любимыми факапами, связанными с управлением требованиями. Веселые и грустные истории про оутсорсинг и продукты, заказчиков и бизнес-аналитиков, а также про требования и их жизненный цикл.
Модно говорить о необходимости развития Product Mindset для команды, причем не только продуктовой, но и аутсорсинговой. Что это такое этот mindset в весёлых картинках, простых терминах и аналогиях, как его очертить для команды и как развивать? Хочу на поделиться 10-летним опытом взращивания и трансформации продуктовых команд.
Модно говорити про необхідність розвитку Product Mindset для команди, до того ж не тільки продуктової, але і аутсорсінгової. Що це таке ций mindset в веселих картинках, простих термінах і аналогіях, як його окреслити для команди і як розвивати? Хочу поділитися 10-річним досвідом плекання і трансформації продуктових команд.
Когда команда переходит к разработке продукта, лидер (или менеджер) сталкивается с типовыми проблемами. В течение многих лет построения и трансформации команд кажды лидер создает наборы или даже целые фреймворки практик, которые позволяют достичь успеха.
Я хочу поговорить про типовые проблемы трансформации команды и их решения: про product mindset и design thinking, про менталитет и наследние, эволюцию и революцию процессов, архитектуру и рефакторинг, тестирование и доставку, кодирование и поддержку, метрики и психологию.
When the team is shifting to product development style, leader (or manager) faces typical problems. And for many years of building and transforming teams, each leader compose sets or frameworks of practices that allow him to succeed. I want to talk about typical problems and practices of their solutions: about product mindset and design thinking, about mentality and legacy, about evolution or revolution of development processes, about architecture and refactoring, about testing and delivery, coding and support. With each of these areas the leader lives every day in “cheek to cheek” mode and solving transformation problems. Hope my experience will helpful for you.
Domain Driven Design (DDD) – зачем он нужен и с чего начать?Dmitriy Yefimenko
Про DDD и его достоинствах не слышал только ленивый, но на каждой пицце возникают вопросы – что это такое, зачем он нужен и как его начать применять в токсичных или не очень условиях устаревшего кода, архитектуры и устоявшихся процессов.
В чем заключается DDD, основные понятия и принципы, практики и примеры, истории внедрения и использования, где эта парадигма может помочь, а где навредить? Как начать, какие риски возникают, что можно взять полезного из DDD, если у вас нет возможности его использовать?
2017 03-28 управление требованиями на agile проектах-web academyDmitriy Yefimenko
-Что такое требования?
-Какие риски управления требованиями?
-Какие практики управления рисками предлагают различные подходы к разработке?
-Как требования тестировать и зачем?
-Как управлять требованиями?
-Как убедиться, что требование нужно реализовывать?
-Какие практики нужно применять, чтобы не потеряться в требованиях на этапе анализа и не потерять требования при разработке и внедрении?
Представляете себе идеальный релиз фичи? Какой процесс необходимо построить? Как организовать жизненный цикл? Как принимать решения о переходе фичи из одного статуса в другой? Как снизить риски и как избежать "узких мест"? Какой должна быть система ценностей команды? Что вы можете изменить в своем проекте или продукте уже прямо сейчас?
про практики проектирование жизненных циклов, процессы разработки, про продуктовое мышление и как сделать релиз безболезненным.
версия 2я, показана и рассказана на Lviv Project Management Day (http://lv.pmday.org/) 26 ноября 2016
приветствуются отзывы и критика :)
Let’s imagine a perfect release of feature(s)? What development process is needed? How organize life-cycle stages in terms of decision-making points? How to reduce risks and bottle necks impact? What about the team properties? What can you change in own project or product right now?
I will try to answer for all these questions. All answers based on my long-year development (sometimes rapid :) experience of complex fintech projects/products.
Адаптована для Lviv Project Management Day 2016 Spring
(http://pmday.com.ua/) доповідь про антіпаттерни.
Тема доповіді: “Produсtonomicon. Antipatterns”
Тези доповіді:
Вбийте ваш продукт з мінімальними зусиллями! Найкращі практики та рішення в керуванні, командотворенні, продажах, архітектурі та кодуванні!
Аудиторія: небайдужі розробники продуктів.
Смешные и грустные истории совершенных ошибок в процессах анализа, проектирования и оценки, разработки и тестирования, выкладки и мониторинга с выводами и решениями.
Ссылка на конфу: https://www.facebook.com/events/900458203396899/
Ссылка на исходник презентации: https://dl.dropboxusercontent.com/u/10586120/Rake-driven-development.pptx
Produсtonomicon. Antipatterns.
Kill your product with minimal efforts! Best practices and solutions are to be applied to your management, sales, team, architecture and code approaches ever.
Audience: any not indifferent developer of any product.
особенности построения процессов тестирования в продуктовой компании. agileba...Dmitriy Yefimenko
Очень кратко (20 минут) попытался рассказать о накопленном опыте организации процессов тестирования в продуктовой разработке софта. Постарался дать обоснование, почему были приняты именно такие решения.
особенности построения процессов тестирования в продуктовой компании. agileba...
Auftragstaktik старые новые принципы самоуправляемых команд
1. Auftragstaktik (Mission-type tactic)
Auftragstaktik
Старые новые принципы
самоуправляемых команд
AgileBaseCamp Crew Drill,
25..26.05.2012
@defimenko #agilebc
2. Знакомство
- Дмитрий Ефименко ака Damiano
- Мне 15 лет
- Харьков. Unitecsys
- Остервенелый продуктолог и синтезолог
- Интернет-эквайринг и самообслуживание
@defimenko #agilebc
4. Перевод
Auftragstaktik:
- «указания цели»
- «указания о намерениях командира»
- направляющее руководство
Befehlstaktik:
- следование приказу
@defimenko #agilebc
9. Проблематика
- Много информации
- Неактуальность
- Много контроля = много работы
- Нет поддержки
- Некорректная обработка исключений
- «Пока противник рисует карту…»
@defimenko #agilebc
14. Принципы
- Профессиональное отношение
- Наставничество
- Позитивный отбор вместо негативного
- Границы самоуправления есть, но его
степень зависит от качества синергии
тактики и стратегии
- Приказы ну очень специфические
@defimenko #agilebc
17. …они же…
- «Как» вместо «что» - только в крайнем
случае, для согласования разных
подразделений
- Инструмент vs. Владение
- Бездействие хуже ошибочного действия
- “Умный, ленивый, усердный и глупый”
@defimenko #agilebc
19. …и еще…
- Не следить, а направлять: Innere Führung
- Объединенность и слаженность
- Критерии оценки
- Смежные знания
- Лидерство не через действие
- Работа через бумагу
@defimenko #agilebc
20. …и они же…
- Ценз значения не имеет
- Единица планирования – цель. Все тот же
«Туман войны»
- Schwerpunkt (решающая точка)
- Массирование и неожиданность
- Нельзя быть слишком сильным в решающей
точке + Нежданчики Неожиданность
@defimenko #agilebc
21. …и вот ещё чуть-чуть
- Критерии достижения цели
- Готово
- Ограничения
- Децентрализация. Оперативный и
тактический уровень
- Неподчинение
- Перспектива, где перспектива?
@defimenko #agilebc
22. Mission-type tactic
- Вьетнам. Проблемы. Сперли Адаптировали
- USMC – несет свет демократии и всегда в
меньшинстве
- SMEAC = Situation + Mission + Execution +
Administration & Logistics + Command &
Signal
@defimenko #agilebc
23. …она же…
- When – Who – What – Where – Why
- Отличный язык сценариев тестирования
- Point of impact
- Jointness
@defimenko #agilebc
24. Но,
- Только тактики недостаточно
- Тактика + стратегия
- Экосистема. Культура
- Транслирование подходов
- Синтез под людей
- Дорого, но эффективно
@defimenko #agilebc
25. Сюрприииз
Ваши предположения Длинные списки
неверны дел никогда не
выполняются
Не будьте героем
Совещания токсичны
Достаточно хороший
это прекрасно Существует ли более
легкий способ?
Зачем вы это делаете?
Начните с эпицентра
Запускайтесь сейчас
Направьте всех на
передовую
Скорость меняет все
Не оставляйте
Обходите рок-звезд шрамов
… после первого пореза
…
@defimenko #agilebc
27. Чтиво
- Major General Werner Widder, Auftragstaktik
and Innere Führung. Mil. Review, 2002
- LtCol Anders Cedergren , Auftragstaktik – a
Philosophy of Command in the German Art of
War. JAWS, 2006
- Масааки Имаи
- Коносукэ Мацусита
@defimenko #agilebc
28. Чтиво
- Dirk W. Oetting, Auftragstaktik - Geschichte
und Gegenwart einer Führungskonzeption.
1993
- Dirk W. Oetting, Command Culture: Officer
Education in the U.S. Army and the German
Armed Forces, 1901-1940, and the
Consequences for World War II. 2011
@defimenko #agilebc
29. Чтиво
- Bruce Condell & David T. Zabecki, On the
German Art of War: Truppenführung: German
Army Manual for Unit Command in World War
II. 2008
- Мемуары и труды: Бальк, Миллентин, Зеект,
Мольтке, Клаузевиц, Гиллебрандт,
Фолькгейм, Лутс, Фуллер, Лиддел Гарт и др.
@defimenko #agilebc