Будни ПМщика
23 subscribers
45 photos
3 files
83 links
Просто пишу про проектный менеджмент в IT

Contact: @kalicham
Download Telegram
Forwarded from Product Management & AI
Предлагаю сегодня изучить возможности крайне функционального и недооцененного инструмента для любого продукта и продакт-менеджера – changelog или журнала изменений.

P.S. Если материал понравился, буду благодарен за плюсы на Виси :)
Когда сходил на конференцию и разбираешь заметки
Сегодня у WTM.kg состоялся FuckUp Night 2.0

Интересно, что один из спикеров затронул тему конфликтов и признался, что проходит мимо конфликтов специально. Будучи менеджеров. ПМом.

В этот момент я поняла, что я по факту тоже стараюсь быть неконфликтной, но к конфликтом отношусь нормально. Мне даже они нравятся)

Конфликт это стороны 2х противоположных мнений. Понимаете да? Мнения)

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

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

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

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

Как вы относитесь к конфликтам?
Думаете менеджеру важно уметь и решать?
Стадии развития команды

Психолог Брюс Такман предложил модель развития команды, которая хорошо ложится на наш ИТ мир. Менеджеры любят к ней апелировать и спрашивать на собеседованиях. Она несложная, убедитесь сами:

Каждая команда с первого дня пройдет 4 стадии роста: forming, storming, norming, performing.

Давайте рассмотрим каждую из них.

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

🖕 Storming
Игра престолов начинается здесь. Люди поняли, кто чего стоит и потихоньку начинают разыгрывать локальные войнушки.

Кто-то уйдет: "в гробу я видал такого тимлида!".
Кто-то отмалчивается: "сами как-нибудь разберутся, зп капает и ОК".
Кто-то проталкивает свои идеи: "я в прошлой компании писал на vue.js, проект взлетел, давайте и тут все перепишем".

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

🤝 Norming
Рано или поздно, народ устает выяснять отношения и кто-то вспоминает, что пришел сюда решать задачи. Люди потихоньку начинают слушать друг друга, договариваться, искать компромисс. Появляются ростки доверия и эмпатия. Как следствие, растет скорость закрытия задач.

На этой стадии ПМ уже задумывается о делегировании.

💪 Performing
На ретроспективе все чаще слышно "у нас сильная команда, все друг другу помогают". Шишки набиты, ответственность распределена, все знают что и как работать. Уйти в отпуск на 3 недели не проблема. Функция менеджера тут поддерживающая. Без него не обойтись только во внештатных и критических ситуациях.

Вот и все, теперь вы знаете модель Такмана.

--------------------------------
Картинка отсюда
Зачем это надо

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

Например, на форминге ОК сказать: "так, я все обдумал и решил, гребем вот сюда". А в другой момент, на перформинге: "ребята, вы уже взрослые, я вам доверяю, решайте сами, куда грести". Так помогаешь команде быстрее придти к следующей стадии.

👉 По моим ощущениям, перейти от первой стадии на последнюю у новой команды занимает от 6 месяцев до года.

А по вашим?
Последние полгода очень сильно уделяю время работе

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

Зрение - сбилось
Движения - почти нет

Не удивлюсь если сдав анализы я пойму, что у меня все плохо)

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

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

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

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

Пост от балды) просто будьте счастливы, берегите свою менталку, чаще улыбайтесь 💜
Иногда я слишком упёртая

Утром на созвоне с коллегами, я так яро высказывала своё мнение, что решили забрать одну задачу на себя со словами

-сделаю это до конца дня, сегодня будет!

Теперь сижу делаю отчёт, вытаскиваю аналитику и хочу построить красивый детальный отчёт, но такого не будет)

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

Уже почти 8, а я не представляю что и как строится 😂
Вот сижу и смотрю как правильно все построить, как я хочу

Не делайте так!
Не давайте пустых обещаний сгоряча
Forwarded from FEDOR BORSHEV
Собственно, продолжаю

