#77 Прогнозирование сроков в Kanban

В одном из постов мы с @AnastasiaProk зарубились на тему планирования.

Она говорила, что можно выстроить планирование без оценок, а я не понимал как.

На своем проекте Настя сделала каноничный Kanban с системой прогнозирования сроков. С помощью lead time и исторических данных она считает вероятность завершения задачи к определенной дате. То есть может сказать стейкхолдерам: “с вероятностью 85% эта задача будет готова в следующий вторник”. Класс!

Некоторые команды действительно работают без оценок и у них все отлично.

Если подумываете ввести такое у себя, приходите послушать Настю на следующий совет. Она расскажет, как работает ее система планирования и какие штуки из Kanban она использует.

📅 среда, 28 июня, 20:00 по Минску

Участвовать

Классный разговор вчера получился с Камиллой!

Оказывается, в Тинькофф проджектов почти нету, только в больших инициативах, где участвует много команд. А в небольших, полу-автономных командах, продакты еще и деливери делают, на пару с тимлидами.

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

Еще ловите подборку рекомендаций для начинающих продактов.

И напоследок, если у вас подписка, то в сегодняшнем конспекте вы узнаете ТОП-1 книги, которые прокачали Камиллу за последние несколько лет. Продолжение читать в источнике 🤣

Вчера на совете Настя поделилась вот таким графиком со своего проекта. Эта диаграмма берет данные с вашей доски и показывает, сколько задач находится в каждом статусе. Такая, кстати, есть в любой версии джиры - Cumulative Flow Diagram.

Что по ней видно? Какие события \ изменения можно предположить, глядя на график?

💬 Пишите в комментарии свои гипотезы, а мы запостим ответ через пару дней.

#78 Увольнения, найм, перевод на партайм

Николай работает ПМом в небольшом продукте. Он прислал вот такие 3 мини-кейса (жиза!) которые мы обсудим на следующей неделе.


📅 среда, 5 июля, 20:00 по Минску

Участвовать

Представьте, что вы решили уволить разработчика за низкий перфоманс. Он в команде 9 месяцев.

Личный разговор с ним прошел нормально, он понимает, что не дотягивает, обиду не затаил. С командой отношения хорошие, рабочие.

Вот на митинге вы объявляете всем, что этот разработчик покидает нас через месяц.

Озвучите про причину?

🐳 - скажу тут же, при разработчике;
🌭 - скажу как-нибудь потом, без него;
🌚 - не скажу вообще;

Хочешь +3,75 стори поинта в следующем спринте?

По статистике на столько увеличивается велосити команды у ПМа, который разобрал свой кейс на совете.

Присылай свой кейс: https://forms.gle/tdMHjpeuDCgqEAbG9

или короткую тему, которую тебе давно хотелось обсудить с коллегами: https://app.sli.do/event/hYFrhE7wwo8bSkH4ir5iRo/live/questions

# 79 Отказоустойчивость в большом банке

На следующей неделе у нас в гостях Артём Арюткин - Head of PMO в Сбере, автор канала @badtechproject.

За 8 лет работы в Сбербанке онлайн Артём видел много сценариев, почему система может упасть и не подняться. Представьте масштаб, когда у тебя 200 тыс. логинов в минуту!

Мы поговорим про отказоустойчивость крупных проектов и ответим на вопросы, как ее повышать.

Обсудим темы:

- как меняется бекенд, когда у тебя в приложении 1К / 100K / 10M / 100 M пользователей;
- в каких случаях микросервисы не помогут, а наоборот, навредят;
- чем отличается отказоустойчивость банка от социальной сети;


📅 среда, 12 июля, 20:00 по Минску

Участвовать

Оригинальный пост.

А вот и разбор, что случилось на проекте на самом деле.

(сорри, что поздно, автор болела)

Для начала напомню, что cumulative flow diagram отражает количество задач в выбранном статусе. Чем шире полоска, тем дольше задачи висят в этом статусе.

Итак, по графику можно увидеть:

1️⃣ Резкие перепады были в момент чистки беклога. Т.е. задачи из dev backlog, Product analytics, Design, переносились в Backlog. По-хорошему, их нужно было закрывать, но мышление людей: "А ВДРУГ ПРИГОДИТСЯ" не получилось обработать.

2️⃣После чистки беклога добавили статус To do, которого раньше не было. Стало прозрачнее, т.к. команде и стейкхолдерам видно, какая задача будет следующей.

