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

2022-06-07 18:00:03 ​Как пишут большие продукты

Представьте очень большой продукт, например, amazon.com. Над ним работают сотни команд, выкатывая новые фичи каждый день. Как столько людей контрибьютят в один проект? Давайте посмотрим как это устроено.

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

В упрощенном виде сайт амазона, который видят обычные покупатели, можно разделить на такие части:

- каталог
- поиск
- карточка товара
- корзина
- оплата
- доставка
- поддержка

За каждой из них будет стоять своя команда со своими метриками. Например, команда "карточка товара" отвечает за конверсию в корзину. Главное для нее - чтобы пользователь нажал на кнопку "добавить в корзину", ̶а̶ ̶д̶а̶л̶ь̶ш̶е̶ ̶х̶о̶т̶ь̶ ̶т̶р̶а̶в̶а̶ ̶н̶е̶ ̶р̶а̶с̶т̶и̶. А дальше действовать будет команда "корзина", у которой свои метрики, интересы и подход.

Конечно, на уровне департамента весь процесс собирается в какой-то узел "покупка", за который отвечает директор-по-конверсии-в-покупку. Но сами команды между собой слабо связаны, именно потому, что каждый отвечает за свой маленький кусочек. Это позволяет команде не тонуть в зависимостях и делать поставку быстро.

Каждая из них будет истово оптимизировать свои метрики. На таком скейле это действительно оправдано. Представьте, сколько денег можно сэкономить на инфраструктуре, сжав фотки всех товаров всего на 5%

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

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

P.S. В этом примере я, конечно, все сильно упростил. В масштабе Амазона за карточку товара будет отвечать целый отдел с десятком команд. Одна команда пишет сервис по загрузке, обработке и хранению картинок. Другая - отзывы. Третья - рекомендации товаров. Четвертая - рейтинг. Пятая - рассчитывает сроки доставки.

Но это еще не все картинка. Такая большая структура делится на несколько отделов или линий бизнеса (line of business). Это такие компании внутри компании, каждая со своими процессами, бюджетами, наймом и так далее. В екоме они обычно такие:

1. пользовательские продукты - приложение, сайт, лендинги с акциями
2. б2б - админка продавцов
3. логистика - доставка, склады, остатки
4. коммерция - продажи, цены, товары

На картинке - скольким командам можно передать привет, открыв страницу товара. Адкрыць / каментаваць

2022-06-02 18:00:01 Решение - Кейс про загрузку дизайнера

Сперва стоит поговорить с CPO, что стало со старым роудмапом, где было много проектов с дизайном. Вдруг они через 3 месяца вернутся? А может их вообще больше не будет, и дизайнер команде уже не понадобится? Ответ на этот вопрос даст контекст для долгосрочного решения.

Если задач все еще мало, нужно честно рассказать Оле о ситуации. Любой вариант развития событий сильно влияет на ее работу. И наверняка не совпадает с вашими первоначальными договоренностями. Поэтому сначала объясняем ситуацию и смотрим на Олину реакцию. Если она конструктивная и адекватная, очень вероятно, что Оля сама предложит решение, сняв с вас эту задачу . Например, скажет, "ой, хорошо, что так совпало, я вообще-то собиралась уходить". Или предложит какой-то из вариантов ниже:

1. Дать Оле других задач, которые делает команда. Пользовательские интервью, которые сейчас проводите вы, или описание требований, которые делает кто придется - хороший вариант для старта, т.к. Оля уже работает "рядом" с этими задачами. Профит даже двойной: у кого-то из команды освободится немного времени, а Оля прокачает новый скилл. Как верно заметили в комментариях, сначала узнаем, кем Оля хочет стать, когда вырастет и ищем подходящие задачи. Наверняка это будут около продуктовые активности.

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

3. Перевести на парт тайм. Можно предложить Оле сократить ее рабочие часы и зп. Это устранит проблему частичного простоя. Но вместе с тем, компания рискует потерять и вторую половину сильного дизайнера. Если Оля живет на Бали, или гуру во фрилансе, то далеко не факт, что потом вы сможете вернуть ее на прежние условия. К тому же, сейчас у вас есть выделенный бюджет на зп для Оли. Его тоже можно лишиться.

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

Хороший пункт из комментариев (спасибо за них!):
Вероятно, изменения в проектах, вероятно, коснутся не только Олю, но и разработчиков клиентских приложений (веб, мобайл). Стоит проверить, что теперь с их загрузкой. Адкрыць / каментаваць

2022-05-31 18:00:03 Кейс про загрузку дизайнера

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

Недавно вы наняли дизайнера Олю на фуллтайм. Она уже прошла испыт и показала себя с лучшей стороны: дизайны шикарные, всегда в срок, правок мало. Сейчас ваша работа выглядит так:
- вы делаете пользовательские интервью и очень кратко описываете цель задачи;
- Оля отрисовывает по ним интерфейс;
- QA, вы или Оля пишете детальное описание юзер-стори для разработчиков;

