Асинхронные стендапы

Я долго работал в синхронных стендапах - когда все приходят на встречу в комнату или зум и проходят по статусу.

В Hellofresh я увидел, как несколько команд проводили дейли в асинхронном формате. Результат выглядел не хуже.

Механика такая: каждое утро бот пишет сообщение в канал “Это дейли митинг команды Х 👇”, и каждый ему отвечает стандартное: что сделал, что будет делать, блокеры.

Иногда был гибридный формат: все пишут статус в слак, но дополнительно можно придти на стендап, чтобы обсудить текущие вопросы.

У такого формата много плюсов:

📌Все экономят время и ментальные силы (ура, не нужно разговаривать!)

📌Всё задокументировано. Можно легко откатиться и посмотреть, что человек делал 4 дня назад.

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

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

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

А как у вас?

Менять команды под новые проекты - норм

В Хеллоуфреш команды постоянно меняются. В соседнем отделе, с которым мы плотно работаем, 4 команды перекраиваются с ног на голову второй год подряд.

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

Для людей это, конечно, стресс: новая команда, новый менеджер, новые процессы. Поэтому такие редизайны происходят нечасто, +- раз в год.

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

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

Теперь думаю, что команды создаются под конкретные цели. Цели меняются, поэтому и команды могут меняться. Надо это просто принять.

Как улучшить любой документ на 5% — добавить Шапку

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

Заметил штуку, которая помогает мне лучше понять судьбу и контекст документа — шапка.

Шапка, это табличка в самом верху, в которой есть следующая инфа:

----------------
Название: Выделенный сервис для картинок.

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

Создан: 11-07-2024 (вот сюда смотрю в первую очередь, чтобы понять, насколько неактуальным будет док).

Статус: В ревью

Джира: PLAT-315

Авторы: Григорий Вишневский, Валентина Ковалева

Ведущая команда: Платформа
----------------

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

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

Первое правило проекта, который тебе передают

- переоцени проект силами текущей команды.

Люди, которые продают проекты, часто занижают оценки, чтобы предложение выглядело выгодным для заказчика или руководства. Закрывают глаза на риски или предполагают, что будет работать команда из 9 сеньоров, которые умеют рожать по ребенку каждый месяц. Такие проекты легко продавать, но больно потом делать. И больно обычно ПМу.

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

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

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

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

Если быть «удобным менеджером» и соглашаться на все дедлайны как есть, то рискуешь завалить проект еще до старта.

Фулстек менеджер

Есть фулстек программисты, а бывают ли фулстек менеджеры?

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

Пожалуй, главный минус этого подхода в том, что из-за огромной области знаний, не хватает времени глубоко погрузиться ни в одну из них. Значит, пострадает качество. Без глубоких знаний продакт будет еще большим генералистом. А ведь на сениор позициях, наоборот, решает специализация и часто выделяют growth pm, AI pm, tech pm и тд. А тут получается супер-генералист.

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

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

1️⃣ стартапы из 10 человек, где надо экономить каждую копейку.
2️⃣ команда в 3-5 человек, где для менеджера нет фуллтайм загрузки.
3️⃣ сильная команда, которая сама может качественно закрыть большую часть вопросов по деливери и продукту.
4️⃣ проект, где мало неопределености, например, 80% работы - интеграция с новыми партнерами или копирование функционала конкурентов

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

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

Интересно узнать, кто еще так делал. Какие встретили проблемы? Почему отказались от такой модели или, наоборот, развили?

💬Поделитесь опытом в комментариях.

Тренажер по распределению задач

Нашел классный тренажер по управлению ресурсами:

http://thatpmgame.com/

Это мини-игра на 3-5 минут на основе диаграммы Ганта. Цель игры - раскидать задачи по сотрудникам так, чтобы проект уложился в бюджет и сроки.

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

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

Смысл
Игра учит базе управления проектами:

🤌 меньше людей работает -> меньше бюджета тратишь;

🤌 таски на критическом пути лучше делать быстро и не рисковать ими;

🤌 как ни оценивай, одни задачи все равно пойдут быстрее, а другие медленнее;

🤌 люди выгорают, если работы дофига;

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

Для ПМов с опытом, сколько проектов закончите “зелеными”? Я зафейлился на пятом.

План на 3-5-х лет

На ПМ совете часто слышим такую боль от ПМов:

