​Как вырасти в ПМ (или в кого угодно)

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

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

Например, ты работаешь единственным тестером на проекте. Пишешь своему ПМу: "Саша, вот ты проводишь демо спринта каждые 2 недели. Мне хочется расти, можешь показать как ты его готовишь? Я бы мог продемить несколько фич в следующий раз, если тебе ОК. У тебя наверняка других дел по горло :)". Если Саша не мудак, то, скорее всего, ему ОК и он все покажет.

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

Проект растет, нанимают еще одного QA и, видя твою активность, назначают QA лидом. А там уже и до ПМ полшага.

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

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

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

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

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

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

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

Кейс про плохие новости

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

Переговоры с Пашей закончились во вторник, с Оксаной - в четверг.

Мой вариант в следующем посте.

Комментарии к кейсу про плохие новости ^

☑️ A - На следующий день после завершения переговоров - в среду и пятницу. В этом варианте есть два небольших плюса.

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

Второй - у вас будет на 2 дня больше для передачи дел и открытия вакансии.

Все же, вариант B более выгодный.

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

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

❌ C - В последний день их работы - этот вариант плох тем, что не дает команде времени "попрощаться" с сотрудником. Могут подумать, что вы что-то скрываете и не хотите, чтобы Оксана и Паша сболтнули лишнего. Или что их уволили одним днем. И то и другое бросает негативную тень на проект, а, следовательно, и на менеджера.

Любопытно, что этот вариант выбрало около 10% менеджеров. Поделитесь в комментариях в чем здесь может быть выгода?

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

P.S.

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

2️⃣ Очень классный вариант предложил Антон Корнев:

1. узнаю, с кем сотрудники уже обсуждали свой уход. может быть все уже в курсе, и нет смысла долго держать в тайне
2. если никто не в курсе, то сначала с теми, кто уходит, проговорю стратегию. как я понимаю, они не из-за проблем в проекте уходят, поэтому важно не создать у команды впечатления, что всё может быть плохо. Тут же назначим день, когда сообщить команде
3. действуем по договоренности ) плюс попрошу ребят озвучить причины ухода остальным, если это возможно

Кейс про небольшую доработку

Это реальная история, которая случилась со мной недавно.

Один клиент попросил сделать фичу - запуск нашего SDK в табке. Хотел реализовать такой флоу, как в инстаграме (см. картинки внизу).

Описание понятное, звучит как небольшая доработка. Просто взять да запустить наше великолепное, блестяще работающее SDK в новом представлении, как в новой вкладке.

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

Таска легкая займет 2 дня с рисками, тестами и багфиксами. Супер. Заказчика все устраивает, начинаем разработку.

Сделали даже быстрее и через 1,5 дня пулл реквест был на столе у тестировщиков.

Комментарий к кейсу про доработку ^

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

Все потому, что когда мы делали оценку, то думали о работе SDK только в контексте самого SDK. А механизм вкладок вносит доп логику снаружи. Благодаря ему юзер может одновременно использовать другие фичи приложения в других вкладках. Там может оказаться еще одна камера, еще одна вспышка, любой функционал, дублирующий наш, или, что еще хуже, противоречащих нашему. Это определенно вызвало бы "помехи", которые мы и начали ловить в эдж кейсах.

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

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

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

​1 картинка вместо 1000 слов

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

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

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

Как говорится, лучше один раз увидеть, что сто раз прочитать в тикете.

Что отличает джуна от сеньора? Самостоятельность

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

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

#джун_vs_сеньор

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

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

Война - это пиздец. Нет войне.

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

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

​Кто тут наши

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

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

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

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

Берегите друг друга.

​Плохие новости

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

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

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

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

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

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

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

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

​Запрос на новую фичу

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