Менеджер от боженьки

Как улучшить любой документ на 5% — добавить Шапку Работая менеджером в большой компании приходится читать кучу документов. Технические дизайны, продуктовые требования, миграционные стратегии — тыщи их. Часто, это документы по 20-30 страниц от команд, о которых ты имеешь весьма поверхностное представление. Заметил штуку, которая помогает мне лучше понять судьбу и контекст документа — шапка. Шапка, это табличка в самом верху, в которой есть следующая инфа: ---------------- Название: Выделенный сервис для картинок. Саммари: Мигрируем все имеющиеся в каталоге картинки в отдельный сервис, чтобы снизить время отклика у пользователя и инфраструктурные затраты. Создан: 11-07-2024 (вот сюда смотрю в первую очередь, чтобы понять, насколько неактуальным будет док). Статус: В ревью Джира: PLAT-315 Авторы: Григорий Вишневский, Валентина Ковалева Ведущая команда: Платформа ---------------- Когда открываю доки без шапки, которые начинаются с текста инициативы, то сразу возникает миллион вопросов: кто это писал, пошло ли в работу и т.д. В маленькой компании, где работает несколько команд, пожалуй, такие шапки добавят не очень много пользы — все и так плюс-минус знают, проекты в работе. Но когда продукт большой и команд десятки - это очень полезная вещь. Рекомендую.

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

#реклама Представьте,что вы тимлид команды художников работающих над игрой «Герои царства Подземелий». Один из сотрудников сообщает вам, что кое-кто из художников начал использовать в своей работе ИИ, несмотря на «неофициальную» просьбу арт-директора этого не делать. Пока непонятно какие угрозы может принести утечка информации о том, что ваша компания применяет в работе ИИ. Никакой официальной директивы на запрет использования ИИ для решения креативных задач в компании нет. Вы встретились с нарушителем, но несмотря на вашу просьбу не использовать ИИ для создания артефактов, он продолжает это делать. Просьбы он рассматривает как ограничение его роста и возможности творческого самовыражения. За свою позицию он не держится, но является для вас ценным кадром, поэтому, вы не хотите его терять. Остальные члены команды также в курсе происходящего и появляется угроза того, что скоро все последуют примеру упрямого художника. Вы не хотите ограничивать творческую свободу сотрудников, но в то же время понимаете, что оставлять происходящее без внимания нельзя. Как вы решите ситуацию, чтобы сотрудник не ушел, команда не была демотивирована и бизнес не пострадал? Такие и подобные ситуации «Стратоплан» предлагает решать в открытом, бесплатном проекте «Университет: Конфликтология» 👉Регистрация здесь Формат: — 2-х недельная онлайн практика по переговорным поединкам в Zoom — абсолютно бесплатное участие группами от 5 человек — личный кабинет с пожизненным доступом к записям, если что-то упустили и возможность получить ответ от тренера в прямом эфире 📆Старт 8 июля. Регистрируйтесь по ссылке и приходите учиться конфликтовать конструктивно!

Асинхронные стеандапы Я долго работал в синхронных стендапах - когда все приходят на встречу в комнату или зум и проходят по статусу. В Hellofresh я увидел, как несколько команд проводили дейли в асинхронном формате. Результат выглядел не хуже. Механика такая: каждое утро бот пишет сообщение в канал “Это дейли митинг команды Х 👇”, и каждый ему отвечает стандартное: что сделал, что будет делать, блокеры. Иногда был гибридный формат: все пишут статус в слак, но дополнительно можно придти на стендап, чтобы обсудить текущие вопросы. У такого формата много плюсов: 📌Все экономят время и ментальные силы (ура, не нужно разговаривать!) 📌Всё задокументировано. Можно легко откатиться и посмотреть, что человек делал 4 дня назад. 📌Не нужно искать компромиссное время, если работаете в разных часовых поясах. Гланый минус - у команды снижается вовлеченность и контакт друг с другом именно потому, что люди теперь реже разговаривают. На живых стендапах то кота увидят в камере и все оживятся, то про отпуск в Грузии тимлид расскажет. Такие разговоры помогают людям узнать друг друга и быть посмелее потом в рабочих вопросах. В асинке этого меньше и, особенно, если у вас полная удаленка, общения может не хватать. Асинхронный формат хорошо работает в командах, которые вместе уже полгода+ без резких движений. Когда стартуешь новый проект или команда только собралась, лучше делать синхронно, на мой взгляд. А как у вас?

