Менеджер от боженьки
26.3K subscribers
85 photos
3 videos
282 links
Проджект менеджмент в IT.

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



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

Реклама: @pm_god_ads

5035224435
Download Telegram
Cracking the PM interview

Эту книжку фичерят во всех каналах о продукте. И не зря. Здесь собрана исчерпывающая инфа о том, как получить работу продакта (с проджектами много пересечений):

📌 пошаговый процесс найма в Google, Amazon, Apple, Microsoft, какие требования, что входит в обязанности;

📌 резюме, с которыми кандидаты получили оферы из этих компаний (+ как их можно улучшить) ;

📌 как отвечать на скользкие вопросы типо "почему вы решили сменить работу?" или "почему мы должны взять именно вас?"

📌 интервью с топовыми продактами, как будто Дудя смотришь;

Меня зацепила вот эта мысль:

Join the company, that's experiencing hyper-growth. The business will be growing faster than the team can scale, so you'll have lots of room to grow in terms of responsibility. Venture capital community can be a great resource here; they value meeting talent (you!) while you value getting job leads.

+ простой и понятный английский, не стесняйтесь читать в оригинале!
Как отвечать за то, в чем не разбираешься

Недавно коллега спросил, как ему отвечать за девопс, в котором он ничего не понимает. Я спросил, а как ты, бывший аналитик, отвечаешь за все остальное? За код, за тесты, за дизайн?

Хороший менеджер отдает принятие многих решений (и ответственность за них) команде. Так она учится и развивает самостоятельность.

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

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

Еще помогает технический бэкграунд, об этом в следующем посте.
Как качать технические навыки, ч1

Прокачивать любые навыки можно в бою. Допустим, приходит требование клиента - надо 5000 сессий одновременно. Вроде понятное требование, несложное, бытовое. Идем к девопсу, узнаем, что сервер тянет 3000 (еще полезно узнать что именно тянет и при каких условиях). Вот тебе капасити.

Как будем делать 5000? А какие есть варианты? Вертикальным скейлингом? Горизонтальным? А как будут распределяться пользователи между серверами? Лоуд балансером? И так далее.

Словом, надо быть любопытным и задавать вопросы как? почему? зачем? можно ли по-другому? и т.д. Еще помогают курсы, статьи и прочее, но это вы и без меня знаете.
👍1
Спринт репорт

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

- Дать быстрый статус боссу \ клиенту;
- Прикрыть тыл менеджера;

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

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

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

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

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

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

Зарплата проджектов в Минске в 2020:

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

$1500-3000 начисляют на карточку мидлам, управляющим командой в 5-15 человек. Эти ПМы сами настраивают джира флоу, уже пробуют делегировать и адаптировать процессы под проект\клиента. Им нужно подсказывать направление и иногда проверять как идут дела.

$3000-5000 получают сеньоры с командой 20+ человек. Это полностью автономные сотрудники, которые решают проблемы еще до того, как те появились.

> $5000 платят лидам, которые делают много внепроектной работы: пре-сейл новых проектов, улучшение процессов компании, менторство и найм других менеджеров и т.д. Часто тайтл таких людей меняется на более звучный - деливери, ресурс менеджер, директор оф что-нибудь.

UPD 2022: легко умножайте все цифры на 20%
на день рождения тим лиду
Проектный треугольник 2.0

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

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

Как вам?
Фидбек на канал

Я веду этот канал, потому что кайфую от своей работы. А еще, чтобы научиться лучше писать. Мне нравится красота текста и емкость мысли.

Автор моей любимой книги "Пиши, сокращай", Максим Ильяхов, разбирает тексты на заказ. Я прислал ему несколько постов и вот что он посоветовал:
https://www.youtube.com/watch?v=PdzuwlYgLUQ

С комментами согласен, есть полезные штуки, которые точно возьму на вооружение. Конспект:

👍 - четкая структура, нет воды, есть примеры и контрпримеры;
👎 - ...но их мало, как и историй из практики, поэтому некоторые идеи сложно уловить в плотном темпе смысла. Мало картинок и графики;

А что бы вы посоветовали каналу? Пишите 👉: https://forms.gle/utScJQwaQMok91Xz6
Как следить за сроками