Тем из вас, кто сейчас ищет работу, у кого есть силы учиться и заниматься будущим (знаю, таких немало) или тем, кто просто хочет глоток нормальности, мы бесплатно отдаём наш с Васей Половнёвым курс «Профессиональный рост: меня и команды».

Этот курс — об осознанном росте в профессии: с планами, целями и отчётами. Мы говорим не о навыках для ежедневной работы, как в других курсах, а об умении системно выбирать направление и расти в нём. Всё это не только для себя, но и для команды (даже новой зарубежной). Мы отдаём полноценный самостоятельный тариф курса — вы прочитаете 4 лонгрида и посмотрите 4 ланчтайма.

К сожалению, мы не умеем отдавать курсы совсем бесплатно, поэтому вам придётся ввести промокод FREE и заплатить 1 рубль. Пожалуйста, не покупайте курс «впрок» — у нас есть себестоимость, и если вы купите курс и сложите его в папку «курсы потом» — вы нагрузите нас на деньги.

Если у вас не работают карты — начните покупать, а затем напишите нам на support@education.borshev.com.
Запускаю новый проект - PM совет

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

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

Теперь я запускаю такой ПМО по подписке - PM совет. И приглашаю вас в него 🌝

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

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

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

Темы первой встречи:
1. Клиент прислал вот такое письмо. Как ответить?
2. Сделаем разбивку и оценку фичи лайки в телеграме.


Приходите!
Недавно я согласилась преподавать Проектный менеджмент

В последние месяцы очень хочу делиться своим небольшим опытом с начинающими пмами.

У меня было даже 2 менти, которые в итоге куда-то пропали) я все же надеюсь, что они очень заняты и попросту некогда) в любом случаи - Хеллоу, если вы меня читаете) дайте знать, что у вас все хорошо)

Программа написана, драфтовая, жду фидбек от организаторов курса.

Пока составляла программу думала :
-как вообще *** научить пма принимать верные решения, где я и сама иногда косячу?!

Очень крутой кейс выше ☝🏼

Дайте знать, если у вас есть предположения как ответить клиенту, чтобы он не отказался от вас и остался доволен(или не навредить своей компании, что в принципе, одно и тоже)
👥 Получить что-то от вас

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

Людям плевать, чего хочет компания. Людям плевать, чего хочет начальство. Людям абсолютно плевать, чего хотите вы.

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

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

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

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

Канбан, в переводе с японского - это "вывеска магазина" или "бирка". На заводе Тойота, который первым начал использовать канбан в автомобилестроении, такие карточки использовали как форму заказа деталей.

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

Мне эта система напомнила тикеты в джире после декомпозиции.

Книга "Канбан и точно вовремя" рассказывает про завод и принципы его работы. Читать, по больше части, скучно. Зато некоторые идеи любопытно переложить на наш ИТ-мир. Например:

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

Производить надо ровно столько деталей, сколько требуется для сборки нужного количества автомобилей. Это число определяет отдел продаж. Если производить детали или целые машины впрок, то потом они стоят на складе, за который надо платить, ржавеют и портятся. Так же и с кодом. Писать надо только те, фичи, которые будут использоваться (= продаваться), чтобы не захламлять продукт и платить минимум за его обслуживание.
Коротко о текущих буднях, что думаете? Что происходит у меня? 🤤
🛰 Спрашивали — отвечаем 45

“Сергей, добрый день. Хочу в рубрику «Спрашивали?отвечаем» задать вопрос. Руководитель подразделения может не разбираться глубоко с том, что знают его подопечные, ему достаточно понимать в общем и грамотно руководить. Если РП не разбирается в теме проекта, может ли он его вести? И как это делать правильно?”

Этот вопрос мучает менеджеров уже много лет. Должен ли РМ быть экспертом в области, в которой он управляет проектом? Если нет, то как управлять тем, в чем не разбираешься? Если да, то, получается, управленческие навыки не так важны, как узкоспециальные знания?

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

