Always assume a positive intent
В презентации что общего у IT компании и плесени (!) встретил вот эту картинку (внизу). Такая жиза!
Периодически ловлю себя на том, что виню других людей за то, что не вписались в какие-то мои ожидания (не только по работе). Хотя мои ожидания - это моя проблема. Сложно полностью избавиться от этого паттерна, но радует, что хотя бы делаю так все реже с каждым годом.
Например, если разработчик обещал задачу ко вторнику, а уже пятница, он виноват? Наверное, но сперва, какой у этой истории контекст?
Предупредил ли он, что не успевает? По силам ли была ему эта задача? Живет ли он в зоне боевых действий?
Как менеджеры, мы можем лишь косвенно влиять на результат. Мотивировать там, создавать условия и все такое. Но есть еще миллион обстоятельств, которые остается только принять.
Поэтому предлагаю по дефолту считать, что каждый разработчик сделал все, что мог, чтобы успеть ко вторнику. И уже дальше разбираться в этих обстоятельствах.
-------------------------------
На половине текста, вспомнил, что что уже писал такой пост 3 года назад 🙃.
В презентации что общего у IT компании и плесени (!) встретил вот эту картинку (внизу). Такая жиза!
Периодически ловлю себя на том, что виню других людей за то, что не вписались в какие-то мои ожидания (не только по работе). Хотя мои ожидания - это моя проблема. Сложно полностью избавиться от этого паттерна, но радует, что хотя бы делаю так все реже с каждым годом.
Например, если разработчик обещал задачу ко вторнику, а уже пятница, он виноват? Наверное, но сперва, какой у этой истории контекст?
Предупредил ли он, что не успевает? По силам ли была ему эта задача? Живет ли он в зоне боевых действий?
Как менеджеры, мы можем лишь косвенно влиять на результат. Мотивировать там, создавать условия и все такое. Но есть еще миллион обстоятельств, которые остается только принять.
Поэтому предлагаю по дефолту считать, что каждый разработчик сделал все, что мог, чтобы успеть ко вторнику. И уже дальше разбираться в этих обстоятельствах.
-------------------------------
На половине текста, вспомнил, что что уже писал такой пост 3 года назад 🙃.
Саббатикал
Недавно я завершил работу в Banuba. Это были отличные 2 года, с хорошими результатами для меня и для компании. Точно буду скучать по команде, ребята, вы крутые!! 💪
Честно говоря, за 9 лет работы в IT я банально устал, поэтому планировал отдохнуть хотя бы пару месяцев.
Но привычка чем-то заниматься не отпускает и я постоянно ищу себе дела. Уже на третий день был составлен список целей саббатикала 😁. Всегда были какие-то идеи, которые хотелось попробовать, и, кажется, сейчас это время пришло.
Об одной из них расскажу в следующем посте.
Недавно я завершил работу в Banuba. Это были отличные 2 года, с хорошими результатами для меня и для компании. Точно буду скучать по команде, ребята, вы крутые!! 💪
Честно говоря, за 9 лет работы в IT я банально устал, поэтому планировал отдохнуть хотя бы пару месяцев.
Но привычка чем-то заниматься не отпускает и я постоянно ищу себе дела. Уже на третий день был составлен список целей саббатикала 😁. Всегда были какие-то идеи, которые хотелось попробовать, и, кажется, сейчас это время пришло.
Об одной из них расскажу в следующем посте.
Запускаю новый проект - PM совет
Когда я начинал работать менеджером, мне очень не хватало обратной связи. Как другие менеджеры проводят звонки? Что конкретно делают, когда горят сроки? Банально, как ведут джиру и беклог? Тестировщиков и программистов на проекте обычно несколько, можно подсматривать у коллег, но как быть менеджеру?
Ответ я получил на третьей работе, где был классный отдел ПМО. Раз в неделю все менеджеры компании собирались в одной комнате и разбирали недавние сложные кейсы. На настоящих проектах! Это очень бустануло мой рост.
Теперь я запускаю такой ПМО по подписке - PM совет. И приглашаю вас в него 🌝
Задача совета - натренировать нейронку по принятию решений. А тренироваться будем на реальных ситуациях из жизни ПМов - ваших.
Приносите сложные письма, проблемы с ретры, конфликты внутри команды - все, с чем были вопросы на работе. Каждую неделю будем собирать темы от участников совета и разбирать их все вместе в прямом эфире. Что было, как решили, какой был результат. Только практические вопросы, никаких скучных лекций.
📅 Первый сбор на следующей неделе. В июне будет 2 бесплатные группы, одна для мидлов и одна для джуниоров. А дальше посмотрим, как пойдет. Вступай в группу ПМ совет, все орг. детали будут там.
Темы первой встречи:
1. Клиент прислал вот такое письмо. Как ответить?
2. Сделаем разбивку и оценку фичи лайки в телеграме.
Приходите!
UPD: разбор этих кейсов https://yangx.top/pm_sovet/19
Когда я начинал работать менеджером, мне очень не хватало обратной связи. Как другие менеджеры проводят звонки? Что конкретно делают, когда горят сроки? Банально, как ведут джиру и беклог? Тестировщиков и программистов на проекте обычно несколько, можно подсматривать у коллег, но как быть менеджеру?
Ответ я получил на третьей работе, где был классный отдел ПМО. Раз в неделю все менеджеры компании собирались в одной комнате и разбирали недавние сложные кейсы. На настоящих проектах! Это очень бустануло мой рост.
Теперь я запускаю такой ПМО по подписке - PM совет. И приглашаю вас в него 🌝
Задача совета - натренировать нейронку по принятию решений. А тренироваться будем на реальных ситуациях из жизни ПМов - ваших.
Приносите сложные письма, проблемы с ретры, конфликты внутри команды - все, с чем были вопросы на работе. Каждую неделю будем собирать темы от участников совета и разбирать их все вместе в прямом эфире. Что было, как решили, какой был результат. Только практические вопросы, никаких скучных лекций.
📅 Первый сбор на следующей неделе. В июне будет 2 бесплатные группы, одна для мидлов и одна для джуниоров. А дальше посмотрим, как пойдет. Вступай в группу ПМ совет, все орг. детали будут там.
Темы первой встречи:
1. Клиент прислал вот такое письмо. Как ответить?
2. Сделаем разбивку и оценку фичи лайки в телеграме.
Приходите!
UPD: разбор этих кейсов https://yangx.top/pm_sovet/19
Нужно больше прикола
Считаю, что в работе должно быть немного прикола, чтобы было нескучно жить. Делегировать прикол отделу hr нельзя. Создавать его надо самостоятельно, никто за нас с вами веселиться не будет 🙃.
Например, на прошлой работе мы называли релизы в честь групп, по алфавиту. То есть, сейчас релиз 1.17_Radiohead, а за ним будет 1.18_Scorpions. Другая команда называла спринты в честь мемов недели, типо 129-Богдан-богом-дан.
Еще один раз мы делали клиенту фичу караоке. Он был из Франции, поэтому на мокапы поместили песню Джо Дассена и я ее как будто пел. Клиент поржал.
Мой друг устроился в берлинский стартап и рассказывал, что у них там на онбординге положено отыграть сколько-то часов в among us!
Такие приколы особенно полезны в новых командах, где люди еще не успели толком узнать друг друга. Помогает разбить лед и "сколотить банду" из просто отдельных личностей. А еще полезно тем, кто пишет црм-ки и банковское ПО (ха-ха).
А какие у вас на работе приколы?
Считаю, что в работе должно быть немного прикола, чтобы было нескучно жить. Делегировать прикол отделу hr нельзя. Создавать его надо самостоятельно, никто за нас с вами веселиться не будет 🙃.
Например, на прошлой работе мы называли релизы в честь групп, по алфавиту. То есть, сейчас релиз 1.17_Radiohead, а за ним будет 1.18_Scorpions. Другая команда называла спринты в честь мемов недели, типо 129-Богдан-богом-дан.
Еще один раз мы делали клиенту фичу караоке. Он был из Франции, поэтому на мокапы поместили песню Джо Дассена и я ее как будто пел. Клиент поржал.
Мой друг устроился в берлинский стартап и рассказывал, что у них там на онбординге положено отыграть сколько-то часов в among us!
Такие приколы особенно полезны в новых командах, где люди еще не успели толком узнать друг друга. Помогает разбить лед и "сколотить банду" из просто отдельных личностей. А еще полезно тем, кто пишет црм-ки и банковское ПО (ха-ха).
А какие у вас на работе приколы?
Кейс про загрузку дизайнера
Вы работаете менеджером в продукте по доставке еды из ресторанов. Ваша команда пилит админку для вендоров: добавление блюд, обработка заказов и так далее. Дела идут хорошо, бизнес растет, все довольны.
Недавно вы наняли дизайнера Олю на фуллтайм. Она уже прошла испыт и показала себя с лучшей стороны: дизайны шикарные, всегда в срок, правок мало. Сейчас ваша работа выглядит так:
- вы делаете пользовательские интервью и очень кратко описываете цель задачи;
- Оля отрисовывает по ним интерфейс;
- QA, вы или Оля пишете детальное описание юзер-стори для разработчиков;
На квартальном планировании ваш CPO сильно скорректировал роудмап. Следующие 3 месяца будет упор на интеграции с партнерами. Будущие проекты поменялись, стало больше бекендовых задач, а интерфейсные сократились. Загрузить Олю на фуллтайм точно не хватит. У вас есть предположение, что и через квартал будет похожая картина.
В ваши обязанности входит ресурсная часть: найм, увольнение, распределение по проектам. Что будете делать?
Пишите варианты в комментарии.
--------------------------
P.S. В этом кейсе несколько путей решения, поэтому варианты ответа не добавлял.
Вы работаете менеджером в продукте по доставке еды из ресторанов. Ваша команда пилит админку для вендоров: добавление блюд, обработка заказов и так далее. Дела идут хорошо, бизнес растет, все довольны.
Недавно вы наняли дизайнера Олю на фуллтайм. Она уже прошла испыт и показала себя с лучшей стороны: дизайны шикарные, всегда в срок, правок мало. Сейчас ваша работа выглядит так:
- вы делаете пользовательские интервью и очень кратко описываете цель задачи;
- Оля отрисовывает по ним интерфейс;
- QA, вы или Оля пишете детальное описание юзер-стори для разработчиков;
На квартальном планировании ваш CPO сильно скорректировал роудмап. Следующие 3 месяца будет упор на интеграции с партнерами. Будущие проекты поменялись, стало больше бекендовых задач, а интерфейсные сократились. Загрузить Олю на фуллтайм точно не хватит. У вас есть предположение, что и через квартал будет похожая картина.
В ваши обязанности входит ресурсная часть: найм, увольнение, распределение по проектам. Что будете делать?
Пишите варианты в комментарии.
--------------------------
P.S. В этом кейсе несколько путей решения, поэтому варианты ответа не добавлял.
Решение - Кейс про загрузку дизайнера
Сперва стоит поговорить с CPO, что стало со старым роудмапом, где было много проектов с дизайном. Вдруг они через 3 месяца вернутся? А может их вообще больше не будет, и дизайнер команде уже не понадобится? Ответ на этот вопрос даст контекст для долгосрочного решения.
Если задач все еще мало, нужно честно рассказать Оле о ситуации. Любой вариант развития событий сильно влияет на ее работу. И наверняка не совпадает с вашими первоначальными договоренностями. Поэтому сначала объясняем ситуацию и смотрим на Олину реакцию. Если она конструктивная и адекватная, очень вероятно, что Оля сама предложит решение, сняв с вас эту задачу 😎. Например, скажет, "ой, хорошо, что так совпало, я вообще-то собиралась уходить". Или предложит какой-то из вариантов ниже:
1. Дать Оле других задач, которые делает команда. Пользовательские интервью, которые сейчас проводите вы, или описание требований, которые делает кто придется - хороший вариант для старта, т.к. Оля уже работает "рядом" с этими задачами. Профит даже двойной: у кого-то из команды освободится немного времени, а Оля прокачает новый скилл. Как верно заметили в комментариях, сначала узнаем, кем Оля хочет стать, когда вырастет и ищем подходящие задачи. Наверняка это будут около продуктовые активности.
2. Дать Оле других задач, за пределами вашей команды. Помните, дела у продукта идут хорошо, скорее всего компания растет и работы больше, чем людей. Спросите соседние проекты, нужен ли кому-то сильный дизайнер на парт тайм. Опять же, сперва спрашиваем Олю ОК ли ей такой вариант. Начать можно с команды, которая помогает продвигать ваш же продукт: рисовать баннеры, лендинги и картинки для соцсетей (не очень актуально для этого кейса с админкой, но для другого пойдет). Так и Оля останется в контексте продукта и вы больше выиграете. Другой неплохой вариант - дать Оле прокачивать джуна.
3. Перевести на парт тайм. Можно предложить Оле сократить ее рабочие часы и зп. Это устранит проблему частичного простоя. Но вместе с тем, компания рискует потерять и вторую половину сильного дизайнера. Если Оля живет на Бали, или гуру во фрилансе, то далеко не факт, что потом вы сможете вернуть ее на прежние условия. К тому же, сейчас у вас есть выделенный бюджет на зп для Оли. Его тоже можно лишиться.
4. Последний вариант, когда перепробовали все - уволить Олю. Возможно, компания ошиблась и ей не нужен сейчас дизайнер, такое тоже бывает. Важно признать ошибку и сделать все, чтобы компенсировать потери для Оли. Все-таки мы взяли обязательство обеспечить ее работой, закрыв ей испытательный срок. Можно порекламировать Олю знакомым компаниям, написать ей отзыв на линкедин, и, конечно, дать денежную компенсацию.
Хороший пункт из комментариев (спасибо за них!):
Вероятно, изменения в проектах, вероятно, коснутся не только Олю, но и разработчиков клиентских приложений (веб, мобайл). Стоит проверить, что теперь с их загрузкой.
Сперва стоит поговорить с CPO, что стало со старым роудмапом, где было много проектов с дизайном. Вдруг они через 3 месяца вернутся? А может их вообще больше не будет, и дизайнер команде уже не понадобится? Ответ на этот вопрос даст контекст для долгосрочного решения.
Если задач все еще мало, нужно честно рассказать Оле о ситуации. Любой вариант развития событий сильно влияет на ее работу. И наверняка не совпадает с вашими первоначальными договоренностями. Поэтому сначала объясняем ситуацию и смотрим на Олину реакцию. Если она конструктивная и адекватная, очень вероятно, что Оля сама предложит решение, сняв с вас эту задачу 😎. Например, скажет, "ой, хорошо, что так совпало, я вообще-то собиралась уходить". Или предложит какой-то из вариантов ниже:
1. Дать Оле других задач, которые делает команда. Пользовательские интервью, которые сейчас проводите вы, или описание требований, которые делает кто придется - хороший вариант для старта, т.к. Оля уже работает "рядом" с этими задачами. Профит даже двойной: у кого-то из команды освободится немного времени, а Оля прокачает новый скилл. Как верно заметили в комментариях, сначала узнаем, кем Оля хочет стать, когда вырастет и ищем подходящие задачи. Наверняка это будут около продуктовые активности.
2. Дать Оле других задач, за пределами вашей команды. Помните, дела у продукта идут хорошо, скорее всего компания растет и работы больше, чем людей. Спросите соседние проекты, нужен ли кому-то сильный дизайнер на парт тайм. Опять же, сперва спрашиваем Олю ОК ли ей такой вариант. Начать можно с команды, которая помогает продвигать ваш же продукт: рисовать баннеры, лендинги и картинки для соцсетей (не очень актуально для этого кейса с админкой, но для другого пойдет). Так и Оля останется в контексте продукта и вы больше выиграете. Другой неплохой вариант - дать Оле прокачивать джуна.
3. Перевести на парт тайм. Можно предложить Оле сократить ее рабочие часы и зп. Это устранит проблему частичного простоя. Но вместе с тем, компания рискует потерять и вторую половину сильного дизайнера. Если Оля живет на Бали, или гуру во фрилансе, то далеко не факт, что потом вы сможете вернуть ее на прежние условия. К тому же, сейчас у вас есть выделенный бюджет на зп для Оли. Его тоже можно лишиться.
4. Последний вариант, когда перепробовали все - уволить Олю. Возможно, компания ошиблась и ей не нужен сейчас дизайнер, такое тоже бывает. Важно признать ошибку и сделать все, чтобы компенсировать потери для Оли. Все-таки мы взяли обязательство обеспечить ее работой, закрыв ей испытательный срок. Можно порекламировать Олю знакомым компаниям, написать ей отзыв на линкедин, и, конечно, дать денежную компенсацию.
Хороший пункт из комментариев (спасибо за них!):
Вероятно, изменения в проектах, вероятно, коснутся не только Олю, но и разработчиков клиентских приложений (веб, мобайл). Стоит проверить, что теперь с их загрузкой.
Как пишут большие продукты
Представьте очень большой продукт, например, amazon.com. Над ним работают сотни команд, выкатывая новые фичи каждый день. Как столько людей контрибьютят в один проект? Давайте посмотрим как это устроено.
Общий принцип дизайна больших проектов - разделить их на независимые составные части. Тогда за каждую часть может отвечать одна команда (или группа команд).
В упрощенном виде сайт амазона, который видят обычные покупатели, можно разделить на такие части:
- каталог
- поиск
- карточка товара
- корзина
- оплата
- доставка
- поддержка
За каждой из них будет стоять своя команда со своими метриками. Например, команда "карточка товара" отвечает за конверсию в корзину. Главное для нее - чтобы пользователь нажал на кнопку "добавить в корзину", ̶а̶ ̶д̶а̶л̶ь̶ш̶е̶ ̶х̶о̶т̶ь̶ ̶т̶р̶а̶в̶а̶ ̶н̶е̶ ̶р̶а̶с̶т̶и̶. А дальше действовать будет команда "корзина", у которой свои метрики, интересы и подход.
Конечно, на уровне департамента весь процесс собирается в какой-то узел "покупка", за который отвечает директор-по-конверсии-в-покупку. Но сами команды между собой слабо связаны, именно потому, что каждый отвечает за свой маленький кусочек. Это позволяет команде не тонуть в зависимостях и делать поставку быстро.
Каждая из них будет истово оптимизировать свои метрики. На таком скейле это действительно оправдано. Представьте, сколько денег можно сэкономить на инфраструктуре, сжав фотки всех товаров всего на 5% 🤑
С технической точки зрения такое разделение часто реализовывают в виде микросервисной архитектуры. У команды "карточка товара" есть свой репозиторий, куда она комитит свой только код. Есть отдельный сервер, где лежат картинки товаров и ничего больше. Есть изолированный АПИ сервис, единственная задача которого - отдавать описание товара. Так каждый кусочек сайта получается независимым и атомарным. И все счастливы.
---------------------------------
P.S. В этом примере я, конечно, все сильно упростил. В масштабе Амазона за карточку товара будет отвечать целый отдел с десятком команд. Одна команда пишет сервис по загрузке, обработке и хранению картинок. Другая - отзывы. Третья - рекомендации товаров. Четвертая - рейтинг. Пятая - рассчитывает сроки доставки.
Но это еще не все картинка. Такая большая структура делится на несколько отделов или линий бизнеса (line of business). Это такие компании внутри компании, каждая со своими процессами, бюджетами, наймом и так далее. В екоме они обычно такие:
1. пользовательские продукты - приложение, сайт, лендинги с акциями
2. б2б - админка продавцов
3. логистика - доставка, склады, остатки
4. коммерция - продажи, цены, товары
На картинке - скольким командам можно передать привет, открыв страницу товара.
Представьте очень большой продукт, например, amazon.com. Над ним работают сотни команд, выкатывая новые фичи каждый день. Как столько людей контрибьютят в один проект? Давайте посмотрим как это устроено.
Общий принцип дизайна больших проектов - разделить их на независимые составные части. Тогда за каждую часть может отвечать одна команда (или группа команд).
В упрощенном виде сайт амазона, который видят обычные покупатели, можно разделить на такие части:
- каталог
- поиск
- карточка товара
- корзина
- оплата
- доставка
- поддержка
За каждой из них будет стоять своя команда со своими метриками. Например, команда "карточка товара" отвечает за конверсию в корзину. Главное для нее - чтобы пользователь нажал на кнопку "добавить в корзину", ̶а̶ ̶д̶а̶л̶ь̶ш̶е̶ ̶х̶о̶т̶ь̶ ̶т̶р̶а̶в̶а̶ ̶н̶е̶ ̶р̶а̶с̶т̶и̶. А дальше действовать будет команда "корзина", у которой свои метрики, интересы и подход.
Конечно, на уровне департамента весь процесс собирается в какой-то узел "покупка", за который отвечает директор-по-конверсии-в-покупку. Но сами команды между собой слабо связаны, именно потому, что каждый отвечает за свой маленький кусочек. Это позволяет команде не тонуть в зависимостях и делать поставку быстро.
Каждая из них будет истово оптимизировать свои метрики. На таком скейле это действительно оправдано. Представьте, сколько денег можно сэкономить на инфраструктуре, сжав фотки всех товаров всего на 5% 🤑
С технической точки зрения такое разделение часто реализовывают в виде микросервисной архитектуры. У команды "карточка товара" есть свой репозиторий, куда она комитит свой только код. Есть отдельный сервер, где лежат картинки товаров и ничего больше. Есть изолированный АПИ сервис, единственная задача которого - отдавать описание товара. Так каждый кусочек сайта получается независимым и атомарным. И все счастливы.
---------------------------------
P.S. В этом примере я, конечно, все сильно упростил. В масштабе Амазона за карточку товара будет отвечать целый отдел с десятком команд. Одна команда пишет сервис по загрузке, обработке и хранению картинок. Другая - отзывы. Третья - рекомендации товаров. Четвертая - рейтинг. Пятая - рассчитывает сроки доставки.
Но это еще не все картинка. Такая большая структура делится на несколько отделов или линий бизнеса (line of business). Это такие компании внутри компании, каждая со своими процессами, бюджетами, наймом и так далее. В екоме они обычно такие:
1. пользовательские продукты - приложение, сайт, лендинги с акциями
2. б2б - админка продавцов
3. логистика - доставка, склады, остатки
4. коммерция - продажи, цены, товары
На картинке - скольким командам можно передать привет, открыв страницу товара.
Помогу настроить вашу разработку
Заходя в новые команды я часто вижу похожие, повторяющиеся проблемы. Топ-3 самых частых:
✖️ Задачи не сдаются в срок, релизы срываются.
✖️ Бизнес и разработка живут в "параллельных мирах". Например, просят одну фичу, а на выходе получается другая.
✖️ Компания выросла с 5 человек до 50 за короткий срок, и работать по-старому уже не получается. Раньше разработка была быстрой, а теперь что-то буксует.
Для всех этих проблем, есть свои "лекарства", и на словах они звучат вроде бы просто. Но на деле у каждой компаний свой контекст и обстоятельства. Тут легаси такое, что оценивать задачи невозможно. Там продакт закрывает весь маркетинг и не успевает готовить точные требования. Поэтому изменения "в лоб" идут тяжело.
Если звучит знакомо, то у меня для вас хорошие новости.
Теперь меня можно нанять, чтобы починить проблемы в разработке. Я въеду в ваш контекст, найду проблемы и помогу их решить.
Выглядит это так. Я изучаю вашу джиру, гитхаб, процессы, хожу с командой на все митинги, разговариваю с лидами, менеджером и бизнесом. Через месяц делаю отчет, где описываю главные проблемы, которые мешают вам быстро деливерить. Для каждой еще будет подробное решение, как ее устранить.
Если понравится, то могу задержаться и навести порядок вместе с командой. Хотя с инструкцией вы легко справитесь и своими силами.
Это не единственный способ поработать вместе, если у вас есть другая идея или запрос - пишите в лс, обсудим!
Заходя в новые команды я часто вижу похожие, повторяющиеся проблемы. Топ-3 самых частых:
✖️ Задачи не сдаются в срок, релизы срываются.
✖️ Бизнес и разработка живут в "параллельных мирах". Например, просят одну фичу, а на выходе получается другая.
✖️ Компания выросла с 5 человек до 50 за короткий срок, и работать по-старому уже не получается. Раньше разработка была быстрой, а теперь что-то буксует.
Для всех этих проблем, есть свои "лекарства", и на словах они звучат вроде бы просто. Но на деле у каждой компаний свой контекст и обстоятельства. Тут легаси такое, что оценивать задачи невозможно. Там продакт закрывает весь маркетинг и не успевает готовить точные требования. Поэтому изменения "в лоб" идут тяжело.
Если звучит знакомо, то у меня для вас хорошие новости.
Теперь меня можно нанять, чтобы починить проблемы в разработке. Я въеду в ваш контекст, найду проблемы и помогу их решить.
Выглядит это так. Я изучаю вашу джиру, гитхаб, процессы, хожу с командой на все митинги, разговариваю с лидами, менеджером и бизнесом. Через месяц делаю отчет, где описываю главные проблемы, которые мешают вам быстро деливерить. Для каждой еще будет подробное решение, как ее устранить.
Если понравится, то могу задержаться и навести порядок вместе с командой. Хотя с инструкцией вы легко справитесь и своими силами.
Это не единственный способ поработать вместе, если у вас есть другая идея или запрос - пишите в лс, обсудим!
kavaleuski.me
Роман Ковалевский - деливери менеджер
Роман Ковалевский - деливери менеджер, автор канала @pm_god, консультант по разработке
🙏 Просьба к читателям:
Если вам нравится этот канал, и у вас есть компании, которым вы можете порекомендовать меня - пожалуйста, отправьте им этот пост или мой сайт 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 или эджайловые сертификаты. Думаю, пригодится.
Удачи на тесте!