Когда следующий релиз? Продакты, сейлы и другие ребята из бизнеса часто спрашивают разработку, когда следующий релиз. Ответ на этот вопрос легко автоматизировать, чтобы сохранить время для себя и других. Вот несколько удобных вариантов, которые я видел: 📌страница в ноушене / конфлюэнсе с датами всех релизов. Здесь же можно перечислить фичи, которые планируются к выпуску. Работая в Банубе, мы делали из таких страничек релиз ноутсы, которые конвертировали в публичные для клиентов сразу после выпуска. 📌гугл календарь. Заводишь отдельный календарь Releases, который каждый сотрудник может добавить себе, чтобы видеть дату релиза. Создаешь повторяющиеся события: code freeze, QA, submit to store, выглядит вот так. Также удобно добавить в эти события всех разработчиков, как напоминание, когда надо подготовить релизную ветку или отправить приложение в стор. 📌закрепленное сообщение в слаке. Самый дешевый вариант, правда, не такой заметный, как остальные. 📌fix version в джире. Для всех задач, которые идут в релиз, проставляешь поле fix version. Тогда в разделе Releases появится список релизов, а в каждом из них - список готовых задач. Автоматически! Надежный вариант, но требует от команды подробно вести джиру. А так как у большинства людей джира вызывает тоску, часть людей все равно будут писать тебе в личку: ⁃ Рома, а когда у нас следующий релиз? ⁃ Посмотри вот тут. 💬Напишите в комментах чем пользуетесь у себя.

Полный гайд по сдаче экзамена PMP Я сдал на PMP в мае 2024. На подготовку ушло 4 месяца и 1,340$. По плану должно было быть в 2 раза быстрее и в 2 раза дешевле. Но если бы все мои планы сбывались, я бы писал вам о том, как готовился к чемпионату Европы по футболу в составе сборной Италии, а не к PMP. Чтобы вы не наступили на те же грабли, что и я, написал вот эти посты: 📌Требования, стоимость, можно ли сдать из РБ и РФ 📌Материалы для подготовки 📌Как технически проходит тест 📌Примеры реальных вопросов из экзамена 📌Кому стоит сдавать на PMP 📌…а кому нет смысла 📌Как я провалил экзамен с первой попытки Пересылайте друзьям-менеджерам и удачи на экзамене!

PMP экзамен (6/6) - как я завалил тест с первой попытки Первый раз я пошел сдавать экзамен спустя 2 месяца подготовки. К тому моменту я решал тренировочные тесты примерно на 70%, в интернете везде писали что этого достаточно. Результат пришел через несколько дней и был очень низким. Наверное, если бы я проставлял ответы рандомно, было бы примерно столько же. Тогда я подумал, что просто плохо подготовился и продолжил учиться. Позже выяснилось, что с прошлого ноября из 40+ человек, кто сдавал тест на русском языке сдало 0 человек. 0 из 40! Инициативные ребята написали коллективное письмо в PMI. Оказалось, был баг именно в русской версии экзамена, а английская работала правильно. Недавно баг починили. Я вообще не совсем понимаю, как в продукте, главной фичей которого является тест, в продукте, который стоит пользователю кучу денег и времени, может блять неправильно работать подсчет результатов в течение 5+ месяцев? Но ладно, мы все работаем в софте, знаем, как легко не заметить проблему, особенно на большом скейле. PMI очень долго не хотел признавать ошибку, но на прошлой неделе вроде бы сдался. Всем пострадавшим обещают бесплатную пересдачу. Спасибо и на этом, конечно, вот бы еще 2 лишних месяца подготовки рефанднуть как-нибудь. Могли бы вручную результаты пересчитать например. Не факт, что для меня это что-то изменило было, но показало бы отношение. P.S. Последний совет по подготовке к экзамену: заранее выберите язык, на котором будете сдавать и учите весь контент только на нем. Я учил часть на русском, часть на английском. На первой попытке пользовался встроенным переодчиком - это дико неудобно и жрет лишнее время. Второй раз учил и сдавал на английском, термины запомнились лучше, время отклика снизилось 👌.

