Project management: определяем вашу крутость!

 Публичный пост
18 мая 2021  4062

Меня давно просили написать про качества и умения проектных менеджеров в применении к уровням seniority. Пришло время об этом поговорить!

Осторожно! Длинный и очень специализированный пост для тех, кто в теме.

Вводная

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

Учитывайте, во многих случаях проектный менеджер это еще и scrum master или business analyst. Специальные вопросы по этим компетенциям не входят в scope этого поста.

Вхождение в профессию

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

Почти не важно откуда вы пришли и чем занимались до этого. IT-шный background важен и очень поможет, но есть много случаев успешных управленцев, кто только вчера пришел из психологии, HR или журналистики. Найдите себе ментора и активно учитесь, а практика добавит знаний со временем.

Проектный менеджер это

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

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

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

Итак, список без приоритезации:

  • Может донести вижн продукта и компании в команду. И убедить почему это важно для команды
  • Имеет влияние на принятие решений внутри команды
  • Знает фазы формирования команды и может предпринимать шаги для эволюции команды. Storming-norming-performing и вот это все. Оно правда работает!
  • Уточняет роли и ответственность между членами команды если есть сложности
  • Распознает индивидуальный вклад членов команды и общие достижения
  • Знает кому дать задачу или у кого спросить
  • Знает какие задачи нельзя делегировать в условиях отдельно выбранной команды / продукта
  • Способен проконтролировать выполнение задач в рамках одной команды и поставить задачу наружу когда надо
  • Фокусируется на решении проблем отдельно взятой команды
  • Способен следовать существующим процессам управления изменениями
  • Способен отследить зависимости между требованиями после того как их определит команда
  • Способен составить краткосрочный project timeline и скоммуницировать с основными заказчиками
  • Фасилитирует идентификацию рисков и может их дальше отследить. Знает атрибуты рисков и способы что с этими рисками дальше делать. Mitigation - accept - transfer и все остальное
  • Составляет проектную документацию по существующим шаблонам
  • Понимает и может посчитать метрики качества того что делает команда. Сюда же про метрики из Agile
  • Учитывает эмоциональную составляющую в коммуникациях
  • Может выявить ожидания заказчика от процессов и результата работы команды
  • Знает разные методологии и их применимость: Scrum / Kanban / Scrumban/ PMP практики / SAFe / LESS / PRINCE2 / что там еще понаизобретали
  • Регулярно и понятно отчитывается по проекту, хотя бы по существующему шаблону
  • Может скоординировать командировку, в том числе к внешнему заказчику
  • Может внедрить улучшения процессов, которые набрейнштормил с командой
  • Способен скоординировать UAT и выкатку нового сервиса в прод + post-production support, скорее всего с консультацией команды
  • Может перевернуть конфликт из эмоционального в конструктивное русло
  • Обладает навыками переговорщика. Желательно позаниматься переговорными поединками.
  • Внешне спокоен даже когда паника и мы в огне
  • Команда до 10 FTE (человеко- единиц на фултайме)
  • Ведет проекты в разных фазах. Не ожидается опыт управления полного цикла. Закрывал и начинал проекты - получи плюсик в карму
  • Знает разные техники оценки проектов и способен объяснить разницу. Story point / человекочасы / PERT / уверенность к дате / футболки и все остальное
  • Держит команду сфокусированной на общей цели и не позволяет растекаться мыслю по древу
  • Ему нужен регулярный супервижн на тему что он делает и как, хотя бы для моральной поддержки

Хочу промоушн!

Итак, вы поняли что уже можете все что описано выше и вам даже не сложно. Или кажется что хочется лычку Senior помидор. Или меняете работу. Или денег захотелось за выслугу лет. Ниже критерии для Senior Project Manager.

Warning! От компании к компании требования к синьорам будут меняться. Ниже описано скорее среднее по больнице. Кстати, часто ожидается что Senior управляет еще и людьми. На практике это не всегда обязательно, но может меняться от конторы к конторе.

