Junior AI PM

#артефакты
EVM (EVA) для чайников

Существует отличный способ узнать прогресс по проекту не прибегая к колбаскам Гантта и сравнению план vs факт. Этот метод освоенного объема. В руках грамотного менеджера он превращается в могучий инструмент.

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

Есть 3 параметра:
PV - запланированный бюджет на данный момент
EV - освоенный бюджет (сколько прибыли принесли те задачи, которые мы успели сделать)
AC - потраченные деньги (сколько денег мы потратили, чтобы сделать таски, себестоимость)

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

SV=EV-PV - shedule variance, отклонение от сроков. Так мы узнаем состояние наших прогнозов по срокам.

CV=EV-AC - cost variance, отклонение от стоимости. Так мы узнаем состояние бюджета нашего проекта.

Хорошо, мы узнали что отстаем от бюджета на 2000 $, как понять много это или мало? Вроде ни о чем. На помощь придут индексы SPI, CPI.
SPI=EV/PV - мы узнали что SPI = 0,2, ага обгоняем дедлайн на 2 недели.

CPI=EV/AC - мы узнали что CPI = -0,3, черт, 2000 $ это 30% бюджета проекта, дело плохо.

Метод универсален и применим в любых! проектах. Так, например я его использую в проекте с итеративно-инкрементным ЖЦ, где планирование происходит в штуках задач, сами задачи заранее не оценивались в часах. Работает чудесно.

Мой шаблон EVM.

#perl
Сжимаем расписание. Техники сатаны
Есть стандартный набор тактик:

Децимация - выкинуть за борт все лишнее в скоупе.

Похудение - уменьшить/упростить сущесвующие айтемы.

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

Такт 22 - команда уходит в овертайм.

Набег варваров - привлечь людей с другого проекта/бенча, экс работников, стахановцев, королеву британии, господа бога.

Ты опять сжимаешь шакал - перетряхиваем последовательные активности в параллельные.

Машина времени - переносим дату релиза.

Специальный соцус от шефа:

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

SEALS 40% rule - заведомо занижать способности команды чтобы иметь резерв на такие реквесты.

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

Девочки по вызову - имитируем фичу армией индусов в ручном режиме.

Оставьте дело профессионалам - покупаем коробочное или саас решение которое имитирует фичу.

Жертвоприношение Исаака - ставим крест на пузе что довезем, недовозим устраиваем срежисированную экзекуцию девелопера/аналитика/тестера "виновного" в провале. На самом деле он получает ротацию с повышением и в лучший проект. Зато не надо записывать в атришен.

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

Приказ 270 - сознаться команде что если не довезем то нам надо будет искать новую работу.

Красноречие 100 - убедить клиента что ему не нужна эта фича.

Ты не пройдешь - говорим заказчику НЕТ твердо и четко.

Я брата позову - эскалация на верх.

Sharing is caring - реализовать фичу силами другой команды в другом приложении.

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

Ejection tie club - покинуть проект.

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

Автор: Олександр Аверченко.

#артефакты
На кой ляд устав проекта?

Если вы спросите своих коллег или товарищей менеджеров проектов, пишут ли они устав, то 50%-60% ответит "нет, зачем?". Невольно задаешься вопросом, а для чего существует этот артефакт, если добрая половина не использует его в практической деятельности.

Вспомним чему учит PMBOK:

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

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

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

Тогда давайте разберемся, зачем вообще этот артефакт нужен.

Устав проекта - это сущность самого проекта. Как говорит Иван Селиховкин, если представлять проект как яйцо - то это его скорлупа.

Устав определяет, что собственно мы понимаем под проектом. Станет ли вам понятно из договора + ТЗ для кого делается проект и с какой целью? Как понять что цель проекта достигнута? Какие риски могут его отменить? Что ожидает заказчик, какие должны быть важные события в течении проекта? Я сомневаюсь.

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

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

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

#мнение
Вы стали Project Manager. Не важно как. В душе тоже сойдет.

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