я не понимаю, что мы будем делать через Х месяцев

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

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

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

📌Планы пишут продакты и инженерные менеджеры уровня директор и випи; их согласуют СТО и СПО.

📌Планы на 3-5 лет - это 3-5 страниц о том, каким мы видим светлое будущее.

📌Годовой план уже гораздо детальнее: 30-40 страниц со всеми инициативами, метриками, ресурсным планом, зависимостиями и т.д.

📌Планы отделов связаны между собой.

📌Апеляция к долгосрочноу плану - сильнейший аргумент в любом споре.

К сожалению, такие планы не всегда бывают доступны менеджеру.

Однажды на собес в топовую продуктовую компанию Минска, я спросил какой у вас план на год. Ответили, что мы максимум планируем на 3 месяца. Я тогда приуныл, не понимая, как можно не знать, что за поворотом, когда на тебя работает 300+ человек. Но некоторые продукты ищут маркет фит и это ОК. В заказной разработке клиенты тоже неохотно делятся планами из-за NDA.

💬В вашей компании есть планы на 1+ год вперед? Поделитесь в комментариях, насколько они полезны для вас.

Работа в Германии vs СНГ

Весной я рассказывал, какими вижу отличия работы в Германии от СНГ.

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

Получилась такая статья: https://devby.io/blogs/posts/BY-vs-DE

⚡️Несколько хайлайтов.

Катя, программистка:

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

Мiця, продакт:

Добрыя тэхнічныя ліды ў беларускім аўтсоры тут пачыналі з пазіцыі Senior Dev. Але гэтае адставанне можна нівеліраваць за гады 2-3, і потым ужо добра пачувацца на еўрапейскім рынку.

Леша, инжинирнг-менеджер:

Больше денег предлагают успешные стартапы и ИТ-гиганты. Важно договариваться на комфортный уровень компенсации во время собеседования. Дальше зарплату сильно не повысят. Только при повышении по карьерной лестнице.

Читайте, комментируйте, приезжайте на работу или на кебаб 🥙

Сколько зарабатывают айтишники в Германии 🇩🇪

Зарплаты ниже – это annual gross base salary в евро. То есть, грязная годовая зарплата до всех отчислений (налоги, страховки), без бонусов и акций. Чтобы было легче ориентироваться, следом приведена зп на карточку для 1-ого налогового класса.

Продакт
▫️product manager: 76,350 ~ 3,877 в месяц на руки
▫️senior: 90,860 ~ 4,474 в месяц
▫️lead: 97,000 ~ 4,691 в месяц
▫️principal: 140,200 ~ 6,696 в месяц
▫️director of product: 123,750 ~ 5,933 в месяц

Проджект
▫️project manager: 63,250 ~ 3,278 в месяц
▫️senior: 78,250 ~ 3,960 в месяц
▫️lead: 84,600 ~ 4,229 в месяц
▫️senior program manager: 99,200 ~ 4,793 в месяц

Разработчик
▫️software engineer: 75,000 ~ 3,817 в месяц
▫️senior: 92,300 ~ 4,538 в месяц
▫️principal: 109,800 ~ 5,285 в месяц
▫️director of technology: 140,400 ~ 6,705 в месяц

Тестировщик
▫️quality engineer: 56, 500 ~ 2,984 в месяц
▫️senior: 64,000 ~ 3,314 в месяц
▫️QA manager: 60,900 ~ 3,173 в месяц
▫️QA automation: 64,850 ~ 3,354 в месяц

Дизайнер
▫️UX designer: 53,000 ~ 2,832 в месяц
▫️senior: 73,000 ~ 3,728 в месяц
▫️product designer: 62,700 ~ 3,252 в месяц
▫️serion product designer: 76,900 ~ 3,901 в месяц

❗️Дисклеймер:

1. Чем выше зп, тем выше налоги. При заработке 66К и больше – налог будет 39%. Welcome to Germany 🥨

2. Процент налогов отличается в зависимости от семейного положения и заработка партнера. Больше всех налогов платят холостые (1-ый класс), для них и приведен расчет. Меньше всех – женатые с детьми, у них будет почти на 20% больше чистыми. Вот тут можно посчитать разницу между налоговыми классами.