Список в дополнение к предыдущему:

  • Имеет влияние на принятие решений еще и заказчиками. Особенно актуально для аутсорса!
  • Вдохновляет команду на инновационные идеи
  • Знает как построить команду из разношерстной группы
  • Непрерывно анализирует перформанс команды и находит точки роста
  • Способен развивать poor performers даже если ими напрямую не управляет.
  • Может передоговориться про сроки и бюджеты или поменять коней на переправе, без ущерба репутации команды. Сюда же про переубедить заказчика бежать в неправильную сторону.
  • Определяет критерии успеха достигнутых договоренностей = как мы поймем что цель достигнута. Это не так просто как кажется!
  • Избегает прогнозируемых конфликтов
  • Определяет ресурсы, необходимое оборудование, материалы и людей, нужное в будущем
  • Управляет активностями, затрагивающими внутренних и внешних stakeholders, а не только одного продуктолога и полтора заказчика.
  • Делегирует с учетом индивидуальных планов развития членов команды, а не просто вбрасывает задачи. Может делигировать проектно-менеджерские задачи если кого-то выращивает.
  • Контролирует выполнение задач в том числе за пределами своей команды и может предусмотреть сценарии задержек
  • Часто у него уже больше одной команды, но он все еще может погрузиться в детали когда надо
  • Фокусируется на решении проблем за пределами команды и способен влиять на внешних для конторы заказчиков
  • Способен создать с нуля процессы управления изменениями и разбора косяков
  • Способен определить метрики для backlog monitoring, тестирования, перформанса команды и чего-нибудь еще
  • Способен определить зависимости между требованиями самостоятельно. Исключение: если менеджер нетехнический, а проект очень технический, но об этом мы поговорим отдельно.
  • Способен оценить проект не только про срок, но и про бюджеты. Понимает что такое P&L и способен его как минимум прочитать
  • Способен составить project timeline долгосрочно и скоммуницировать изменения чтобы не больно
  • Способен определить риски scope, schedule, budget and resources, дополнить их с командой и регулярно отслеживать их вероятности. В деньгах тоже может посчитать (хотя почему-то это очень редко реально нужно)
  • Составляет проектную документацию по шаблонам, придумывает шаблоны и может аргументированно выбрать нужный именно этому проекту набор документов. Это не про бизнес-анализ!
  • Делает онбординг документы для команды / проекта и менторит новичков
  • (Если технический менеджер) Может аргументированно обсудить с тест-лидом вопросы качества и метрики. И поговорить с техлидом про архитектуру
  • Emotional intelligence всегда и везде
  • (Если управляет людьми) Мотивирует подчиненных с учетом их долгосрочных целей
  • Обсуждает нужные и потенциальные ротации людей в команде и имеет на них влияние
  • Может определить разницу ожиданий заказчиков и реальности, а затем ее починить
  • Может выбрать и внедрить методологию, подходящую именно для этого проекта
  • Настраивает процессы репортинга по проекту, в зависимости от аудитории
  • Может обосновать командировку / закупку оборудования / бонусы команде
  • Способен придумать и внедрить процессы как выкатывать сервис в прод и потом поддерживать
  • Участвует в pre-sale, RFP / RFI, может написать scope statement или SoW
  • Может аргументированно предугадать последствия действий и решений команды / заказчика
  • Отслеживает особенности аудитории и может по-разному вести себя. Пример: суровые олдскульные stakeholders из Англии требуют совершенно другого подхода чем архитектор из соседней команды
  • Формулирует критерии принятия решений в зависимости от ситуации
  • Примерно три года опыта и команда 7-25 FTE, но это зависит от сложности предыдущего опыта
  • Управлял проектами полного цикла и на всех фазах
  • Способен выбрать способ оценки и единицы измерения для проекта в зависимости от ситуации
  • Ему уже не нужен регулярный супервижн, но он придет с вопросами сам когда приспичит