На квартальном планировании ваш CPO сильно скорректировал роудмап. Следующие 3 месяца будет упор на интеграции с партнерами. Будущие проекты поменялись, стало больше бекендовых задач, а интерфейсные сократились. Загрузить Олю на фуллтайм точно не хватит. У вас есть предположение, что и через квартал будет похожая картина.

В ваши обязанности входит ресурсная часть: найм, увольнение, распределение по проектам. Что будете делать?

Пишите варианты в комментарии.

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

P.S. В этом кейсе несколько путей решения, поэтому варианты ответа не добавлял. Адкрыць / каментаваць

2022-05-27 18:00:03 ​Нужно больше прикола

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

Например, на прошлой работе мы называли релизы в честь групп, по алфавиту. То есть, сейчас релиз 1.17_Radiohead, а за ним будет 1.18_Scorpions. Другая команда называла спринты в честь мемов недели, типо 129-Богдан-богом-дан.

Еще один раз мы делали клиенту фичу караоке. Он был из Франции, поэтому на мокапы поместили песню Джо Дассена и я ее как будто пел. Клиент поржал.

Мой друг устроился в берлинский стартап и рассказывал, что у них там на онбординге положено отыграть сколько-то часов в among us!

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

А какие у вас на работе приколы? Адкрыць / каментаваць

2022-05-25 18:00:03 ​Запускаю новый проект - PM совет

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

Ответ я получил на третьей работе, где был классный отдел ПМО. Раз в неделю все менеджеры компании собирались в одной комнате и разбирали недавние сложные кейсы. На настоящих проектах! Это очень бустануло мой рост.

Теперь я запускаю такой ПМО по подписке - PM совет. И приглашаю вас в него

Задача совета - натренировать нейронку по принятию решений. А тренироваться будем на реальных ситуациях из жизни ПМов - ваших.

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

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

Темы первой встречи:
1. Клиент прислал вот такое письмо. Как ответить?
2. Сделаем разбивку и оценку фичи лайки в телеграме.


Приходите! Адкрыць / каментаваць

2022-05-23 18:00:03 ​Саббатикал

Недавно я завершил работу в Banuba. Это были отличные 2 года, с хорошими результатами для меня и для компании. Точно буду скучать по команде, ребята, вы крутые!!

Честно говоря, за 9 лет работы в IT я банально устал, поэтому планировал отдохнуть хотя бы пару месяцев.

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

Об одной из них расскажу в следующем посте. Адкрыць / каментаваць

2022-05-18 17:00:02 ​Always assume a positive intent

В презентации что общего у IT компании и плесени (!) встретил вот эту картинку (внизу). Такая жиза!

Периодически ловлю себя на том, что виню других людей за то, что не вписались в какие-то мои ожидания (не только по работе). Хотя мои ожидания - это моя проблема. Сложно полностью избавиться от этого паттерна, но радует, что хотя бы делаю так все реже с каждым годом.

Например, если разработчик обещал задачу ко вторнику, а уже пятница, он виноват? Наверное, но сперва, какой у этой истории контекст?

Предупредил ли он, что не успевает? По силам ли была ему эта задача? Живет ли он в зоне боевых действий?

Как менеджеры, мы можем лишь косвенно влиять на результат. Мотивировать там, создавать условия и все такое. Но есть еще миллион обстоятельств, которые остается только принять.

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

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

На половине текста, вспомнил, что что уже писал такой пост 3 года назад . Адкрыць / каментаваць

2022-05-12 18:00:03 Друзья, спасибо за ваши комменты! Некоторые прямо супер в точку, опубликую тут:

1. На какие задачи мы ищем человека? Если это продакт или ПМ+БА, то экспертиза критична. Если проджект или деливери менеджер - значительно меньше.
(мне стоило дописать это в условии )

2. На какой проект? Может это "Прямые трансляции", тогда релевантный опыт был как раз у Игоря.

3. Скорее всего ожидания по зп у Игоря будут в 2 раза выше, чем у Антона. Будет ли бюджет у компании? Адкрыць / каментаваць

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

Помимо стандартных навыков, компании ценят еще и доменную экспертизу. Это знания в области, на которую нацелен продукт. В нашем примере это финтех (переводы) и соцсети (патреон, блогеры).

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

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

Доменная экспертиза важна для любых спецов: менеджеров, программистов, тестировщиков и сейлов. Если вы хотите однажды работать в гугле, то чтобы попасть, например, в команду Youtube, нужен опыт в видео и соцсетях. Вот такие компании будут плюсом в резюме: Megogo, MX player, Splice, Reddit, Vk.

Немного о том, из чего состоит доменная экспертиза на примере видео домена, в котором я работаю последние пару лет:
- знание технологий (WebRTC, h.264, CDN, Kurento)
- больших игроков (Netflix, RingCentral, Agora, BrightCove)
- значимых событий, в этой области (запуск Twitch в 2011, Apple отказывается от флэша и делает свой протокол HLS, создание кодека HEVC в 2013)
- стоимости продуктов или как она формируется (минуты подключения или другая форма трафика)
- бест практик по решению проблем
- что волнует клиентов и пользователей (качество подключения и переподключения, максимальное количество юзеров на лайв стрим). Адкрыць / каментаваць

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