3. Чем выше роль, тем больше будет бонусная часть – акции и бонусы. То есть, например, сениор продакт зарабатывает 80 base и 10 stock, а директор 90 base и 30 stock. Учитывая, что акции выдают постепенно в течение 3-4 лет, разница в том, сколько на руки получает директор и сениор не такая уж и большая: 400-600 евро в месяц. Ответственности при этом в разы больше.

4. Как и на любом большом рынке, немецкие компании можно условно разделить по классам (tier). Google, Amazon, Github, Spotify, Stripe – это tier-1, в них будет максимальная зп на рынке. Переходить из одной в другую легко, они хорошо засчитывают опыт друг друга. Tier-2 уже попроще, сюда входит мой HelloFresh, а еще Klarna (которые уволили 700 человек одним видео), N26, Soundcloud, Wolt, Zalando. По сравнению с tier-1, здесь платят процентов на 30 меньше. Вот тут больше про tiers.

5. ЗП отличается по городам. Например, полная компенсация для сениор продакта в Берлине – 93К, во Франкурте уже 87К. Самый топ в Берлине, Мюнхене и Гамбурге.

6. Разные сайты по-разному считают зп: кто-то base, кто-то total (base + stock + bonus). Обращайте на это внимание, чтобы ожидания совпали с реальностью. Я ориентируюсь на эти ресурсы: levels.fyi, glassdoor.de, ksyula.github.io/Salary-report, payscale.com/research.

Читайте также: соцпакет в немецком ИТ 🍪

Этикет в переговорках

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

🎩Если ты один – бери самую маленькую переговорку из доступных.

🎩Если вас двое – бери переговорку на 2, максимум 4 человека. Не бери комнату на 10.

🎩Если тебе нужно 4 часа сфокусированной работы, чтобы никто не мешал – не бери переговорку для этого.

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

🎩Выключай свет, когда уходишь. Ледники тают, алло.

🎩Принес кофе, воду, распечатки в перговорку? Унеси кофе, воду, распечатки из переговорки.

🎩Был напряженный мит с пятью джавистами? Открой окно проветрить напряженность.

🎩Если комната забронирована до 14.00, выходи до 14.00, максимум в 14.01. Не заставляй других неловко приоткрывать дверь и просить тебя свалить.

См. также:

🎩​Этикет видеозвонков
🎩​Календарный этикет

Поиск у нас vs зарубежом

2 года назад я писал о том, как искал работу в Европе. Тогда за полгода я получил 4 оффера и выбрал работу в HelloFresh, переехав в Берлин.

Несколько ребят писали потом в личку, что посты помогли им понять отличия рынка СНГ от западного и скорректировать тактику поиска. Мне дико приятно получать такие сообщения и быть полезным для вас. Это одна из причин почему я веду этот канал уже 6 лет.

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

Хочу исправить одну вещь, которую не сделал тогда – собрать все посты в один, чтобы ими было удобно пользоваться.

Итак, вот все, что вам нужно знать о поиске ПМ работы зарубежом:

📌Выбор страны
📌Доменные знания и местный опыт
📌На каких сайтах искать вакансии
📌Как находить рефералов
📌Что делать, когда компания мечты не отвечает
📌Шаблон резюме
📌Как адаптировать резюме под вакансию
📌Сопроводительное письмо
📌Как составить линкедин, чтобы его лучше находили рекрутеры
📌Сходи на тренировочные интервью
📌Что и где узнать о компании перед интервью
📌3-8 стадий интервью на менеджера
📌Примеры вопросов на интервью
📌Шпаргалка с ответами на популярные вопросы
📌Meeting notes после интерьвю
📌Что писать, чтобы дали фидбек после интервью
📌Зарплата в Европе (2022)
📌Сколько зарабатывают айтишники в Германии (2024)
📌Как использовать несколько офферов

Отправляйте этот пост своим друзьям и успехов с поисками!

Фича флаги

Фича-флаг (ФФ, фича-тогл) - кусочек кода, if-else условие, которое запускает параллельные сценарии приложения. Один сценарий (if) - пускает пользователя в новую фичу, другой (else) - прячет ее, запуская старый флоу.

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

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

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

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

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

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

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

Если думаете о том, что пора внедрять ФФ, вот несколько популярных сервисов: Unleash, LaunchDarkly, Optimizely, Statsig. Не уверен, кто из них еще работает в СНГ, если знаете другие топовые - напишите в комменты.