Если здесь вам показалось что вы уже все умеете, не спешите с выводами, а поотвечайте на вопросы ниже. А лучше обсудите свои ответы с более опытным коллегой. Большинство менеджеров переоценивают свои навыки!

Вопросики

Для проверки всего этого у меня выработался набор вопросов. Часть подходит только для собеседований, часть - только для комитетов на промоушн. Однако если у вас получится переформулировать вопросы в микро-кейсы, вы сможете понять как человек думает. А это - самое важное в оценке "тянет vs не торт". Перед тем как оценивать ответы, как можно четче сформулируйте кто вам нужен. Иначе будет очень субъективно.

На большую часть вопросов нет правильных ответов и это прекрасно. У нас тут творчество, а не по учебнику!

  1. Как вы обрабатываете change requests если у вас Agile, а проект с внешним заказчиком?
  2. Чем fix-price проект отличается от time&materials, с точки зрения проектного управления? Какие единицы измерения и методику оценки примените для fix-price проекта?
  3. Для какого проекта вы бы применили оценки в человеко-часах, а когда story points? Почему? Как это было в вашей практике?
  4. Что делать если заказчик игнорирует ваши сообщения / не принимает решение по важному вопросу? Осторожно, это вопрос со звездочкой и эскалация это ответ джуниора.
  5. Почему отчеты по проекту это важно? Зачем они нужны? Как вы строите практику проектной отчетности у себя и почему именно так?
  6. Как вы знаете что проект on track и зеленый? Универсальный маркер проверки на seniority, обожаю этот вопрос
  7. Что такое успешный проект? Как вы поймете что он успешный? Приведите пример своего успешного проекта?
  8. Приведите пример stakeholders вашего проекта и опишите их интересы. Как вы управляете их ожиданиями?
  9. Какой самый сложный конфликт вы решили? Почему он сложный?
  10. Пример хорошей и плохой эскалации из вашей практики?
  11. Какие стратегии реакции на риски вы применяете на нынешнем проекте и почему?
  12. Как вы считаете риски в цифрах? Почему и когда этого делать не нужно?
  13. Как используете роадмапы на Agile проектах?
  14. Возможно ли использовать Agile на fix-price проектах и почему?
  15. Что такое SAFe и на каком проекте вы бы его применили? Какие метрики уникальны для этой методологии? (задавайте вопросы про SAFe только если это релевантно - не все должны его знать)
  16. Что будете делать если член команды демотивирован скучными для него, но обязательными для проекта задачами?
  17. Какая основная проблема с распределенными командами и что с этим делать чтобы было не так больно?
  18. В чем разница управления командой на 5 и 25 человек? Какой ваш опыт?
  19. Как справиться с культурными различиями в команде / с заказчиками?
  20. Какие задачи вы никогда не делегируете и почему?
  21. Что такое follow-the-sun концепт в контексте распределенных команд?
  22. Какая ваша основная проблема с неформальным лидерством в команде и что вы с этим делаете?
  23. Вы управляете четырьмя командами с проектами, которые все длятся примерно год и сейчас находятся в разных фазах. Как будете планировать ротации между ними, особенно для технических лидов?
  24. Какой ваш опыт работы с бюджетами проекта и P&L? Если да, то какие пути снижения стоимости ресурсов вы знаете? Сюда же: как вы поймете что ваш P&L зеленый?
  25. (Аутсорс онли) Опишите жизненный цикл контракта в вашей компании. Где и как вы вовлечены? Сюда же: что вы включите в SoW? Почему?
  26. Какие основные метрики для проекта с фиксированным бюджетом?
  27. Опишите разницу между проектными и командными метриками?
  28. Представьте что вы завтра начинаете новый проект. Вам спустили сверху дедлайн и если его завалить, контора попадает на деньги. Ваши действия в первые две недели? Вы не участвовали в оценке проекта.
  29. Ваши действия когда нужно набрать людей в команду на новый проект?
  30. Какие цели у project kick-off meeting? Другими словами, что нужно сделать на старте проекта?
  31. Ваши действия при закрытии проекта? Разница в процессе закрытия проекта если продукт запустили / проект просто отменили?

