Сколько получают менеджеры

Зарплата проджектов в Минске в 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 (!) месяцев.

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

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

​Право отказаться

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

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

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

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

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

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

Менеджерский приём - смещение фокуса

Сравните:

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

или

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

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

Смещайте фокус.

via copout.me

Не все баги надо фиксить

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

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

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

Забейте на красивую статистику, поставляйте в продукт максимум ценности.

​Из проджекта в продакты. 3 истории перехода

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

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

Внутри:

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

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

​Scrum аудит

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

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

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

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

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

​Проджект менеджеры не нужны

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

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

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

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

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

​Post-mortem шаблон для инцидентов

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

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

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

После того, как пожары потушены, надо отдышаться и провести мини-ретроспективу инцидента (post-mortem). Бизнес будет чувствовать заботу и вовлеченность, если написать такое письмо:

Что случилось: Европейский сервер чекаута упал из-за переполнения памяти.
Ущерб: Часть пользователей не могла оплатить покупки. Приблизительно 200 заказов не завершились на протяжении 2 часов.
Решение: Подняли сервер вручную.
Выводы (что мы сделаем, чтобы проблема не повторилась): Перепишем автоподъем серверов с помощью инструментов Амазона (ссылка на задачу в джире).

Для работы с инцидентами есть специальные тулы, например Opsgenie от Atlassian. В нем 200+ интеграций, чтобы делать всю продакшн поддержку в одном месте: мониторинг, оповещения, графики дежурств и т.д. Можно даже настроить автоматический звонок на мобильный именно той команде, чей модуль упал.

Маст хэв для больших проектов в лайве.

Когда сделал все дела

На любом проекте всегда можно найти чем заняться.

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

Если ничего не приходит в голову, вот 5 дел, которые можно делать при любых обстоятельствах:

📌 посмотреть аналитику, где отваливаются пользователи, подумать почему;

📌 почистить беклог;

📌 узнать у поддержки с какими проблемами юзеры обращаются чаще всего и как им помочь;

📌 написать классный текст вакансии, без стрессоустойчивости и современного офиса у метро;

📌 подумать, как ускорить поставку новых фич (например, через cumulative flow diagram или control chart)

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

Что спрашивают на собеседованиях

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

От компании к компании вопросы часто повторяются, вот эти - самые популярные:

https://telegra.ph/Voprosy-na-PM-sobesedovaniyah-06-30

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

Удачи на интервью!

​"Новые правила деловой переписки"

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

Все это в ней есть, но в действительности книга о другом: о заботе, внимательности и уважении к читателю.

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

👉Как именно заботиться в переписке:

1️⃣ одно дело - одно сообщение, не надо обсуждать 3 проекта в 1 треде;
2️⃣ объяснять что внутри прикрепленных ссылок;
3️⃣ называть файлы так, чтобы их потом было легко найти на компьютере;
4️⃣ хвалить работу, достижения человека, а не его самого;
5️⃣ если накосячил, надо предлагать варианты решения проблемы, а не просто «прости, мне стыдно»

В тексте запросто теряются интонации и эмоции. Иногда даже смысл можно потерять по дороге. Поэтому главный совет выглядит вот так:

​Закрыть незавершенную задачу в спринте

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

Зависит от условий.

Посчитать сторю завершенной не будет проблемой, если:

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

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