Цель 1 - пройти фильтр.
На начальном этапе воронки кандидатов много. В первую очередь текст будет смотреть фильтр - рекрутер, либо машина. Грамотный текст резюме содержит ключевые слова, которые совпадают по семантике с моделью "PM".

Резюме должно кратко и емко описывать навыки, опыт работы и достижения. Оно должно напрямую коррелировать с представлением ревизора о том, кто такой Project Manager. Пробежав текст глазами за 10 секунд по диагонали, ревизор составит суждение о том, на кого вы похожи. Если глядя на резюме затрудняетесь сказать кто перед вами (то ли продажник, то ли продакт), то такое резюме нужно в топку.

Цель 2 - выделиться.
После фильтра текст попадет к тому, кто отличит полезного кандидата от бестолкового.

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

Возьмете ли вы себя как помощника по такому резюме? Ответьте себе, какую прикладную пользу может принести человек, описанный в тексте.

Практический совет.
Опишите грамотно опыт работы. По структуре - обязанности→проекты→достижения.

Обязанность это то, что можно описать отглагольным существительным и то, что повторяется регулярно.

Проект - предприятие с высокой неопределенностью, направленное на достижение цели в соответствии с заданными ограничениями. Если было что-то с явной целью; прибитым бюджетом/дейдлайном/требованиями; неповторимое; что-то о чем перед стартом сложно сказать, а как точно его делать, то мои поздравления, у вас был проект!

Достижение - промежуточный результат на пути к цели, желательно с цифрой. "Занимался внедрением Jira" не достижение. "Внедрил jira и увеличил touch time до 4 часов в среднем" уже лучше.

Junior AI PM pinned «Навигация 📬 Почтовый ящик #почтовый_ящик Ответы на вопросы ищущих ответы 🍴Рецепты #рецепт Практические советы для кейсов и трудовых будней ⚖️ Мнения #мнение Авторское мнение о том о сем 👁Полезности #полезности Образовательный контент из внешних источников…»

Навигация
📬 Почтовый ящик #почтовый_ящик
Ответы на вопросы ищущих ответы
🍴Рецепты #рецепт
Практические советы для кейсов и трудовых будней
⚖️ Мнения #мнение
Авторское мнение о том о сем
👁Полезности #полезности
Образовательный контент из внешних источников
📔 Артефакты #артефакты
Шаблоны полезных документов и инструментов
😅 Перлы #perl
Иронично-прекрасные фразы, провоцирующие рефлексию
👻 Иное #иное
Контент, связанный со сторонней активностью автора

#perl
Scrum. Waterfall. Kanban. Что лучше?
Не ссорьтесь, девчата! Самое правильное для проектов - это методология «Плачь и херачь».

В этой методологии на инженера можно повесить до 10 проектов. Ибо по статистике тач-тайм на проектах не больше 10% . И нужно выгнать Скрам-мастера. Это самое бесполезное существо на проекте. Но проект вы один хрен про№#@те. Либо по времени, либо по деньгам. Как следствие, и по качеству.
Спасибо @gospodchikovs за перл

#полезности
Недавно запустилась бесплатная менторская программа от No Flame No Game.

В ней есть трек проджект-менеджмента. Я в ней участвую как ментор и как менти, мне все очень нравится.

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

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

К инициативе можно присоединиться через бота @nfng_bot

#артефакты
Для руководителя проектов крайне важно иметь свою рабочую площадку. То самое место, где ссылки, документы, планы и т.д. Также немаловажен процесс управления знаниями, ведь управление проектами - труд интеллектуальный, а если проект в IT, то тем более. Шаринг знаний встает на 1 место.

PMI также обеспокоился и планирует выпустить в новой редакции PMBOK немного про knowledge management . Ну а пока все в предвкушении, что же там будет, публикую один из своих шаблонов для пространства проекта. Представляет из себя обложку + фундамент базы знаний. Шаблон доступен для дубликата.
https://www.notion.so/artemletyushev/5181220f387f48c9a92d4fe9a13c33e2

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