Я стар. Я супер-стар.

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

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

Всегда есть зоны роста. Вопрос только когда вам надоест. Мне вот надоело спустя 10 лет. Часто бывает что проектник уходит в Delivery и там доучивается про домен / аналитику / технарство / что там у вас. Бывает, уходят в продакты и там учатся совсем другому.

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

Что там за горизонтом?

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

Выводы

А не будет их. Вы просили длиннопсто - я написала. Давайте обсуждать. А то вдруг бабушка Юля оторвалась от реальности и оно все совсем не так.

Этот пост закрыт от внешнего мира, что-то не хочется бесплатно делиться в этот раз :)

Аватар Yulia Belozerova
Yulia Belozerova @Covectb_cobaka
Technical Program ManagerКое-что про payments :)
📍Amsterdam, Нидерланды

✍️ Телеграм: Covectb_cobaka

Связанные посты
37 комментариев 👇
🕵️ Юзер скрыл свои комментарии от публичного просмотра...

Недавно сам сдавал внутренний экзамен на сеньора-помидора в этом нашем проектом управлении. Как-то так получилось, что я им уже 20 лет как занимаюсь с переменным успехом, нанимаю всяких разных менеджеров (и проектных, и деливери, и сениор, и не-сениор), а сам всё ещё рылом не вышел.

И вот какое наблюдение в этой связи. Говорю только за своих коллег, ибо как оно там в других компаниях я не знаю.

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

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

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

То есть у нас тут ошибка выжившего, помноженная на эффект Данинга-Крюгера в полный рост. И это очень опасно.

Если кандидат предлагает другую стратегию решения — интервьюер автоматически считает её проигрышной, просто потому, что она отличается от его выигрышной. Но вот только проектное управление — это не шашки. И даже не шахматы. Это скорее го в трёхмерном пространстве с камнями всего RGB-спектра.

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

Потом ещё напишу, очень жжёт тема конечно.

  Развернуть 1 комментарий

@zahhar, Если у вас большой опыт проведения интеревью с манагерами, я бы почитал длиннопост на тему)

  Развернуть 1 комментарий

@JdaZKJAz8qxqvCOn, я увы не умею в длиннопосты связные, я могу за раз сфокусироваться на 10 минут на 1 задаче

  Развернуть 1 комментарий

@zahhar, может тогда на AMA получится раскрыть свой потенциал?)

  Развернуть 1 комментарий

@OkunevDmitrii, ама можно, если это кому-то интересно. но только ж недавно в апреле было уже ама про пм с Юлей, было ама про собеседования и ама про нетехнические интервью. Сложно будет дать новую перспективу. но если будет интерес — я готов.

  Развернуть 1 комментарий
Максим Смелов Проджект манагер 19 мая 2021

Вижу пост @covectb_cobaka - ставлю плюс

  Развернуть 1 комментарий

@smelov, гран мерси) По контенту поста есть комментарии?

  Развернуть 1 комментарий

@Covectb_cobaka, не, кто я такой чтобы комменты давать? У меня весь проджектинг идет по наитию в трелло досках чтобы всем удобненько было

Ни о каких человекочасах и стори поинтах еще не задумываемся даже

  Развернуть 1 комментарий

@smelov, мне всегда интересно читать, как там, в большом мире бизнеса.

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

Осталось перевести все в чек-лист и можно устроить assesment в нашем PMO))

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

  Развернуть 1 комментарий
Sergei Ruzki Python Developer, ERP Architect, Odoo User 19 мая 2021

Я так понял, сверху расписан скучный вторник хорошего, годного PM?

  Развернуть 1 комментарий

