В эту среду в ПМ совете классный ивент. Разбираем кейс о менеджерской прокрастинации вместе с Максом Дорофеевым!

Приглашаю вас 😊

# 65 Когда не хочется делать дела

На следующем совете у нас в гостях легендарный Максим Дорофеев.

Корпоративный прократстинатолог, автор “Джедайских техник” и тренер по продуктивности. Максим 15 лет проработал в ИТ, в том числе в знаменитой Лаборатории Касперского.

На встрече мы разберем вот этот кейс Натальи:

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

📅 среда, 5 апреля, 19:00 по Минску.

Можно участвовать или смотреть стрим на канале Максима.

​Рефакторинг под шумок

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

Крутые менеджеры умеют превращать технические задачи в бизнес задачи:

🌧️Запилить сервис для кеша картинок
🌈Ускорить загрузку картинок -> конверсия +2%

🌧️Отрефакторить класс Deals
🌈Дешевле фиксить баги и делать новые фичи в Deals

Задача менеджера в этом случае - выяснить у команды, в чем смысл рефакторинга и переложить это на понятный бизнесу язык, объяснить “зачем”.

Но иногда и это не помогает. Тогда особо отчаянные менеджеры идут на хитрость.

Например, приходит от бизнеса новая фича - добавить в Deals историю сделок. Проводят груминг, обсуждают метрики, выбирают техническое решение. Когда дело доходит до оценки, менеджер тихонечко накидывает 30% сверху. За эти доп. часы команда перепишет один из классов.

Потом приходит дефект в Deals. Не блокер, дедлайнами никто не давит. И менеджер разработчику на ушко шепчет: “закрой хвосты по тестам заодно”.

Так, за несколько итераций и Deals посвежел и бизнес доволен. Некоторые компании так и живут, их руководство вообще не слышало ни про какие рефакторинги. Программисты просто закладывают свой “налог на разработку” во все оценки.

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

​Есть тикет?

Хороший менеджер заводит тикет на любой пук.

💨
- Босс, Петя из соседней команды не хочет приоритезировать мою фичу, мы так не успеем!
- Есть тикет?

💨💨
- Сань, поправь там попапчик на экране доставки.
- Есть тикет?

💨💨💨
- Так, тогда договариваемся, что Аня сделает список самых тормозящих экранов к следующему спринт планингу.
- Есть тикет?

Если тикет не завести, то происходит следующее:

💨
- Петр, мне наш менеджер жалуется, что ты его фичу приоритезировать не хочешь. Чего так?
- Босс, там вообще ничего не понятно. Дизайны по фигме разбросаны (и до сих пор обновляются), вместо требований какие-то обрывки писем и диалогов в слаке. Я хз как это планировать.

💨💨
- Сань, а чего попачик на доставке старый, мы же его меняли на той неделе?
- О, это вообще прикол. Короче, тестеры не знали про это изменение и завели баг. А Юра его и “пофиксил” на старую версию.

💨💨💨
- Давайте возьмем самый тормозящий экран и пофиксим в следующем спринте. Аня, что там у нас получилось?
- Ой, а я что-то замоталась на той неделе и совсем забыла про это, прости.

Тикееет!

​Как выглядит рабочий день проджект менеджера

9:00 пришел на работу

9:27 начал работать
9:27 новых писем в почте: 9
9:39 несколько важных писем оставлю на потом, остальные прочитаны
9:40 слак
9:40 слак: эти ругаются, лучше не буду встревать, посмотрю, чем закончится
9:41 слак: тут что-то на непонятном, но вроде не про меня
9:43 слак: джависты придумали какой-то улучшайзер, молодцы! Напишу “интересная тема, давайте посмотрим глубже”
9:46 слак: аккаунт менеджер расшарил фидбек от одного из клиентов. Ну и дела! Видимо, не разобрался, как работает продукт. Надо помочь накатать ответ.

10:24 готово! Первая польза принесена, можно и кофе попить. За ночь ничего не сгорело, уже хорошие новости
10:27 таак, а что там у нас в новостях? открываем @devby
10:32 черт, у меня же 🗓️дейлик!
10:45 остаемся с тестером и разработчиком после дейли обсудить вопросы по фиче

