Менеджер от боженьки

2022-03-01 11:23:01 Мой дедушка часто говорил: "главное, чтобы не было войны". Теперь я понимаю, что это, пожалуй, действительно главное. То, что происходит сейчас в Украине - ужас, катастрофа и преступление.

Держитесь, ребята. И держите друг друга. Надеюсь, это все скоро закончится.

Война - это пиздец. Нет войне. Адкрыць / каментаваць

2022-02-22 17:00:06 Что отличает джуна от сеньора? Самостоятельность

Джун-ПМ: Рома, мой кастомер спрашивал про перфоманс нашего приложения. У меня в команде этого никто делать не умеет. Что делать?

Сеньор-ПМ: Рома, мой кастомер спрашивал про перфоманс нашего приложения. Я сходил к ресурс-менеджеру QA, он нашел Петю Быстрова, тот умеет такое делать. Правда, он сейчас занят, но я договорился с Витей Меркуловым, его ПМом, привлечь его с 1 марта на 2 недели. Кастомеру выставим по 60$, спец редкий :) Подозреваю, что там все будет не очень хорошо по перфу на самом деле, поэтому щас пойду искать еще сеньорного джависта, который починит нам потом эти проблемки. FYI.

#джун_vs_сеньор Адкрыць / каментаваць

2022-02-10 18:00:06 Адкрыць / каментаваць

2022-02-10 18:00:05 ​1 картинка вместо 1000 слов

Заметил, что читая что-то в интернете первым делом смотрю на картинку, если она есть. Некоторые ресурсы заморачиваются с визуальным повествованием и добавляют комментарии прямо на сами на картинки, рисуют схемы. Читать такой текст в разы проще и быстрее, сразу становится понятно о чем идет речь. Посмотрел картинку, глянул на заголовок, если это мэтч, то дальше уже можно и не читать. По диагонали максимум пробежаться.

Хорошо подобрать картинку - это целое искусство. В некоторых медиа для этого даже есть специальные люди - пикчеры.

У нас в команде нету пикчеров, но мы тоже любим картинки. Используем их для описания багов, прикрепляем скриншоты проблем. Тогда разработчикам сразу ясно, что чинить. Так мы экономим немного времени читателям нашей джиры.

Как говорится, лучше один раз увидеть, что сто раз прочитать в тикете. Адкрыць / каментаваць

2022-02-08 18:00:05 ​#реклама

Зачем формировать единый бэклог для разных команд
Кейс Райффайзенбанка из канала @epicgrowth

Часто над одним продуктом работают несколько Scrum-команд. У каждой свои KPI, цели и бэклоги. Из-за этого они фокусируются не на улучшениях, а на достижении собственных метрик. Подход, где «каждая команда делает что-то свое», разрушает ценность продукта.

Команда Райффайзенбанка решила эту проблему путем смены методологии. Переход от Scrum к LeSS (Large Scale Scrum) позволил пересмотреть стратегию и сформировать единый бэклог.

Одно из главных отличий LeSS от Scrum — планирование спринтов разного уровня:
Sprint planning 1 — общее планирование для всех команд.
Sprint planning 2 — планирование для отдельных кросс-функциональных команд.

Ретроспектива спринта также поделена на 2 уровня. Это помогает проанализировать как работу отдельных команд, так и всех в целом.

Какие результаты дал LeSS?
— Методология позволила объединять усилия и решать сложные задачи быстрее. На протяжении квартала четыре команды Райффайзенбанка занимаются одной общей важной задачей, тогда как одна команда не смогла бы и приступить к ее выполнению.

— Быстрый профессиональный рост: процесс перехода из Junior в Middle сократился до 8 месяцев. Раньше это занимало больше года.

— Time-To-Market снизился на 20+%.

— Сократилось количество увольнений, вовлеченность команды выросла на 15%.

***

На канале Epic Growth делятся лучшими кейсами роста и практиками от международных продуктовых компаний (Flo, Miro, Bolt, Яндекс, Bооking, Joom и других).

Подписывайтесь на @epicgrowth, чтобы каждую неделю получать полезные материалы и идеи для роста продуктов. Адкрыць / каментаваць

2022-02-03 18:00:05 Комментарий к кейсу про доработку ^

Когда фича дошла до QA, в ней нашли миллион эдж кейсов:
- делаешь фото, в этот момент включаешь другую вкладку, апа крашится
- делаешь съемку с таймером, пока идет обратный отсчет, переходишь в другую вкладку, съемка продолжается (хотя юзер уже в другой вкладке ).
и т.п.