@sergeiruzki, скорее набор умений в формате выберите любые 70%

  Развернуть 1 комментарий

В разных компаниях могут быть разные критерии которые обычно отражены в competency matrix (если у вас более десятка ПМов вам надо как то стандартизировать процесс) я тут наткнулся на такое вот https://www.progression.fyi/ и сейчас пишу гайд по компетенциям для EM/PM/TPM (и готовлюсь к собеседованиям)

  Развернуть 1 комментарий

@rkononov, спасибо за ссылку на фреймворк. Долго искал что-то подобное

  Развернуть 1 комментарий

@rkononov, получилось из гайда что-то?

  Развернуть 1 комментарий

Читать список скиллов из разных областей тяжело, тк список выходит длинный. Столкнулся с такой же проблемой, когда создавал карту грейдов для инженерной ветки в офисе. Улучшает ситуацию разбиение по категориям(управление командой, планирование и тп), хороший пример подсмотрел здесь https://docs.google.com/spreadsheets/d/11W3TujA-Lx7oj79lt3QgjqdwY6aAUTC76RF-vnPfHYI/edit#gid=668888240

Сложно это использовать, так как и критерии для оценки этих навыков не просто подобрать.

Допустим, если использовать этот лист как set expectations для менеджеров определенного уровня в компании. Сидит напротив менеджер на квартальном ревью и ты пытаешься оценить человека по пунктам:
"Может аргументированно предугадать последствия действий и решений команды / заказчика"
"Отслеживает особенности аудитории и может по-разному вести себя." (взял 2 рандомных)

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

  Развернуть 1 комментарий

@artmaro, по хорошему, в течение того же квартала должны набираться кейсы про то, что менеджер (не) делал на практике. В примере из "Может аргументированно предугадать последствия действий и решений команды / заказчика" - идет конкретный проект, исходя из общей логики менеджер заранее закладывает нужную гибкость решения там, где у заказчика возможна смена мировоззрения (ну, если остальные условия позволяют), заказчик мировоззрение под конец меняет - а у нас уже всё готово, осталось немного подпилить под детали. И тогда на ревью есть конкретный аргумент - да, хотя бы один раз у менеджера получилось. Если получилось несколько раз - наверное, это все же уже не везение, а скилл.

  Развернуть 1 комментарий
alex konstantinov Менеджер проекта 20 мая 2021

А я всегда считал, что ПМ это тот, кто должен попасть в треугольник и оставить заказчика с командой довольные. Для меня градация такая:
Джун - не попадает в треугольник сильно, всем грустно
Синьор - не попадает поменьше, но все довольны.

А перечисленное - лишь инструменты, которые могут и не пригодиться

  Развернуть 1 комментарий

@alexk, В целом да, но очень много полутонов. Че не Синьор, если - сильно не попадает, но все довольны.

  Развернуть 1 комментарий

@Uladzimir, если человек не попадает, но им довольны, значит он нашёл своё место. Кто мы такие, чтобы запрещать инвестору сливать кэш в трубу?
Просто это история об отношениях, а не профессиональном развитии

  Развернуть 1 комментарий

@alexk, если разбивать тот треугольник на более ощутимые кусочки, примерно такой список и выйдет. Поищите ответ на вопрос как понять что человек попадает в квадратик ожиданий, чтобы осмысленно посчитать и более объективно чем "нраица".

  Развернуть 1 комментарий

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

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

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

  Развернуть 1 комментарий

@alexk, если обратить внимание, в списке вопросов про это много говорится. Я не сторонник гонять по теории. Должны быть примеры из опыта кандидата.
С другой стороны, при формальных комиссиях на промоушн нужно более развесисто высчитывать готовность кандидата - рождаются критерии формата "может это - не может то". И оно тоже на примерах, куда же без них.

Так что мы говорим про одно и то же.

  Развернуть 1 комментарий

