А нужны ли "PMBoK-и"?
Недавно писал о необходимости методологий — и ряд событий подтолкнул меня к ещё одному посту.
В работе иногда слышу от заказчиков и коллег такие мнения о сводах стандартов (PMBoK, ICB и др.):
- «Этот PMBoK никому не нужен»
- «Ничего полезного там нет»
- «Я и без пиэмубков проекты закрывал»
Далее делюсь своим взглядом.
————————————————————
📙Что такое PMBoK?
Это свод правил и стандартов. Ок, понятно... А как он создавался?
- Первую версию выпустил PMI в 1996 году (Американский институт проектного менеджмента);
- Обновляется каждые 4 года с учетом лучших практик и требований рынка;
- В обновлённые версии добавляют новые инструменты, подходы, разъяснения от тысяч специалистов из разных стран, причастных к работе с этим документом*.
*- Речь о профессионалах своего дела с огромным опытом.
❔Делает ли это PMBoK «священной книгой» РП?
- Конечно, нет.
При разработке или очередном обновлении мнения профессионалов усредняются, контекст обезличивается и "вымывается". А например, если не ошибаюсь, впервые Agile появился в PMBoK только в 2017 году (поправьте если не прав).
Плюс без многолетнего практического опыта эту литературу не удастся понять во всей ее глубине.
Однако отвергать ее полезность тоже не совсем верно...
📝 Что же делать? (Практические советы)
1. Использовать ключевые понятия:
· Функциональные области (домены) — помогают выстроить устойчивую структуру проекта.
· Жизненный цикл проекта — держит временные рамки и управляемость.
· Проектный треугольник (из версии 4) — помогает фокусироваться на главном.
2. Нарабатывать опыт и брать инструменты из разных практик.
📌 Вывод
Ознакомиться и понять различные своды стандартов будет полезно. Не следует принимать за чистую монету.
Я убежден, что каждый проектный менеджер должен сам определять набор инструментов для проекта — как опытный хирург перед операцией.
Регулярно пробуйте новые подходы, усиливайте свой инструментарий и повышайте насмотренность. Да прибудет с вами сила!💪
#управление_проектами #PMBoK
Недавно писал о необходимости методологий — и ряд событий подтолкнул меня к ещё одному посту.
В работе иногда слышу от заказчиков и коллег такие мнения о сводах стандартов (PMBoK, ICB и др.):
- «Этот PMBoK никому не нужен»
- «Ничего полезного там нет»
- «Я и без пиэмубков проекты закрывал»
Далее делюсь своим взглядом.
————————————————————
📙Что такое PMBoK?
Это свод правил и стандартов. Ок, понятно... А как он создавался?
- Первую версию выпустил PMI в 1996 году (Американский институт проектного менеджмента);
- Обновляется каждые 4 года с учетом лучших практик и требований рынка;
- В обновлённые версии добавляют новые инструменты, подходы, разъяснения от тысяч специалистов из разных стран, причастных к работе с этим документом*.
*- Речь о профессионалах своего дела с огромным опытом.
❔Делает ли это PMBoK «священной книгой» РП?
- Конечно, нет.
При разработке или очередном обновлении мнения профессионалов усредняются, контекст обезличивается и "вымывается". А например, если не ошибаюсь, впервые Agile появился в PMBoK только в 2017 году (поправьте если не прав).
Плюс без многолетнего практического опыта эту литературу не удастся понять во всей ее глубине.
Однако отвергать ее полезность тоже не совсем верно...
📝 Что же делать? (Практические советы)
1. Использовать ключевые понятия:
· Функциональные области (домены) — помогают выстроить устойчивую структуру проекта.
· Жизненный цикл проекта — держит временные рамки и управляемость.
· Проектный треугольник (из версии 4) — помогает фокусироваться на главном.
2. Нарабатывать опыт и брать инструменты из разных практик.
📌 Вывод
Ознакомиться и понять различные своды стандартов будет полезно. Не следует принимать за чистую монету.
Я убежден, что каждый проектный менеджер должен сам определять набор инструментов для проекта — как опытный хирург перед операцией.
Регулярно пробуйте новые подходы, усиливайте свой инструментарий и повышайте насмотренность. Да прибудет с вами сила!
#управление_проектами #PMBoK
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6👍4✍1❤1
Хочу поздравить всех причастных с Днём РП! Но сначала - история.
Время неумолимо летит, мой трудовой стаж растёт. Я успел поработать в разных компаниях и многое повидал.Говорю как дед :)
Однажды я работал в коллективе, который обожал жаловаться.
Приходишь на работу - и начинается:
«Заказчики плохие, начальство неадекватное, проекты неподъёмные, все вокруг - чудаки на букву "М"». Ладно... мы все живые люди и это так или иначе свойственно многим, но не в такой концентрации.
Я особо не участвовал в этих обсуждениях, но и не сопротивлялся. И знаете… со временем я понял, что всё вокруг и правда стало соответствовать этим жалобам.
Тогда я осознал: наше восприятие происходящего - это очень важная штука.
Мы сами своими мыслями и словами рисуем в сознании образ «злых заказчиков», сами в это верим - и живём в этой парадигме.
Это было предисловие к поздравлению. И теперьтост:
Дорогие руководители проектов, а также те, кто хочет ими стать, и все причастные!
От всей души поздравляю вас с нашим профессиональным праздником! 🎉
Желаю вам управлять не только проектами, но и своим восприятием.
Пусть даже в самые сложные времена вы находите силы превращать проблемы в возможности.
Успехов, карьерного и личностного роста! Пусть ваши проекты меняют мир к лучшему 💫
Время неумолимо летит, мой трудовой стаж растёт. Я успел поработать в разных компаниях и многое повидал.
Однажды я работал в коллективе, который обожал жаловаться.
Приходишь на работу - и начинается:
«Заказчики плохие, начальство неадекватное, проекты неподъёмные, все вокруг - чудаки на букву "М"». Ладно... мы все живые люди и это так или иначе свойственно многим, но не в такой концентрации.
Я особо не участвовал в этих обсуждениях, но и не сопротивлялся. И знаете… со временем я понял, что всё вокруг и правда стало соответствовать этим жалобам.
Тогда я осознал: наше восприятие происходящего - это очень важная штука.
Мы сами своими мыслями и словами рисуем в сознании образ «злых заказчиков», сами в это верим - и живём в этой парадигме.
Это было предисловие к поздравлению. И теперь
Дорогие руководители проектов, а также те, кто хочет ими стать, и все причастные!
От всей души поздравляю вас с нашим профессиональным праздником! 🎉
Желаю вам управлять не только проектами, но и своим восприятием.
Пусть даже в самые сложные времена вы находите силы превращать проблемы в возможности.
Успехов, карьерного и личностного роста! Пусть ваши проекты меняют мир к лучшему 💫
🎉13❤7🍾7👏2🔥1🫡1
Предпоследняя тема из фазы планирования.
🎯 Управление поставками в проекте: как избежать срывов и конфликтов
Сегодня разберём одну из областей PMBOK - управление поставками. Еще ее называют управление закупками.
Когда нам нужна эта область знаний? В случае если реализующей проект организации нужны дополнительные материалы/ресурсы/оборудование, которое она не в силах произвести сама. Это могут быть например лицензии на ПО, серверные кластеры или кирпичи :)
В подавляющем большинстве проектов есть потребность в дополнительно материальном снабжении, поэтому эта функциональная область крайне важна. И кстати, это не только про закупку материалов, но и про работу с подрядчиками, партнёрами и внешними ресурсами.
📌 Что входит в управление поставками?
1. Планирование закупок - определяем, что, когда и у кого будем закупать.
2. Выбор поставщиков - проводим тендеры, оцениваем риски.
3. Заключение контрактов - фиксируем условия, SLA, штрафы.
4. Контроль исполнения - следим за сроками, качеством, бюджетами.
5. Закрытие контрактов - подводим итоги, оцениваем сотрудничество.
✍️ Чем пользуемся? Советы, лайфхаки
1.Центральный элемент для РП - Договоры с поставщиками/подрядчиками. Они должны быть качественно составлены. Четкое ТЗ - приблизит к хорошему результату.Но не гарантирует, хе-хе
2. Важна процедура выбора поставщиков. Выбираем, сравниваем и работаем только с теми, кто вызывает доверие или имеет хорошую репутацию.
3. Всегда имейте "план Б". Резервные поставщики спасут от форс-мажоров.
💡 Когда всё идёт не так?
Тревожные звоночки (на самом деле весьма очевидные):
-Поставщик игнорирует ваши письма.
-Срываются промежуточные сроки.
-Сотрудники поставщика часто меняются.
Желаю успехов в закупках 🚀
🎯 Управление поставками в проекте: как избежать срывов и конфликтов
Сегодня разберём одну из областей PMBOK - управление поставками. Еще ее называют управление закупками.
Когда нам нужна эта область знаний? В случае если реализующей проект организации нужны дополнительные материалы/ресурсы/оборудование, которое она не в силах произвести сама. Это могут быть например лицензии на ПО, серверные кластеры или кирпичи :)
В подавляющем большинстве проектов есть потребность в дополнительно материальном снабжении, поэтому эта функциональная область крайне важна. И кстати, это не только про закупку материалов, но и про работу с подрядчиками, партнёрами и внешними ресурсами.
📌 Что входит в управление поставками?
1. Планирование закупок - определяем, что, когда и у кого будем закупать.
2. Выбор поставщиков - проводим тендеры, оцениваем риски.
3. Заключение контрактов - фиксируем условия, SLA, штрафы.
4. Контроль исполнения - следим за сроками, качеством, бюджетами.
5. Закрытие контрактов - подводим итоги, оцениваем сотрудничество.
1.Центральный элемент для РП - Договоры с поставщиками/подрядчиками. Они должны быть качественно составлены. Четкое ТЗ - приблизит к хорошему результату.
2. Важна процедура выбора поставщиков. Выбираем, сравниваем и работаем только с теми, кто вызывает доверие или имеет хорошую репутацию.
3. Всегда имейте "план Б". Резервные поставщики спасут от форс-мажоров.
💡 Когда всё идёт не так?
Тревожные звоночки (на самом деле весьма очевидные):
-Поставщик игнорирует ваши письма.
-Срываются промежуточные сроки.
-Сотрудники поставщика часто меняются.
Желаю успехов в закупках 🚀
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥2✍1👍1🙏1
⚡️Новости проектного управления
Вы уже в курсе, что вышел PMBoK 8?
Ну как вышел... пока для членов PMI. А все остальные увидят его 13 января.
Анонсируют актуализацию структуры, терминов, включение новых веяний, а-ля ИИ... Ну и вроде как отошли от подхода 7 версии, которая вызывала споры внутри комьюнити.
Я как раз недавно размышлял на тему необходимости PMBoK и ему подобных документов)
Есть тут те, кто уже ознакомился с ним? Пишите в комменты :)
Вы уже в курсе, что вышел PMBoK 8?
Ну как вышел... пока для членов PMI. А все остальные увидят его 13 января.
Анонсируют актуализацию структуры, терминов, включение новых веяний, а-ля ИИ... Ну и вроде как отошли от подхода 7 версии, которая вызывала споры внутри комьюнити.
Я как раз недавно размышлял на тему необходимости PMBoK и ему подобных документов)
Есть тут те, кто уже ознакомился с ним? Пишите в комменты :)
⚡2❤2🔥2🤝1
Меня недавно спросили: что в работе проектного менеджера самое важное? Без чего шанс факапа возрастает?
Если выделить действительно только один навык...
то этот скилл важен как в проектном управлении, так и среди других управленцев. Речь об управлении заинтересованными сторонами.
Но речь не о формальностях в виде матриц. Если РП реально знает кто заказчик, пользователь, ЛПР... и оценивает влияние разных людей на проект, а также качественно управляет их требованиями и ожиданиями - это в разы повышает шансы на успех. В этом случае РП тонко чувствует пульс проекта и может «подкрутить настройки».
А как же остальное? Управление сроками, стоимостью, содержанием? Разумеется, это очень важно. Но если лажануть с заинтересованными сторонами, то сроки могут поехать, затраты вырасти или проект вообще не будет сдан.
Опять-же, важно, чтобы не было сильного перекоса в сторону управления ЗС. Иначе РП уже
#управление_проектами #стейкхолдеры
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4💯3✍2❤2🤓1
Проджект vs продакт. Разбираем роли.
В мире IT сегодня так много «менеджеров», что можно легко запутаться: продакт-менеджер, проджект-менеджер, продукт-оунер, тимлид, руководитель портфеля... Где заканчиваются зоны ответственности одного и начинаются задачи другого?
Недавно наткнулся на интересную аналогию, которая быстро проясняет ключевое различие между проджект-менеджером и продакт-менеджером. Хочу поделиться.
Проджект - это акушер, который помогает ребёнку родиться.
Продакт - это педиатр, который с момента рождения следит за здоровьем и развитием ребёнка.
Давайте разберемся.
📌 Проджект-менеджер (Project Manager): «Акушер»
Его миссия - успешно завершить «роды», то есть реализовать проект в рамках ограничений (сроки, бюджет, качество).
➖ Фокус: На цели - довести инициативу от точки А (идея) до точки Б (результат).
➖Ключевые задачи: Планирование, распределение ресурсов, управление рисками, контроль сроков и бюджета, коммуникация...
➖Метрики успеха: Проект сдан вовремя, в рамках бюджета, соответствует требованиям (scope) и все ключевые стейкхолдеры довольны. "Ребёнок родился здоровым и в срок".
➖Когда его миссия завершена? В момент успешной сдачи проекта и передачи результата заказчику или продукт-команде. "Роды" прошли успешно.
📌 Продакт-менеджер (Product Manager): "Педиатр"
Его миссия - обеспечить долгую и счастливую жизнь "ребёнку", то есть продукту на рынке.
➖ Фокус: Ценность и жизненный цикл. Его цель - чтобы продукт рос, развивался, оставался здоровым (востребованным) и приносил пользу.
➖ Ключевые задачи: Исследование рынка и пользователей, формирование видения и стратегии продукта, определение дорожной карты, приоритизация фич, анализ метрик.
➖ Метрики успеха: Рост пользовательской базы, удовлетворённость клиентов, достижение бизнес-целей (например, увеличение выручки). "Ребёнок хорошо развивается, набирает вес и радует родителей".
➖ Когда его миссия завершена? Технически никогда, пока продукт жив на рынке. Это непрерывный цикл анализа и улучшений.
Вывод: Это не вопрос "кто важнее". Это вопрос разных фаз жизненного цикла. Как всегда дьявол кроется в мелочах и бизнес модели разных компаний подразумевают несколько иные подходы или пересечение функций. Бывает, что руководитель проекта разработки курирует каждый релиз и т.п.
Однако на мой взгляд для рассмотрения в "вакууме" аналогия вполне неплохая.
Также в качестве наблюдения могу заметить, что иногда наблюдается переход сотрудника с одной роли на другую. ПМ-ы становятся продактами, а продакты ПМ-ми (но это сильно реже, по моему опыту).
❔А как вы считаете? Насколько эта аналогия резонирует с вашим опытом?
В мире IT сегодня так много «менеджеров», что можно легко запутаться: продакт-менеджер, проджект-менеджер, продукт-оунер, тимлид, руководитель портфеля... Где заканчиваются зоны ответственности одного и начинаются задачи другого?
Недавно наткнулся на интересную аналогию, которая быстро проясняет ключевое различие между проджект-менеджером и продакт-менеджером. Хочу поделиться.
Проджект - это акушер, который помогает ребёнку родиться.
Продакт - это педиатр, который с момента рождения следит за здоровьем и развитием ребёнка.
Давайте разберемся.
📌 Проджект-менеджер (Project Manager): «Акушер»
Его миссия - успешно завершить «роды», то есть реализовать проект в рамках ограничений (сроки, бюджет, качество).
➖ Фокус: На цели - довести инициативу от точки А (идея) до точки Б (результат).
➖Ключевые задачи: Планирование, распределение ресурсов, управление рисками, контроль сроков и бюджета, коммуникация...
➖Метрики успеха: Проект сдан вовремя, в рамках бюджета, соответствует требованиям (scope) и все ключевые стейкхолдеры довольны. "Ребёнок родился здоровым и в срок".
➖Когда его миссия завершена? В момент успешной сдачи проекта и передачи результата заказчику или продукт-команде. "Роды" прошли успешно.
📌 Продакт-менеджер (Product Manager): "Педиатр"
Его миссия - обеспечить долгую и счастливую жизнь "ребёнку", то есть продукту на рынке.
➖ Фокус: Ценность и жизненный цикл. Его цель - чтобы продукт рос, развивался, оставался здоровым (востребованным) и приносил пользу.
➖ Ключевые задачи: Исследование рынка и пользователей, формирование видения и стратегии продукта, определение дорожной карты, приоритизация фич, анализ метрик.
➖ Метрики успеха: Рост пользовательской базы, удовлетворённость клиентов, достижение бизнес-целей (например, увеличение выручки). "Ребёнок хорошо развивается, набирает вес и радует родителей".
➖ Когда его миссия завершена? Технически никогда, пока продукт жив на рынке. Это непрерывный цикл анализа и улучшений.
Вывод: Это не вопрос "кто важнее". Это вопрос разных фаз жизненного цикла. Как всегда дьявол кроется в мелочах и бизнес модели разных компаний подразумевают несколько иные подходы или пересечение функций. Бывает, что руководитель проекта разработки курирует каждый релиз и т.п.
Однако на мой взгляд для рассмотрения в "вакууме" аналогия вполне неплохая.
Также в качестве наблюдения могу заметить, что иногда наблюдается переход сотрудника с одной роли на другую. ПМ-ы становятся продактами, а продакты ПМ-ми (но это сильно реже, по моему опыту).
❔А как вы считаете? Насколько эта аналогия резонирует с вашим опытом?
4🔥3👏2💯2❤1🤓1
This media is not supported in your browser
VIEW IN TELEGRAM
🍾11❤6🔥5👏4😁1
ПроекTouch - PRO проекты
🎉Полгода работы, итоги (ура).
Мы с вами долго и методично копили материалы и вот дайджест по теме планирования готов.
Получилась отличная шпаргалка для РП.Обязательно сохраните себе :)
Как же осуществляется планирование в классическом (предиктивном) жизненном цикле?
За счет управления:
📌Содержанием
📌Сроками
📌Стоимостью ч.1; стоимостью ч.2
📌Качеством
📌Ресурсами
📌Коммуникациями
📌Рисками ч.1; рисками ч.2; рисками ч.3
📌Поставками
📌Заинтересованными сторонами ч.1; Заинтересованными сторонами ч.2
И, конечно... интеграцией. О ней не было отдельного поста и сейчас мы это исправим.
✍️ Управление интеграцией
Дело в том, что в отдельности друг от друга все вышеперечисленные функциональные области не принесут нужного результата.
Во-первых нужен регулярный фокус внимания, во-вторых кроссфункциональная координация. Эти два пункта обеспечат нам успех. Ведь руководитель проекта, оркестрируя весь поток событий, задач и планов обеспечивает синергию всех функциональных областей.
Если кратко, то так. Когда-нибудь расскажу подробней об этой важной штуке)
Мы с вами долго и методично копили материалы и вот дайджест по теме планирования готов.
Получилась отличная шпаргалка для РП.
Как же осуществляется планирование в классическом (предиктивном) жизненном цикле?
За счет управления:
📌Содержанием
📌Сроками
📌Стоимостью ч.1; стоимостью ч.2
📌Качеством
📌Ресурсами
📌Коммуникациями
📌Рисками ч.1; рисками ч.2; рисками ч.3
📌Поставками
📌Заинтересованными сторонами ч.1; Заинтересованными сторонами ч.2
И, конечно... интеграцией. О ней не было отдельного поста и сейчас мы это исправим.
Дело в том, что в отдельности друг от друга все вышеперечисленные функциональные области не принесут нужного результата.
Во-первых нужен регулярный фокус внимания, во-вторых кроссфункциональная координация. Эти два пункта обеспечат нам успех. Ведь руководитель проекта, оркестрируя весь поток событий, задач и планов обеспечивает синергию всех функциональных областей.
Если кратко, то так. Когда-нибудь расскажу подробней об этой важной штуке)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6✍1❤1👍1🙏1
Хочу посвятить несколько постов проектному офису. За один точно не управимся)
📌Проектный офис - это структурная единица в организации, которая отвечает за стандартизацию, координацию и эффективное управление проектами, программами, портфелями. Давайте разбираться глубже.
Это не просто модный термин, а стратегический инструмент в руках бизнеса, который может кардинально повысить управляемость и результативность компании. Но единой модели не существует. Хочу в этом посте разобрать два на мой взгляд ключевых варианта организации проектного офиса.
В зависимости от задач он может быть либо боевым подразделением, отвечающим за реализацию проектов, либо центром экспертизы, обеспечивающим процессы. Давайте разберемся, как сделать правильный выбор.
1️⃣ Управляющий проектный офис: «Штаб»
Это операционное ядро, которое напрямую отвечает за результат. Здесь сосредоточены проектные менеджеры, которые ведут все проекты.
✍️ Что делает: Непосредственно управляет проектами, распределяет ресурсы, назначает руководителей, контролирует сроки, бюджет, качество и несет за них ответственность.
Сравнил с армейским штабом. Он отдает приказы на поле боя (в проектах), управляет войсками (командами) и несет ответственность за победу.
2️⃣ Поддерживающий (Консультативный) проектный офис: «База»
Это отдельное подразделение, которое не ведет проекты напрямую, а создает условия для их успешной реализации.
✍️ Что делает: Разрабатывает и внедряет единые методологии, стандарты и шаблоны. Обучает сотрудников, внедряет инструменты, консультирует команды, управляет знаниями и обеспечивает прозрачную отчетность для руководства.
Сравнил с тыловой базой снабжения и обучения. Она не воюет, но обеспечивает армию единым оружием (методологиями), картами (стандартами), готовит новобранцев (обучает) и анализирует разведданные (отчетность).
Продолжим в следующих постах. Напишите в комментах, что именно хотели бы узнать о проектном офисе?
📌Проектный офис - это структурная единица в организации, которая отвечает за стандартизацию, координацию и эффективное управление проектами, программами, портфелями. Давайте разбираться глубже.
Это не просто модный термин, а стратегический инструмент в руках бизнеса, который может кардинально повысить управляемость и результативность компании. Но единой модели не существует. Хочу в этом посте разобрать два на мой взгляд ключевых варианта организации проектного офиса.
В зависимости от задач он может быть либо боевым подразделением, отвечающим за реализацию проектов, либо центром экспертизы, обеспечивающим процессы. Давайте разберемся, как сделать правильный выбор.
Это операционное ядро, которое напрямую отвечает за результат. Здесь сосредоточены проектные менеджеры, которые ведут все проекты.
Сравнил с армейским штабом. Он отдает приказы на поле боя (в проектах), управляет войсками (командами) и несет ответственность за победу.
Это отдельное подразделение, которое не ведет проекты напрямую, а создает условия для их успешной реализации.
Сравнил с тыловой базой снабжения и обучения. Она не воюет, но обеспечивает армию единым оружием (методологиями), картами (стандартами), готовит новобранцев (обучает) и анализирует разведданные (отчетность).
Продолжим в следующих постах. Напишите в комментах, что именно хотели бы узнать о проектном офисе?
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍5❤3🔥2🤓1
Как определить - какие инструменты в проекте понадобятся, а какие будут лишними?
Я много раз сталкивался с ситуацией, когда в проекте используется несколько план-графиков, сложная ИСР и другие инструменты. Но в конечном итоге они оказывались никому не нужными и пылились на цифровой полочке.
Вот бы на старте выбрать то, что реально нужно и не тратить силы на кучу сомнительных активностей. Это вообще реально?
✍️ Я думаю, что вполне. Для этого можно воспользоваться принципом "Бритва Оккама".
Изначально это философский принцип, предлагающий не усложнять гипотезы и давать явлениям и событиям простые интерпретации.
Впоследствии принцип видоизменился и его суть стала звучать так: Не следует множить сущности сверх необходимого.
📌 Таким образом стоит сесть и подумать, а что же РЕАЛЬНО необходимо, чтобы выполнить проект и как именно вы будете им управлять. Этим нетривиальным упражнением вы одновременно прикинете общий план, предусмотрите ключевые риски и выработаете нужный инструментарий.
Приятным бонусом будет конечно-же экономия трудозатрат.
Итого - необходимо вооружиться базовым минимумом инструментов и начать работу. Докрутить и добавить что-то можно будет в ходе реализации.
❗️Однако, важное отступление. Вы не сможете выбрать нужные инструменты, если у вас нет опыта. Если вы только начинаете свой путь в проектном управлении, смело беритесь за все доступные вам инструменты, пробуйте, тестируйте, проверяйте гипотезы.
Только наработав значительный опыт и насмотренность вы сможете безошибочно выбирать действительно то, чего требует проект.
В помощь вам шпаргалка по планированию.
Желаю успехов!
Я много раз сталкивался с ситуацией, когда в проекте используется несколько план-графиков, сложная ИСР и другие инструменты. Но в конечном итоге они оказывались никому не нужными и пылились на цифровой полочке.
Вот бы на старте выбрать то, что реально нужно и не тратить силы на кучу сомнительных активностей. Это вообще реально?
Изначально это философский принцип, предлагающий не усложнять гипотезы и давать явлениям и событиям простые интерпретации.
Впоследствии принцип видоизменился и его суть стала звучать так: Не следует множить сущности сверх необходимого.
📌 Таким образом стоит сесть и подумать, а что же РЕАЛЬНО необходимо, чтобы выполнить проект и как именно вы будете им управлять. Этим нетривиальным упражнением вы одновременно прикинете общий план, предусмотрите ключевые риски и выработаете нужный инструментарий.
Приятным бонусом будет конечно-же экономия трудозатрат.
Итого - необходимо вооружиться базовым минимумом инструментов и начать работу. Докрутить и добавить что-то можно будет в ходе реализации.
❗️Однако, важное отступление. Вы не сможете выбрать нужные инструменты, если у вас нет опыта. Если вы только начинаете свой путь в проектном управлении, смело беритесь за все доступные вам инструменты, пробуйте, тестируйте, проверяйте гипотезы.
Только наработав значительный опыт и насмотренность вы сможете безошибочно выбирать действительно то, чего требует проект.
В помощь вам шпаргалка по планированию.
Желаю успехов!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍2❤1✍1🙏1
Сегодня день рождения Agile.
Угадайте сколько лет исполнилось?
Угадайте сколько лет исполнилось?
Anonymous Quiz
4%
13 лет
15%
19 лет
47%
25 лет
34%
32 года
Всем привет!
Давно не было постов, обещаю в скором времени исправиться.
Расскажу о своих новых задачах и интересных кейсах.
А пока можете посмотреть забавный кейс использования канбана военными США.
PS: вот что канбан животворящий делает))
PPS: Рассматриваю тему исключительно с профессиональной точки зрения (проектный менеджмент). Без привязки к текущей геополитеческой ситуации.
Давно не было постов, обещаю в скором времени исправиться.
Расскажу о своих новых задачах и интересных кейсах.
А пока можете посмотреть забавный кейс использования канбана военными США.
PS: вот что канбан животворящий делает))
PPS: Рассматриваю тему исключительно с профессиональной точки зрения (проектный менеджмент). Без привязки к текущей геополитеческой ситуации.
Telegram
Ньюсач/Двач
Выяснилось, что американские военные управляют боями через аналог Jira с канбаном — программу, которая работает как обычный планировщик задач: они используют систему Maven от компании Palantir.
Как устроен этот процесс:
🟠Военные создают карточку задачи –…
Как устроен этот процесс:
🟠Военные создают карточку задачи –…
🔥5👍2🤔2❤1👏1🙏1
Об удаленке и управлении распределенными командами.
Люблю писать о злободневном.
О том, с чем мы все часто имеем дело.
Сейчас все чаще сталкиваюсь с нюансами распределеных команд. Мне кажется они у многих схожие (давайте проверим). Поэтому хочу поговорить о том, какие они эти проблемы и как их лечить.
1. Информационный вакуум.
-"Я не знал, что задача изменилась". Важное теряется в чатах и личках.
✅ Решение: Единый "источник правды" или мастер-данных. Принцип «Если процесс не записан, его не существует». Все задачи — в трекере, вся база знаний — в одном документе. Нет в системе — значит, не было.
2. Недостаток живого общения, вовлечённости
Люди чувствуют себя винтиками системы, нет неформального общения у кофемашины или на кухне.
✅ Решение: Виртуальная культура. Создайте каналы для хобби и мемов, систему наставничества (новичок не должен чувствовать себя одиноким в первую же неделю).
Уделяйте первые минуты рабочих встреч непринужденному общению.
3. Бесконечные встречи
Они убивают продуктивность.
✅ Решение: Гигиена встреч. Нет повестки - нет встречи. Если информацию можно передать текстом, не созывайте звонок. Введите дни без митингов.
Добавляйте свои варианты, если что-то забыл)
Люблю писать о злободневном.
О том, с чем мы все часто имеем дело.
Сейчас все чаще сталкиваюсь с нюансами распределеных команд. Мне кажется они у многих схожие (давайте проверим). Поэтому хочу поговорить о том, какие они эти проблемы и как их лечить.
1. Информационный вакуум.
-"Я не знал, что задача изменилась". Важное теряется в чатах и личках.
✅ Решение: Единый "источник правды" или мастер-данных. Принцип «Если процесс не записан, его не существует». Все задачи — в трекере, вся база знаний — в одном документе. Нет в системе — значит, не было.
2. Недостаток живого общения, вовлечённости
Люди чувствуют себя винтиками системы, нет неформального общения у кофемашины или на кухне.
✅ Решение: Виртуальная культура. Создайте каналы для хобби и мемов, систему наставничества (новичок не должен чувствовать себя одиноким в первую же неделю).
Уделяйте первые минуты рабочих встреч непринужденному общению.
3. Бесконечные встречи
Они убивают продуктивность.
✅ Решение: Гигиена встреч. Нет повестки - нет встречи. Если информацию можно передать текстом, не созывайте звонок. Введите дни без митингов.
Добавляйте свои варианты, если что-то забыл)
👍5🔥4💯2❤1✍1🤓1
Об успехах и неудачах, или как учиться на ошибках.
Наткнулся на размышления о том, что за нашими победами часто кроется бесчисленное множество усилий, тревоги и, в конце концов, неудач.
Несчастный мозг после очередного безумного проекта заметает под коврик негативные воспоминания, оставляя только лавры победителя. Но, забыв о факапах, мы можем потерять и часть извлеченных уроков. И это распространённая практика отечественного менеджмента. Например, на собеседованиях не так часто спрашивают о провалах.
Однако, в практике западного бизнеса ошибкам и неудачам отводится особое место. Логика в этом есть. Ведь чаще всего дважды в одну реку не войдёшь. И опытные граблеходцы в большинстве случаев знают верный путь :)
Лично моё мнение такое. Центрироваться на неудачах конечно же не стоит, но учиться на ошибках (особенно чужих) - это признак зрелого специалиста.
По теме фейлов я достаточно давно состою в FailConf сообществе. Ребята проводят встречи по обмену опытом в факапах.
Если 18 апреля будете в Москве, рекомендую посетить мероприятие. По промокоду PROEKTOUCH - скидка 10%.
Я же, в свою очередь, обещаю подумать над темой факапов в проектном управлении и возможно вспомню и расскажу чего нибудь интересного.
Наткнулся на размышления о том, что за нашими победами часто кроется бесчисленное множество усилий, тревоги и, в конце концов, неудач.
Несчастный мозг после очередного безумного проекта заметает под коврик негативные воспоминания, оставляя только лавры победителя. Но, забыв о факапах, мы можем потерять и часть извлеченных уроков. И это распространённая практика отечественного менеджмента. Например, на собеседованиях не так часто спрашивают о провалах.
Однако, в практике западного бизнеса ошибкам и неудачам отводится особое место. Логика в этом есть. Ведь чаще всего дважды в одну реку не войдёшь. И опытные граблеходцы в большинстве случаев знают верный путь :)
Лично моё мнение такое. Центрироваться на неудачах конечно же не стоит, но учиться на ошибках (особенно чужих) - это признак зрелого специалиста.
По теме фейлов я достаточно давно состою в FailConf сообществе. Ребята проводят встречи по обмену опытом в факапах.
Если 18 апреля будете в Москве, рекомендую посетить мероприятие. По промокоду PROEKTOUCH - скидка 10%.
Я же, в свою очередь, обещаю подумать над темой факапов в проектном управлении и возможно вспомню и расскажу чего нибудь интересного.
🔥7❤3👍3🙏1
Не усложняй.
В повседневной череде событий я все никак не мог дочитать книгу Дмитрия Ильенкова и Валерии Ильенковой - Не усложняй (книга об управлении проектами по методу P3․express). Но судьба подкинула мне пару перелётов на самолёте. Итог: несколько часов без связи и коммуникаций и я осилил книгу)
Хочу написать отзыв.
Небольшая вводная: я обучался и сертифицировался по P3․express в 2024 году. С этого момента я использую различные инструменты в работе и даже делился ими в блоге (пост 1, пост 2).
Хочу сказать, что для меня книга послужила отличным дополнением к курсу. Помогает вспомнить изученые ранее материалы. А если вы не проходили его, то это отличный способ понять особенности методологии и принять решение об обучении.
Для кого это книга?
Для проджектов с разным уровнем опыта, для управленцев или специалистов, работающих в проектно-ортентированных компаниях.
Подойдёт ли книга для новичков? Имхо: Будет интересно, но не совсем понятно. Многие моменты в проектном менеджменте нужно прожить, а не прочитать. Я думаю, это не та книга, которая нужна для старта. Но если вы уже сталкивались с проектным управлением и готовы развиваться в нем дальше, смело добавляйте в очередь к прочтению. Однозначно рекомендую!
Диме отдельное спасибо за возможность прочитать книгу раньше выхода в свет.
В повседневной череде событий я все никак не мог дочитать книгу Дмитрия Ильенкова и Валерии Ильенковой - Не усложняй (книга об управлении проектами по методу P3․express). Но судьба подкинула мне пару перелётов на самолёте. Итог: несколько часов без связи и коммуникаций и я осилил книгу)
Хочу написать отзыв.
Небольшая вводная: я обучался и сертифицировался по P3․express в 2024 году. С этого момента я использую различные инструменты в работе и даже делился ими в блоге (пост 1, пост 2).
Хочу сказать, что для меня книга послужила отличным дополнением к курсу. Помогает вспомнить изученые ранее материалы. А если вы не проходили его, то это отличный способ понять особенности методологии и принять решение об обучении.
Для кого это книга?
Для проджектов с разным уровнем опыта, для управленцев или специалистов, работающих в проектно-ортентированных компаниях.
Подойдёт ли книга для новичков? Имхо: Будет интересно, но не совсем понятно. Многие моменты в проектном менеджменте нужно прожить, а не прочитать. Я думаю, это не та книга, которая нужна для старта. Но если вы уже сталкивались с проектным управлением и готовы развиваться в нем дальше, смело добавляйте в очередь к прочтению. Однозначно рекомендую!
Диме отдельное спасибо за возможность прочитать книгу раньше выхода в свет.
❤8🔥6👍3✍1👏1
Система бьёт класс. Почему проджект должен уметь создавать системы?
Разработчики говорят, что всё готово, но тестировщики ничего не видели, заказчик утверждал одно и переобулся. В требованиях вообще написано другое. Итог - хаос, срывы сроков, масса "договорнячков" в обход контракта, сразу после старта. Знакомо?
Почему так происходит? Потому что в проекте нет дирижёра. Отдельные партии сыграны, но звучат они вразнобой.
⚓️ Помните в дайджесте я говорил об управлении интеграцией?
Речь о том, чтобы собрать все функциональные области управления проектом и интегрировать между собой в
единую систему (рекомендую вернуться к дайджесту и еще раз вспомнить их)
Да, именно поэтому проджект должен уметь строить системы (речь не о ПО, а о совокупности процессов и инструментов).
✏️Что нужно сделать?
Как минимум три вещи:
1. Утвердить устав проекта, чтобы у всех было единое понимание целей.
2. Создать единый "источник правды", куда стекаются все остальные планы (по срокам, бюджету, рискам, ресурсам и т.д.)
3. Назначить "точку сборки". Чаще всего это сам РП, который сводит всё и вся воедино.
Именно поэтому система бьёт класс. Я убежден, что проекты нуждаются не в "звёздных" проджектах, которые умеют решать вопросики, а в системных людях, способных выстроить систему и поддерживать ее работоспособность.
Тогда оркестр и зазвучит 🎼
Разработчики говорят, что всё готово, но тестировщики ничего не видели, заказчик утверждал одно и переобулся. В требованиях вообще написано другое. Итог - хаос, срывы сроков, масса "договорнячков" в обход контракта, сразу после старта. Знакомо?
Почему так происходит? Потому что в проекте нет дирижёра. Отдельные партии сыграны, но звучат они вразнобой.
⚓️ Помните в дайджесте я говорил об управлении интеграцией?
Речь о том, чтобы собрать все функциональные области управления проектом и интегрировать между собой в
единую систему (рекомендую вернуться к дайджесту и еще раз вспомнить их)
Да, именно поэтому проджект должен уметь строить системы (речь не о ПО, а о совокупности процессов и инструментов).
✏️Что нужно сделать?
Как минимум три вещи:
1. Утвердить устав проекта, чтобы у всех было единое понимание целей.
2. Создать единый "источник правды", куда стекаются все остальные планы (по срокам, бюджету, рискам, ресурсам и т.д.)
3. Назначить "точку сборки". Чаще всего это сам РП, который сводит всё и вся воедино.
Именно поэтому система бьёт класс. Я убежден, что проекты нуждаются не в "звёздных" проджектах, которые умеют решать вопросики, а в системных людях, способных выстроить систему и поддерживать ее работоспособность.
Тогда оркестр и зазвучит 🎼
👍5🔥5❤1👌1