Адаптована для Lviv Project Management Day 2016 Spring
(http://pmday.com.ua/) доповідь про антіпаттерни.
Тема доповіді: “Produсtonomicon. Antipatterns”
Тези доповіді:
Вбийте ваш продукт з мінімальними зусиллями! Найкращі практики та рішення в керуванні, командотворенні, продажах, архітектурі та кодуванні!
Аудиторія: небайдужі розробники продуктів.
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.
Смешные и грустные истории совершенных ошибок в процессах анализа, проектирования и оценки, разработки и тестирования, выкладки и мониторинга с выводами и решениями.
Ссылка на конфу: https://www.facebook.com/events/900458203396899/
Ссылка на исходник презентации: https://dl.dropboxusercontent.com/u/10586120/Rake-driven-development.pptx
2017 03-28 управление требованиями на agile проектах-web academyDmitriy Yefimenko
-Что такое требования?
-Какие риски управления требованиями?
-Какие практики управления рисками предлагают различные подходы к разработке?
-Как требования тестировать и зачем?
-Как управлять требованиями?
-Как убедиться, что требование нужно реализовывать?
-Какие практики нужно применять, чтобы не потеряться в требованиях на этапе анализа и не потерять требования при разработке и внедрении?
Яким би досвідченим не був менеджер проекту чи продукту, яку б з топ-3, 5, 10 моделей керування пріоритетами він не використовував, бізнес (замовник, інвестор, ідеолог,..) каже “треба” - менеджер іде і робить, інженери кажуть “не можна” - менеджер сумує і не отримує. Технічний борг, відсутність problem/solution fit, втрачені можливості, вигорання - це основні наслідки нерозумного керування очікуваннями, цілями та вимогами. Я хочу поділитися власним досвідом виживання в аутсорсингу, стартапах та продуктових компаніях і власним мікро фреймворком керування цілями, пріоритетами, очікуваннями та прийняття рішень, за допомогою якого було створено декілька крутезних продуктів.
Останні 11 років я працюю з продуктами, які агрегують багато різних сервісів - банки, телекоми, е-ком і т.д. Хочу поділитися історіями моїх фейлів в комунікаціях та архітектурі взаємодії та потоків даних.
Хочу поделиться любимыми факапами, связанными с управлением требованиями. Веселые и грустные истории про оутсорсинг и продукты, заказчиков и бизнес-аналитиков, а также про требования и их жизненный цикл.
Модно говорить о необходимости развития Product Mindset для команды, причем не только продуктовой, но и аутсорсинговой. Что это такое этот mindset в весёлых картинках, простых терминах и аналогиях, как его очертить для команды и как развивать? Хочу на поделиться 10-летним опытом взращивания и трансформации продуктовых команд.
Адаптована для Lviv Project Management Day 2016 Spring
(http://pmday.com.ua/) доповідь про антіпаттерни.
Тема доповіді: “Produсtonomicon. Antipatterns”
Тези доповіді:
Вбийте ваш продукт з мінімальними зусиллями! Найкращі практики та рішення в керуванні, командотворенні, продажах, архітектурі та кодуванні!
Аудиторія: небайдужі розробники продуктів.
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.
Смешные и грустные истории совершенных ошибок в процессах анализа, проектирования и оценки, разработки и тестирования, выкладки и мониторинга с выводами и решениями.
Ссылка на конфу: https://www.facebook.com/events/900458203396899/
Ссылка на исходник презентации: https://dl.dropboxusercontent.com/u/10586120/Rake-driven-development.pptx
2017 03-28 управление требованиями на agile проектах-web academyDmitriy Yefimenko
-Что такое требования?
-Какие риски управления требованиями?
-Какие практики управления рисками предлагают различные подходы к разработке?
-Как требования тестировать и зачем?
-Как управлять требованиями?
-Как убедиться, что требование нужно реализовывать?
-Какие практики нужно применять, чтобы не потеряться в требованиях на этапе анализа и не потерять требования при разработке и внедрении?
Яким би досвідченим не був менеджер проекту чи продукту, яку б з топ-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, если у вас нет возможности его использовать?
Представляете себе идеальный релиз фичи? Какой процесс необходимо построить? Как организовать жизненный цикл? Как принимать решения о переходе фичи из одного статуса в другой? Как снизить риски и как избежать "узких мест"? Какой должна быть система ценностей команды? Что вы можете изменить в своем проекте или продукте уже прямо сейчас?
про практики проектирование жизненных циклов, процессы разработки, про продуктовое мышление и как сделать релиз безболезненным.
версия 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.
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, если у вас нет возможности его использовать?
Представляете себе идеальный релиз фичи? Какой процесс необходимо построить? Как организовать жизненный цикл? Как принимать решения о переходе фичи из одного статуса в другой? Как снизить риски и как избежать "узких мест"? Какой должна быть система ценностей команды? Что вы можете изменить в своем проекте или продукте уже прямо сейчас?
про практики проектирование жизненных циклов, процессы разработки, про продуктовое мышление и как сделать релиз безболезненным.
версия 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.
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 минут) попытался рассказать о накопленном опыте организации процессов тестирования в продуктовой разработке софта. Постарался дать обоснование, почему были приняты именно такие решения.
2. Дмитрий “Damiano” Ефименко.
Харьков, Украина.
Свой продукт + созданная команда.
Платежные карты в ИЭ унд СО.
Инженер.
Остервенелый продуктолог.
Знакомство
6. Вдруг откуда ни возьмись ниоткуда не
взялось то одно, то другое, то одно на
другое. И ох..ли боги девелопмента и
ангелы их выронили арфы от JetBrains и
сгорели те в плотных слоях атмосферы,
сиянием возвещая кошер аваль масриах…
Евангелие от Damiano, стих 14й
14. Если яйцо разбивается силою извне – жизнь
прекращается. Если яйцо разбивают изнутри –
жизнь начинается.
Все великое начинается изнутри.
Буддийской мудрости псто
Сидите на
попе ровно
44. Auftragstaktik & Mission type tactic
SMEAC
Atraa ishit
Feature-driven / API-driven development
Domain-driven design
Business goals trees
Искусство войны
…
Google в руки…
47. Если вы испуганы, одиноки,
вам стыдно или просто
хочется поговорить «об
этом» - вы знаете, где меня
найти…
d.efimenko
d.efimenko
Editor's Notes
А поговорим мы сегодня о технике безопасности. Про то, как все хорошо начинается – отличные идеи, солнце, улыбающиеся люди, открытое небо и прочее мимими…
Наступает момент, когда тьма сгущается и возникает жгучее желание нанести добро и причинить пользу.
Иными словами – хочется какой-нибудь гадости или сожрать или сделать.
Как? Я вас научу.
Начинаются всякие паранормальные штуки…
И вот она мудрость, выстраданная годами – советы, как усугубить и углубить.
Номикон – книга закона, правовой.
Пройон – продукт.
Чтобы не звучало, как ругательство – адаптировал до моднопривычного «чтототамномикон», пусть икнется Лавкрафту.
Это не мистическая динозаврология, за каждым «вредным советом» стоит боль и смешные или не очень истории из жизни. Моя цель – чтобы вам стало немного стыдно и захотелось побежать что-то изменить.
Антипаттерны командотворчества.
Команда - самое уязвимое место, «грибница» в экосистеме продукта.
Бизнес существует потому, что кто-то чем-то недоволен и готов платить за решение своих проблем. Мало спланировать и спроектировать - важно еще и реализовать. Не цените людей, которые умеют решать проблемы.
Нетерпимые люди часто зануды, которые придумают 237 основных и 186 косвенных признаков, что они не зануды. Не берегите их, пусть вас окружают те, кому плевать.
Зачем вам внимание к мелочам? Притча про стулья.
Нетерпимость, даже если она есть - не должна порождать действие. Сидите на попе ровно, будьте перфекционистом – добивать, так добивать.
Собеседование – неправильный и популярный метод приема на работу. Пользуйтесь им.
«Приняли за умного. Выкрутился»
Людей нужно нанимать за ответственность, честность, аккуратность, активность и умение посчитать канализационные люки на Манхеттене. Их не нужно нанимать за то, что они умеют решать задачи, которые перед ними будут поставлены. Не нужно понимать их восприятие сложности инженерной задачи.
Если тревожные сигналы возникают слишком рано, не пытайтесь обмануть себя - такие сотрудники смогут навредить вам в самый ответственный момент.
Хороший специалист часто становится менеджером. Тогда компания теряет хорошего специалиста и получает плохого менеджера. Бинго!
Чайкоменеджеры – это же лучше, чем чайкоинженеры.
Прилетел, поорал, нагадил, улетел – это лучше, чем прилетел, поорал, накодил, улетел.
Притча про Люка, Гарри, Бильбо, Нео.
Качайте мотивацию
Щоб вступити в рукопашний бій, боєць повинен про…ать на полі бою автомат, пістолет, ніж, поясний ремінь, лопатку, бронежилет i каску. Знайти рівну площадку на якій немає ні одного каменю чи палиці. І вступити в жорстоку епічну сутичку з таким же розп...яєм – майстром рукопашного бою.
Качайте мотивацию, а не дисциплину, зачем вам дисциплина. И плевать, что настоящую мотивацию невозможно навязать или создать, ее можно только усилить либо ослабить.
«Двигайся, стреляй, общайся. Всё на кону. Всегда» - ха!
Дисциплина разработчика – это не «ать-два». Не делать плохо, не смотреть на плохое, не слушать «авторитетов», не брать невыполнимых обязательств.
Эффективные командные практики: auftragstaktik & mission type tactic, smeac, atraa ishit, выход в поля, рабочие группы вместо команд…
Зачем вам это? Это все маркетинговый буллшит, дорого, долго и хрупко.
Берегите состав команды, даже если они рукожопы – пусть отдуваются за них нормальные перцы и перчинки
Не нужны: Общее цели, понимание, инструменты, практики, система ценностей.
Зачем? Приспосабливаются же люди ко всему.
Ну давайте, рассказывайте:
«полгода пилили архитектуру и потом печем фичи как пирожки»
«из отходов и палок» – «lean-development»
«вставил костыль» – ad-hoc solution
«фигак-фигак и в продакшен» – «быстрая обратная связь от пользователя»
«рукожопы» – «гибкие разработчики»
О продажах внутренних и внешних…
Зачем вам несколько горизонтов планирования? Зачем запасные планы и пути отхода? Решайте утилитарные задачи «на сейчас» для «поддержания штанов».
Не общайтесь с конкурентами.
Не общайтесь с пользователями. Главные инсайты кроются в тонком взаимодействии пользователей с продуктом, и, зачастую, это те вещи, которые пользователь не может описать словами или сам не замечает. Зачем вам это? «Не выходите из офиса».
У вас всегда будет шанс оказать второе впечатление.
Не говорите нет заказчикам, продажникам, коллегам
Быть милым котиком гораздо важнее, чем эти ваши бизнес-цели, MVP и прочие штуки мира безжалостного деньготворчества.
Продавайте продукт, сделайте конкурентам хорошо. Не нужно думать, что не вы продаете продукт, а ваши клиенты инвестируют в него свои наборы фич и ценностей. И управляете портфелем инвестиций – работа на опережение, беспокойство о максимальном ROI и т.д. Не ищите инвесторов, ищите покупателей.
Не цените время, будьте уверены, что планета большая и продать продукт найдется кому.
Мы все перфекционисты, ны мы все и люди – поэтому будьте перфекционистами-прокрастинаторами.
Лучше казаться, чем быть.
Как только вы ловите себя на этом – вы сразу почувствуете эффект. История про багфикс и мелочи.
Рынок не будет наказывать тот бизнес, который не понимает важности времени. Каждый, кого нанимает клиент – не кандидат на увольнение. И не ошибаются те, кто считает, что у них нет конкурентов.
Бессмысленно меняться и продавать, если не получаешь за это деньги/растет добавленная стоимость.
Продажи – это переговоры.
Переговоры - это не сверкающие зубы и дорогие костюмы, это анализ, подготовка и планирование.
План работает до первого контакта с врагом.
Понятие «готово».
Мало набрать команду, продать и спланировать стратегию. Важно ещё и реализовать.
Где деньги? Срок превращения идеи в деньги? – самые неправильная метрика. Ведь если их померять –становится стыдно, поэтому придумайте другие метрики.
А теперь – о нашем всем, чего так хочется, чтобы оно было в стиле «водка – дамы – патефон», а каменный цветок не выходит.
Визуализация не нужна. История про тренинг, скелетон и визуализацию.
Если уж вас угораздило заняться визуализацией – используйте паттерн WTF. Точки из окрестностей множества Жюлиа в пространстве чисто мнимых кватернионов – это же очевидно и понятно каждому.
Делайте фичи и не знайте, как вы будете сдаваться. Зачем вам сценарии?
Притча про сценарии, эволюцию и волков.
Деградирует все и всегда: идеи, архитектура, код, модель, процессы изготовления, процессы контроля изготовления. Зачем с этим бороться, если это естественный процесс?
Что такое 1-шаговое мышление? Исправил.
Что такое 2-шаговое мышление? Исправил/предотвратил.
Что такое 3-шаговое мышление? Исправил/предотвратил/деградацию поборол.
Что такое 4-шаговое мышление? Исправил/предотвратил/деградацию поборол/развил, улучшил, распространил.
Развитие архитектуры vs MVP.
Быстрая выкладка = Ценность -> Грязная архитектура для быстрой выкладки = Ценность. Шах и мат.
Разделяйте архитектуру и ценность – это приведет к «замечательному» результату.
Рефакторинг архитектуры (это вообще невозможно).
Рефакторинг модели (история про BFQ, кодировки и партиции).
Рефакторинг кода (метод переключений фич – это не для крутых).
Это все недостижимо.
Если вы с самого начала накопите технический долг, он сможет убить ваш продукт.
Делайте последними подсистемы логирования, сбора и ротации, доставки и хранения.
Зачем трассировка в логах, пишите так?
Зачем тестировать логи?
Fuckup-driven development – поймали неведому фигню и начинаем расширять логгирование.
История про чувствительные данные в логах.
API-driven development.
История про автоматизированные тесты и скорость их выполнения. История про параллельную разработку 5 участников и эмуляторы.
История про “упрощенный API” и “API”.
У вас такие интересные решения.
В первую очередь, делайте его простым. Потом быстрым. А потом – красивым. Глупость – делайте его функциональным
Вытягивающие принципы, приоритизация через ценность.
Пусть у тебя будут мускулистые руки, твердый взгляд и ощущение великого нагибатора.
История про непроходящие по умолчанию тесты и нетерпимость.
Итоги…
Вы можете верить или не верить в то, что я говорил, но если вам стало немножко стыдно и у вас чешутся руки что-то изменить – мы с вами не зря провели это время.