🙏 Просьба к читателям:
Если вам нравится этот канал, и у вас есть компании, которым вы можете порекомендовать меня - пожалуйста, отправьте им этот пост или мой сайт kavaleuski.me. Для меня это будет супер большой наградой! И поможет писать новый контент :)
Если вам нравится этот канал, и у вас есть компании, которым вы можете порекомендовать меня - пожалуйста, отправьте им этот пост или мой сайт kavaleuski.me. Для меня это будет супер большой наградой! И поможет писать новый контент :)
Топология команд
На прошлой неделе вышел пост про структуру команд в больших продуктах. Захотелось углубиться в эту тему и я быстро вырулил на популярную сейчас книгу «Топология команд».
Ее авторы нашли очень жизненную модель дизайна команд. Оглядываюсь на компании, где работал, и понимаю - все так и было!
По их мнению, все команды сводятся к 4 типам:
1. Платформенная. На примере нашего Амазона, это разработчики покупательской платформы. Они создали и поддерживают основные сущности: покупатель, товар, оплата и так далее. Получается фреймворк (движок), на котором легко писать фичи, относящиеся к покупке. Цель этой команды - сделать удобные инструменты и сервисы, которыми другая команда будет зарабатывать деньги.
2. Команда стрима как раз этим и занимается. Она делает основной функционал, который дает продукту ценность. Например, команда customer buying experience будет делать процесс покупки от карточки товара до "спасибо за ваш заказ". А команда merchant sales monitoring будет писать отчеты и статистику для продавцов.
3. Команда сложных подсистем - отвечает за какую-то очень дремучую, но очень нужную штуку. Например, поиск или рекомендации. В такую команду обычного фронтендера с рынка не возьмёшь, подойдут только лучшие умы планеты. Самой команде стрима не по зубам написать классный поиск, вот она и аутсорсит его другой тиме.
4. Помощники - это юристы, найм, безопасность и даже девопс, словом все, кто помогают стриму поскорее зарабатывать денежки. Немного похоже на платформенную команду, но с более узкими, локальными кейсами, которые нет смысла выкатывать на половину компании, как платформу.
Кто работает на больших продуктах, похоже на правду?
На прошлой неделе вышел пост про структуру команд в больших продуктах. Захотелось углубиться в эту тему и я быстро вырулил на популярную сейчас книгу «Топология команд».
Ее авторы нашли очень жизненную модель дизайна команд. Оглядываюсь на компании, где работал, и понимаю - все так и было!
По их мнению, все команды сводятся к 4 типам:
1. Платформенная. На примере нашего Амазона, это разработчики покупательской платформы. Они создали и поддерживают основные сущности: покупатель, товар, оплата и так далее. Получается фреймворк (движок), на котором легко писать фичи, относящиеся к покупке. Цель этой команды - сделать удобные инструменты и сервисы, которыми другая команда будет зарабатывать деньги.
2. Команда стрима как раз этим и занимается. Она делает основной функционал, который дает продукту ценность. Например, команда customer buying experience будет делать процесс покупки от карточки товара до "спасибо за ваш заказ". А команда merchant sales monitoring будет писать отчеты и статистику для продавцов.
3. Команда сложных подсистем - отвечает за какую-то очень дремучую, но очень нужную штуку. Например, поиск или рекомендации. В такую команду обычного фронтендера с рынка не возьмёшь, подойдут только лучшие умы планеты. Самой команде стрима не по зубам написать классный поиск, вот она и аутсорсит его другой тиме.
4. Помощники - это юристы, найм, безопасность и даже девопс, словом все, кто помогают стриму поскорее зарабатывать денежки. Немного похоже на платформенную команду, но с более узкими, локальными кейсами, которые нет смысла выкатывать на половину компании, как платформу.
Кто работает на больших продуктах, похоже на правду?
закон Конвея
Контрольный выстрел в большую разработку.
Нашел очень любопытный закон Конвея:
❗️Архитектура продукта копирует структуру коммуникации в компании.
Моя первая реакция - да не может быть! Мы же всегда пишем архитектуру, оптимальную для продукта, от требований и т.д и т.п.
Оказывается, нет.
Самый простой пример. В аутсорсинговую фирму приходит проект для 2х бекендеров. У компании на бенче 3 пхпшника и 1 джавист. Угадайте, на каком языке напишут бек? :)
Другой пример. В одном продукте дизайнер работает фултайм в команде. Он участвует в планировании, имеет доступ к аналитике, видит фидбек пользователей. В другом продукте дизайнера привлекают из соседнего отдела, когда появляются юайные задачи.
В каком из них дизайн будет лучше? Конечно, в первом, потому что дизайнер там - в контексте.
ОК, что с этим делать?
1️⃣ Создавать кросс-функциональные команды (привет, скрам), в которых есть все специалисты для достижения цели. Так уменьшаются коммуникации между внешними командами и отделами, а следовательно, уменьшаются и потери.
2️⃣ Прежде, чем собирать команду, определяем какая нужна архитектура. То есть так:
Продукт -> Архитектура -> Команда.
Не наоборот! Иначе сложившаяся структура компании «задавит» планируемую архитектуру и она будет просто повторять устоявшиеся шаблоны.
Картинка отсюда.
Хорошая статья по теме.
Контрольный выстрел в большую разработку.
Нашел очень любопытный закон Конвея:
❗️Архитектура продукта копирует структуру коммуникации в компании.
Моя первая реакция - да не может быть! Мы же всегда пишем архитектуру, оптимальную для продукта, от требований и т.д и т.п.
Оказывается, нет.
Самый простой пример. В аутсорсинговую фирму приходит проект для 2х бекендеров. У компании на бенче 3 пхпшника и 1 джавист. Угадайте, на каком языке напишут бек? :)
Другой пример. В одном продукте дизайнер работает фултайм в команде. Он участвует в планировании, имеет доступ к аналитике, видит фидбек пользователей. В другом продукте дизайнера привлекают из соседнего отдела, когда появляются юайные задачи.
В каком из них дизайн будет лучше? Конечно, в первом, потому что дизайнер там - в контексте.
ОК, что с этим делать?
1️⃣ Создавать кросс-функциональные команды (привет, скрам), в которых есть все специалисты для достижения цели. Так уменьшаются коммуникации между внешними командами и отделами, а следовательно, уменьшаются и потери.
2️⃣ Прежде, чем собирать команду, определяем какая нужна архитектура. То есть так:
Продукт -> Архитектура -> Команда.
Не наоборот! Иначе сложившаяся структура компании «задавит» планируемую архитектуру и она будет просто повторять устоявшиеся шаблоны.
Картинка отсюда.
Хорошая статья по теме.
Обратная связь по дефектам
Есть категория особенно неприятных багов - те, что присылают извне. Например, пользователи, клиенты, стейкхолдеры, словом все те, стыд перед кем может стоить менеджеру бонуса 🎃
Хочется, чтобы все баги находила только команда. Тогда можно уверенно ответить: "да, мы в курсе про этот дефект, решили пока отложить, починим к августу". В таком контексте присылающий видит, что у нас все под контролем и больше команде доверяет.
Но как этого добиться?
На всех проектах, где я работал, мы делали такое упражнение.
Раз в месяц собирались qa лид, тимлид и я и проходились по "чужим" дефектам. Составляли такую табличку:
и проговаривали каждый баг. Такая мини-ретра по точечным проблемам.
Чаще всего всплывали недоработки в требованиях и пропущенные тест-кейсы. Но иногда находились любопытные штуки. Так, на одном проекте мы скорректировали стратегию по тестам.
Для команды - это настоящая, живая обратная связь, люди своими глазами видят косяки и их последствия. Причем не от менеджера, на которого уже иммунитет, а от тех, кто деньги платит.
Рекомендую.
Есть категория особенно неприятных багов - те, что присылают извне. Например, пользователи, клиенты, стейкхолдеры, словом все те, стыд перед кем может стоить менеджеру бонуса 🎃
Хочется, чтобы все баги находила только команда. Тогда можно уверенно ответить: "да, мы в курсе про этот дефект, решили пока отложить, починим к августу". В таком контексте присылающий видит, что у нас все под контролем и больше команде доверяет.
Но как этого добиться?
На всех проектах, где я работал, мы делали такое упражнение.
Раз в месяц собирались qa лид, тимлид и я и проходились по "чужим" дефектам. Составляли такую табличку:
дефект | причина | выводи проговаривали каждый баг. Такая мини-ретра по точечным проблемам.
Чаще всего всплывали недоработки в требованиях и пропущенные тест-кейсы. Но иногда находились любопытные штуки. Так, на одном проекте мы скорректировали стратегию по тестам.
Для команды - это настоящая, живая обратная связь, люди своими глазами видят косяки и их последствия. Причем не от менеджера, на которого уже иммунитет, а от тех, кто деньги платит.
Рекомендую.
"Канбан и точно вовремя"
Канбан, в переводе с японского - это "вывеска магазина" или "бирка". На заводе Тойота, который первым начал использовать канбан в автомобилестроении, такие карточки использовали как форму заказа деталей.
Менеджер брал план продаж автомобилей, определял сколько понадобится деталей для производства, и, чтобы заказать каждую из них, делал карточку с названием детали. Когда деталь была готова, на нее вешали карточку, давая всем понять, что можно приступать к сборке.
Мне эта система напомнила тикеты в джире после декомпозиции.
Книга "Канбан и точно вовремя" рассказывает про завод и принципы его работы. Читать, по больше части, скучно. Зато некоторые идеи любопытно переложить на наш ИТ-мир. Например:
✅ Экономически выгоднее брать в работу те тикеты, которые висят на доске правее, т.е. ближе всего к завершению. На примере машин сразу становится понятно почему. Автомобиль, в котором не хватает всего лишь зеркала заднего вида, имеет нулевую ценность - его никто не купит. А раз он ближе всего к завершению, значит и продастся быстрее, поэтому берем его первым.
✅ Производить надо ровно столько деталей, сколько требуется для сборки нужного количества автомобилей. Это число определяет отдел продаж. Если производить детали или целые машины впрок, то потом они стоят на складе, за который надо платить, ржавеют и портятся. Так же и с кодом. Писать надо только те, фичи, которые будут использоваться (= продаваться), чтобы не захламлять продукт и платить минимум за его обслуживание.
Канбан, в переводе с японского - это "вывеска магазина" или "бирка". На заводе Тойота, который первым начал использовать канбан в автомобилестроении, такие карточки использовали как форму заказа деталей.
Менеджер брал план продаж автомобилей, определял сколько понадобится деталей для производства, и, чтобы заказать каждую из них, делал карточку с названием детали. Когда деталь была готова, на нее вешали карточку, давая всем понять, что можно приступать к сборке.
Мне эта система напомнила тикеты в джире после декомпозиции.
Книга "Канбан и точно вовремя" рассказывает про завод и принципы его работы. Читать, по больше части, скучно. Зато некоторые идеи любопытно переложить на наш ИТ-мир. Например:
✅ Экономически выгоднее брать в работу те тикеты, которые висят на доске правее, т.е. ближе всего к завершению. На примере машин сразу становится понятно почему. Автомобиль, в котором не хватает всего лишь зеркала заднего вида, имеет нулевую ценность - его никто не купит. А раз он ближе всего к завершению, значит и продастся быстрее, поэтому берем его первым.
✅ Производить надо ровно столько деталей, сколько требуется для сборки нужного количества автомобилей. Это число определяет отдел продаж. Если производить детали или целые машины впрок, то потом они стоят на складе, за который надо платить, ржавеют и портятся. Так же и с кодом. Писать надо только те, фичи, которые будут использоваться (= продаваться), чтобы не захламлять продукт и платить минимум за его обслуживание.
Приколы про Канбан
Когда готовил предыдущий пост, немного копнул историю Канбана и узнал несколько любопытных штук:
1. Когда говорят про доску, wip-лимиты и вот это все в контексте ИТ-проектов, то имеют в виду Канбан Метод. Его придумал Дэвид Андерсон, консультируя Майкрософт в 2005. Он вдохновлялся, конечно, Канбаном Тойоты и теорией ограничений Голдрата, которого все продакты знают по популярной книге "Цель". Захватывающая статья о том, как это было (промотайте до середины).
2. Тойота тоже не то чтобы сама все придумала. Ее тогдашний директор, Тайити Оно, скатался в США на завод Форд, чтобы набраться опыта зарубежных коллег. Но все пошло не по плану, и больше завода его впечатлили супермаркеты. На их полках всегда было нужное количество товаров. Достаточное, чтобы не испортиться, и необходимое, чтобы полностью обеспечить местных покупателей. Когда люди скупали, половину запасов тунца, это было сигналом заказать столько же тунца у производителя. Этот принцип - Supermarket Pull System - лег в основу Канбана.
3. В Канбане есть свой гайд, написанный мистером Андерсеном. Но метод еще молодой, и, как я понял, в среде менеджеров он пока не стал единым источником правды, как Скрам гайд. Есть даже конкурирующая фирма от бывшего партнера Андерсона, который сделал свою версию гайда. История развивается на наших глазах 🍿
4. В Скраме нам часто повторяют, что если хоть что-то изменить, даже переименовать скрам-мастера в менеджера, то сразу все сломается. При этом у каждой команды "немного своя версия Скрама" и никто до сих пор не умер. В Канбане такого запрета нет. Можно использовать все практики из гайда, а можно только часть, которая сейчас решит проблему твоего проекта. Например, работать по SAFe + брать классы обслуживания и каденции по рискам. Удобно, гибко и не чувствуешь себя еретиком.
Когда готовил предыдущий пост, немного копнул историю Канбана и узнал несколько любопытных штук:
1. Когда говорят про доску, wip-лимиты и вот это все в контексте ИТ-проектов, то имеют в виду Канбан Метод. Его придумал Дэвид Андерсон, консультируя Майкрософт в 2005. Он вдохновлялся, конечно, Канбаном Тойоты и теорией ограничений Голдрата, которого все продакты знают по популярной книге "Цель". Захватывающая статья о том, как это было (промотайте до середины).
2. Тойота тоже не то чтобы сама все придумала. Ее тогдашний директор, Тайити Оно, скатался в США на завод Форд, чтобы набраться опыта зарубежных коллег. Но все пошло не по плану, и больше завода его впечатлили супермаркеты. На их полках всегда было нужное количество товаров. Достаточное, чтобы не испортиться, и необходимое, чтобы полностью обеспечить местных покупателей. Когда люди скупали, половину запасов тунца, это было сигналом заказать столько же тунца у производителя. Этот принцип - Supermarket Pull System - лег в основу Канбана.
3. В Канбане есть свой гайд, написанный мистером Андерсеном. Но метод еще молодой, и, как я понял, в среде менеджеров он пока не стал единым источником правды, как Скрам гайд. Есть даже конкурирующая фирма от бывшего партнера Андерсона, который сделал свою версию гайда. История развивается на наших глазах 🍿
4. В Скраме нам часто повторяют, что если хоть что-то изменить, даже переименовать скрам-мастера в менеджера, то сразу все сломается. При этом у каждой команды "немного своя версия Скрама" и никто до сих пор не умер. В Канбане такого запрета нет. Можно использовать все практики из гайда, а можно только часть, которая сейчас решит проблему твоего проекта. Например, работать по SAFe + брать классы обслуживания и каденции по рискам. Удобно, гибко и не чувствуешь себя еретиком.
Начать с хорошего
Заметил такой паттерн в коммуникации - начинать с хорошего.
Залил свое резюме в анализатор классности резюме - подсветило, что я молодец, сделал структуру и много цифр. А потом уже, что has и had путаю.
Опытные консультанты по секрету рассказали, что в начале аудита добавляют секцию "что ваша команда сейчас делает хорошо". Чтобы менеджер подумал "я такой молодец, вон сколько классных вещей внедрил". А потом уже рубят правду, что люди уставшие.
Мы все подсознательно ищем похвалы и одобрения, поэтому приятное начало стимулирует вовлекаться дальше.
Что с этим делать?
Менеджеру этот принцип помогает не выглядеть пессимистом в глазах коллег. И, конечно, растапливать лед перед тяжелыми разговорами. Например:
📍 На 1-1:
"Стас, ты отлично делаешь код ревью и многие ребята отметили, что растут благодаря твоему наставничеству. Но вот с коммуникацией у тебя беда"
📍 Клиенту:
"Мэтт, спасибо за описание фичи. Команда приятно удивилась таким подробно описанным сценариям, оценивать было быстро. Если бы еще получать их немного заранее, чтобы вовремя прорабатывать."
📍 Разбирая новый дизайн:
"Мне понравился экран подписки, ценность выглядит очень понятной. Думаю, улучшив попапы и CTA, мы можем повысить конверсию в покупку."
Заметил такой паттерн в коммуникации - начинать с хорошего.
Залил свое резюме в анализатор классности резюме - подсветило, что я молодец, сделал структуру и много цифр. А потом уже, что has и had путаю.
Опытные консультанты по секрету рассказали, что в начале аудита добавляют секцию "что ваша команда сейчас делает хорошо". Чтобы менеджер подумал "я такой молодец, вон сколько классных вещей внедрил". А потом уже рубят правду, что люди уставшие.
Мы все подсознательно ищем похвалы и одобрения, поэтому приятное начало стимулирует вовлекаться дальше.
Что с этим делать?
Менеджеру этот принцип помогает не выглядеть пессимистом в глазах коллег. И, конечно, растапливать лед перед тяжелыми разговорами. Например:
📍 На 1-1:
"Стас, ты отлично делаешь код ревью и многие ребята отметили, что растут благодаря твоему наставничеству. Но вот с коммуникацией у тебя беда"
📍 Клиенту:
"Мэтт, спасибо за описание фичи. Команда приятно удивилась таким подробно описанным сценариям, оценивать было быстро. Если бы еще получать их немного заранее, чтобы вовремя прорабатывать."
📍 Разбирая новый дизайн:
"Мне понравился экран подписки, ценность выглядит очень понятной. Думаю, улучшив попапы и CTA, мы можем повысить конверсию в покупку."
Как вести беклог и груминг
Если когда-нибудь изучали техники ведение беклога, то наверняка встречали вот такую картинку. Она предлагает держать вверху наиболее важные задачи и грумить их первыми. Ниже будут менее приоритетные с меньшей детализацией. И так далее, вниз по беклогу.
Вот 2 способа как это реализовать на практике и немного улучшить:
Способ 1: борд для груминга
Все задачи из беклога заносим в отдельный борд. Создаем колонки, которые соответствуют вашему процессу работы с фичами. У меня на аутсорсинговом проекте были такие: to do, prioritized, in BA review, customer's approval, tech review, ready for dev.На планинге с командой и клиентом проходим по ready for dev и выбираем, что взять в следующий спринт.
Этот метод подходит, если у вас строгий процесс подготовки фич с несколькими стейкхолдерами. Если процесс попроще (например, вы автономный продакт или собственник), то можно использовать 👇
Способ 2: спринт с наиболее близкими задачами
В беклоге создаем спринт next sprint candidates, куда складываем все задачи, которые хотим сделать в ближайшее время. У меня в продукте было планирование на неделю и в этом спринте лежало работы на 3-4 недели. Тимлиды по пятницам проходились по задачам, а в понедельник мы решали, что взять в работу.
Если когда-нибудь изучали техники ведение беклога, то наверняка встречали вот такую картинку. Она предлагает держать вверху наиболее важные задачи и грумить их первыми. Ниже будут менее приоритетные с меньшей детализацией. И так далее, вниз по беклогу.
Вот 2 способа как это реализовать на практике и немного улучшить:
Способ 1: борд для груминга
Все задачи из беклога заносим в отдельный борд. Создаем колонки, которые соответствуют вашему процессу работы с фичами. У меня на аутсорсинговом проекте были такие: to do, prioritized, in BA review, customer's approval, tech review, ready for dev.На планинге с командой и клиентом проходим по ready for dev и выбираем, что взять в следующий спринт.
Этот метод подходит, если у вас строгий процесс подготовки фич с несколькими стейкхолдерами. Если процесс попроще (например, вы автономный продакт или собственник), то можно использовать 👇
Способ 2: спринт с наиболее близкими задачами
В беклоге создаем спринт next sprint candidates, куда складываем все задачи, которые хотим сделать в ближайшее время. У меня в продукте было планирование на неделю и в этом спринте лежало работы на 3-4 недели. Тимлиды по пятницам проходились по задачам, а в понедельник мы решали, что взять в работу.
ПМ году 4 года
Сегодня у канала день рождения. Я обычно не обращаю внимания на такие штуки, но сейчас по-другому.
За это время канал стал большой часть моей профессиональной жизни. Благодаря ему, я изучил много новых штук, познакомился с кучей классных ребят, улучшил навык письма, закрыл потребность "делиться опытом". Я счастлив, что он есть.
Канала не было бы без читателей - вас. Ведь писать для кого-то гораздо веселее и ответственней, чем просто писать. Особенно, когда это 12 тыщ человек!
Хочу сказать спасибо за то, что читаете, комментируете, лайкаете и пересылаете посты друзьям.
❤️
Сегодня у канала день рождения. Я обычно не обращаю внимания на такие штуки, но сейчас по-другому.
За это время канал стал большой часть моей профессиональной жизни. Благодаря ему, я изучил много новых штук, познакомился с кучей классных ребят, улучшил навык письма, закрыл потребность "делиться опытом". Я счастлив, что он есть.
Канала не было бы без читателей - вас. Ведь писать для кого-то гораздо веселее и ответственней, чем просто писать. Особенно, когда это 12 тыщ человек!
Хочу сказать спасибо за то, что читаете, комментируете, лайкаете и пересылаете посты друзьям.
❤️
Новый фреймворк в эджайле - Evidence based management
Всегда было немного обидно за продакт оунеров, которым скрам не дал никаких конкретных инструментов, кроме беклога.
И вот 2 года назад ребята из scrum.org выпускают новый фреймворк - Evidence based management*. Он фокусируется на ценности выпускаемого продукта, и предлагает рассматривать его с 4 сторон:
- где мы сейчас
- потенциал рынка
- скорость поставки
- инновационность
Получается такой SWOT-анализ только с другими секциями.
Любопытно, что скрам пытается зафреймвочить не только "как", но теперь и "что". В конце гайда даже приведены конкретные метрики, которые полезно считать по каждой из сторон. Для моей любимой темы поставки это: lead time, частота билдов и релизов, время на фикс критического бага в продакшене и другие. Очень хорошие и важные вопросы.
Клево, что скрам, наконец, предлагает конкретные шаги, как сделать продукт лучше, а не общие формулировки в духе "будьте хорошими и инспектируйте проблемы". Надеюсь скоро мы увидим еще больше конкретики для людей из бизнеса.
*Интернет говорит, что Evidence based management придумал американский медик в 1990. Версия скрама на мой взгляд значительно отличается от оригинальной теории. Если разбираетесь в вопросе - напишите в комментах как там было дело.
Всегда было немного обидно за продакт оунеров, которым скрам не дал никаких конкретных инструментов, кроме беклога.
И вот 2 года назад ребята из scrum.org выпускают новый фреймворк - Evidence based management*. Он фокусируется на ценности выпускаемого продукта, и предлагает рассматривать его с 4 сторон:
- где мы сейчас
- потенциал рынка
- скорость поставки
- инновационность
Получается такой SWOT-анализ только с другими секциями.
Любопытно, что скрам пытается зафреймвочить не только "как", но теперь и "что". В конце гайда даже приведены конкретные метрики, которые полезно считать по каждой из сторон. Для моей любимой темы поставки это: lead time, частота билдов и релизов, время на фикс критического бага в продакшене и другие. Очень хорошие и важные вопросы.
Клево, что скрам, наконец, предлагает конкретные шаги, как сделать продукт лучше, а не общие формулировки в духе "будьте хорошими и инспектируйте проблемы". Надеюсь скоро мы увидим еще больше конкретики для людей из бизнеса.
*Интернет говорит, что Evidence based management придумал американский медик в 1990. Версия скрама на мой взгляд значительно отличается от оригинальной теории. Если разбираетесь в вопросе - напишите в комментах как там было дело.
Сдал на продакт оунера
Вчера сдал на PSPO 1 от Scrum.org.
Здесь я писал, как сдавал на скрам мастера и в чем отличие от сертификации Scrum Alliance. Это очень похожий опыт, поэтому расскажу в чем отличия:
1️⃣ На подготовку ушло 4 дня. В прошлый раз я готовился несколько месяцев, и сейчас понимаю, что можно быстрее. Больше всего помогли вот эти ресурсы:
- тесты на Udemy
- тесты Михаила Лапшина
- вот эта книжка с тестами
Я проходил их, в среднем, на 90% (при проходном в 85) и не был уверен, что справляюсь с реальным тестом. Иногда попадались вопросы, которые вводили в ступор, например: "Какими метриками измерить успешность перехода от Waterfall к Scrum?". Чегооо?
В итоге настоящий тест оказался немного проще, я ответил неправильно только на один вопрос.
Плюс, конечно, скрам гайд, нексус гайд, EBM и бесплатные тренировочные тесты на scrum.org.
2️⃣ Тест PO сложнее теста SM. Если хотите сдать оба, то начинайте с SM.
3️⃣ Вопросы на PO на 60% совпадают с вопросами на SM. Если бы я знал это раньше, то сдавал бы PO сразу же после SM, пока свежи знания.
4️⃣ Насчет знаний. Получил ли я какие-то новые знания благодаря этому тесту? Скорее, нет. Любой из экзаменов точно поможет упорядочить знания по скраму. Но сдача второго не особо что-то дает.
Напишите в комментах, если у вас по-другому, интересно послушать.
5️⃣ Зачем тогда его сдавать? Я начал смотреть работу в Европе и вижу, что около 20% вакансий просят PMI или эджайловые сертификаты. Думаю, пригодится.
Удачи на тесте!
Вчера сдал на PSPO 1 от Scrum.org.
Здесь я писал, как сдавал на скрам мастера и в чем отличие от сертификации Scrum Alliance. Это очень похожий опыт, поэтому расскажу в чем отличия:
1️⃣ На подготовку ушло 4 дня. В прошлый раз я готовился несколько месяцев, и сейчас понимаю, что можно быстрее. Больше всего помогли вот эти ресурсы:
- тесты на Udemy
- тесты Михаила Лапшина
- вот эта книжка с тестами
Я проходил их, в среднем, на 90% (при проходном в 85) и не был уверен, что справляюсь с реальным тестом. Иногда попадались вопросы, которые вводили в ступор, например: "Какими метриками измерить успешность перехода от Waterfall к Scrum?". Чегооо?
В итоге настоящий тест оказался немного проще, я ответил неправильно только на один вопрос.
Плюс, конечно, скрам гайд, нексус гайд, EBM и бесплатные тренировочные тесты на scrum.org.
2️⃣ Тест PO сложнее теста SM. Если хотите сдать оба, то начинайте с SM.
3️⃣ Вопросы на PO на 60% совпадают с вопросами на SM. Если бы я знал это раньше, то сдавал бы PO сразу же после SM, пока свежи знания.
4️⃣ Насчет знаний. Получил ли я какие-то новые знания благодаря этому тесту? Скорее, нет. Любой из экзаменов точно поможет упорядочить знания по скраму. Но сдача второго не особо что-то дает.
Напишите в комментах, если у вас по-другому, интересно послушать.
5️⃣ Зачем тогда его сдавать? Я начал смотреть работу в Европе и вижу, что около 20% вакансий просят PMI или эджайловые сертификаты. Думаю, пригодится.
Удачи на тесте!
Топовое исследование об эффективности команд
Иногда на проект выделяют разработчика на 4 часа в день. Остальные 4 часа он занят другим проектом.
Понятно, что эффективность такой работы ниже, так как на переключение между проектами нужно время. Но сколько мы потеряем в производительности? 10%? 20%
Исследователи CA Technologies опросили 50,000 команд и выяснили, что правильный ответ - 50%. Т.е. люди, работающие фултайм, делают в 2 раза (!) больше работы на единицу времени, чем работающие парт-тайм.
Еще несколько фактов, которые цепляют:
📍 Команды, оценивающие задачи в часах на перформят на 20% хуже, чем те, кто оценивают в стори поинтах. Перфоманс оценивали по нескольким параметрам, вроде качества, продуктивности и т.д.
📍 Команды в 5-9 человек, использующие 2-х недельные спринты наиболее результативны по сравнению с другими сетапами.
📍 Команды, которые проводят ретроспективу, перформят на 20% лучше, чем те, кто не проводят. Особенно видно улучшение по качеству: + 42%.
📍 Разработчик, у которого в момент времени 1-2 задачи, делает на 70% меньше багов, чем разработчик с 3-5 задачами.
Если хотите продать команде идею не брать кучу тасок в работу, то такое исследование - мощный аргумент. Советую почитать его полностью (всего 16 страниц с картинками!), действительно много интересной инфы: https://docs.broadcom.com/doc/the-impact-of-agile-quantified.
Иногда на проект выделяют разработчика на 4 часа в день. Остальные 4 часа он занят другим проектом.
Понятно, что эффективность такой работы ниже, так как на переключение между проектами нужно время. Но сколько мы потеряем в производительности? 10%? 20%
Исследователи CA Technologies опросили 50,000 команд и выяснили, что правильный ответ - 50%. Т.е. люди, работающие фултайм, делают в 2 раза (!) больше работы на единицу времени, чем работающие парт-тайм.
Еще несколько фактов, которые цепляют:
📍 Команды, оценивающие задачи в часах на перформят на 20% хуже, чем те, кто оценивают в стори поинтах. Перфоманс оценивали по нескольким параметрам, вроде качества, продуктивности и т.д.
📍 Команды в 5-9 человек, использующие 2-х недельные спринты наиболее результативны по сравнению с другими сетапами.
📍 Команды, которые проводят ретроспективу, перформят на 20% лучше, чем те, кто не проводят. Особенно видно улучшение по качеству: + 42%.
📍 Разработчик, у которого в момент времени 1-2 задачи, делает на 70% меньше багов, чем разработчик с 3-5 задачами.
Если хотите продать команде идею не брать кучу тасок в работу, то такое исследование - мощный аргумент. Советую почитать его полностью (всего 16 страниц с картинками!), действительно много интересной инфы: https://docs.broadcom.com/doc/the-impact-of-agile-quantified.
Как успевать стендап за 15 минут
1️⃣ Продайте команде проблему. Объявите целью августа начать укладываться в 15 минут.
2️⃣ Начинайте вовремя. Если договорились на 10.00, значит в 10.00 первый человек рассказывает статус. Не задерживайте ни на минуту, даже если пришло 3 человека. Через неделю народ втянется и будет приходить вовремя.
3️⃣ Следуйте формату что сделал - что буду делать - есть ли проблемы.
4️⃣ Для молодых команд добавьте четвертый вопрос - успеваю / не успеваю сделать задачу вовремя, в оговоренные сроки.
5️⃣ ❗Самый важный пункт: каждый раз, когда начинаются лишние детали останавливайте говорящего.
"В 347 таске, по-моему, какая-то херня с требованиями, вчера начал..."
"Саша, стоп, давай обсудим после стендапа"
6️⃣ ❗Самый важный пункт-2: любой затруднительный вопрос, требующий >30 сек разбирайте после стендапа. Т.е. сначала завершили статус, часть ребят ушла, а те, у кого были вопросы, остаются (можно прямо в том же митинге). Да, вы будете оставаться два раза из трех, зато большая часть команды экономит время.
Было: 8 человек слушают претензии Саши по требованиям в 347 таске.
Стало: ПМ, БА и Саша разбирают претензии по требованиям в 347 таске.
7️⃣ Расшарьте экран со списком задач, чтобы соотносить слова Саши с 347 таской. Так всем понятнее о чем идет речь.
--------------------------------------
Менеджер - тоже часть команды. Рассказывайте ребятам, с каким клиентом вчера был звонок, что отдел маркетинга думает про последний релиз и тому подобное.
1️⃣ Продайте команде проблему. Объявите целью августа начать укладываться в 15 минут.
2️⃣ Начинайте вовремя. Если договорились на 10.00, значит в 10.00 первый человек рассказывает статус. Не задерживайте ни на минуту, даже если пришло 3 человека. Через неделю народ втянется и будет приходить вовремя.
3️⃣ Следуйте формату что сделал - что буду делать - есть ли проблемы.
4️⃣ Для молодых команд добавьте четвертый вопрос - успеваю / не успеваю сделать задачу вовремя, в оговоренные сроки.
5️⃣ ❗Самый важный пункт: каждый раз, когда начинаются лишние детали останавливайте говорящего.
"В 347 таске, по-моему, какая-то херня с требованиями, вчера начал..."
"Саша, стоп, давай обсудим после стендапа"
6️⃣ ❗Самый важный пункт-2: любой затруднительный вопрос, требующий >30 сек разбирайте после стендапа. Т.е. сначала завершили статус, часть ребят ушла, а те, у кого были вопросы, остаются (можно прямо в том же митинге). Да, вы будете оставаться два раза из трех, зато большая часть команды экономит время.
Было: 8 человек слушают претензии Саши по требованиям в 347 таске.
Стало: ПМ, БА и Саша разбирают претензии по требованиям в 347 таске.
7️⃣ Расшарьте экран со списком задач, чтобы соотносить слова Саши с 347 таской. Так всем понятнее о чем идет речь.
--------------------------------------
Менеджер - тоже часть команды. Рассказывайте ребятам, с каким клиентом вчера был звонок, что отдел маркетинга думает про последний релиз и тому подобное.
Новости ПМ совета
3 месяца назад я запустил ПМ совет - сообщество проджектов по решению кейсов.
С тех пор мы разобрали 20 ситуаций из жизни ребят. Некоторые из них можно почитать здесь, остальные доступы по подписке.
Еще до запуска я думал, как реализовать подписку. Нужен был механизм оплаты, управление пользователями, 2 вида подписки, статистика, в общем целый проект. Хотелось найти готовое решение, желательно, не за миллион денег. Так я обнаружил бот @donate от официальной команды телеграма, он принимает большинство карт и комиссия минимальная.
Нервничал перед запуском подписки - кто ее вообще купит? Какую поставить цену? Но нашлось целых 20 человек, кому формат зашел и почти все ребята продлили ее на 2 месяц. Спасибо вам!! ❤️
Было несколько гостевых встреч, где мы разобрали мое резюме и линкедин с экспертами по найму. Мне кажется, это интересный формат и я хочу его еще покрутить. В сентябре будет одна такая встреча, где построим архитектурную схему (system design) какого-нибудь продукта.
Любопытно, что чаще других присылают проблемы, связанные с токсичным или зазвездившимся членом команды. К сожалению, это действительно нередко встречается в наших широтах.
Из проблем, которые хочется решить - это невысокая конверсия в подписку - 2%. Если есть идеи, как ее увеличить - пишите в комментах.
В последнее время уменьшился поток присылаемых кейсов, сейчас тоже думаю, как мотивировать народ делиться. Если у вас есть ситуация, которую хотели бы разобрать - велкам.
И приходите на ПМ совет, у нас классно :)
3 месяца назад я запустил ПМ совет - сообщество проджектов по решению кейсов.
С тех пор мы разобрали 20 ситуаций из жизни ребят. Некоторые из них можно почитать здесь, остальные доступы по подписке.
Еще до запуска я думал, как реализовать подписку. Нужен был механизм оплаты, управление пользователями, 2 вида подписки, статистика, в общем целый проект. Хотелось найти готовое решение, желательно, не за миллион денег. Так я обнаружил бот @donate от официальной команды телеграма, он принимает большинство карт и комиссия минимальная.
Нервничал перед запуском подписки - кто ее вообще купит? Какую поставить цену? Но нашлось целых 20 человек, кому формат зашел и почти все ребята продлили ее на 2 месяц. Спасибо вам!! ❤️
Было несколько гостевых встреч, где мы разобрали мое резюме и линкедин с экспертами по найму. Мне кажется, это интересный формат и я хочу его еще покрутить. В сентябре будет одна такая встреча, где построим архитектурную схему (system design) какого-нибудь продукта.
Любопытно, что чаще других присылают проблемы, связанные с токсичным или зазвездившимся членом команды. К сожалению, это действительно нередко встречается в наших широтах.
Из проблем, которые хочется решить - это невысокая конверсия в подписку - 2%. Если есть идеи, как ее увеличить - пишите в комментах.
В последнее время уменьшился поток присылаемых кейсов, сейчас тоже думаю, как мотивировать народ делиться. Если у вас есть ситуация, которую хотели бы разобрать - велкам.
И приходите на ПМ совет, у нас классно :)
Forwarded from ПМ совет
Вчера на совете увлеклись таким вопросом:
В решении споров на чьей стороне должен быть ПМ: команды или клиента? Или может быть выступать таким медиатором, посередине?
Я думаю, что ПМ должен быть на стороне правды и здравого смысла. Например, если команда пропустила критовый баг, надо честно в этом признаться клиенту, не юлить. Да, так и так, мы лошары, пропустили баг. Завтра все починим, платить не нужно, т.к. это наш косяк.
С другой стороны, важно не дать клиенту сесть на шею, ПМ все-таки на компанию работает. Например, если сдали фичу, а заказчик говорит, ой, я не совсем так ее представлял. Сорри, но вот у нас ТЗ и дизайны, которое ты заапрувал, мы сделали, что обещали. Да, изменение небольшое, но мы не можем его сделать бесплатно, т.к. не хотим уйти в минус.
А вы как думаете?
В решении споров на чьей стороне должен быть ПМ: команды или клиента? Или может быть выступать таким медиатором, посередине?
Я думаю, что ПМ должен быть на стороне правды и здравого смысла. Например, если команда пропустила критовый баг, надо честно в этом признаться клиенту, не юлить. Да, так и так, мы лошары, пропустили баг. Завтра все починим, платить не нужно, т.к. это наш косяк.
С другой стороны, важно не дать клиенту сесть на шею, ПМ все-таки на компанию работает. Например, если сдали фичу, а заказчик говорит, ой, я не совсем так ее представлял. Сорри, но вот у нас ТЗ и дизайны, которое ты заапрувал, мы сделали, что обещали. Да, изменение небольшое, но мы не можем его сделать бесплатно, т.к. не хотим уйти в минус.
А вы как думаете?
Тест на технические скилы
Недавно на собеседовании спрашивали про устройство CI/CD пайплайнов в мобильной разработке 🤯. Я рассказал, что знал про тесты, инфру для билдов, метрики и гитфлоу, но чувствую, что можно было лучше.
Так глубоко спрашивают не везде, но на позиции вроде technical product manager или delivery manager довольно часто.
В честь этого я собрал тест по техническим скилам для всех не-программистов. Получилось больше в стиле куку, типо "какой-ты-летний-фрукт", но, как говорится, в каждой шутке есть доля шутки.
https://kavaleuski.me/tech-test
Пишите в комментах сколько набрали.
Недавно на собеседовании спрашивали про устройство CI/CD пайплайнов в мобильной разработке 🤯. Я рассказал, что знал про тесты, инфру для билдов, метрики и гитфлоу, но чувствую, что можно было лучше.
Так глубоко спрашивают не везде, но на позиции вроде technical product manager или delivery manager довольно часто.
В честь этого я собрал тест по техническим скилам для всех не-программистов. Получилось больше в стиле куку, типо "какой-ты-летний-фрукт", но, как говорится, в каждой шутке есть доля шутки.
https://kavaleuski.me/tech-test
Пишите в комментах сколько набрали.
kavaleuski.me
Тест на технические знания для не-программистов
PM tech skills test
Как работать с рисками
О риск-менеджменте принято говорить шепотом, как о неприлично сложной науке, доступной только тем, кто читал PMBOK. На деле любой ПМ работает с рисками каждый день.
Объясню на примере.
Представим, джависта Валеру, который в последнее время стал больше материться и ходит какой-то грустный. Производительность пока не упала, но с ним явно что-то не так.
Хороший ПМ увидит в этом потенциальную проблему и пойдет ее решать:
1️⃣ Вспомнит, что Валера говорил на последних ретрах. Какие из его задач были самыми грустными. Проведет 1-1 и выяснит, что Валера устал от проекта за 3 года, но пока еще не созрел уходить. Это идентификация риска.
2️⃣ Если забить на проблему, то с вероятностью 70% Валера уволится. На замену джависта компания потратит примерно $15K. Это анализ риска.
3️⃣ Затем ПМ прикинет варианты решения. Дать Валере других задач или, быть может, перевести на другой проект. А если Валера не вписался в коллектив, и код его так себе, то, может, и нафиг Валеру?
4️⃣ Предположим, другие задачи и проект Валеру не впечатлят, и он решит уйти. Как к этому заранее подготовиться? Потянет ли второй джавист Леша весь проект? Где быстро раздобыть замену? Как дела с документацией? Этот и предыдущий пункты называют смягчение (mitigation) риска.
5️⃣ Валера теперь под прицелом. ПМ будет наблюдать его настроение пристальнее обычного и встречаться с ним раз в неделю. Это мониторинг риска.
Все эти рассуждения ^^ обычно складывают в специальную табличку - реестр рисков. Она создает дополнительный контекст для вашего менеджера или клиента. Им будет чуть понятнее, что происходит на проекте. А в случае пожара можно продемонстрировать свою дальновидность и сказать "я же предупреждал!".
Честно говоря, я часто забиваю и не веду этот реестр. В продуктовых компаниях с плоской структурой, где ПМ репортает СТО, CPO или CEO, можно без него обойтись. Но если не чувствуете хорошей, доверительной культуры - лучше вести.
Напоследок расскажу о планировании рисков. Это когда перед стартом проекта все садятся и придумывают все возможные неприятности, которые могут случиться с проектом. То есть прорабатывают заранее план, что делать, если Валера захочет свинтить.
Вот и весь риск-менеджмент.
О риск-менеджменте принято говорить шепотом, как о неприлично сложной науке, доступной только тем, кто читал PMBOK. На деле любой ПМ работает с рисками каждый день.
Объясню на примере.
Представим, джависта Валеру, который в последнее время стал больше материться и ходит какой-то грустный. Производительность пока не упала, но с ним явно что-то не так.
Хороший ПМ увидит в этом потенциальную проблему и пойдет ее решать:
1️⃣ Вспомнит, что Валера говорил на последних ретрах. Какие из его задач были самыми грустными. Проведет 1-1 и выяснит, что Валера устал от проекта за 3 года, но пока еще не созрел уходить. Это идентификация риска.
2️⃣ Если забить на проблему, то с вероятностью 70% Валера уволится. На замену джависта компания потратит примерно $15K. Это анализ риска.
3️⃣ Затем ПМ прикинет варианты решения. Дать Валере других задач или, быть может, перевести на другой проект. А если Валера не вписался в коллектив, и код его так себе, то, может, и нафиг Валеру?
4️⃣ Предположим, другие задачи и проект Валеру не впечатлят, и он решит уйти. Как к этому заранее подготовиться? Потянет ли второй джавист Леша весь проект? Где быстро раздобыть замену? Как дела с документацией? Этот и предыдущий пункты называют смягчение (mitigation) риска.
5️⃣ Валера теперь под прицелом. ПМ будет наблюдать его настроение пристальнее обычного и встречаться с ним раз в неделю. Это мониторинг риска.
Все эти рассуждения ^^ обычно складывают в специальную табличку - реестр рисков. Она создает дополнительный контекст для вашего менеджера или клиента. Им будет чуть понятнее, что происходит на проекте. А в случае пожара можно продемонстрировать свою дальновидность и сказать "я же предупреждал!".
Честно говоря, я часто забиваю и не веду этот реестр. В продуктовых компаниях с плоской структурой, где ПМ репортает СТО, CPO или CEO, можно без него обойтись. Но если не чувствуете хорошей, доверительной культуры - лучше вести.
Напоследок расскажу о планировании рисков. Это когда перед стартом проекта все садятся и придумывают все возможные неприятности, которые могут случиться с проектом. То есть прорабатывают заранее план, что делать, если Валера захочет свинтить.
Вот и весь риск-менеджмент.
Пример джира тикета
Я оформляю задачи вот так. Поясню некоторые поля:
🏷️ Goal + Affected metrics - зачем мы это делаем и на что повлияет.
🏷️ Description - подробное описание, как работает фича, расписан флоу, как работает каждая кнопка.
🏷️ Acceptance Criteria (AC) - главные сценарии, которые надо сделать, чтобы считать задачу выполненной.
🏷️ Subtask - декомпозиция.
🏷️ Time tracking - начальная оценка в часах, сколько времени потратили + есть ли вылет.
🏷️ Assignee - кто сейчас занимается задачей.
🏷️ Development - подтягивает ссылки на коммиты и ветки, удобна фича для разработчиков.
🏷️ Labels - использую для фильтрации на разные темы. Например, фича для клиента (Chingari), к какой части системы относится (FAR-effects), делаем доп. контрактом (CR).
🏷️ Epic link - ссылка на эпик (разбивка системы большими мазками).
🏷️ Fix version - в какой релиз войдет.
--------------------------------
А вы какие поля еще используете?
Я оформляю задачи вот так. Поясню некоторые поля:
🏷️ Goal + Affected metrics - зачем мы это делаем и на что повлияет.
🏷️ Description - подробное описание, как работает фича, расписан флоу, как работает каждая кнопка.
🏷️ Acceptance Criteria (AC) - главные сценарии, которые надо сделать, чтобы считать задачу выполненной.
🏷️ Subtask - декомпозиция.
🏷️ Time tracking - начальная оценка в часах, сколько времени потратили + есть ли вылет.
🏷️ Assignee - кто сейчас занимается задачей.
🏷️ Development - подтягивает ссылки на коммиты и ветки, удобна фича для разработчиков.
🏷️ Labels - использую для фильтрации на разные темы. Например, фича для клиента (Chingari), к какой части системы относится (FAR-effects), делаем доп. контрактом (CR).
🏷️ Epic link - ссылка на эпик (разбивка системы большими мазками).
🏷️ Fix version - в какой релиз войдет.
--------------------------------
А вы какие поля еще используете?
Тестовые данные на проде
Однажды я искал дальних родственников на сайте кладбища.
Ради фана вбил в урл
Через нее можно было скачать всю базу с захоронениями, добавить или удалить кого-то. Ну или поменять админский пароль на более сложный.
Разблокировав ачивку cool hacker, я написал разработчикам с левого имейла (они не ответили).
Было видно, что сайт сделан на коленке и наверняка создатели решали более мирские проблемы гос. заказов. Например, сдать проект в срок с оговоренными фичами и не сильно уйти в минус. Да, у проектов не всегда есть бюджет на супер секьюрити, но поставить сложный пароль ничего не стоит.
❗На всякий случай спросите сегодня у тестеров, какие креденшелы на вашем проде.
И будьте осторожны с тестовыми данными. Подумайте, как они могут повлиять на реальных пользователей. Что с их помощью можно сделать, как навредить вашей системе или бизнесу.
Недавно в одном сервисе я ввел промокод test на чекауте и получил год подписки бесплатно (+ coolhacker lvl2). Т.е. для компаний такие косяки могут иметь вполне измеримую стоимость.
Однажды я искал дальних родственников на сайте кладбища.
Ради фана вбил в урл
/admin. Открылась страница с логином. Недолго думая я ввел admin, admin и....открылась админка.Через нее можно было скачать всю базу с захоронениями, добавить или удалить кого-то. Ну или поменять админский пароль на более сложный.
Разблокировав ачивку cool hacker, я написал разработчикам с левого имейла (они не ответили).
Было видно, что сайт сделан на коленке и наверняка создатели решали более мирские проблемы гос. заказов. Например, сдать проект в срок с оговоренными фичами и не сильно уйти в минус. Да, у проектов не всегда есть бюджет на супер секьюрити, но поставить сложный пароль ничего не стоит.
❗На всякий случай спросите сегодня у тестеров, какие креденшелы на вашем проде.
И будьте осторожны с тестовыми данными. Подумайте, как они могут повлиять на реальных пользователей. Что с их помощью можно сделать, как навредить вашей системе или бизнесу.
Недавно в одном сервисе я ввел промокод test на чекауте и получил год подписки бесплатно (+ coolhacker lvl2). Т.е. для компаний такие косяки могут иметь вполне измеримую стоимость.