Релиз через 2 месяца, мы точно успеваем сделать все к 1 июля?

Есть несколько способов проверить:

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

- Джира отчет Release burndown chart. То же самое, только автоматизировано, если пользуетесь fix version и оцениваете в SP.

- Если на этапе продажи проекта составляли план в MS Project, то в нем же можно следить за расписанием. Вносите дату завершения каждой задачи, а программа покажет дату окончания всего проекта, даже с учетом нерабочих дней.

- Джира плагин Folio - айфон, в мире плагинов. Помимо дедлайнов, он отслеживает еще и бюджет, закрывая базовые нужды ПМов при работе с фикс прайс проектами. Стоит безбожные $5,000 в год, но есть триал на 6 (!) месяцев.
👍7
Главное правило управления сроками - разбивать проект на короткие фазы по 1-2 месяца. Например, если проект заканчивается в октябре, выберите фичи, которые должны быть готовы к июлю и трекайте их успеваемость.

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

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

Отказаться - не значит проявить слабость.

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

Прыгать с проекта на проект, завидев первые трудности, тоже грешно. Проведите личную границу между усилием и насилием и решите с чем готовы мириться, а с чем нет. Например:

в команде нет культуры юнит тестов -> убежу 1 программиста, проведем эксперимент на нескольких фичах, потом сделаю презу для всех с примерами и цифрами -> усилие

команда отказалась писать тесты безо всяких аргументов -> есть другие показатели низкой инженерной культуры, а для меня это на первом месте в работе -> насилие
Менеджерский приём - смещение фокуса

Сравните:

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

или

API гугл хрома не позволяет записывать экран без согласия пользователя.

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

Смещайте фокус.
👍3
Не все баги надо фиксить

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

Баги, как и фичи, решают задачи пользователей. Они имеют ценность, которую надо оценить и приоритизировать.

Например, SMS нотификации - ценность 5, а поехавшая верстка в IE - 0.05. Пользователей IE всего 2%, их можно долго мариновать внизу беклога и ничего не случится.

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

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

Вот что получилось: https://bit.ly/2XDQhTR

Внутри:

1. Ценят ли компании опыт проджекта?
2. Что сделать сегодня на проекте, чтобы уже завтра стать продактом (максимум, послезавтра)?
3. Какие скиллы качать, а какие нет?

Раньше я не брал интервью, будет классно, если сможете написать свои впечатления в комменты или в директ.
Scrum аудит

Менеджеров хлебом не корми, дай что-нибудь измерить и оценить. Даже Scrum умудряются превратить в число.

Рассуждают так: если весной Scrum на условные 3, а летом уже на 5, значит дела идут в гору, а менеджер не зря ест свой хлеб.

Идея не лишена смысла, а воплотить ее поможет Scrum аудит.

Он оценивает процессы в команде, опираясь на фреймворк и его лучшие практики. Советую использовать его не как линейку, а как предлог для поиска улучшений (те самые inspection & adaption из гайда).

От миллиона других аудитов в интернете этот отличает фокус на ценностях фреймворка, а не артефактах. Сердце скрама бьется именно благодаря открытости, смелости и ответственности команды, а не стендапам и беклогу, они лишь инструменты.
👍1
Проджект менеджеры не нужны

Работа ПМа критична на старте проекта: построить отношения с клиентом, отладить процессы, помочь команде выйти на стабильную производительность. Тут ПМ незаменим. А что потом?

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

Через 8-12 месяцев можно освободить добрых полдня. За этот срок команда в состоянии научиться работать без менеджера.

Перегибать с делегированием тоже не стоит, вот эти дела лучше оставить себе:
- ресурсная часть (1-1, найм-увольнение);
- финансовая (попадание в бюджет, инвойсы, прибыльность проекта, ставки, контракты);
- долгосрочные цели, стратегия по аккаунту;
- новые инициативы (все что угодно, что команда не делала раньше);

Разумеется, такой подход работает, пока проект не переживает резких изменений - тот же заказчик, команда и продукт. Как только радостный клиент сообщает, что подписал Google и нужно нанять 5 фронтендеров, чтобы подпилить для него функционал - все начинается сначала.