11:03 кажется, разрабу нужен отпуск, какой-то он дерганный. Где у нас посмотреть, когда он ходил в последний раз?
11:05 слак: пишет менеджер соседнего проекта «Рома, будет 10 минут на колл?»
11:49 так, надо теперь это все в тикет оформить
11:52 ну и куда мне впихнуть эту работу? Ладно, оценим в четверг с командой, а дальше пусть продакты разбираются

11:55 так, сейчас будет 🗓️1-1 со Славой, чем он отличился за последний месяц? вспоминай
12:45 Слава, конечно, отличный разраб. Фичи пилит быстро, по пустякам не ноет и стоит адекватных денег. Надо чаще его хвалить

12:47 слак: пишет босс “Рома, а сколько вам реально надо айосников щас? У нас там новый проект стартует, мне бы Андрея на 2 месяца забрать. С возвратом.”
12:51 слак: ага, знаю я ваш с возвратом: “Стас, смотри, если Андрея снять, из критичного мы не успеем….”
12:52 слак: "аа, понял. А сможешь сделать детальный план, что у вас будет до конца года с ним и без него?"
12:52 слак: "ладно, пришлю завтра"

13:03 так, пора и пообедать. Наверное, доставку, а то на планинг не успею
13:06 надо бы подготовиться. Что там у нас в джире?
13:09 что-то мне подсказывает, что вот эту фичу мы не успеем к 10-ому числу поставить. Бахну мит на завтра, обсудить с ребятами варианты
13:42 вроде бы следующий спринт выглядит прилично, можем планировать
13:58 слак: пишет QA “Ром, сорри, не успеваю на планинг :(”. Ох уж эти студенты, который раз у него какие-то дела, возьму на карандаш
14:00 🗓️планинг
14:05 звонок в дверь. Черт, доставка! Выключить камеру
15:18 планинг завершен. Уф, 6 новых сообщений в слаке, когда вы только успеваете?

16:00 🗓️клиентский звонок
16:03 клиентский звонок: "Ваня, этот клиент придет на звонок или как?"
16:12 клиентский звонок: “Hey guys, sorry I’m a bit late…"
16:52 клиентский звонок: “Thank you for your time and efforts Gabriel, bye! Рома, Слава, останьтесь, пожалуйста, обсудим что делать по нему дальше."
17:13 новых писем в почте: 3
17:35 новых писем в почте: 0

17:43 скоро операционный синк, начну пока накидывать план по Андрею
18:00 🗓️синк
18:00 синк: “Коллеги, добрый вечер! Сегодня обсудим, как нам планировать зависимости на следующий год. У кого какие идеи?”
18:04 что-то тут не особо интересно, вернусь-ка я к плану по Андрею
18:45 синк: "коллеги, хорошего вечера!"
18:52 все, пора гасить комп, пойду проветрюсь.

21:03 уведомление в канале urgent (единственном, который не на мьюте): AllertManager: Internal DNS resolution impacting multiple services
21:04 б***, звоним Коле
22:25 ну вроде потушили, Коль, спасибо, что подключился оперативно. Завтра давай разберем после обеда.

#реклама_по_любви

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

Присмотрелся, оказалось - выборы в местный профсоюз (work council).

Все по-взрослому. Чтобы зарегистрироваться кандидатом, нужно набрать 50 голосов. Избирают на 4-летний срок.

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

Немного непривычно видеть эту систему в современной технологический компании. Но в Германии хватает таких социальных приколов.

У авторов ИТ каналов тоже есть импровизированный профсоюз. К Паше Дурову нас пока не приглашают, но мы иногда делаем полезные штуки вместе.

Сейчас тестируем новую фичу тг - папки. Это типо плейлистов, где лежит сразу несколько каналов по одной теме.

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

https://yangx.top/addlist/YvmnHCHUp700Nzky

​DORA метрики или насколько элитна ваша разработка

Я работаю в платформенной команде. Наша цель - сделать так, чтобы остальные команды перформили как ошпаренные.

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

Одни из трендмейкеров в этой области - команда DevOps Research and Assessment (DORA) из Google Cloud. Они придумали 4 главные метрики разработки:

▫️Deployment Frequency - частота поставки
▫️Lead Time for Changes - время от комита до релиза
▫️Change Failure Rate - количество багов на релиз
▫️Time to Restore Service - время на фикс бага в проде

Недавно еще добавили пятую - Reliability, но она лежит немного в другой в плоскости operational excellence.

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

У ребят много интересных материалов:
- Тест на сколько % ваша команда перформит круче других.
- Исследование производительности 33 тысяч команд (2022)
- Как влиять на каждую из метрик. Даже рассказывают, как избавляться от монолита, это прям моя текущая программа.

​Как делать предсказуемые сроки поставки

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

Вопрос, который будет постоянно волновать вашего клиента \ босса \ инвестора - когда будет готово?

Вот что нужно сделать, чтобы на него ответить:

1️⃣ Выяснить скоуп.
2️⃣ Определить Definition of Done.
3️⃣ Оценить скоуп с командой и построить расписание.
4️⃣ Зафиксировать предыдущие три пункта в джире \ контракте \ митинг ноутсах.

Прокол на любом шаге ставит проект под удар.

Например, недавно я осмелел на новой работе, и покрасил самый главный проект нашего отдела в красный (до этого никто отчетов не делал).

Все н̶е̶м̶н̶о̶г̶о̶ ̶о̶х̶е̶р̶е̶л̶и̶ высказали озабоченность. Я говорю - а какой у нас DoD? Технари отвечают - разработка новых модулей архитектуры. Продакты говорят, да, все правильно. И еще миграция и удаление старого кода (+ полгода работы). Так ведь?

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

Задача менеджера здесь - найти эту подвижность и показать всем (это еще называют visibility).

Поэтому, чтобы ваш клиент \ босс \ инвестор не высказывал озабоченность, сделайте для него еще вот эти два пункта:

5️⃣ Настройте трекинг.
6️⃣ Отправляйте отчеты по срокам раз в неделю.

С такой системой ваши сроки будут предсказуемыми.

————————————
#реклама_по_любви

Чтобы сроки ехали реже, нужен сильный тимлид. Это главный друг ПМа. Он и команду замотивирует, и скоуп нарежет ровно и риски увидит рано.

Классные тимлиды, многих из которых я давно читаю сам, сделали вот эту папку с каналами:
https://yangx.top/addlist/mDWR2gD6UEhlOWRi

Добавляйте, читайте, попадайте в сроки 😉

​Приглашение на интервью

Приглашение на интервью в СНГ:

- Приходите на интервью.
- Хорошо.

Приглашение в Европе:

​Статусы проектов и план спасения

У нас в компании на этот год запланировано 600 OKR-ов. Чтобы СТО не потратил целый день, просматривая их все, а понимал большую картину по поставке, за которую он отвечает, сделали статусы. Всем OKR (считай, проектам) ставят статус, а затем строят разную статистику на этой основе. Такие есть в любой организации, где работает 300+ человек.

Бывает 3 статуса:

🟩Зеленый: Проект on track, все риски понятны и есть митигейшн план.

🟨Желтый: У проекта есть блокер или большая неопределенность, но есть четкий план, как вернуться к зеленому.
Например: Нашли неучтенный кусок работы для команды Х, из-за которого может поехать дата релиза.

🟥Красный: У проекта есть блокеры или неопределенность, из-за которых он пропустит дедлайн, а также нету согласованного плана спасения.

Последний как раз и представляет наибольший интерес.

Большая часть работы ПМа - придумывать такие планы. Или как ему не оказаться в желто-красном статусе, что в сущности, одно и то же.

Залог хорошего плана спасения - понятные шаги, благодаря которым блокеры растворятся. Например:

1. Что делаем: анализируем, что из неучтенного куска влияет на OKR и составляем technical proposal вместе с командой Х.

2. Кто именно отвечает за действие: тимлид Ваня.

3. В какие даты: 24-30 мая.

4. Какие критерии того, что проект снова будет зеленым: команда Х подтвердила доп. работы и успевает их выполнить к дедлайну по OKR.

5. Что делать, если проект остается желтым или красным: пересмотреть другие фичи из OKR, чтобы вместить неучтенный кусок.

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

В маленькой компании эта бюрократия чаще не нужна. Хотя методы работают те же:

​Этикет видеозвонков

Несколько советов, которые сделают из вас английского лорда (или леди) в сфере видеозвонков.

Нормально:
🎩Пить кофе или воду.
🎩Сидеть без камеры, когда у всех тоже выключена камера.
🎩Заходить на звонок с выключенным микрофоном.
🎩Raise hand, когда хочешь что-то сказать.
🎩Написать в чат “sorry I’m late”, если опоздал и дискуссия уже началась.

Не смертельно, но лучше бы не:
🗿Совмещать звонок и обед, выключив камеру.
🗿Совмещать звонок и ответы в слаке, почту.
🗿Включать запись звонка без предупреждения.
🗿Звонить за рулем \ на прогулке \ из спорт зала в рабочие часы.
🗿При демонстрации экрана виден кусочек переписки в слаке или телеге.
🗿“Коллеги меня слышно? Видно мой экран?”. Когда что-то заглючило, конечно, не в счет. Просто проверьте перед звонком на всякий.
🗿Когда за спиной ходит кто-то из домашних.
🗿Логиниться на рабочий звонок с личного аккаунта.
🗿Сидеть без камеры, когда все с камерой.

Неприлично:
🙈Оставлять включенным микрофон, когда не говоришь, и все слышат это шуршание.
🙈Перебивать.
🙈Курить сигареты (вейпы, электронки, айкосы, шмайкосы).
🙈“Ваня, что ты думаешь по этому поводу?”, а в ответ - тишина. Ваня куда-то отошел, но все еще висит на звонке.

См. также: Календарный этикет

​Прогулочные встречи

У нас в компании продвигают прогулочные встречи. Это когда вместо переговорки идешь митинговать на улицу.

HRы нарисовали карту района вокруг офиса, обозначив маршруты на 15, 30 и 45 минут. Удобно, что не надо думать, куда идти и сколько времени закладывать, чтобы вовремя успеть обратно.

Я так сходил на несколько встреч, мне понравилось. Вроде бы и поработал, и очков здоровья немного собрал, размялся. Для 1-1 это отличный формат.

Правда, когда идут 3+ человека, то уже не всех хорошо слышно из-за перемещения. И, конечно, встречи, где нужен экран или какие-то материалы, так не проведешь.

Еще один минус лично для меня, это сниженная концентрация. Постоянно надо смотреть, куда шагаешь, чтобы не попасть под велосипед или самокат. Думать одновременно с этим сложнее.

Напишите в комментах, как вам формат, если попробуете.

​3 истории из немецкого ИТ

В Германии любят процессы и правила. Моя компания по культуре ближе к американской и немцев у нас мало. Поэтому, кроме подробной должностной инструкции, я с этим пока мало сталкивался.

А вот в компании моего друга Мити полно немцев. Он поделился любопытными историями.

История 1
В один из спринтов к нам приходит фича, в которой есть бек и фронт. Вся команда по уши в других задачах, кроме одного разраба. А он как раз фуллстек. Сидим мы с тимлидом, и планируем следующий спринт:
- Петер, давай Алексу дадим эту фичу, он как раз освобождается.
- Можно, а кого поставим на бек?
- Его же и поставим, он же джаву тоже знает.
- Ну знает, и, что?
- Так если знает, то почему бы ему не сделать сразу и фронт, и бек? Будет быстрее, не надо двум девам синхронизироваться, все в одной голове.
- Митя, Алекс по контракту фронтэнд разработчик. Мы не можем давать фронтенд разработчикам задачи по беку, даже если они могут их сделать.

---

История 2
Наш СЕО любитель полировать интерфейс. Все время отбиваюсь от его улучшалок с пометкой срочно.

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

As a user I want to change the fonts, as they look ugly.

---

История 3
Я стараюсь максимально расписывать задачи, чтоб команда потом не бегала с вопросами. Добавляю контекст, бизнес ценность и все детали.

После очередного тех ревью, открываю один из тикетов и читаю: Rejected, as acceptance criteria are missing.

В задаче действительно пустые AC, но зато все описано в description. Думаю, ладно. Делаю копи-пэйст из description в AC и пишу тимлиду:
- Так пойдет?
- Да, теперь все ок, можем брать в работу.

---

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

​Fix price flexible scope модель или как совместить бюджет и эджайл

Часто заказчики не знают точно чего хотят. У них есть лишь примерное видение продукта. Они буквально приходят и говорят: “Постройте нам что-то типо X за 100К”.

Fix price модель не подходит для такой работы, потому что по дороге будет слишком много изменений и проводить их через change request - боль для всех.

Time & material тоже не оч, ведь есть жесткий бюджет, превысить который клиент не может.

В этом случае на помощь приходит модель fixed price, flexible scope (FPFS). Иногда ее еще называют “T&M с крышкой”.

В ней мы берем лучшее от обеих моделей. Фиксируем бюджет, за который проект не выйдет, как в fixed price. При этом позволяем клиенту менять scope в лучших традициях T&M и эджайла.

Как это работает (коротко)

1️⃣ Выделяем 4 фичи из 10, без которых нельзя запустить проект. Обещаем их поставить.
2️⃣ Разрабатываем по скраму, Канбану, XP, да хоть стоя на голове.
3️⃣ Фокусируемся на 4 фичах и делаем их, скажем, за 60% бюджета
4️⃣ Оставшиеся 40% тратим на полировку, 6 других фич или новые фичи, которые осенили клиента по дороге.

Как это работает (подробно)

Flexible scope
Главное, что нужно сделать для FPFS модели - определить, какой scope нельзя выкинуть ни под каким соусом. С этим обычно проблем нет, клиенты даже на старте проекта знают, что вот эти 4 фичи нужны кровь из носа, а остальные можно пустить под нож (flexible scope).

Спецификация, как в FP не нужна, достаточно нескольких высокоуровневых критериев приемки. Их добавляем в контракт.

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

Хотим добавить новые фичи? Не проблема - добро пожаловать в беклог.

Хотим приоритезировать новые фичи в следующем спринте? Мелочь за 2 стори поинта - может быть. Все остальное - извините, нет. Сначала мы сделаем наивысший приоритет, а потом все остальное.

Fixed price
Добавим щепотку проджект-менеджмента, чтобы уложиться в бюджет.

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

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

Оценку можно дать в часах, стори поинтах или спринтах. Любой формат, в котором потом будет удобно следить бюджетом.

Команда у нас постоянная, поэтому burndown (скорость съедания бюджета) тоже. Например,

100K (budget) / 10K (burndown) = 10 sprints (total budget)

Если из груминга мы узнали, что 4 фичи займут 6 спринтов, то еще 4 спринта у нас есть в запасе на остальной скоуп.

Теперь каждый спринт мы считаем, сколько денег потрачено и сколько работы осталось. Расход трекаем через release burndown chart, earned value или обычный эксель.

В конечном итоге FPFS - компромиссный вариант между FP и T&M. Он удобен и заказчику, и исполнителю.

В fixed price менеджер постоянно на нервах, думает, где бы срезать скоуп, чтобы попасть в бюджет. В time & material, наоборот, в проект затягивают любые фичи и доработки, лишь бы выжать побольше денег из клиента.

FPFS не тянет проект ни в какую из сторон, позволяя больше фокусироваться на ценности, которую мы поставляем с продуктом.

P.S. для продукта эту модель тоже можно использовать. Тут она подходит для проектов типо "надо запустить акцию к 8 марта".

Как я попал в айти

Иногда этот вопрос задают в комментах, поэтому давайте всем расскажу.

🎓Универ

Я закончил Мех-Мат БГУ. Из него в ИТ мне пригодились 2 навыка:

▫️базовое понимание программирования. Могу перемножить 2 матрицы на С++ и джаве. От современного программирования это далеко, но принципы знать полезно.
▫️умение находить обходные пути. Этот скилл рос с каждым экзаменом, ведь сдать функциональный анализ очень сложно, когда ты его не понимаешь. Значит надо искать воркэраунд, например: ходить на все пары, написать шпоры или сдать все лабы (взяток не существовало). Иногда этого хватало, чтобы получить минимальную оценку и не вылететь.

🏦 Банк

На 4 курсе я устроился в ИТ отдел банка. У нас была десктопная программа Bank-IT, типо банковской апы на телефоне, только для юрлиц. Я ездил устанавливать ее на компьютеры, объяснял, как делать платежи и отвечал на звонки, когда у клиентов что-то не работало. Клиенты были очень разные - от директоров птицефабрик до парикмахеров-ИПэшников.

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

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

Тогда я решил, что тоже так могу, и нашел свою первую работу бизнес-аналитиком за 400$ в месяц. Это было 24 июня 2013 года. В почте мейлру даже нашелся тот самый первый оффер.

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

🧑‍💻 Веб-студия

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

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

Еще я настраивал контекстную рекламу в гугле и яндексе. Помню как чел, которому мы за 300$ в месяц настроили рекламу, иногда звонил и говорил «Рома хули у меня сегодня мало звонков?». Тоже школа управления ожиданиями своего рода.

Правда, как аналитик я рос слабо. Проект на 200 часов считался уже серьезным предприятием, а на такой мелочи сильно не прокачаешься. Самое серьезное, что я делал, были спеки для внутренней CRM-ки (так и не запустили) и UX-прототип для большого музыкального магазина.

Требования и интерфейсы мне нравились, но в компании не было ПМа.

👼 PM is born

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

Оценка моего скила доросла до космических 1200$ в мес. Для стоимости жизни в Беларуси тех лет, это был успех (так мне казалось).

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

Пожалуй, самой крутой конторой в то время считался Wargaming, которая делала культовую игру World of Tanks. Я подавался несколько раз и однажды даже прорвался на собеседование на релиз-менеджера. Но мои технические знания были слабыми, поэтому получил ожидаемый отказ.

Однако их хватило для Softeq - первой аутсорсинговой компании, в которой я работал (из двух). Тут уже были хорошие проекты по разработке на 3-5К часов, но это уже совсем другая история.

​P.S. Одной из причин, почему меня взяли в Softeq, был сильный английский. Коротко расскажу, как я его выучил:

- в школе 6 раз в неделю;
- потом в универе 4 года;
- ездил в штаты 4 раза, к клиентам и по work & travel;
- музыка, фильмы, конечно;

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

Кроме шотландцев, их хрен разберешь. 

2013 >>

​Что такое программа

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

Программа - это мега-проект, у которого под капотом несколько проектов поменьше, объединенных одной целью, которые делают несколько команд.

Например:

1️⃣Мигрировать базу пассажиров Uber с Amazon на Oracle. Представьте сколько команд пользуются данными пассажиров в убере, десятки! Даже просто найти эти команды уже непростая задача.

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

2️⃣Сделать фичу кошелек в Wolt.
В такой программе тоже десятки команд: платежи, маркетинг, комплайенс, CRM, customer success…и это мы даже до инжиниринга не дошли :)

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

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

