Менеджер от боженьки
26.6K subscribers
44 photos
2 videos
267 links
Проджект менеджмент в IT.

Рома Ковалевский — о современных деливери практиках, продуктовой разработке и как быть классным менеджером.



Сообщество менеджеров: @pm_sovet

Реклама: @pm_god_ads

Для РКН: 5035224482
加入频道
Что отличает джуна от сеньора? Самостоятельность

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

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

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

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

Война - это пиздец. Нет войне.
Ребята, предыдущий пост (он уже удалён) писал не я. Мой канал и многие другие каналы в тг взломали с помощью бота аналитики.

Сейчас доступ восстановлен, все хорошо.
Кто тут наши

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

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

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

Максим Кац, который много снимает про войну, задал очень уместный в этом контексте вопрос: кто тут наши? И правильный ответ тут один. Наши и те, и другие. Не наши здесь только кучка политиков, развязавшая войну. Но я уверен, что они с нами ненадолго. Они уйдут, а мы с вами останемся и будем как-то жить дальше.

Берегите друг друга.
Плохие новости

Компании нашего региона умеют отмечать успехи. Обычно это выглядит так. Топ менеджмент собирает всех на all-staff митинг раз в квартал и промоутит хорошие новости.

"Нашим клиентом стала Тойота!"
"В прошлом квартале мы заработали на 30% больше денег, чем планировали!"

Это супер важная функция. Слушаешь топов и думаешь, о, супер, дела идут в гору, радуешься за фирму. И даже работать чуть хочется больше (на то и расчет).

С другой стороны, компании совершенно не умеют работать с негативной повесткой. Я нигде не слышал, чтобы говорили:

"От нас ушли 3 ключевых разраба, мы не смогли их удержать"
"Проект Apple blossom не взлетел. Мы потратили кучу денег на его продвижение, но ошиблись в позиционировании"

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

На самом деле сотрудники все равно заметят уход ключевых разрабов и закрытие проекта. Только они еще додумают драматичных и пикантных причин, почему это случилось 🙃.

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

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

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

В один момент я понял, почему это делаю. Я видел красную единичку на иконке почты и мне хотелось, чтобы она исчезла. Мотивация была в том, чтобы к утру было как можно меньше писем (испытываю эстетическое удовольствие от этого).

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

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

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

Не бойтесь отключить все пуши: смс, яндекс, слак, почту, телеграм, все, что найдете. Ну, кроме кроме мамы и бабушки в вайбере, конечно. Берегите свое внимание 😌
Советы по change requests

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

Что ж, придется изучать блокчейн и МЛ 😁. А если у вас fix price контракт, то эти две фичи для проекта - change request (CR).

Вот несколько хороших практик по работе с такими изменениями:

1️⃣ Закладывайте время на оценку в стоимость CR. За обсуждение новых фич заказчик вряд ли заплатит, потому что это как бы пресейл, он обычно бесплатный. Но ведь нам нужно превратить хотелки в требования, погрумить их с командой, дать оценку. На все это тоже нужно время. Можно добавить потраченные часы к будущему контракту. Т.е. насчитали 100 часов на новую фичу, 4 потратили на оценку, выставляем клиенту 104 часа.
Если же изменение большое, как в примере выше, то его проводят как фазу discovery, уже платно.

2️⃣ Закладывайте старые косяки по бюджету в новые CR. Классика. Если часть проекта на старте недооценили и он ушел в минус, то совсем не стыдно часть недостачи заложить в новую оценку, чтобы улучшить баланс. Это вообще не грех, я узнавал.

3️⃣ Помимо оценки в деньгах, не забывайте про оценку сроков. Самое важное тут - проверить, как новый скоуп влияет на дату основной поставки. Обычно он как раз влияет, т.к. поменять просят что-то близкое по функционалу. Будьте внимательны здесь.

4️⃣ Если CR становится слишком много, предложите клиенту перейти на Time and Material - контракт, с оплатой за потраченные по факту часы. Тогда не нужно будет бегать за каждой оценкой и подписывать документы на любое изменение. Для обеих сторон это вин.

5️⃣ Ваша компания работает за прибыль, поэтому, чем больше будет нового скоупа, тем больше денег вы заработаете. С другой стороны, у вас нет обязательства делать каждый CR, особенно если работать с этим клиентом - боль. В любой момент можно сослаться на недоступность команды, заказчики хорошо принимают этот аргумент.

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

7️⃣ Когда заказчик даст аппрув на новую фичу, положите ваши договоренности на бумагу. Для каждого CR надо подписать два документа: scope of work, с описанием фичи и delivery acceptance, в котором заказчик эту фичу принимает. Если отношения с клиентом хорошие, то начинать работу можно и без подписанного договора, но иметь его все равно нужно.

Эти советы настоены на горьком опыте многих ПМов. Не повторяйте их ошибок 🙏
Сколько времени тратишь на разработчика

Открою вам маленькую тайну.

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

Один из супер-важных параметров в этом списке - maintenance. Означает, сколько времени и усилий менеджер тратит на этого человека.

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

В каждой машине надо менять масло, но в одной раз в месяц, а в другой раз в три месяца.

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

Про первого говорят high maintenance, про второго - low maintenance. Менеджеры, конечно, больше вторых любят.
Главная задача менеджера - хороший найм

Иногда мне кажется, что единственная, по-настоящему важная задача менеджера - собрать толковую команду. И просто не мешать ей работать. Это уже 80% успеха.

Крутые спецы сами разберутся и сделают хорошо. Заложат гибкую архитектуру, не забудут про корнер кейсы, попадут в оценку. Геройства и овертаймы станут просто не нужны.

На одном проекте я полгода выбивал разработчика от боженьки. В какой-то момент лёд руководства треснул (как и наша профитабилити) и нам дали Юру. У Юры было 17 лет опыта.

Он пришёл и за месяц порешал все проблемы, которые мы не могли решить год. Я не мог в это поверить. Юра просто брал и фиксил все самые дикие баги!

Один супер-профи может закрывать такой же объем работы, как несколько обычных разработчиков. Поэтому в Гугле и Фейсбуке такой жесткий отбор. Они набирают звезд-олимпиадников, чтобы выпускать свои продукты максимально быстро и качественно.

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

Здесь наша с вами задача - построить в голове руководства вот такую нейронную связь:

Экономия на команде = экономия на продукте.
Кейс про выбор кандидата

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

🧓 Игорь, 9 лет опыта:
- 2 года в продукте по видео-звонкам
- 4 в аутсорсе, на разношерстных проектах
- 3 в продукте по подбору автомобилей

🧔 Антон, 4 года опыта:
- 1 год в соцсети для собак
- 3 в стартапе по быстрому переводу денег

У вас есть один слот для интервью на этой неделе.
Кого позовете первым?
Anonymous Poll
32%
🧓 Игорь
68%
🧔 Антон
Комментарии к кейсу про выбор кандидата ^

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На половине текста, вспомнил, что что уже писал такой пост 3 года назад 🙃.
Саббатикал

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

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

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

Об одной из них расскажу в следующем посте.
Запускаю новый проект - PM совет

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

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

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

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

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

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

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


Приходите!

UPD: разбор этих кейсов https://yangx.top/pm_sovet/19
Нужно больше прикола

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

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

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

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

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

А какие у вас на работе приколы?
Кейс про загрузку дизайнера

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

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

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

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

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

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

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