ПМ году 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). Т.е. для компаний такие косяки могут иметь вполне измеримую стоимость.
Шаблон для пулл реквестов
В проектах, где я работал, обычно были лайтовые правила по оформлению пулл-реквестов. Добавить ссылку на тикет, короткое описание и погнали. Если еще написать что изменили, то на следующем ревью получишь сеньора.
У ребят из Soundcloud процессы на высоте, они придумали целую систему и заполняют:
📌 описание задачи
📌 детали реализации (тут порефакторили, там добавили новое поле в базу)
📌 скриншот до\после
📌 как тестировать
Это очень хорошие вопросы, о которых надо позаботиться заранее. Без шагов по тестированию QA тратят кучу времени на разбор задачи. А без деталей реализации тимлид долго въезжает в код ревью.
С таким подходом ПРы становятся более предсказуемыми и команда закрывает задачи быстрее, снижая cycle time.
Самое крутое, что есть настройка, чтобы ПР автоматически предзаполнялись этими полями. То есть нажал "открыть ПР" и эти заголовки уже тут, осталось только внести контент.
Это, конечно, автоматизация, но еще и прикольный психологический трюк. Если в команде есть такой джава-пират, который плевать хотел на правила, то чтобы их нарушить, ему придется прям брать и ручками удалять эти заголовки из пулл-реквеста.
В проектах, где я работал, обычно были лайтовые правила по оформлению пулл-реквестов. Добавить ссылку на тикет, короткое описание и погнали. Если еще написать что изменили, то на следующем ревью получишь сеньора.
У ребят из Soundcloud процессы на высоте, они придумали целую систему и заполняют:
📌 описание задачи
📌 детали реализации (тут порефакторили, там добавили новое поле в базу)
📌 скриншот до\после
📌 как тестировать
Это очень хорошие вопросы, о которых надо позаботиться заранее. Без шагов по тестированию QA тратят кучу времени на разбор задачи. А без деталей реализации тимлид долго въезжает в код ревью.
С таким подходом ПРы становятся более предсказуемыми и команда закрывает задачи быстрее, снижая cycle time.
Самое крутое, что есть настройка, чтобы ПР автоматически предзаполнялись этими полями. То есть нажал "открыть ПР" и эти заголовки уже тут, осталось только внести контент.
Это, конечно, автоматизация, но еще и прикольный психологический трюк. Если в команде есть такой джава-пират, который плевать хотел на правила, то чтобы их нарушить, ему придется прям брать и ручками удалять эти заголовки из пулл-реквеста.
Работа ПМ в период войны, протестов, мобилизации
В России очередной виток пиздеца. При этом наша с вами работа никуда не делась. От нас по-прежнему ждут релизы, роудмапы и новые фичи.
В 20 году беларусские менеджеры прошли через другой, но тоже пиздец. Хочу поделиться несколькими советами, которые помогли нам его пережить:
📌 Объясните вашим клиентам, заказчикам и стейкхолдерам, что скорость снизится. Важно не развести руками, мол, извините у нас война, а показать план действий. Есть вот такие-то замены, этот скоуп подсократим, компания делает 1,2,3, чтобы вернуться на прежнюю скорость.
📌 У каждого проекта есть ключевые люди, без которых все ляжет. Если их не перевезли после 24 февраля, спросите, не хотят ли теперь.
📌 Узнайте у руководства, какой глобальный план компании и чем вы можете помочь. Популярный вариант - открытие юрлица в другой стране и переезд. Будет много работы, связанной с организацией переезда, а это самое место для наших скиллов.
📌 HR ищут пропавших сотрудников, кто не отметился на дейли. А когда находят, то помогают вернуться в строй. Забрали на сутки, вручили повестку - hr про все в курсе, объясняет как себя вести, какие доки при себе иметь и так далее. Юристы проводят вебинары "что делать, если тебя задержали" и "что говорить в военкомате".
📌 Чаще созванивайтесь с командой. Обсуждайте пусть даже второстепенные, неважные вопросы, просто чтобы отвлечь людей от новостей. Вместе полегче.
Вашей команде сейчас нужен лидер. Уверенный голос, который расскажет какой будет план. Знаю, самому страшно, но вы справитесь. Вы же менеджер, я в вас верю.
В России очередной виток пиздеца. При этом наша с вами работа никуда не делась. От нас по-прежнему ждут релизы, роудмапы и новые фичи.
В 20 году беларусские менеджеры прошли через другой, но тоже пиздец. Хочу поделиться несколькими советами, которые помогли нам его пережить:
📌 Объясните вашим клиентам, заказчикам и стейкхолдерам, что скорость снизится. Важно не развести руками, мол, извините у нас война, а показать план действий. Есть вот такие-то замены, этот скоуп подсократим, компания делает 1,2,3, чтобы вернуться на прежнюю скорость.
📌 У каждого проекта есть ключевые люди, без которых все ляжет. Если их не перевезли после 24 февраля, спросите, не хотят ли теперь.
📌 Узнайте у руководства, какой глобальный план компании и чем вы можете помочь. Популярный вариант - открытие юрлица в другой стране и переезд. Будет много работы, связанной с организацией переезда, а это самое место для наших скиллов.
📌 HR ищут пропавших сотрудников, кто не отметился на дейли. А когда находят, то помогают вернуться в строй. Забрали на сутки, вручили повестку - hr про все в курсе, объясняет как себя вести, какие доки при себе иметь и так далее. Юристы проводят вебинары "что делать, если тебя задержали" и "что говорить в военкомате".
📌 Чаще созванивайтесь с командой. Обсуждайте пусть даже второстепенные, неважные вопросы, просто чтобы отвлечь людей от новостей. Вместе полегче.
Вашей команде сейчас нужен лидер. Уверенный голос, который расскажет какой будет план. Знаю, самому страшно, но вы справитесь. Вы же менеджер, я в вас верю.
How to speak tech
Раньше у меня было несколько дежурных советов как менеджеру (тестировщику, аналитику, дизайнеру) качать технические навыки.
Сегодня дополню еще одним - книгой How to speak tech.
Она о том, какие технологии работают в продуктах, которыми мы пользуемся каждый день. Написана специально для нетехнарей, очень понятным языком и всего 100+ страниц. При этом покрыты практически все темы, которые попадутся на работе. От самых простых (клиент-сервер, базы данных) до более сложных:
💾 Виды архитектуры: mvc и 3-tier architecture (вы точно где-то слышали эти слова).
💾 Почему все вокруг переписывают приложения на С (он такой шустрый, т.к. "разговаривает" с процессором сразу на понятном ему, машинном языке и моментально выполняется. А php сперва надо как бы "перевести" на этот машинный язык, и только потом выполнить).
💾 Минимум про безопасность: токены, юзер-сессия, sql инъекции, куки, умные урлы. Помните, как в ВК можно было смотреть скрытые фотки, т.к. все альбомы имели определённый урл-паттерн? Жаль они эту книгу не читали.
💾 Зачем переиспользовать код и готовые решения. Какие у этого плюсы (скорость разработки, экспертиза, дешевая поддержка) и минусы (неуправляемые зависимости, раскрытие данных, сложно кастомизировать).
💾 Что такое гитфлоу, все эти мерджи и пулл реквесты объясняют на молоке, яблоках и яйцах, типо закупаемся в магазине.
Если набрали мало баллов в тесте по тех. скиллам, то рекомендую прочитать.
Джуниор менеджеру нужно понимать хотя бы 30% книги. На 80+ вести проект будет комфортно.
Раньше у меня было несколько дежурных советов как менеджеру (тестировщику, аналитику, дизайнеру) качать технические навыки.
Сегодня дополню еще одним - книгой How to speak tech.
Она о том, какие технологии работают в продуктах, которыми мы пользуемся каждый день. Написана специально для нетехнарей, очень понятным языком и всего 100+ страниц. При этом покрыты практически все темы, которые попадутся на работе. От самых простых (клиент-сервер, базы данных) до более сложных:
💾 Виды архитектуры: mvc и 3-tier architecture (вы точно где-то слышали эти слова).
💾 Почему все вокруг переписывают приложения на С (он такой шустрый, т.к. "разговаривает" с процессором сразу на понятном ему, машинном языке и моментально выполняется. А php сперва надо как бы "перевести" на этот машинный язык, и только потом выполнить).
💾 Минимум про безопасность: токены, юзер-сессия, sql инъекции, куки, умные урлы. Помните, как в ВК можно было смотреть скрытые фотки, т.к. все альбомы имели определённый урл-паттерн? Жаль они эту книгу не читали.
💾 Зачем переиспользовать код и готовые решения. Какие у этого плюсы (скорость разработки, экспертиза, дешевая поддержка) и минусы (неуправляемые зависимости, раскрытие данных, сложно кастомизировать).
💾 Что такое гитфлоу, все эти мерджи и пулл реквесты объясняют на молоке, яблоках и яйцах, типо закупаемся в магазине.
Если набрали мало баллов в тесте по тех. скиллам, то рекомендую прочитать.
Джуниор менеджеру нужно понимать хотя бы 30% книги. На 80+ вести проект будет комфортно.
Кейс: тимлид просит +1К
Вы пишете приложение для фитнеса командой в 12 человек. Работаете через аутсорсинговую фирму, клиент с вами уже 2 года. Результатами он доволен, продукт окупает затраты на разработку, есть амбициозный роудмап.
Раз в год вы проводите перф. ревью для всех сеньоров. Но на этот раз тимлид пришел к вам раньше срока. С прошлого ревью прошло 8 месяцев, тогда вы подняли ему зп на 500$. Теперь он просит поднять еще на тысячу. Говорит, что походил по собесам, и местами предлагают даже на 1,500$ больше, чем сейчас.
Тимлид работает неплохо, хотя случаются и косяки. Местами команда вылетает за оценки на день-два, иногда пропускает 1-1 разработчиков. Вы бы хотели, чтобы тимлид прокачался в софт скиллах, т.к. некоторые встречи проходят напряженно. С другой стороны, большого криминала в его работе не замечено, основные вопросы тимлид закрывает хорошо.
С рейзом +1К, рентабельность проекта снизится. После повышения для тимлида она будет нулевой, т.е. компания не будет на нем (тимлиде) ни зарабатывать, ни терять.
Вы пишете приложение для фитнеса командой в 12 человек. Работаете через аутсорсинговую фирму, клиент с вами уже 2 года. Результатами он доволен, продукт окупает затраты на разработку, есть амбициозный роудмап.
Раз в год вы проводите перф. ревью для всех сеньоров. Но на этот раз тимлид пришел к вам раньше срока. С прошлого ревью прошло 8 месяцев, тогда вы подняли ему зп на 500$. Теперь он просит поднять еще на тысячу. Говорит, что походил по собесам, и местами предлагают даже на 1,500$ больше, чем сейчас.
Тимлид работает неплохо, хотя случаются и косяки. Местами команда вылетает за оценки на день-два, иногда пропускает 1-1 разработчиков. Вы бы хотели, чтобы тимлид прокачался в софт скиллах, т.к. некоторые встречи проходят напряженно. С другой стороны, большого криминала в его работе не замечено, основные вопросы тимлид закрывает хорошо.
С рейзом +1К, рентабельность проекта снизится. После повышения для тимлида она будет нулевой, т.е. компания не будет на нем (тимлиде) ни зарабатывать, ни терять.
Что будете делать c рейзом?
Anonymous Poll
10%
Не буду повышать. Объясню тимлиду про рентабельность и предложу дождаться следующего ревью
8%
Не буду повышать. Предложу исправить косяки, тогда и поговорим
76%
Повышу на 500 сейчас и еще на 500 через 4 месяца, если решит текущие проблемы
5%
Сразу повышу на 1К безо всяких условий
1%
Повышу на 1,5К, чтобы перебить конкурентов
Что будете делать с рентабельностью?
Anonymous Poll
14%
Сразу предложу клиенту компенсировать рост зп
76%
Подожду удобного момента, чтобы поднять ставки сразу для всей команды
10%
Ничего. Времена тяжелые, спасибо, что клиент вообще платит
Что будете делать c рейзом?
Выбрав вариант Предложу дождаться следующего ревью, тимлид с большой вероятностью уйдет.
Сейчас он получает ниже рынка и его запрос вполне справедлив. Он даже не просит максимум из того, что ему предлагают. Да, есть процесс пересмотра раз в год, но зачем ему столько ждать? Свою работу он делает хорошо (почти). Какое ему дело до процессов и бюрократии, когда он в одном шаге от хорошей прибавки? И тем более до рентабельности? Эти вопросы - не его забота.
Но готовы ли мы его потерять?
Разобраться помогут доп. вопросы, многие из которых вы предложили в комментариях (спасибо!):
- Есть ли среди сеньоров кто-то, кто хотел бы стать лидом?
- Поедет ли проект без этого лида, или он тащит команду?
- В каких отношениях заказчик с лидом, доволен ли непосредственно его работой? Будет ли ему больно потерять лида?
Учитывая, что проект идет 2 года, клиент доволен, и проект будет развиваться, я бы делал ставку на сохранение команды, чтобы играть ее экспертизой в долгую. То есть пытался оставить лида.
Вариант Предложу исправить косяки, тогда и поговорим немного лучше. За выслугу лет в ИТ не доплачивают. Зп растет, когда сотрудник повышает свои навыки, которые компания может "перепродать". Раз у тимлида есть косяки, резонно предложить ему их исправить, а после сделать рейз. Но вы все еще платите ниже рынка (это стоит проверить), поэтому большой шанс, что тимлид не согласится на этот вариант и уйдет. Ведь где-то его ждут соблазнительные +$1,500.
Я выбираю вариант 500+500. Вы показываете, что компания идет на диалог, и признает, что платите ниже рынка. И делает моментальную компенсацию, сразу исправляя свои ошибки. Отличный ход! Вы также признаете ценность тимлида, ведь основные вопросы он решает хорошо. При этом, обозначив косяки, вы показываете, что ему есть над чем работать. Пофиксил - держи свои +500, и ровно ту зп, которую и просил. Следующий пересмотр можно назначить через 4 месяца, чтобы формально соблюсти процесс годового ревью.
Хороший вариант, который тоже предложили в комментах - дать денег не в зп, а премией. Так, формально вы не нарушаете правила пересмотра, при этом лид получает свою надбавку.
В варианте Сразу повышу на 1К безо всяких условий тимлид придет через полгода еще раз и снова попросит рейз. А потом и другие члены команды подтянутся. Повышать так до бесконечности не даст бюджет, поэтому лучше привязывать пересмотр к новым обязанностям или скилам.
Вариант Повышу на 1,5К, чтобы перебить конкурентов сработает, если вы работаете в условном Нетфликсе. У них действительно есть такая политика моментально матчить зп, даже если сотрудник этого не просил. Но в обычной аутсорсинговой фирме, где борются за каждую копейку, это выстрел себе в ногу (точнее, в кошелек).
Выбрав вариант Предложу дождаться следующего ревью, тимлид с большой вероятностью уйдет.
Сейчас он получает ниже рынка и его запрос вполне справедлив. Он даже не просит максимум из того, что ему предлагают. Да, есть процесс пересмотра раз в год, но зачем ему столько ждать? Свою работу он делает хорошо (почти). Какое ему дело до процессов и бюрократии, когда он в одном шаге от хорошей прибавки? И тем более до рентабельности? Эти вопросы - не его забота.
Но готовы ли мы его потерять?
Разобраться помогут доп. вопросы, многие из которых вы предложили в комментариях (спасибо!):
- Есть ли среди сеньоров кто-то, кто хотел бы стать лидом?
- Поедет ли проект без этого лида, или он тащит команду?
- В каких отношениях заказчик с лидом, доволен ли непосредственно его работой? Будет ли ему больно потерять лида?
Учитывая, что проект идет 2 года, клиент доволен, и проект будет развиваться, я бы делал ставку на сохранение команды, чтобы играть ее экспертизой в долгую. То есть пытался оставить лида.
Вариант Предложу исправить косяки, тогда и поговорим немного лучше. За выслугу лет в ИТ не доплачивают. Зп растет, когда сотрудник повышает свои навыки, которые компания может "перепродать". Раз у тимлида есть косяки, резонно предложить ему их исправить, а после сделать рейз. Но вы все еще платите ниже рынка (это стоит проверить), поэтому большой шанс, что тимлид не согласится на этот вариант и уйдет. Ведь где-то его ждут соблазнительные +$1,500.
Я выбираю вариант 500+500. Вы показываете, что компания идет на диалог, и признает, что платите ниже рынка. И делает моментальную компенсацию, сразу исправляя свои ошибки. Отличный ход! Вы также признаете ценность тимлида, ведь основные вопросы он решает хорошо. При этом, обозначив косяки, вы показываете, что ему есть над чем работать. Пофиксил - держи свои +500, и ровно ту зп, которую и просил. Следующий пересмотр можно назначить через 4 месяца, чтобы формально соблюсти процесс годового ревью.
Хороший вариант, который тоже предложили в комментах - дать денег не в зп, а премией. Так, формально вы не нарушаете правила пересмотра, при этом лид получает свою надбавку.
В варианте Сразу повышу на 1К безо всяких условий тимлид придет через полгода еще раз и снова попросит рейз. А потом и другие члены команды подтянутся. Повышать так до бесконечности не даст бюджет, поэтому лучше привязывать пересмотр к новым обязанностям или скилам.
Вариант Повышу на 1,5К, чтобы перебить конкурентов сработает, если вы работаете в условном Нетфликсе. У них действительно есть такая политика моментально матчить зп, даже если сотрудник этого не просил. Но в обычной аутсорсинговой фирме, где борются за каждую копейку, это выстрел себе в ногу (точнее, в кошелек).
Что будете делать с рентабельностью?
Давайте прикинем общую рентабельность.
На проекте 12 человек. Если на тимлиде зарабатывали 1,000, то на остальных, в худшем случае, 1,500. Суммарно получается $17,500 в месяц, а после рейза станет на 6% меньше.
Звучит не так драматично, правда? С другой стороны, рентабельность будет падать после каждого такого пересмотра.
На пустом месте терять прибыль тоже не хочется, поэтому вариант ничего не делать не про нас. После нескольких таких рейзов к ПМу обязательно придут и спросят, где бабки :)
Каждый раз согласовывать новые рейты с клиентом как минимум неудобно. Завтра тестировщик "отправится на поиски сокровищ", а через месяц дизайнер. Бегать каждый раз к клиенту как-то мелочно. Такое только с арендой квартир в Тбилиси работает :)
Оптимальный вариант - повышать рейт сразу всех спецов. Такие пересмотры обычно проводят раз в год, чтобы не сильно нервировать клиента. А еще потому, что и клиент, и компания расчитывают бюджет раз в год. Так удобней планировать.
💰 В контрактах на разработку даже часто включают такой пункт, что раз в год рейты пересматриваются.
💰 В рост рейтов закладывают в том числе повышение зп сотрудникам. В этом смысле, ответ "ничего не делать" тоже подходит, если мы остались в прогнозируемой рентабельности.
💰 Как и в карьере, пересмотры хорошо привязывать к успехам проекта. Сделали хороший релиз, затащили новую интеграцию - можно и про рейты поговорить.
Давайте прикинем общую рентабельность.
На проекте 12 человек. Если на тимлиде зарабатывали 1,000, то на остальных, в худшем случае, 1,500. Суммарно получается $17,500 в месяц, а после рейза станет на 6% меньше.
Звучит не так драматично, правда? С другой стороны, рентабельность будет падать после каждого такого пересмотра.
На пустом месте терять прибыль тоже не хочется, поэтому вариант ничего не делать не про нас. После нескольких таких рейзов к ПМу обязательно придут и спросят, где бабки :)
Каждый раз согласовывать новые рейты с клиентом как минимум неудобно. Завтра тестировщик "отправится на поиски сокровищ", а через месяц дизайнер. Бегать каждый раз к клиенту как-то мелочно. Такое только с арендой квартир в Тбилиси работает :)
Оптимальный вариант - повышать рейт сразу всех спецов. Такие пересмотры обычно проводят раз в год, чтобы не сильно нервировать клиента. А еще потому, что и клиент, и компания расчитывают бюджет раз в год. Так удобней планировать.
💰 В контрактах на разработку даже часто включают такой пункт, что раз в год рейты пересматриваются.
💰 В рост рейтов закладывают в том числе повышение зп сотрудникам. В этом смысле, ответ "ничего не делать" тоже подходит, если мы остались в прогнозируемой рентабельности.
💰 Как и в карьере, пересмотры хорошо привязывать к успехам проекта. Сделали хороший релиз, затащили новую интеграцию - можно и про рейты поговорить.