В следующих постах расскажу в чем отличие программы от проекта, и что делает програм-менеджер.

​Чем программа отличается от проекта

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

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

Программа - это проект на стероидах. Окей, вместо 6 человек, которые делают 5 фич, будет 60 человек и 50 фич. Но главное не меняется - им все еще нужно поставить ценность в каких-то ограничениях.

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

И вот как раз здесь, появляется существенное, на мой взгляд, различие:
❗️Программам нужен продуктовый подход.

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

Я вам этого всего, конечно, не говорил :). Если где-то спросят о разнице между проектом и программой, отвечайте примерно так:

​Как понять, кто перформер, а кто нет

В небольшой команде все варятся в общем информационном пузыре. Народу мало, проектов мало, все на виду. Если новый лид айосник оказался лодырем, это быстро станет заметно.

В большой не так, здесь легко затеряться.

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

Для тех, кто делает пипл менеджмент такая непрозрачность, это большая проблема.

Есть классный инструмент, который ее решает - Small Improvements. Его главный функционал - написать публичный комплимент о коллеге.

В линкедине вы наверняка видели посты со словом Kudos, когда люди хвалят друг друга и выражают признательность. Тут то же самое.

Лид айосник сделал классный tech proposal новой фичи - напиши ему Kudos, чтобы все знали, какой он красавчик. Менеджер из другой команды быстро сделал то, что вы просили (в отличие от других менеджеров-бездельников) - Kudos. Продакт провел крутой воркшоп без воды и соплей - Kudos. Так ты “хвалишь при всех”, причем сразу на всю компанию.

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