3️⃣ Как и многим в комментариях, мне тоже бросилось в глаза отсутствие колонки Done. Оказалось, что у Насти статус waiting for feedback означает, что фича уже вылита на прод и ждет фидбека. Т.е. задача формальна выполнена и время цикла померить можно.
Немного странно, что фидбек просят после релиза, но предположим, тому есть причина.
В любом случае, после фидбека с задачей ведь что-то происходит. Она либо переходит в Done, либо в какой-нибудь Reverted. Добавил бы такие на борд.

4️⃣Можно заметить, что в начале и в конца графика полоски development примерно одинаковой ширины. Это значит, что команда поставляет со стабильной, предсказуемой скоростью.

#80 Высокий спрос на доработки в продукте

В ситуации Елисея бывал каждый ПМ. Это когда непробиваемый стейкхолдер говорит: “ничего не хочу знать, сделайте фичу к среде”. И топает ножкой. И таких стейкхоледров много, и каждый ножкой топает.

Есть несколько классических трюков, как на такое реагировать. Некоторые из них Елисей уже пробовал: напугать оценкой, выделать отдельную команду, продать через включение в роудмап.

Задача - минимизировать влияние на роудмап.

Какие еще варианты могут сработать?

📅 среда, 19 июля, 20:00 по Минску

Участвовать

Вчера на совете обсуждали кейс, где клиенты часто просят доработки в продукте. Думали о том, как уменьшить количество хотелок от клиентов.

Один из любопытных вариантов - сделать роудмап публичным для всех.

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

По себе знаю, что публиковать роудмап - стремно. Вдруг что-то изменится, а мы уже вроде как закомитились.

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

Кажется, будто сидим на двух стульях, но что ж поделаешь, работа такая.

#81 Качество без выделенных тестировщиков (MQA)

В аутсорс командах в среднем на 3,5 разработчиков приходится 1 тестировщик.

Аутсорсерам выгодно продавать MQA, да и вроде логично выглядит для заказчиков. Хотите качества - нанимайте специального человека, который будет им заниматься.

Некоторые продуктовые команды при этом работают без тестировщиков вообще.

Как им это удается? Кто ищет в софте дефекты и заводит тикеты?

Наш следующий гость - Андрей Худовец, Principal Quality Engineer в Atlassian. Он расскажет, как устроен процесс тестирования в их популярных продуктах - Jira, Confluence и Bitbucket.

У Андрея 2 ютуб канала: про тестирование и про жизнь в Австралии, подписывайтесь на оба 😉


📅 суббота, 29 июля, 10:00 по Минску

Участвовать

#82 Как становятся ПМами

Классический путь в ПМы - из разработчиков, тестировщиков и аналитиков. Иногда переходят из смежных областей.

Одна моя знакомая перешла из банка и первое время ей дико резало ухо, что все на ты и иногда матерятся.

На следующей неделе повспоминаем истории минувших лет и потравим байки, о том, кто как стал ПМом.

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

📅 четверг, 3 августа, 20:00 по Минску

Участвовать

Встреча, как обычно, по подписке. Если хотите поделиться своей историей, напишите в лс, вышлю вам инвайт.

До сих пор под впечатлением от нашего разговора о подходе к тестированию Shift left c Андреем из Atlassian. Несколько хайлайтов:

💬Самый дорогой баг - делать фичу, которая никому не нужна.

💬Garbage in = garbage out. Если архитектура - 💩, дизайн - 💩, требования - 💩, то как круто ты не тестируй, на выходе ничего сладкого не получится.

💬Качество - это не только тесты, код ревью и сонар кьюб (фаза разработки). Основы качества закладывается еще раньше:
- на этапе определения проблемы;
- затем, когда мы создаем требования;
- а после на фаза дизайна.

И только потом сонар кьюб.

💬Разделять тестирование и разработку противоречит некоторым принципам эджайла.
Можно использовать как аргумент, чтобы протащить нужные изменения у себя в компании.

💬Вот так качество интегрируется на этапе разработки (см. картинку).

Вчера на совете очень душево повспоминали истории входа в ПМство.

Опубликую несколько отрывков:

Вошел через курсы продактов. ИТ сфера понравилось, захотелось остаться здесь.

Начал искать работу, но меня не брали. Стал искать практический опыт, сходил на 4 хакатона. Переработал резюме, стал получать отклики.

—————————

Начинала с позиции джуна БА. Дальше росла в компании, в основном за счет того, что брала новые обязанности. Ходила и задавала вопросы какая стратегия, где цифры, это же не удобно. Задолбала всех, и мне дали право на то, чтобы менять процессы в компании.


—————————

Самым сложным в начале было переключиться на новую культуру и отучиться от дисциплины завода - люди не выполняют сроки, смотрят ютуб, не работают 8 часов, опаздывают. А руководство говорит, что все окей 😆

