потому что теории много, а вот как это применять - фиг его знает. Как я всем говорю - вода камень точит, но где эта грань, когда пора прекращать точить камень и просто сменить место работы на то, где руководство потенциально более гибкое?
короче любопытная тема, интересно опытного человека послушать
История хорошая и важная.И действительно, имеет место быть, по моему опыту.
Но есть пара нюансов:
психологическая безопасность крайне завязана на личность лидера команды. Лидер - на своего руководителя, а они - на СЕО компании. Если СЕО манипулятор, не признает свои ошибки и тд и тп - никакой бирюзы на всех остальных уровнях ждать не стоит. Итого - речь не про лидера, а про КУЛЬТУРУ компании.
Культура компаний в РФ, несмотря на все декларации - в большинстве или HiPPO типа или вовсе дисфункциональная - в меру психологической зрелости СЕО. Это ни хорошо, ни плохо - просто такая стадия развития.
продавать "культуру" СЕО не выйдет , ему культура по барабану, его интересуют бабки. Следовательно, надо продавать основной вывод проекта Аристотель: "чем больше культуры в твоей команде, тем больше бабок ты заработаешь" . Но и тут мы столкнемся с тем, что "отпускать" мы предлагаем часто тем, кто отпускать не умеет, а хочет всего и все контролировать сам (тем более, что поводов для этого и правда много)
Короче - слова то красивые, но как практически применять - вопрос ))
Я люблю ITIL, нежно. Сервисный подход я пропогандировал и пропогандирую всегда, хоте сертификата у меня нет. Больше - я вижу, насколько сервисный и продуктовый, ныне модный, подходы похожи. По сути IT Product manager - это IT Service manager by ITIL. Короче - хорошая библиотека.
Статья не несет полезной нагрузки, кроме того что вышел ITIL5. Чем именно отличается, что было , что стало - нету. Мне, как ITIL practioner (причем реальный а не по серту) очень интересно: почему 10 лет прошло, почему от конкретных фреймов - одни общие слова? И тд, но ничего этого нет.
Есть общие слова, явно made by AI. Для меня это неуважение. Промпт вида: "знаю что вышел новый ITIL v5, расскажи, чем он отличается от прошлых версий, что нового, что осталось старого, структурируй по разделам, текст должен быть на 4 минуты чтения + сделай 2 картинки на тему статьи" - я и сам могу вбить хоть в гпт, хоть в джемини, хоть в клод...
зачем гадать, вы можете пройти ко мне в профиль и почитать, о чем я пишу.
Можете и покритиковать - это запросто, Хабр и нужен для обсуждения идей.
Вся цель моих статей и постов в телеге одна - я вижу не рост, а падение качества проектного управления.
Сейчас 45% РПшников это джуны (это не бьется с моим личным опытом, по нему 20-30, но таковы данные исследования, которое у меня есть). А значит, нести иногда надо самые простые идеи - они их банально не знают.
Если у вас другой опыт, как учить начинающих - поделитесь.
Так, господа, комментарии ясны, все хотят квест карту и ответы на вопросы, которые вот здесь и сейчас позволят вам запустить "идеальную методологию". Ок, сдаюсь)
статью допишу )
не очень так, как вам понравится, но как есть, в реалиях нашего текущего рынка.
Я уже отвечу, как ответил выше, но это правда считаю важным
Хорошая методология - это долгая инвестиция. История выше как раз такая. Именно поэтому в РФ сейчас нет и в ближайшее время таких методологий не будет. Но я считаю это важным шагом к эффективности внедрений (про эффективность - не пустое, я прекрасно понимаю определение этого слова и могу обосновать его применение здесь). Его придется когда то сделать. И важно говорить, что в мире такие решения есть и их много. В РФ нет, там есть. И делать придется.
Хорошая методология всегда будет уникальна для предприятия и его вида деятельности. Именно поэтому тут не будет одного рецепта всеобщего счастья. Но база есть общая и это
полнота по всем шагам
все артефакты
все шаблоны
наглядность и протота обучения
масштабируемая для разных проектов (все прошли мимо, а ведь вообще ни одна методология в РФ этого не делает!)
да сделал бы хоть кто-то это для начала, а потом начал критиковать статью за неполноту, ребята ))
а про канал - да, я буду говорить, потому что могу дать ссылку на пост, где эту тему тоже обсуждали. Что мне - молчать чтоли про него? )
А потому что иногда про цену не вспоминают, или вспоминают, глядя лет на 10-15 вдаль. Такого не встретить на рынке РФ, тут и на три года мало кто смотрит.
Хорошая методология - это долгая инвестиция.
История выше как раз такая.
Мы такие примеры увидим не скоро, я думаю. Но я считаю правильным про это говорить, как ориентир повышения эффективности внедрения.
Да, это будет специфично по отраслям, да документы будут зваться по-разному, общая суть:
полноста по всем шагам
все артефакты
все шаблоны
наглядность и протота обучения
масштабируемая для разных проектов (все прошли мимо, а ведь вообще ни одна методология в РФ этого не делает!)
да сделал бы хоть кто-то это для начала, а потом начал критиковать статью за неполноту, ребята ))
неа. я уверен, что начинающий РПО не выстроит то, что называется роскошным максимумом, этого посыла в статье нет, расскажите где вы его увидели, пожалуйста?
чтобы понять и освоить методологию, которая описана в статье, у меня ушел 1 проект. Больше того, я полезные шаблоны утащил и потом долго еще применял в других местах. А матрицей рисков и проблем пользуюсь до сих пор - простая и удобная
чтобы понять, как применять ГОСТ, у меня ушло несколько лет. Неясно, когда нужна ПЗ к ТП, когда нет. Неясно, зачем заполнять все формальные разделы ТЗ - часто выглядит излишним. Неясно, когда делать кучу других документов (привет "Описанию языков программирования"), а когда не нужно. Но вообще еще раз да - он норм. Вот ему масштабируемость можно было бы попробовать прикрутить и сделать визуализацию - было бы интересно.
А я не призываю такое внедрять. Я буду рад, если РП и начинающие РПО просто прочитают и отложат в голове что "бывает и так" , а потом что-то из этого внедрят у себя.
Визуализацию
Шаблон, в котором будет написано, что и как писать
Разные пакеты документов для разного размера проектов
А уже если вдруг кто-то придет из крупняка и расскажет, что это все фигня - вот у них... Я с удовольствием признаю, что это не идеал.
Любую best practice можно раскритиковать. Но это не повод ничего не делать вообще.
показать РПшникам и РПОшникам, которые не видели подобного максималистского подхода, что он бывает и что гдето - это best practises
что корпоративная методология - это не PMBoK и не ГОСТ и не P3, а что-то индивидуальное, что им не противоречит.
ну и лично для меня важно: я в РФ не видел ни одной методологии, где была бы вшита масштабируемость. Если кто-то это увидит и внедрит - я буду очень рад, считаю это важным для больших отделов.
Аудитория Хабра такова, что как только будет ссылка на идеал комментаторы напишут, что он неидеален, потому что неприменим для их деятельности. И даже будут правы, скорее всего. Потому что для производственных проектов - одни этапы и их наполнение, для проектов разработки ПО - вторые, а для внутренних команд разработки - третье.
А должно быть что-то у всех.
Цель статьи - показать как это может выглядеть "по максимуму" - раз, и что это отличается от PMBoK (хотя и полностью ему соотвествует) - два.
В остальном - спасибо за комментарий. Первоначально пост и правда был на канале, что уж тут сделаешь и да , я даю на него ссылку, там вся аудитория с Хабра, так то :)
Все вместе эти шаги не только убирают хаос (потому что описанный процесс управления убирает бардак), но и снижают стоимость обучения персонала + его конечную цену (людей можно брать дешевле).
и если тут все очевидно, и базара ноль, у меня вопрос: Если это настолько элементарно, почему этого никто не делает?
Почему сейчас, работая как приглашенный эксперт я вижу какую то кашу из документации, которую каждый РП делает так, как ему хочется? И это касется не только SMB, это вполне себе большие конторы и в госухе и в коммерции.
Расскажите, если знаете ответ, мне искренне интересно.
за водой не заметили ребенка - отчасти согласен, чтобы сделать статью краткой и неунылой, я часть сократил.
Но если вы ждете от меня описания всех проектных артефактов - смысла в этом ровно ноль, и я написал ниже, почему: вы (или любой другой комментатор) мне в 2 счета докажет, что эта документация для его проектов не нужна/лишняя.
Тогда зачем описывать детальные артефакты, когда они для каждой компании уникальны?
Сам подход , где есть процесс/роли/шаблоны - обычный.
Подход, где он
а) визуализирован наглядно
б) максимально наполнен
в) при этом гибкий и масштабируемый
уникален.
просто нет других таких методологий. ГОСТ масштабируется, но далеко неочевидно.
Так что есть куда расти крупнякам - я бы на их месте смотрел сюда, а не нанимал десятки администраторов проектов для сведения отчетности по отделам.
А мелким надо понимать, что им не ПМБоК нужен, а совсем другая, простая история.
PS: а про канал сказано в начале ровно один раз - честно говоря, не виду проблемы сказать что это статья реально по мотивам моего поста там. И там он популярен. Могу дать пруф :)
По сути спасибо огромное за разбор и вообще все познавательно.
немного понимая логику работы, допускаю, что там есть мысли через макс делать обновления сервисов, запрещенных в аппсторе, а это апк.
то есть не злой умысел, а мысли норм, просто не очень профи и все торопятся.
любопытно, пишите, интересно почитать.
потому что теории много, а вот как это применять - фиг его знает. Как я всем говорю - вода камень точит, но где эта грань, когда пора прекращать точить камень и просто сменить место работы на то, где руководство потенциально более гибкое?
короче любопытная тема, интересно опытного человека послушать
История хорошая и важная.И действительно, имеет место быть, по моему опыту.
Но есть пара нюансов:
психологическая безопасность крайне завязана на личность лидера команды. Лидер - на своего руководителя, а они - на СЕО компании. Если СЕО манипулятор, не признает свои ошибки и тд и тп - никакой бирюзы на всех остальных уровнях ждать не стоит. Итого - речь не про лидера, а про КУЛЬТУРУ компании.
Культура компаний в РФ, несмотря на все декларации - в большинстве или HiPPO типа или вовсе дисфункциональная - в меру психологической зрелости СЕО. Это ни хорошо, ни плохо - просто такая стадия развития.
продавать "культуру" СЕО не выйдет , ему культура по барабану, его интересуют бабки. Следовательно, надо продавать основной вывод проекта Аристотель: "чем больше культуры в твоей команде, тем больше бабок ты заработаешь" . Но и тут мы столкнемся с тем, что "отпускать" мы предлагаем часто тем, кто отпускать не умеет, а хочет всего и все контролировать сам (тем более, что поводов для этого и правда много)
Короче - слова то красивые, но как практически применять - вопрос ))
ага, норм, ценю за честность, спасибо!
Если уж совсем соломоново, то записать снепшот на диск, разрезать его болгаркой пополам и каждому отдать по половине =)
Вижу что автор отвечает, я тогда скажу
Я люблю ITIL, нежно. Сервисный подход я пропогандировал и пропогандирую всегда, хоте сертификата у меня нет. Больше - я вижу, насколько сервисный и продуктовый, ныне модный, подходы похожи. По сути IT Product manager - это IT Service manager by ITIL. Короче - хорошая библиотека.
Статья не несет полезной нагрузки, кроме того что вышел ITIL5. Чем именно отличается, что было , что стало - нету. Мне, как ITIL practioner (причем реальный а не по серту) очень интересно: почему 10 лет прошло, почему от конкретных фреймов - одни общие слова? И тд, но ничего этого нет.
Есть общие слова, явно made by AI. Для меня это неуважение. Промпт вида: "знаю что вышел новый ITIL v5, расскажи, чем он отличается от прошлых версий, что нового, что осталось старого, структурируй по разделам, текст должен быть на 4 минуты чтения + сделай 2 картинки на тему статьи" - я и сам могу вбить хоть в гпт, хоть в джемини, хоть в клод...
Я говорил тут про другое, вы неправильно поняли мой тезис.
О, пассивная агрессия :)
зачем гадать, вы можете пройти ко мне в профиль и почитать, о чем я пишу.
Можете и покритиковать - это запросто, Хабр и нужен для обсуждения идей.
Вся цель моих статей и постов в телеге одна - я вижу не рост, а падение качества проектного управления.
Сейчас 45% РПшников это джуны (это не бьется с моим личным опытом, по нему 20-30, но таковы данные исследования, которое у меня есть). А значит, нести иногда надо самые простые идеи - они их банально не знают.
Если у вас другой опыт, как учить начинающих - поделитесь.
Критиковать просто, предложить чтото свое, обычно, сложнее.
Так, господа, комментарии ясны, все хотят квест карту и ответы на вопросы, которые вот здесь и сейчас позволят вам запустить "идеальную методологию". Ок, сдаюсь)
статью допишу )
не очень так, как вам понравится, но как есть, в реалиях нашего текущего рынка.
Жаль, а может, вы просто не ЦА статьи.
Я уже отвечу, как ответил выше, но это правда считаю важным
Хорошая методология - это долгая инвестиция. История выше как раз такая. Именно поэтому в РФ сейчас нет и в ближайшее время таких методологий не будет. Но я считаю это важным шагом к эффективности внедрений (про эффективность - не пустое, я прекрасно понимаю определение этого слова и могу обосновать его применение здесь). Его придется когда то сделать. И важно говорить, что в мире такие решения есть и их много. В РФ нет, там есть. И делать придется.
Хорошая методология всегда будет уникальна для предприятия и его вида деятельности. Именно поэтому тут не будет одного рецепта всеобщего счастья. Но база есть общая и это
полнота по всем шагам
все артефакты
все шаблоны
наглядность и протота обучения
масштабируемая для разных проектов (все прошли мимо, а ведь вообще ни одна методология в РФ этого не делает!)
да сделал бы хоть кто-то это для начала, а потом начал критиковать статью за неполноту, ребята ))
а про канал - да, я буду говорить, потому что могу дать ссылку на пост, где эту тему тоже обсуждали. Что мне - молчать чтоли про него? )
А потому что иногда про цену не вспоминают, или вспоминают, глядя лет на 10-15 вдаль. Такого не встретить на рынке РФ, тут и на три года мало кто смотрит.
Хорошая методология - это долгая инвестиция.
История выше как раз такая.
Мы такие примеры увидим не скоро, я думаю. Но я считаю правильным про это говорить, как ориентир повышения эффективности внедрения.
Да, это будет специфично по отраслям, да документы будут зваться по-разному, общая суть:
полноста по всем шагам
все артефакты
все шаблоны
наглядность и протота обучения
масштабируемая для разных проектов (все прошли мимо, а ведь вообще ни одна методология в РФ этого не делает!)
да сделал бы хоть кто-то это для начала, а потом начал критиковать статью за неполноту, ребята ))
знакомый подход. я считаю это перфекционизм в стиле - не сделал туториал "как внердить проектное управление для всех" - не пиши.
Я и сам так считал 10 лет примерно.
А потом понял, что часто любая информация для новичков и джунов может быть полезна. И какая - пусть они сами решают.
неа. я уверен, что начинающий РПО не выстроит то, что называется роскошным максимумом, этого посыла в статье нет, расскажите где вы его увидели, пожалуйста?
тут не согласен.
я не видел нормальной визуализации проектной методологии.
я не видел в больших компаниях масштабированных пакетов документации внедрения от размера проекта
ну и документов по фазам - бывает, но достаточно редко.
Я считаю, этого достаточно, чтобы рассказать, что так бывает.
все верно. моя статистика такая:
чтобы понять и освоить методологию, которая описана в статье, у меня ушел 1 проект. Больше того, я полезные шаблоны утащил и потом долго еще применял в других местах. А матрицей рисков и проблем пользуюсь до сих пор - простая и удобная
чтобы понять, как применять ГОСТ, у меня ушло несколько лет. Неясно, когда нужна ПЗ к ТП, когда нет. Неясно, зачем заполнять все формальные разделы ТЗ - часто выглядит излишним. Неясно, когда делать кучу других документов (привет "Описанию языков программирования"), а когда не нужно. Но вообще еще раз да - он норм. Вот ему масштабируемость можно было бы попробовать прикрутить и сделать визуализацию - было бы интересно.
А я не призываю такое внедрять. Я буду рад, если РП и начинающие РПО просто прочитают и отложат в голове что "бывает и так" , а потом что-то из этого внедрят у себя.
Визуализацию
Шаблон, в котором будет написано, что и как писать
Разные пакеты документов для разного размера проектов
А уже если вдруг кто-то придет из крупняка и расскажет, что это все фигня - вот у них... Я с удовольствием признаю, что это не идеал.
Любую best practice можно раскритиковать. Но это не повод ничего не делать вообще.
идеал недостижим, если вспомнить про цену.
Задача этой статьи:
показать РПшникам и РПОшникам, которые не видели подобного максималистского подхода, что он бывает и что гдето - это best practises
что корпоративная методология - это не PMBoK и не ГОСТ и не P3, а что-то индивидуальное, что им не противоречит.
ну и лично для меня важно: я в РФ не видел ни одной методологии, где была бы вшита масштабируемость. Если кто-то это увидит и внедрит - я буду очень рад, считаю это важным для больших отделов.
Аудитория Хабра такова, что как только будет ссылка на идеал комментаторы напишут, что он неидеален, потому что неприменим для их деятельности. И даже будут правы, скорее всего. Потому что для производственных проектов - одни этапы и их наполнение, для проектов разработки ПО - вторые, а для внутренних команд разработки - третье.
А должно быть что-то у всех.
Цель статьи - показать как это может выглядеть "по максимуму" - раз, и что это отличается от PMBoK (хотя и полностью ему соотвествует) - два.
В остальном - спасибо за комментарий. Первоначально пост и правда был на канале, что уж тут сделаешь и да , я даю на него ссылку, там вся аудитория с Хабра, так то :)
Ирония понятна, может так и звучит, но я о другом
Все вместе эти шаги не только убирают хаос (потому что описанный процесс управления убирает бардак), но и снижают стоимость обучения персонала + его конечную цену (людей можно брать дешевле).
и если тут все очевидно, и базара ноль, у меня вопрос: Если это настолько элементарно, почему этого никто не делает?
Почему сейчас, работая как приглашенный эксперт я вижу какую то кашу из документации, которую каждый РП делает так, как ему хочется? И это касется не только SMB, это вполне себе большие конторы и в госухе и в коммерции.
Расскажите, если знаете ответ, мне искренне интересно.
за водой не заметили ребенка - отчасти согласен, чтобы сделать статью краткой и неунылой, я часть сократил.
Но если вы ждете от меня описания всех проектных артефактов - смысла в этом ровно ноль, и я написал ниже, почему: вы (или любой другой комментатор) мне в 2 счета докажет, что эта документация для его проектов не нужна/лишняя.
Тогда зачем описывать детальные артефакты, когда они для каждой компании уникальны?
Сам подход , где есть процесс/роли/шаблоны - обычный.
Подход, где он
а) визуализирован наглядно
б) максимально наполнен
в) при этом гибкий и масштабируемый
уникален.
просто нет других таких методологий. ГОСТ масштабируется, но далеко неочевидно.
Так что есть куда расти крупнякам - я бы на их месте смотрел сюда, а не нанимал десятки администраторов проектов для сведения отчетности по отделам.
А мелким надо понимать, что им не ПМБоК нужен, а совсем другая, простая история.
PS: а про канал сказано в начале ровно один раз - честно говоря, не виду проблемы сказать что это статья реально по мотивам моего поста там. И там он популярен. Могу дать пруф :)