Сообщества:
@agile_ru
@BA_PO_PM_PdM
@kanban_talks
@PM_lunch
@spbspm
@pmi_ru

Статьи:
@psilonsk
@pm_god
@managerjournal
@selihovkin
@pmdaily
@borisbutton

Новости:
@necodernotes
@pmclub
@PM_Events
@agile_events

#мнение
О сертификациях
Сдал сертификацию в ScrumStudy Scrum Fundamentals Certified. Сразу попрошу не хейтить, сдал бесплатно и исключительно ради спортивного интереса.

Хочется написать какую-то рецензию. Сейчас очень много организаций, которые предлагают получить навыки в Scrum/Kanban/Agile (нужно подчеркнуть) и позиционируют себя как профильные курсы. Казалось бы, везде курсы, тут и там даются знания, на выходе сертификат.

Серьезная разница заключается в 3 фундаментальных вещах: усилиях, рефлексии и признании в обществе.
Проходя условный курс на Coursera, вряд ли будет частить ситуация, когда вы будете ставить на паузу лекцию и думать по полчаса. Уж точно не будет ситуации, когда вы будете тратить долгие часы на подготовку к тесту или решение задания.

И уж точно такой курс не будет "открывать двери", как, например, PSM. Он просто не является фильтром профессионализма и эксклюзивных знаний.

P.S Прошел курс за час, из которых 40 минут скипал видео и 20 отвечал на вопросы сертификации. Решил написать пост на эмоциях.
P.P.S Бросайте себе вызовы, учитесь новому и сдавайте сложные сертификации. Я ушел готовится к CAMP.

#рецепт
Вопросы для работодателя
На собеседовании не только выбирают вас, но и вы приглядываетесь к работодателю.
Есть много подборок с вопросами, которые могут задать на собеседовании. Но почему-то нет вопросов, которые должен задавать соискатель потенциальному работодателю. Исправим ситуацию.
Публикую список вопросов, которые чаще всего задаю на собеседовании:

Культура управления в компании:
- Какая структура у компании? Как устроена иерархия?
- Есть ли okr/kpi/какие-то цели? Как устроено стратегическое планирование?
- Откуда берется команда на проект? Как устроено управление ресурсами?
- Какие есть циклы обратной связи/совещания/собрания?
- Какие есть метрики на проектах (от план/факта и до SLA)?

Контекст проектов:
- Кто основные клиенты?
- Какое типовые проекты (лендинги, бюджетные коттеджи, SAP и т.д.)?
- На чём специализируется компания?

Запуск проекта:
- Откуда берутся проекты?
- Как происходит предварительная оценка проектов?
- Используется ли устав проекта?
- Участвует ли ПМ в составлении юридических документов?

Планирование проекта:
- Как происходит планирование расписания проекта? Как происходят оценки задач?
- Как планируется бюджет проекта? Управляет ли ПМ бюджетом?
- Как планируется содержание проекта? Как собираются требования?

Инфраструктура:
- Какие инструменты используются для управления проектами (MS Project, Jira, Excel)?
- Как выглядит борд в типовом проекте, какие у него есть статусы?
- Какие есть артефакты (смета, тз, реестр рисков)?
- Вопросы про типовые процессы,Например, как устроены тестирование или дизайн?
- Есть ли сисадмин/девопс для поддержки рабочего пространства?

Подводные камни:
- Есть ли премирование команды после завершения проекта?
- Подводятся ли итоги проекта?
- Есть ли планы развития сотрудников?
- Оплачивает ли организация оплату обучения/конференций сотрудников?
- Что произойдет, если ПМ пропадет на один день посреди проекта?
- Что произойдет, если ПМ будет загружен и не сможет писать ТЗ/формировать кп/проводить демо?
- Как происходит повышение в компании?

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

Channel created