Люди не станут просто так хвалить друг друга за фигню (если вы не привяжите кудосы к kpi, конечно). Если пишут, то за дело. Получается честный, справедливый и адресный фидбек.

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

В Small improvements кроме Kudos есть еще функционал 1-1, перф ревью, 360 фидбек и всякое такое. Но наверняка, есть и другие хорошие сервисы с Kudos. Напишите в комментарии, если пользовались такими.

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

UPD: в комментах многие пишут, что в их компании такой подход не работает (спасибо, что делитесь опытом 🤝). Кудосы получают не реальные герои, те, кто общается с большим количеством людей или просто более говорливые и харизматичные люди.

Я думаю, это вопрос культуры. А любая культура всегда идет сверху.

Чтобы система работала, менеджеры должны:
- хвалить за успехи и результаты, а не ожидаемую работу или просто "спасибо";
- постоянно писать кудосы своей команде;
- напоминать писать кудосы другим;

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

​Английские сокращения, которые встретятся на работе за рубежом

🇬🇧 ETA - expected time of arrival.
Начнем с любимого вопрос менеджеров - когда будет готово?

🇬🇧EOD - end of day.
- Какой ETA у этой фичи?
- EOD.
Аналогично, EOW - end of the week.

🇬🇧СС - carbon copy.
Никто не расшифровывает СС, а просто ставят в копию:
Вы охренели, не сделали мою часть проекта! СС @Василий_Петрович.

