26448
Проджект менеджмент в IT. Современные деливери практики, продуктовая разработка и как быть классным менеджером. — Сообщество менеджеров: @pm_sovet Реклама: @pm_god_ads 5035224435
Улучшенная версия реестра рисков – RAID
Чтобы было удобно следить за рисками, их часто вносят в отдельную табчику. Пишут, в чем именно риск, как будем его предотвращать и кто ответстственный.
Это реестр рисков.
Иногда, кроме рисков хочется записать и другие штуки.
Например, что другая команда нам висит кусок скоупа (зависимость). Или, что субподрядчики задержали поставку фичи уже на 2 недели (проблема). Или, что мы считаем, что требования нового закона “переводятся” в вот такие фичи (допущение).
Для таких “расширений“, есть хороший формат – RAID.
RAID это тоже табличка, куда вносят:
R – risks (риски);
A – assumptions (допущения),
I – issues (проблемы);
D – dependencies (зависимости);
Я использую RAID как журнал того, что случилось на проекте. Например, встречаюсь с новым стейкхолдером и рассказываю ему, что было в “предыдущих сериях”. Особенно помогает на длинном проекте, т.к. вещи забываются.
Еще такая табличка помогает рефлексировать над проблемами – полезно открыть перед ретрой или когда делаешь SWOT-анализ.
Пример заполненного RAID для проекта “next day delivery” 👇
“Совет директоров” проекта (Steering Comittee)
Когда делаешь проект в большой компании, у тебя могут быть сотни стейкхоледров. Общаться со всеми лично врядли успеешь. Поэтому договариваешься о представителе из каждого юнита и решаешь вопросы уже с ними.
Раз в месяц главные представители собираются вместе, чтобы обсудить, как идут дела. Типо, как “совет директоров” проекта.
Такая встреча называется Steering committee, обычно сокращают до SteerCo.
По сути, это просто встреча с большими дядьками и тетьками, чтобы обкашлять вопросы.
Ценность стирко в принятных решениях.
Можно неделями пытаться договориться с продактами из разных отделов, кому делать кусок скоупа. Но когда собираются топ-стейкхолдеры, такие решения принимаются мгновенно. Это шанс для менеджера решить самые сложные блокеры.
———
Если знаете подходящий перевод для steering comittee – напишите в комментах.
Бесконечно можно смотреть на 3 вещи:
▫️как горит огонь
▫️как течет вода
▫️как продакт переносит рефакторинг в следующий спринт
#реклама
Менеджер устал. Команда — тоже.
Каждый день менеджер делает выбор:
📍 быть удобным или поднимать неудобные темы
📍 «закрыть» план или признать, что он давно устарел
📍 поддержать человека или пожертвовать им ради дедлайна
Он смотрит, как выгорает тимлид, которому обещали рост, но забыли
Он слушает, как бизнес—аналитик давит, потому что «бизнес не понимает»
Он отвечает за то, что не может контролировать, и делает вид, что держит всё под контролем
И в какой-то момент он начинает задаваться вопросом —
А как вообще быть менеджером, если ты ещё и человек?
Есть идея: искать ответы вместе с теми, для кого это тоже важно и актуально. А такие люди соберутся на новой конференции PeopleSense
📍 19–20 мая 2025 года в Москве
Организаторы — команде ProductSense. Но в этот раз говорить будут не про продукты и фреймворки, а:
— Про то, как управлять, не теряя себя
— Про софты, которые стали важнее хардов
— Про культуру, обратную связь, рост, усталость и силу доверия
— Про то, как развивать лидерские компетенции в компании
30+ докладов и 20+ мастер-классов
— Как перейти от управления людьми к управлению работой
— Сильные сотрудники — радость или боль для руководителя?
— Менеджмент 18+: сотрудник — не ребенок, менеджер — не родитель.
— Власть без жертв: как руководителю сохранить человечность и эффективность
Если человек — мера всего, то с него и надо начинать.
С себя. С команды. С процессов между людьми.
Темы докладов и список спикеров тут:
https://peoplesense.ru
-----
ООО «Продакт Сенс» ИНН 6162077311
2VtzqxB6B84
Встречи без экшн айтемов
Все уже давно знают, что стоит записывать следущие шаги по результатам встречи. Это менеджерская база, так же как готовить темы для встречи.
Тем не менее я сам тыщу раз забивал на экшн айтемы. Например, думая, что раз вокруг меня такая сеньорная команда, то зачем. Мы же взрослые, ответственные люди, раз обсудили, значит, сделаем. Ага, ну да.
Нет, часто, оно и правда потом делалось. Но иногда оказывалось, что один не так понял, а второй забыл. И тогда дела продалбывались почти наверняка.
Например, обсуждая с командой недавний инцидент, приходим к тому, что причина непонятна и надо собрать больше данных.
Магия экшн айтемов в том, что когда начинаешь записывать, всплывает неудобная конкретика:
▫️один думал, что данные соберут аналитики.
▫️у аналикитов в этом спринте времени нет.
▫️а данные по проблемным сессиям у нас, оказывается, вообще не логируются.
Поэтому лучше записывать. Даже сениор директоры, работа которых мне иногда видна, записывают и не стесняются. И вы не стесняйтесь.
Новый закон по Accessibility софта в Европе
Летом в Европе вступает в силу закон о доступности European Accessibility Act (EAA). Под его действие попадает любой бизнес, у которого есть сайт или приложение. Проверьте, не касается ли вас, а я расскажу немного деталей.
Чтобы выполнить требования закона, нужно соответствеовать стандарту WCAG 2.1 на уровне АА. Это главный в мире стандарт доступности, разработанный умными дядьками из World Wide Web Consortium еще в 1999 году.
Штрафы за невыполнение закона могут быть в районе 5-20К. А в Ирландии даже могут посадить в тюрьму!
Есть ли тут деньги
Еще как!
Задачи по доступности часто оказываются внизу беклога, т.к. на первый взгляд не приносят денег. Но это не совсем так. Вот несколько фактов для презентации вашему CPO:
▫️в США живет 61 миллион человек с ограниченными возможностями.
▫️70% из них выбирают продукты, в которых есть поддержка доступности.
▫️Расходы людей с ограниченными возможностями, составлют $8 трлн ежегодно.
Рынок есть, и немаленький, осталось научиться на нем зарабатывать.
Какие требования нужно выполнить
На практике, комплайенс означает поддержку 55 требований WCAG в продукте.
Среди них много логичных, которые сделают любой интерфейс удобнее. Например, размер иконок должен быть не меньше 24 пикселей или текст должен хорошо контрастировать с фоном.
По моим ощущениям, у среднестатистического сайта большая часть работы сведется к простановке лейблов и тегов, которые используют скрин ридеры. Кстати, посмотрите, как слепые пользуются инстой с его помощью.
Самый серьезный риск для разработки, на мой взгляд, касается пункта про портретный режим. Реализовать его поддержку с нуля в приложении безумно дорого.
Инструменты для разработки
Бесплатные тулы, которые сделают аудит вашего приложения или сайта:
▫️Accessibility Inspector, iOS;
▫️Accessibility Scanner, Android;
▫️Lighthouse, web.
Анонимный фидбек vs неанонимный
Когда мы собираем фидбек для перфоманс ревью, есть два способа, как это сделать – анонимно и нет.
С одной стороны, когда люди оставляют фидбек анонимно, он становится гораздо откровенее. Когда я знаю, что никто не придет с расспросами, я гораздо охотнее напишу, что продакт-директор – самодур.
С другой стороны, именно потому, что фидбек неанонимный, я вынужден пояснить, что продакт-директор бывает невнимателен к мнению команды, а также продавливает свои решения силой. Когда под фидбеком стоит мое имя, я лишний раз подумаю, что в нем написать. Не желая прослыть треплом, я вспомню примеры, детали, а это как раз самое ценное в фидбеке!
Я пробовал разные варианты, и самым эффективным, мне кажется, собирать фидбек неанонимно, а делиться уже анонимно, без имен. Так, я могу доуточнить детали у автора, если его обратная связь на уровне “продакт-директор – самодур”. А у самого автора появляется больше безопасности, чтобы говорить честно.
А вы как делаете?
Как выбрать дату завершения проекта
Когда оцениваешь небольшой проект на 3-6 месяцев, очень трудно назвать точный день его завершения.
Будет 1 декабря или 2-ое? Обычно на этапе оценки у нас не так много данных, чтобы дать настолько точный прогноз.
Эту проблему решают несколькими способами:
1️⃣Как есть перевести трудозатраты в длительность и назвать дату. Например, 480 часов = 3 месяца от сейчас = 2 декабря. Проблема в том, что даже крошечный риск сдвинет эту дату, а значит мы с самого начала даем нереалистичное обещание.
2️⃣Добавить рисков, и назвать 30-ое декабря, но тогда могут вернуться с вопросами почему так долго.
3️⃣Можно сказать просто – закончим в декабре. Это ОК для больших проектов на 6+ месяцев, но для более коротких выходит снова слишком большой буфер.
Хорошая альтернатива – оценивать дату завершения в неделях (или спринтах). Например, закончим на 50-ой неделе (в 25 спринте), это вторая неделя декабря.
Так, у стейкхолдеров появляется достаточно точное ожидание по срокам. А у команды – зазор в целую неделю. Можно и в понедельник, 8-ого декабрая проект сдать, а можно и в пятницу, 12-ого.
Кто должен отвечать за сроки (проекта или фичи)?
Технари.
Под технарями я имею в виду людей на технических позициях: программист, инжиниринг менеджер, тимлид, СТО.
Когда за сроки отвечают продакты, маркетинг, очень крутой директор-of-что-то-там – сроки профукиваются. Большинство проектов, которые я видел, где сроки оценивали не технари, переносились.
Оценка технарей более реалистична, потому что они знают КАК будет вестись разработка, какие есть ограничения у текущей архитектуры и команды. Бизнес знает об это приблизительно, поэтому их оценка менее точная.
Когда сроки спускаются сверху, у команды гораздо меньше энтузиазма в них попасть.
Это как если бы я делал ремонт, нанял плиточников, и сказал бы им: туалет нужно закончить за неделю. Почему неделя? Ну, нам надо квартальный ОКР по ремонту закрыть через неделю, поэтому так. Что, туалет делается минимум три? Ну придумайте что-нибудь, вы же плиточники, а не я.
При этом нормальная ситуация, когда, я прихожу к плиточникам и говорю: мне нужна плитка через неделю, что можно сделать? Я слышал, что если приклеить плитку не цементом, а скотчем (знаю, что это дичь, но нам для витрины, поэтому пофиг), то можно быстрее сделать. Помогите придумать вариант.
Как найти классного босса, ч1.
Когда меняешь работу, по нанимающему боссу примерно понятно в какое место попал.
Классный босс вряд ли будет работать в неклассном месте и наоборот.
Босс – это индикатор культуры. По крайней мере часть компании будет похожа на него в рабочих привычиках.
Один босс будет дрючить за отчеты, другой – читать первые два абзаца. Формально, отчеты надо будет делать для обоих, но разница в том, сколько времени этому придется уделять.
Классность босса всегда была для меня в топ-5 критериев при выборе новой работы.
Конечно, босса не выбираешь, как помидоры на рынке. Скорее, познакомившись с новым боссом, ты выбираешь идти работать с ним или нет.
“Классность” я раскладываю на:
▪️босс не лезет глубоко в то, как именно я делаю свою работу, пока я не косячу. И спрашивает за результат;
▪️у босса есть скилл, который я хочу прокачать, и в котором он на голову лучше, чем я сейчас. Например, он сильный политик или пишет топовые документы;
Эти два пункта закрывают 80% классности для меня. Остальные 20% примерно такие:
▫️мне понятна мотивация босса работать в этой компании. Например, был один босс, который хотел изучить, как работает аутсорсинговая компания, чтобы потом открыть свою. Другой был сильнейшим программистом и кайфовал от всего, что касалось разработки. Мне была понятна эта мотивация, я ее уважал и мог спрогнозировать поведение босса. А вот третий босс в какой-то момент досиживал свой контракт и ждал увольнения. С ним работалось трудно, т.к мотивация была на исходе.
▫️босс последовательный, не меняет свои принципы и точку зрения в зависимости от ситуации. Например, если сказал, что нашему отделу надо улучшить планирование, то когда придет новый-важный-проект-сверху, босс вспомнит свои же слова и скажет: “ок, что выкидываем взамен?”, а не тихонько добавит его в роудмап.
▫️босс не ругает место, где работает. Если ему что-то не нравится, он либо попытается это изменить либо сваливает в другое место. Ну или просто молчит.
Это мои пункты для классного босса. У вас наверянка будут другие, но я советую прояснить их для себя. Так будет больше шансов попасть именно к классному боссу.
Классный босс
Важнейшая вещь на работе – иметь классного босса. Чем круче босс, тем быстрее менеджер растет в скиллах и зарплате.
Мне везло с боссами, и каждому из них я очень благодарен.
Один научил меня азам управления проектами. Другой объяснил, что софт – это только инструмент, чтобы решать проблем бизнеса. Третий показал, как находить подход и партнериться с тяжелыми стейкхолдерами.
Есть простой способ оценить класcность своего босса. Если завтра он уйдет в другое место и позовет с собой, стоит ли рассматривать предложение всерьез?
У меня это всегда “да”.
А как у вас?
Прогноз бюджета
Обычно на проектах с почасовой оплатой (time & material) или выделенной командой (dedicated team) в начале каждого месяца клиенту высылают инвойс на оплату. Хорошие менеджеры прикрепляют к нему прогноз затрат на будущий месяц.
Это добавляя бюджету предсказуемости и помогает клиентам планировать свои затраты. С ним будет меньше шансов встретить удивление или дебаты на следующем инвойсе.
Рекомендую отправлять прогноз, даже если на проекте постоянно работает одна и та же команда. Цифра может отличаться на 10-20% за счет отпусков и количества рабочих дней в месяце.
Недавно увидел такой отчет у аутсорсеров, с которыми мы работаем. У них он был с понедельной разбивкой. Такой я бы не стал вести, так как будет дорого поддерживать, а вот раз в месяц идеально.
Типичные команды в большой компании
Программист в маленькой компании - как швейцарский ножик. Он и серверы для тестов поднимает, и CRM-ку для маркетинга настраивает и фичи новые делает, куда ж без них.
Когда компания растет, выделяют отдельные команды, которые отвечают за свою, определенную функцию. Многие из таких функций уже стали лучшими практиками, и вы встретите их во многих больших компаниях.
Вот некоторые типичные команды в компании 500+ человек и чем они занимают:
Platform затаскивают в проект новые технологии, поддерживают инфраструктуру, архитектуру и библиотеки, процесс релиза. В такой команде работаю я.
Design System создают общие UI-компоненты (кнопки, дропдауны, поля ввода) благодаря которым, интерфейс остается унифицированным.
Payments делают так, чтобы платеж по карте прошел без ошибок, прикручивают новые способы оплаты.
Loyalty делают маркетинговые проекты для роста, например, купоны, премиум подписки, пригласи друга, внутриплатформенную валюту и т.д. Чтобы вы понимали, насколько это важная часть бизнеса - в прошлом году авиакомпания Lufthansa заработала 431 миллон евро только на программе лояльности.
Data внедряют GDPR, переносят важные эксельки маркетинга во что-то более долговечное и постоянно что-то куда-то мигрируют.
Security следят, чтобы в коде не хранились апи ключи и пароли, настраивают Cloudfare, чтобы проложение сильно не ддосили. Еще security защищают нас от ботов. Хотите верьте, хотите нет, но почти половина всего трафика в интернете - это боты. Представьте, какое тут пространство для скама!
Search делают поиск удобным и быстрым, например, через автозамену или поиск голосом. В екоме, тревеле и многих других бизнесах, большая часть воронок начинается именно с поиска.
AI \ ML \ Personalization подкидывают нам интересные товары в маркетплейсе или фильмы в кинотеатре.
---
Работаете в важной команде, которая часто встречается в больших компаниях? Расскажите, чем занимаетесь в комментах 👉
Не так страшны первые 80% проекта, как вторые 80%
⁃ бородатая поговорка проджект-менеджеров.
Cмысл ее в том, что иногда цель дальше, чем кажется.
Бывает, что проект вылетает по срокам или бюджету. Скажем, сделали 80% запланированного, а потратили 90% ресурсов (времени или денег).
В этой точке можно себя убедить, что все плохое уже позади, все риски случились, и дальше проект пойдет по первоначальному плану. А вылет нагоним!
В жизни так бывает, но редко.
Чаще риски продолжают возникать: еще один кусок работы не учли, снова разработчик заболел, опять клиент перестал отвечать на вопросы.
Когда проект вылетает, очень важно признать это, хотя бы самому себе, и честно прикинуть, сколько уйдет на оставшиеся 20%. Например, можно заложить тот же % вылета, что уже случился в 80% завершенной работы. Да, будет неприятно сообщать боссу плохие новости, зато больше шансов вырулить проект.
Сделать важное или что обещал?
Недавно был в ситуации, где пришлось выбирать между двумя проектами.
Первый проект мы пoобещали сделать другой команде еще в начале года, но переносили уже несколько раз. И вот, за неделю до старта, продакт приносит команде второй проект – новый, красивый, с очень многообещающим результатом.
Проекты нельзя сравнить между собой по одной метрике и взять тот, где больше – они просто разные. Выбрать и успеть можно только один.
Итак, мы собираемся группой ребят, кто должен принять решение. Вроде бы все понимают, что делать надо проект 2. Но у каждого в комнате жуткий дискмофрт – мы же обещали. А раз пообещали, значит надо делать, мы же четкие менеджеры. Даже в плане на год есть этот проект, как мы можем его просто скипнуть.
В таких ситуациях важно отключать человека и включать продакта – безжалостно выбирать важное над всем остальным. Что мы и сделали.
Менеджеру (и мне тоже), надо запомнить, что план – это не гарантия. План – это план. То что в нем написано, необязательно сбудется, хоть мы и очень постараемся. Реальность постоянно подкидывает нам новые вводные, которые могут наш план менять. И то, что было запланировано год назад, не факт что будет сделано. И это нормально!
Я потом сходил к менеджеру обещанного проекта и долго рассказывал как мне жаль (правда было жаль), на что он ответил: “вообще все ОК, не парься”. Видимо, тоже порой продакта включает.
Замечать успехи команды (Recognition)
Работая с несколькими топ-левел стейкхолдерами в этом году, заметил, как круто они отмечают успехи других. Порой буквально на ровном месте.
Например:
▫️”Ребята, настраиваю трекинг задач на проекте на 100 команд. Есть удачные примеры?”.
“Спроси Анну, она построила супер удобный трекинг для проекта Х в прошлом году”.
▫️”Я вычитаю твой документ до пятницы. Кстати, хочу сказать спасибо за то, как ты затащил тот проект без особой поддержки”.
▫️”Поздравляем Алекса с повышением до Senior product manager. Он сделал проекты А, Б и Ц, которые вырастили конвесию в…”. Такие письма менеджер Алекса отправляет на всю компанию.
Бывает, ответ на какой-то вопрос топа начинается издалека, и человек дает явно лишних продробностей. Но даже тут:
▫️“Спасибо, что объяснил, как работает сервис аутентификации. Не знал, что у него столько клиентов. Сейчас я хочу узнать о …”
В большой компании плохо видны успехи коллег. Пофиксить это можно через специальную тулу для благодарностей. Такая штука хорошо работает на вовлеченность команды. Писал о ней тут.
Вообще, хвалить в публичном пространстве – важная роль топов. На этих сообщениях и строится культура компании.
#реклама_по_любви
Что ты хочешь, если ты такой хреновый менеджер
— Что же вы не присылаете отчёты?
— А что ты хочешь, если ты такой хреновый менеджер?
Команда не вкладывается в оценки. Что делать?
Представьте, что приходите менеджером в новую команду. Быстро понимаете, что есть проблема с деливери – команда успевает завершить 60-70% того, что пообещала.
Что будете делать?
Вот буду делать я:
▫️проверю, как именно собирается статистика.
▫️спрошу у команды, в чем главная причина на их взгляд.
▫️проверю описание задач, понятно ли из них, что делать.
▫️проверю, что фичи разбиты на задачи размером хотя бы в 1-2 дня.
▫️уточню, самостоятельно ли команда дает оценку или кто-то делает это за нее.
▫️проверю, что в итерацию заложено время на риски и непрограммирование – встречи, тестирование и т.д.
▫️проверю, не успевает вся команда или 1-2 человека.
90% команд, с которыми мы работали над улучшением деливери, имели по крайней мере одну проблему из списка выше.
Менеджерский трюк: вынести проблемный скоуп в отдельный майлстоун
Представьте, что вы запланировали 2 месяца на майлстоун-А, в котором нужно перевести сайт на английский язык.
Начали разработку, и поначалу все шло хорошо. Через пару недель обнаружили проблему в лендингах. Чтобы нормально использовать их на нескольких языках, нужно сначала порефакторить способ доставки ключей перевода. Иначе перевести лендинги возможно, но получится прям совсем костыльное решение. СТО в глаза будет стыдно смотреть.
И вот трюк:
🎩Поддержку лендингов выносим в отдельный майлстоун-Б.
Обосновываем так:
Когда мы закладывали 2 месяца на проект, то исходили из того, что лендинги заведутся легко, из коробки. Но оказалось, что они не поддерживают мультиязычность. Поэтому наш майлстоун-А все еще ЗЕЛЕНЫЙ, а поддержку лендингов мы сделаем позже, в майлстоуне-Б.
Формально проект был перевести весь сайт, и лендинги входят в его скоуп. По-хорошему, надо оставлять лендинги в майлстоуне-А и красить его в КРАСНЫЙ.
В заказной разработке обычно так и поступают, если заранее не включили мультиязычность в assumptions. И идут по пути костылей, потому что финансы важнее косых взглядов СТО.
В продуктовой компании посмотрят, что на лендинги ходит 5% пользователей, и скажут, что главная цель – перевести сайт – выполнена на 95%, вот и славно.
«Торги» скоупом – обычное дело на любом проекте. Трюк именно в том, что бы отделить проблемный скоуп от основной работы. Так, им легче потом торговать, а проект остается ЗЕЛЕНЫМ.
#реклама
Одни постоянно растут в деньгах, а другие застряли на одной позиции
Первых от вторых отличает умение проходить всю воронку в найме от правильного самоопределения, до собеседования, онбординга и даже увольнения (да так, что ещё и парашют могут заплатить).
• Junior продакт Лиза — выросла от 110к до 175к за 2 недели. Ей достаточно было просто поправить резюме. Её коллега, нынешний продакт компании X, вырос в доходе x2,5 буквально за 2 месяца и уже к 24 годам планирует стать CPO. Всё благодаря нормально описанному опыту работы в резюме и уверенному собеседованию, никакой магии.
• Другая девушка — Катерина — ушла на те же 300к в другую компанию, но получила ту рабочую структуру, которую не могла найти даже в компаниях, которые предлагали x1,5. Всё тоже благодаря четкой цели, а от нее — правкам в резюме и отработкам собеседований.
Дожимать
Вспоминая проекты, которые я профукал, понимаю, что в некоторых тупо не дожал.
Решения, коммуникацию, риски.
Например, на одном проекте мы пропустили часть подготовки, из-за чего релиз провалился. За пару недель до этого я ходил-рассказывал всем о том, что “кажется мы падаем”, но делал это не слишком убедительно, и стейкхолдеры не считали серьезность проблемы. Не дожал.
Или в другой раз, мы решили переписать половину бекенда, чтобы пофиксить критичный баг. Идея с первого дня была спорной, уверенности в глазах разработки не читалось. Я это заметил, но забил, “делегировал”. Не вкопался в детали, не настоял сделать PoC, не поискал экспертизы снаружи. В итоге черезе полгода, мы не смогли зарелизиться и проблема осталась нерешенной. Снова не дожал.
Дожимать трудно. Часто это значит поднять неудобный вопрос или указать, что человек чего-то не сделал. Донести такое сообщение так, чтобы и проблему четко обозначить, не срезать углы, и еще и человека не обидеть – безумно трудно. Это я уже не говорю про внутренее сопротивление в таких разговорах.
Дожимать также не всегда уместно. Например, был у меня один сложный клиент, сам тот еще дожиматель. В момент, когда он сам оказался неправ, разумнее было дать ему сохранить лицо, чем дожимать.
Дожимание – сложное искусство, которому я постоянно учусь. Практики хватает, особенно в корпе, где миллион стейкхолдеров с разными интересами. Пару раз в неделю стабильно я нахожу себя в ситуации, где приходится выбирать между быть “удобным менеджером” и быть“дожимателем дел и вопросов”. Скажу по правде, второе получается далеко не всегда.
#реклама_по_любви
У Стратоплана снова бесплатные ивенты по софт-скиллам. Конечно, в конце будут что-то продавать, но это в конце!
Стратоплан делают одни из лучших курсов для ИТ-менеджеров на рынке. Я сам проходил их тыщу лет назад, поэтому рекомендую сходить.
———
ПМов, тимлидов и прочих руководителей разработки спросили, какие навыки они считают самыми важные для менеджера. Они назвали:
Стратегическое видение (42%)
Коммуникацию (28,6%)
Самоорганизацию (26,1%)
*по данным исследования devcrowd.
Стратоплан проводит серию открытых воркшопов Руководитель 2030, v2.0 по этим навыкам. Будет три воркшопа:
▫️Стратегическое мышление на всех уровнях, 3 марта.
Разберемся как делать стратегическое мышление, формировать четкие планы, устанавливать приоритеты и выстраивать связь между задачами команды и бизнес-целями.
▫️Управление своими фокусом и временем, 5-е марта.
Научимся определять главные фокусы работе и стратегии. Узнаем, где брать на это время и силы.
▫️Умение договариваться, 7-е марта.
Узнаем о существующих инструментах, техниках и особенностях коммуникации и о том, что делать, когда все идет не по плану.
Присоединяйтесь к открытой серии воркшопов Руководитель 2030, v2.0!
👉👉👉Регистрация 👈👈👈
Delivery sync
– это встреча менеджера проекта с руководителем раз в 1-3 недели, где обсуждается состояние проекта.
Для руководителя это возможность своими глазами убедиться, что на проекте все ОК.
Например, руководитель спрашивает «А что будет, когда в этот сервис зайдёт +100% пользователей?». И через такие вопросы ищет, где стрельнет.
Для менеджера деливери синк, это повторяющаяся напоминалка посмотреть на проект под критическим углом. К встрече ведь надо подготовиться! И самому сперва подумать, где стрельнет.
Еще через деливери синк менеджер учится у своего руководителя.
Когда я работал в Оксаджайле, мы открывали джиру с моим менеджером Стасом, и начиналось: «А почему не успели вот эти задачи в прошлом спринте? Как ты понимаешь, что успеете в следующем? А как заказчик отреагировал?». В первый год я сильно прокачался как ПМ, благодаря тем беседам.
На встрече обычно идут по чек-листу: скоуп, сроки, команда, заказчик, метрики. Вот один из чек-листов, которые мы использовали в то время.
Сейчас, в продуктовой компании, я участвую в деливери синках у нескольких команд, работа которых находится на критическом пути в моих программах. Иногда задаю вопросы, а иногда помогаю продактам и тимлидам на них отвечать.
———
Знаю, что во многих компаниях в той или иной форме проводят деливери синк.
Как он у вас называется? Ищу название на русском, которое передает суть встречи.
Как найти классного босса, ч.2.
ч.1.
Понять, что босс будет классным, или хотя бы нормальным, непросто.
Вот несколько пунктов, которые помогают мне:
▫️посмотреть, где работал до этого. Если есть в списке компании, которые я уважаю – супер. Если нет, тоже не проблема. Тогда смотрю на траекторию в карьере. Например, если босс проработал 10 лет в шараге без роста в должности, то возникают вопросы. А если из шараги перешел в среднюю компанию, а затем в глубокоуважаемую – это уже хорошая траектория.
▫️посмотреть, что пишет в линкедин. Если ничего, то и на том спасибо, но иногда можно встретить тревожные звоночки. Знаю одного менеджера, который читает линкедины, чтобы оценить уровень владения русским языком, такой вот у него минимальный порог для найма.
▫️твиттер, фейсбук, инсту, иногда тоже получается найти (ну а что). Вдруг, новый босс окажется на неожиданной стороне в вопросе творчества группы “кровосток”. Для меня проще перебороть стеснение и загуглить, чем внезапно обнаружить себя работающим на монстра.
▫️на интервью у меня будет всего 10 минут в конце на вопросы. Моя задача за это время – понять, как босс принимает решения, на что ориентируется, делая выбор. Спрашиваю, например: “расскажите, как пришлось закрыть проект”.
▫️Другой мой любимый вопрос: “расскажите кейс, где сотрудник в вашем отделе вырос”. Тут я хочу оценить, насколько босс включался и помогал, или сотрудник сам все затащил.
▫️Если офер уже пришел, а сомнения в боссе остались – прошу дополнительную встречу с боссом 1-1. Компании считывают это хорошо, считая, что человек серьезно относится к работе.
▫️вопросы от босса на интервью – тоже пробничек культуры. Если спрашивает, что я буду делать, если столкнусь с истеричным продактом, который не дает команде общаться с бизнесом – большой шанс, что в этой компании работает именно такой.
Желаю вам классного босса!
Но если вдруг попался неклассный, это еще не конец света. Боссы приходят и уходят, а мы остаемся. Может, уже сейчас вам собеседуют нового, блестящего босса (но, может и нет).
#реклама_по_любви
Привычка опираться на факты и цифры отличает сильного менеджера от просто менеджера.
Менеджер говорит:
“Нам надо 5 дней на рефакторинг”.
“За 5 дней рефакторинга, мы уменьшим скорость загрузки страницы, что увеличит конверсию на 5%”.
Топ посты 2024
▫️Сколько зарабатывают айтишники в Германии
▫️Тренажер по распределению задач в команде
▫️Как я сдавал экзамен PMP
▫️Асинхронные стендапы
▫️Оценка по трем точкам
▫️Фича-флаги
▫️Критический путь
▫️Метод освоенного объема
▫️Типажи клиентов
▫️Как выбрать что рефакторить
Друзья, спасибо, что читали менеджера от боженьки в этому году! Если захотите порекомендовать канал другу-менеджеру, просто перешлите ему этот пост. Я буду вам очень за это благодарен ❤️
С наступающим!
Когда выкатил релиз, но не знаешь, что именно он сломает
Читать полностью…
*временное сообщение
вам в личку могут написать якобы другие подписчики моего канала
спросят в духе "покупали ли вы мои консультации / курсы и насколько они вам понравились"
⚠️это скам
если начнете отвечать, в конце предложат курсы по трейдингу
спасибо всем, кто проявил бдительность и написал в личку 🤝
#реклама
Канал об ИТ в Китае
Сегодня в рекомендациях канал о продуктовой разработке Саши Лебединского, Chief Growth Officer в Т-Банке.
Сейчас Саша работает в Китае, активно изучает местный технологический бизнес и делится наблюдениями, например:
– 6-ти дневка и слушать старшего - как выжить в китайской компании;
– как частные компании Китая работают с государством;
– как TikTok измененил формат потребления контента.
Саша делится своим опытом в маркетинге, стратегии и построении команды, а также рассматривает кейсы известных компаний.
Подписывайтесь на 👉 @lebedinskiyalex
Продакт спрашивает фидбек команды на новые требования
The requirements you receive are always dumb to some degree, no matter how smart the person is who gave them to youЧитать полностью…