Желание поставить во главе проекта человека, который разбирается в предметной области, продиктовано либо страхом (ой, ну как это кому попало отдашь?), либо соображениями экономии (профи у руля — другие профи в проекте не нужны).

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

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

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

Если отвечать за скоуп, бюджет и срок уже скучно, посмотрите каким еще менеджером можно стать:

Resource - хэд отдела ПМов, такие встречаются в компаниях 100+ человек. Помогает менеджерам расти, нанимает новых, распределяет между проектами. Иисус, наверное, был RMом - без любви к человеку здесь никак. 

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

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

Account - развивает отношения с существующим клиентом. Главный по контрактам, доп. продажам, сбору фидбека и поздравлениям на праздники. 

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

Product - отвечает за фичи, метрики, пользователей, прибыль. В СНГ сейчас бум на эту специальность, много вакансий, курсов, конференций. Классный опыт, чтобы потом запустить свой проект.
Как работать с рисками

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

Объясню на примере.

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

Хороший ПМ увидит в этом потенциальную проблему и пойдет ее решать:

1️⃣ Вспомнит, что Валера говорил на последних ретрах. Какие из его задач были самыми грустными. Проведет 1-1 и выяснит, что Валера устал от проекта за 3 года, но пока еще не созрел уходить. Это идентификация риска.

2️⃣ Если забить на проблему, то с вероятностью 70% Валера уволится. На замену джависта компания потратит примерно $15K. Это анализ риска.

3️⃣ Затем ПМ прикинет варианты решения. Дать Валере других задач или, быть может, перевести на другой проект. А если Валера не вписался в коллектив, и код его так себе, то, может, и нафиг Валеру?

4️⃣ Предположим, другие задачи и проект Валеру не впечатлят, и он решит уйти. Как к этому заранее подготовиться? Потянет ли второй джавист Леша весь проект? Где быстро раздобыть замену? Как дела с документацией? Этот и предыдущий пункты называют смягчение (mitigation) риска.

5️⃣ Валера теперь под прицелом. ПМ будет наблюдать его настроение пристальнее обычного и встречаться с ним раз в неделю. Это мониторинг риска.

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

Честно говоря, я часто забиваю и не веду этот реестр. В продуктовых компаниях с плоской структурой, где ПМ репортает СТО, CPO или CEO, можно без него обойтись. Но если не чувствуете хорошей, доверительной культуры - лучше вести.

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

Вот и весь риск-менеджмент.
Forwarded from Product Management & AI
#exp Диего Гранадос делится своим шаблоном резюме продакт-менеджера (с которым его взяли в Microsoft в 2019 году) и советами по его составлению:

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

Записывайте достижения с помощью XYZ, формулы которую используют рекрутеры Google: «Достиг [X], измеряемый [Y], выполнив [Z]». Следуйте ей как можно точнее.

🔴 Используйте сильные глаголы. Начинайте каждое достижение с глагола в прошедшем времени. Сильные глаголы (ведущие) >>>> Мягкие глаголы (вспомогательные).

Используйте слова, соответствующие роли. Для PM я использовал: Led, Designed, Researched, Priority и т. д.

🔵 Соответствующие навыки. У меня нет отдельного раздела "навыки", заполненного ключевыми словами менеджера по продукту, такими как «многофункциональность», «лидерство», «приоритизация», «дорожная карта».

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

🟡 Покажите свое влияние. Не все должно иметь влияние – вы можете выполнять работу, делать ее хорошо и это будет иметь значение. Любой может «завершить проект вовремя», но не каждый может «завершить проект вовремя, выполнив x и оказав влияние y».

🟢 Технические навыки. Я записываю все известные мне технические навыки и многие из них взяты из описаний вакансий, на которые я претендовал.

Разбросайте технические (сложные) навыки и здесь и там. Не помещайте их просто в раздел навыков.

Полезное по теме:

Список топовых ошибок в резюме менеджеров по продукту

10 советов, чтобы сделать ваше резюме лучше

Пишем собственное handmade резюме продакта