🇬🇧 FTE - full-time employee.
Если в команде 2 разработчика фуллтайм, и 1 на пол-ставки, то говорят что в команде 2,5 FTE.

🇬🇧PTO - paid time off.
Не знаю, честно говоря, зачем тут делать упор на paid, но часто слышу, что так говорят. Особенно, в контексте parent leave.

🇬🇧OOO - out of the office.
На следующей неделе я буду в отпуске, так что все вопросики направляйте Василию Петровичу и держите меня в СС.

🇬🇧BRB - be right back.
Когда на звонке все сидят с включенными камерами, а к тебе в дверь звонит курьер и надо его встретить. Тогда ты пишешь в чате brb, как бы шепча всем присутствующим на ушко “я отойду на минутку, ща буду”, чтобы никто не дай бог не подумал, что тебе просто надоело слушать.

🇬🇧TBD - to be determined.
Так можно написать, когда, например, вы определились с датой релиза для фазы 1, а вот фаза 2 пока хз (TBD) когда будет готова.

🇬🇧WDYT? - what do you think?
Помню, как впервые увидел это в чате и подумал, wtf? Потом погуглил, и узнал, что это просто сокращенное что думаешь?

🇬🇧LMK - let me know.
Почти то же, что и wdyt.

🇬🇧FYI - for your information.
К твоему сведению….только не такое формальное.

🇬🇧IDK - I don’t know.
Я хз кароч.

🇬🇧AFAIK - as far as I know.
Насколько я знаю.

🇬🇧nvm - nevermind.
Забей.

🇬🇧ty, thx - thank you, thanks.
Если thx еще можно догадаться что такое, то с ty я орал, когда узнал что это просто спасибо.

🇬🇧dm - direct messages.
Цену отправил в лс (dm).

​Как окупаются тимбилдинги и корпоративы

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

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

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

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

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

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

Я смотрю на тимбилдинги, как на возможность понетворкать (так же, как и на конференции). А нетворк - это моя забота. Если я хочу работать в этом месте, то для меня важны люди и контакт с ними, важно выстраивать эти связи. Это мне надо. Отношения, это вообще большая часть работы менеджера.

А раз так, то и на лазертаг меня зовите, и на картинг.