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.
Представляете себе идеальный релиз фичи? Какой процесс необходимо построить? Как организовать жизненный цикл? Как принимать решения о переходе фичи из одного статуса в другой? Как снизить риски и как избежать "узких мест"? Какой должна быть система ценностей команды? Что вы можете изменить в своем проекте или продукте уже прямо сейчас?
Яким би досвідченим не був менеджер проекту чи продукту, яку б з топ-3, 5, 10 моделей керування пріоритетами він не використовував, бізнес (замовник, інвестор, ідеолог,..) каже “треба” - менеджер іде і робить, інженери кажуть “не можна” - менеджер сумує і не отримує. Технічний борг, відсутність problem/solution fit, втрачені можливості, вигорання - це основні наслідки нерозумного керування очікуваннями, цілями та вимогами. Я хочу поділитися власним досвідом виживання в аутсорсингу, стартапах та продуктових компаніях і власним мікро фреймворком керування цілями, пріоритетами, очікуваннями та прийняття рішень, за допомогою якого було створено декілька крутезних продуктів.
Останні 11 років я працюю з продуктами, які агрегують багато різних сервісів - банки, телекоми, е-ком і т.д. Хочу поділитися історіями моїх фейлів в комунікаціях та архітектурі взаємодії та потоків даних.
Хочу поделиться любимыми факапами, связанными с управлением требованиями. Веселые и грустные истории про оутсорсинг и продукты, заказчиков и бизнес-аналитиков, а также про требования и их жизненный цикл.
Модно говорить о необходимости развития Product Mindset для команды, причем не только продуктовой, но и аутсорсинговой. Что это такое этот mindset в весёлых картинках, простых терминах и аналогиях, как его очертить для команды и как развивать? Хочу на поделиться 10-летним опытом взращивания и трансформации продуктовых команд.
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.
Представляете себе идеальный релиз фичи? Какой процесс необходимо построить? Как организовать жизненный цикл? Как принимать решения о переходе фичи из одного статуса в другой? Как снизить риски и как избежать "узких мест"? Какой должна быть система ценностей команды? Что вы можете изменить в своем проекте или продукте уже прямо сейчас?
Яким би досвідченим не був менеджер проекту чи продукту, яку б з топ-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
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.
особенности построения процессов тестирования в продуктовой компании. agileba...Dmitriy Yefimenko
Очень кратко (20 минут) попытался рассказать о накопленном опыте организации процессов тестирования в продуктовой разработке софта. Постарался дать обоснование, почему были приняты именно такие решения.
Модно говорити про необхідність розвитку 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
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.
особенности построения процессов тестирования в продуктовой компании. agileba...Dmitriy Yefimenko
Очень кратко (20 минут) попытался рассказать о накопленном опыте организации процессов тестирования в продуктовой разработке софта. Постарался дать обоснование, почему были приняты именно такие решения.
7. 1. Система ценностей.
2. Auftragstaktik || SMEAC || Atraa ishit || ...
3. Готово и ценность.
4. Рост = бережливость.
5. Гибкость и работа над ошибками.
6. Приоритизация и вытягивание.
7. Лидерство и выход в поля.
Команда, 1 из 2
8. 8. Её не боятся.
9. Быть, а не казаться.
10.Не факты, а кейсы.
11. Правильные шахматы.
12. Не боится говорить Нет и Да.
13. Экономика потока «идея – продукт».
14. Сквозные методики.
Команда, 2 из 2
12. 15. Вместе, а не вместо.
16. Уровень компетенции +1.
17. Обоснованное бесстрашие.
18. Архитектура.
19. Претензионка будет всегда.
20.Мелочей не бывает.
21. Не жди.
Ценности, 3 из 3
14. 1. Все деградирует.
2. Несгибаемость.
3. Дисциплина vs. Мотивация.
4. Друг vs. Враг.
5. Многоконтурность процессов.
6. Прозрачная работа над ошибками.
7. Рабочие группы vs. Команды.
Деградация