PMP экзамен (5/5) - Стоит ли сдавать и для кого будет максимальная польза. Кому нужен PMP 🧑‍🎓 ПМам с 3-5 годами опытами, кто переходит в ИТ из гос. сектора, банков, телекома, веб-студий и не чувствует уверенности в своих знаниях по управлению проектами. Полистайте PMBOK, если встретите много незнакомых концепций - будет полезно. PMP можно рассматривать как продолжение курсов - вы пошли поучиться, а заодно сдали экзамен. 🧑‍🎓ПМам, которые ищут работу проджектом зарубежом. К сожалению, за пределами СНГ никто не слышал про Епам и Яндекс в вашем резюме. Для нанимающего менеджера этот опыт ни о чем не говорит. А вот PMP, это как английский - его понимают и котируют везде. В немецком линкедине, например, в 20% вакансий упоминается PMP, хотя в СНГ я редко встречал такое требование. Если у вас есть этому объяснение - напишите в комментах, любопытно. 🧑‍🎓Продактам, QA-лидам, тимлидам и т.п., кто хочет расти из своей роли выше, например, в директора и кому в резюме не хватает опыта деливери. Тогда PMP закроет этот пробел.

Почему не стоит сдавать на PMP 1️⃣Чтобы допуститься до экзамена, нужно иметь 3 года опыта в ПМ (5 лет без вышки). Если вы отработали 3 года в компании с сильными процессами, вроде того же Епама или Яндекса, 90% контента в PMBOK вы будете уметь применять просто из опыта. 2️⃣ Сдача PMP - это подготовка к тесту, а не обучение навыкам. Здесь ты учишься мыслить как PMI, чтобы правильно отвечать на вопросы с подвохом. Практической пользы, чтобы начать что-то завтра применять на работе здесь немного, опять же, если работали до этого в сильных процессах. Даже наоборот - в некоторых вопросах теста, мои действия в реальной жизни отличались от того, что считалось правильным ответом. 3️⃣Контент PMBOK написан под проекты в любой сфере, поэтому здесь много кейсов, например, про стройку и медицину, которые нерелевантны для ИТ. 4️⃣ Исследование PMI говорит, что менеджеры с PMP получают на 33% больше, чем менеджеры без сертификата. Другое исследование по РФ, говорит, что разница в зп будет целых 700$. Возможно так оно и есть. Но я думаю, что если подкачать любой другой навык, которого не хватает сейчас на работе, то и зп вырастет. Почему сдавал я Я работаю ПМом 10 лет и мне хотелось сформировать свое мнение о PMP. Сформировал, такое себе. Сдавал бы я тест снова, зная все это наперед? Да, чтобы повысить “рейтинг” своего резюме для будущих поисков работы. Других причин не вижу. 💬Если у вас есть PMP, напишите в комментах вашу мотивацию сдать экзамен.

PMP экзамен (4/5) - Вопросы и темы в тесте Большая часть вопросов сформулирована в виде кейсов. Например: “На проекте есть проблема 1, 2, 3, какую будешь решать первой?” Я думал, что со моим опытом будет легко на них отвечать, но по факту правильный ответ в тесте, нередко расходился с тем, что я делал бы в реальной жизни. Например, как в этом вопросе о тестировании. Тест покрывает три основных типа проектов: эджайл, вотерфол, гибрид. Отвечая на вопрос, первым делом нужно определить о каком типе проекта идет речь. Так могут сразу отпасть неподходящие варианты. Экзамен иногда ловит на этом, миксуя вроде бы правильный вариант, но в неправильных условиях. Например, как в этом вопросе об управлении изменениями. Желание подловить это вообще фишка экзамена. Иногда в вариантах ответа дают выдуманные термины, похожие на реальные определения. Или перегружают вопрос лишними подробности, заствляя тебя думать о другом, как в вопросе об обновлении документов. На расчет критического пути вопросов у меня не было. 1 или 2 вопроса попались на метод освоенного объема. Сложных формул типо EAC или TCPI не было, спрашивали только на понимание, например: “CPI проекта 1.3. Что можно сказать о бюджете (переиспользован \ есть запас)?”. Пожалуй самый частый сценарий в тесте, это когда ты выбираешь из двух хороших вариантов, как, например, в вопросе о добавлении новой задачи. Вот еще несколько таких примеров, близкие к которым мне попались на экзамене. В следующем, предпоследнем посте на эту тему, порассуждаю о плюсах и минусах PMP.