Все потому, что когда мы делали оценку, то думали о работе SDK только в контексте самого SDK. А механизм вкладок вносит доп логику снаружи. Благодаря ему юзер может одновременно использовать другие фичи приложения в других вкладках. Там может оказаться еще одна камера, еще одна вспышка, любой функционал, дублирующий наш, или, что еще хуже, противоречащих нашему. Это определенно вызвало бы "помехи", которые мы и начали ловить в эдж кейсах.

Заказчик, конечно, не рассчитывал на них, ему нужна стабильная работа с любой его фичей. Сдать работу в таком состоянии мы, разумеется, не могли. Сложность была в том, что клиентов у SDK много, а поставка для всех одна. То есть, если фича выпускается, то ее получают все клиенты, нельзя отдать только одному.

Получается, что фича нарушает принцип универсальности поставки. Т.е. под каждого клиента ее пришлось бы адаптировать и что-то чинить. Представьте, чего стоила бы поддержка на сотне кастомеров! Поэтому задачу мы откатили, до продакшена она не дошла.

Для заказчика, конечно, это не было хорошей новостью. Мы ему что-то наобещали, а потом этого не дали - худший сон ПМа. Но даже если бы он от нас ушел, это все равно вышло бы дешевле, чем поддерживать эту фичу. В моменте мы потеряли, но сэкономили на долгой дистанции. Адкрыць / каментаваць

2022-02-02 18:33:13 Адкрыць / каментаваць

2022-02-02 18:33:06 Адкрыць / каментаваць

2022-02-02 18:33:05 Кейс про небольшую доработку

Это реальная история, которая случилась со мной недавно.

Один клиент попросил сделать фичу - запуск нашего SDK в табке. Хотел реализовать такой флоу, как в инстаграме (см. картинки внизу).

Описание понятное, звучит как небольшая доработка. Просто взять да запустить наше великолепное, блестяще работающее SDK в новом представлении, как в новой вкладке.

Иду разговаривать к разработчику, рассказываю про фичу. Тоже нет проблем, добавим там метод present, который... дальше что-то на разработческом.

Таска легкая займет 2 дня с рисками, тестами и багфиксами. Супер. Заказчика все устраивает, начинаем разработку.

Сделали даже быстрее и через 1,5 дня пулл реквест был на столе у тестировщиков. Адкрыць / каментаваць

2022-01-26 18:00:05 Комментарии к кейсу про плохие новости ^

A - На следующий день после завершения переговоров - в среду и пятницу. В этом варианте есть два небольших плюса.

Первый - в том, что команда узнает новость раньше всех. Это помогает строить честные отношения с менеджером - ребята видят, что от них ничего не скрывают и вся проектная инфа сразу доходит до них, минуя "министерство правды".

Второй - у вас будет на 2 дня больше для передачи дел и открытия вакансии.

Все же, вариант B более выгодный.

B - В один день расскажу про уход обоих - в пятницу. Я выбираю этот вариант, потому что уход двух человек - это одна плохая новость. Уход Оксаны, а через несколько дней, уход Паши - это уже две плохие новости, хоть и менее масштабные. В голове команды это разница между "в январе от нас ушли Оксана и Паша" и "сначала Оксана от нас ушла, а за ней еще Паша....". Первое воспринимается менее депрессивно.

Да, будет на 2 дня меньше на передачу дел и поиск нового человека. Но уходят обычно за месяц, поэтому 2 дня погоды не сделают (если это не ваш случай - берите вариант А).

C - В последний день их работы - этот вариант плох тем, что не дает команде времени "попрощаться" с сотрудником. Могут подумать, что вы что-то скрываете и не хотите, чтобы Оксана и Паша сболтнули лишнего. Или что их уволили одним днем. И то и другое бросает негативную тень на проект, а, следовательно, и на менеджера.

Любопытно, что этот вариант выбрало около 10% менеджеров. Поделитесь в комментариях в чем здесь может быть выгода?

------------------------

P.S.

В комментариях звучало много мнений о том, что команда все узнает еще раньше официальных новостей. Необязательно. Чтобы этого не случилось попросите сотрудника не распространяться коллегам об уходе. Если у вас нормальные отношения - согласится.

Очень классный вариант предложил Антон Корнев:

1. узнаю, с кем сотрудники уже обсуждали свой уход. может быть все уже в курсе, и нет смысла долго держать в тайне
2. если никто не в курсе, то сначала с теми, кто уходит, проговорю стратегию. как я понимаю, они не из-за проблем в проекте уходят, поэтому важно не создать у команды впечатления, что всё может быть плохо. Тут же назначим день, когда сообщить команде
3. действуем по договоренности ) плюс попрошу ребят озвучить причины ухода остальным, если это возможно Адкрыць / каментаваць