Охх, мой любимый автор, да еще и на любимую тему!!! 

  Развернуть 1 комментарий
Olga Sentemova Королева заправки 21 мая 2021

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

  Развернуть 1 комментарий

@tomasmor, спросите его, какой портрет "идеального разработчика", с кем ему комфортно работать.

  Развернуть 1 комментарий

Как-то очень мало о том, как вкатиться. Чтоб найти работу в разработке, можно самому сколотить портфолио. Ещё хорошо представляю, как в рамках одной компании человека переводят с разработки в ПМ при его желании. А как устроиться ПМом без опыта в разработке? Как доказать свою компетентность?

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

@standin, большинство ПМов не из разработки, кстати говоря.

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

  Развернуть 1 комментарий

@standin, можно посмотреть на курсы, например, https://productuniversity.ru/project. Правда не знаю, есть ли у них практика и достаточно ли этого для трудоустройства.

  Развернуть 1 комментарий

@standin, У поста нет цели про вкатиться. На вкатывание отдельный пост нужен. Но он сведется к тому же: начинайте управлять проектами и набивать шишки.

  Развернуть 1 комментарий

Список вопросиков здорово приземляет, ггг

Я бы послушал ответ автора на вопрос 6.

Мой вариант, если коротко:

  • отсутствие вновь выявленных рисков
  • требования Заказчика не менялись после последнего согласования
  • по вехам всё в графике
  • стороны всё ещё соблюдают обязательства в части приёмки и оплаты ;)
  Развернуть 1 комментарий

@Arthur777, Да, список вопросов выглядить или как заготовка на интервью или как список дискуссионых вопросов)

  Развернуть 1 комментарий

@Uladzimir, вы не сможете все вопросы задать на интервью. В первую очередь потому что вопросы зависят от роли и кандидата, а точнее его опыта. Вопросами покрываются области, где или критично для роли, или есть вопросики к резюме кандидата. Аналогично на promotion assessment.

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

  Развернуть 1 комментарий

@Arthur777,

Критерии зеленость проекта не одинаковы между проектами. Более того, зеленость - непостоянный атрибут. Если ваш проект всегда зеленый, вы underreport.

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

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

Если ваш проект вечно красный, вы overreport. Потому что красный = нужно вмешательство senior stakeholders и это разовое событие. Например, нам не платят по контракту в обещанные даты и мы уже со всеми поговорили, но получили только завтраки = красный = памагите!

Есть новые риски и они грозят выстрелить завтра, но у нас есть план? Проект максимум рыжий.

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

Завершая ответ, учитывайте несколько метрик, оценивайте их отдельно и выводите общее. Например:
Риски - green, зависимости - amber потому что нам должны вот эти доступы и не дають, delivery - green потому что все по плану, requirements - red потому что не можем финализировать scope следующей фазы, а там пора начинать пилить уже. Если что-то не-зеленое, весь проект скорее всего заленым не будет. А для этого пример он будет скорее рыжим, но даже красным если требования к следующей фазе это Самое Главное для этого отдельно выбранного проекта.

  • Новые риски это хорошо. Значит вы продолжаете следить за проектом. Плохо если случается нежданчик и вы к нему не готовы.
  • Изменяющиеся требования это тоже не так плохо как кажется. Особенно если Agile. А если не он, то формальный change request с переоценкой оставшегося срока и ресурсов никто не отменял. Плохо станет если требования меняются мимо процессов и за них никто не готов платить. И если даты не меняются, а пытаются впихнуть невпихуемое.
  • План соответствет реальности, да. Ну или вы обновили план и все с ним согласны.
  • Обязательства это очень важно, да.

Помогло?

  Развернуть 1 комментарий

@Covectb_cobaka, конечно, большое спасибо. По некоторым моментам я бы подискутировал, но непринципиально ))

  Развернуть 1 комментарий

😎

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

Что вообще здесь происходит?


Войти  или  Вступить в Клуб