Комментарии 16
круто)
Как стать ПМ, если на эту должность нужен опыт, а опыт взять негде?
Здравствуйте! Стать PM без опыта непросто, но возможно. Если у вас нет опыта в IT, начните с курсов по управлению проектами. Затем можно попробовать себя на позиции ассистента PM или стажёра (Project Manager Trainee). Многие крупные компании предлагают стажировки, где вы получите реальный опыт. Да, зарплата на старте будет небольшой, но это шанс набрать навыки и вскоре претендовать на полноценные вакансии PM.
Где-то я уже встречал эти пять пунктов, про которые «не расскажут в учебниках». По крайней мере ни один из них не вызвал у меня того самого «Вот оно как, Михалыч!». Как мне кажется, заголовок уж слишком многообещающий.
К содержанию претензий нет, четко, сжато, все по делу.
Разве что в конце ожидал стандартное «Доклад закончил!» :)
Спасибо @WMT, что делаете эту жизнь лучше: выполнил промпт "преврати статью в дообучающий промпт для моего AI-ассистента проект менеджера" и добавил результат в настройки моему Project-Manager AI-ассистенту. Ниже перевод промпта с английского:
[Ты — проект менеджер в IT.....]
Добавь к своей модели поведения следующие принципы:
Фокус на ценности для бизнеса
Перед стартом задачи уточни: какую проблему решаем?
Определи, что является MVP.
Избегай избыточной документации, если это мешает скорости и эффективности
Работа с конфликтами
Не сглаживай конфликт, а помогай организовать конструктивные обсуждения.
Предлагай формат анализа «Плюсы / Минусы / Интересно» для принятия решений в команде.
Открытая коммуникация
Помогай формулировать проблемы прозрачно.
Советуй регулярные синхронизации не только по статусу, но и по рискам.
Поощряй честность и вовлечённость внутри команды.
Бери на себя инициативу
Не требуй одобрения для каждого действия, если уровень риска допустим.
Помогай PM принимать решения на основе оценки: риски, альтернативы, влияние.
Предотвращай выгорание
Следи за перегрузками в расписании.
Предлагай расстановку приоритетов по матрице Эйзенхауэра.
Напоминай о необходимости отдыха.
Может быть и использовался LLM, но статья всё равно получилась хорошей, причём с включением в неё своих примеров из работы.
Прикольно я каждый день делаю эту матрицу эйзенхауера
Сильно разгружает мозг когда открыто 150 задачь
Есть лайфхак с этой матрицей попробуйте заполнять ее не просто по всем дела. Одновременно а таким образом
В одной такой таблице заполните ваши приоритеты затем спускайтесь по приоритетам соотносить остальные дела разбивая их таким вот фрактальным методом... У вас получится много листочков но они всегда будут четко сгруппированы.
Также можно делать по приоритетам или по клиентам если много задачь они так лучше группируются таким образом можно найти стек задачь с одинаковыми механизмами исполнения
Ну и чтобы проще печатать можно использовать супер быстрое решение https://eisenhower.ru
Хоть сайт и позволяет типа чтото там написать Можно даже ничего не заполнять просто чисто в печать и дальше от руки у меня так лучше работает как оказалось
На старте я пытался следовать методологиям буквально: идеальный backlog, идеальные user stories, детальные диаграммы Ганта.
Но вскоре я понял, что бизнес-заказчик не оценит ваши документы, если вы не решаете его реальную проблему.
Простите, а вы точно проджект-менеджер?
Разве ваша задача - не управлять проектом?
А решать проблемы заказчика должны аккаунт-менеджеры, которые предложат заказчику продукт, соответствующий его проблемам (и нормам маржинальности компании) - которые, предварительно, выявят аналитики. А если вы, по-русски колхозно, сам себе и АМ, и РП и аналитик - а также бухгалтер, генеральный директор и немножко разработчик - и пытаетесь по ходу разработки решать проблемы заказчика (которые надо было решить ещё на этапе ТЗ) - то лучше не тратьте время на написание статей на Хабре. Это точно последнее, что должен делать такой многофункциональный "проджект менеджер"
На счет дейликов (из урока №3), на которых подсвечивают риски и проблемы. Они для этого и нужны, так как понять в каком статусе задача можно и смотря на доску в Jira или на доске со стикерами. Если там написано inProgress, значит я ее делаю и есть ли смысл спрашивать об этом - не понятно, оно же видно. Там же видно и то, что я делал вчера и то, что буду делать дальше (потому что у задач есть приоритет и надо брать самую приоритетную).
А вот если я оценили задачу в 2 дня, а делаю ее неделю - вот тут стоит спросить, что пошло не так. Или если я вижу затык по проблеме - я должен уточнить у кого-нибудь на дейли, если не сделал этого раньше.
Странно, что о базовых требованиях вдруг не пишут в учебниках. Может, вы не учебники изучали?)
Все по делу. Респект автору.
Заголовок уж очень маркетинговый
Содержание больше похоже, на заявку о себе (резюме+) - на радость HR'ам:
"год стал для меня испытанием, но и подарил ценные уроки"
"помогло мне выжить и стать лучше в профессии"
"понял, что бизнес-заказчик не оценит ваши документы, если"
"Конфликты - это не угроза, а возможность"
"я предложил провести короткий воркшоп, где команда"
"найден компромиссный вариант, который ускорил релиз на две недели"
"но редко говорят, как важно честно признавать ошибки и делиться проблемами с командой и заказчиками"
"Вместо того чтобы «тянуть резину», я собрал команду и честно рассказал о проблеме"
"Это позволяет команде быть на одной волне"
"PM это тот, кто должен взять на себя ответственность за результат,"
* ... устал цитировать
Непонятно, о каких учебниках говорит автор, но в том же PMBOK всё это (кроме, пожалуй, необходимости бережного отношения к себе) описывается с горкой.
5 уроков, которые я усвоил за год работы проджект-менеджером в IT: об этом не расскажут в учебниках