#83 Надо ли дружить с командой?

На следующей неделе обсудим тему отношений в команде.

▫️Влияет ли дружба на эффективность работы?
▫️Надо ли менеджеру “шевелить” людей, чтобы они больше общались по нерабочим вопросам?

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

Я пригласил к нам в гости Евгения Антонова - старшего технического менеджера проектов Yandex Infrastructure, автора телеграм-канала «Тимлид Очевидность», соведущего подкаста «Кода кода».

На встрече поделимся историями своих проектов, кто как дружил и против кого.

📅 8 августа, вторник, 20:00 по Минску

Участвовать

За последние пару месяцев мы с вами разобрали вот эти темы.

Спасибо, что присылаете их, очень любопытно узнавать что волнует реальных ПМов.

Присылайте еще 😊

Темы
общие вопросы, дебаты, обмен опытом:
https://app.sli.do/event/hYFrhE7wwo8bSkH4ir5iRo/live/questions

Кейсы
конкретная ситуация, произошедшая в жизни, которую мы разберем и поищем пути решения:
https://forms.gle/tdMHjpeuDCgqEAbG9

Автора приглашаем на разбор без подписки 🎫

Цитаты со встречи об отношениях в команде:

—————————

Один раз пригласил старую знакомую на собес. Собес проводил я. Отношения у нас до этого были нормальные, хотя мы не то что бы друзья. Собес она в итоге не прошла. В итоге, после него мы больше не общались.

—————————

Ребята работали 3 года на одном проекте, все это время команда росла, народ почти не уходил. Сильно дружил костяк - люди, которые начинали + новые ребята, с похожей культурой.
Общались за пределами работы, собирались на пиво и концерты, ходили друг другу в гости. При этом были те, кто жил своей жизнью. Их приглашали на ивенты, они почти всегда отказывались, всем было комфортно.
Как на мой взгляд это повлияло на проект:
- хорошая взаимовыручка (если у кого-то что-то не получается, другие с радостью помогают)
- чувство собственности в продукте - неплохо (могло быть выше, если бы мы не были аутсорсной командой)

—————————

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

#84 Тимлид не принимает нового ПМ

Анна помогает команде в мастерстве скрама. Выступая в роли фасилитатора, она столкнулась с нежеланием тимлида работать с новым ПМом.

Что может помочь разрешить этот конфликт?

Разбирать эту ситуацию нам поможет Саша Бапизманская из Co-Actors. Саша ведет тренинги по фасилитации и Agile-коучингу и пишет в канал Нестыдная Фасилитация.

📅 16 августа, среда, 20:00 по Минску

Участвовать

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

Это примерно как пустую бытулку с пляжа унести.

#85 ПМ отказался делать проект по заниженной оценке

Часто бывает так, что оценивают проект одни, а делать другим.

Классическая беда, когда сеньор оценил проект в 2 месяца, а на разработку выделили джуна, который сделал за 4 (хорошо если).

Собак в этом случае повесят на ПМа.

Поэтому перед стартом любого проекта, хорошо бы переоценить его с новой командой. Это может стать почвой для обсуждения с руководством: как ПМу отвечать за успех проекта, если еще перед стартом в нем видны косяки?

Обсудим этот вопрос и что делать ПМу на примере кейса от Kir.

Кстати, у него любопытный сетап, про который тоже интересно поговорить.

Эту модель работы можно встретить у больших аутсорсеров:
- открывают инкубатор стартапов;
- продают им своих разработчиков “по себестоимости”;
- взамен получают долю в стартапе.
- profit!

📅 24 августа, четверг, 20:00 по Минску

Участвовать

Нельзя просто так взять и запустить продукт в сфере медицины.

Вчера на совете Кирилл поделился несколькими фактами из разработки таких проектов:

Требования к запуску медицинских продуктов описывает ISO-13485. Это международных стандарт, который опубликован на сайте в домене .org.

Из любопытного в таком проекте обязательно должны быть:

- артефакты: SRS, тест-план и баг трекер.

- участники: тестировщик, архитектор, бизнес-аналитик и проджект-менеджер, прошедшие определенную сертификацию.

Если этого не будет, продукт не пройдет комиссию регулятора и запустить в лайв его просто не дадут.

Еще перед стартом проекта нужно обязательно провести риск ассесмент с экспертами из конкретной области медицины. Это нужно, чтобы определенить уровень безопасности проекта. Их всего 3, и на каждом из них конкретные требования ISO, которым нужно соответствовать.

Определишь не в ту категорию - и проект 100% зарежет регулятор, т.к. требования на каждом уровне свои.