Если глубже погрузиться в тему тогглов, вот две хорошие статьи: статья_1, статья_2.

Оценка по трем точкам (​PERT)

PERT - это метод оценки проектов, его еще называют оценка по трем точкам.

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

Чтобы сделать оценку по PERT нужно найти 3 оценки:

- оптимистичную (O)

- пессимистичную (P)

- наиболее вероятную (M).

и посчитать по формуле:

PERT = (O+4*M+P) / 6

Допустим, мы получили оценку O = 5 дней, P = 15, M = 7. Тогда наш PERT = (5+4*7+15) / 6 = 8 дней.

С точки зрения математики эта формула говорит, что мы попадем в оценку 8 дней с вероятностью 68%. Или можно сказать, что с вероятностью 68% мы завершим задачу в промежутке между 6,3 и 9,7 дней (более подобные расчеты в этом примере).

Для большинства оценок этого будет достаточно. Берём верхнюю границу 9,7 и идем делать проект.

Но иногда заказчик требует большей точности, например, добавляя в контакт большие штрафы за вылет. Тогда можно обезопасить себя, заложив больше рисков и сказать, что с вероятностью 95% мы завершим задачу между 4,6 и 11,3 дней. Либо, если прям ракеты в космос запускаете, можно заложить 99,7%, что уложимся в промежутке между 3 и 13 дней.

Даже если вам не особо важны точные оценки, от PERT все равно есть польза. Он приглашает команду продумать возможные риски, пессимистичный вариант. А уж это ни одному проекту не повредит.

Телеграм чат для работы - плохая идея

Самая большая проблема в том, что стирается граница между рабочим и личным.

Вот представь, вторник, 19.00, ты закрыл рабочий ноут, открыл личный комп и спокойно пошел смотреть Наследников. Скроллишь мемы, читаешь новости, в общем, отдыхаешь как нормальный айтишник. И тут в рабочем чате вот такое превью:

“помните джависта Сашку, который положил прод на первой неделе испыта? его жена ….”

Чат можно и не открывать, но ты уже забайчен и начал вспоминать Сашку. А вместе с ним и мониторинг прода, который вы, кстати, так и не прикрутили. Надо бы найти в беклоге. Интересно, а чем сейчас лучше всего делать мониторинг?...

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

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

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

Если формируете новую команду и выбираете мессенджер - не берите телегу.

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

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

Еще более радикальное средство - попросить для работы отдельный комп. Его даже можно оставить в офисе!

Интро к ретроспективе

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

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

Смысл в том, что во время ретры мы не ищем виноватых, а ищем возможность что-то улучшить.

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

Я еще иногда добавляю от себя такое:

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

Что делать, если заказчик просит подвинуть сроки

Несколько советов из книги для подготовки к PMP:

Сделать важное или что обещал?

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

Первый проект мы пoобещали сделать другой команде еще в начале года, но переносили уже несколько раз. И вот, за неделю до старта, продакт приносит команде второй проект – новый, красивый, с очень многообещающим результатом.

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

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

В таких ситуациях важно отключать человека и включать продакта – безжалостно выбирать важное над всем остальным. Что мы и сделали.

Менеджеру (и мне тоже), надо запомнить, что план – это не гарантия. План – это план. То что в нем написано, необязательно сбудется, хоть мы и очень постараемся. Реальность постоянно подкидывает нам новые вводные, которые могут наш план менять. И то, что было запланировано год назад, не факт что будет сделано. И это нормально!

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

Не так страшны первые 80% проекта, как вторые 80%

⁃ бородатая поговорка проджект-менеджеров.

Cмысл ее в том, что иногда цель дальше, чем кажется.

Бывает, что проект вылетает по срокам или бюджету. Скажем, сделали 80% запланированного, а потратили 90% ресурсов (времени или денег).

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

В жизни так бывает, но редко.

Чаще риски продолжают возникать: еще один кусок работы не учли, снова разработчик заболел, опять клиент перестал отвечать на вопросы.

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

*временное сообщение

вам в личку могут написать якобы другие подписчики моего канала

спросят в духе "покупали ли вы мои консультации / курсы и насколько они вам понравились"

⚠️это скам

если начнете отвечать, в конце предложат курсы по трейдингу

спасибо всем, кто проявил бдительность и написал в личку 🤝