Свести - не равно выставить комфортный срок. Если у вас есть опыт проектного управления или вы руководили РП, вы поймете , о чем я.
Комфортно для РП не равно комфортно для бизнеса. Как то один продакт Яндекса сказала что ее best practice - вообще не называть сроки заказчику, потому что они все равно поедут. А полгода назад я был на встрече где были РПО / СТО Сбера, Авито и Альфы и говорили, что они умеют в продукт но очень страдают, что перестало получаться в сроки.
Не бизнес должен подстраиваться под РП, а наоборот. Это важно.
"Не умеешь показывать ценность результата" - если руководству неясна ценность деятельности сотрудника, а он ее все равно делает - это нехорошо :) Нужно или вначале доказать и тогда ОК, или не делать вообще.
Тут решается точно также, как и в статье написано. И ноги - последний шаг, а не первый (потому что такое встречается достаточно часто и менять места при появлении проблем - для меня так себе стратегия. Я ее тоже пробовал, и считаю неэффективной).
Во-первых, "сложно фиксировать" и невозможно - большая разница. Есть очень мало вещей, которые вообще никак не отфиксировать, зато есть мое, как исполнителя, желание, чтобы "мне поставили официально". Задачи могут ставиться на совещаниях, в курилке, просто как идеи. Отвественность за фиксацию - на исполнителе, все так.
Во-вторых, по определию руководитель должен быть немного больше Е по Адизесу, чем исполнители. А значит, исполнителям будет казаться, что он переобувается "на лету". Так и есть, просто потому что его задача - генерить идеи. И хорошо, если из них выживет половина. Статистика стартапов - 1/10, а то и меньше. Так что тем, кому кажется, что шеф несет хрень - стоит перечитать этот абзац.
В-третьих, от руководителя скажу: бывает так, что сотрудник пытается регламентировать процесс, который фиг регламентируешь. причем шеф это видит, а сотрудник - нет. Спорить про это бессмысленно - сотруднику конечно виднее, как надо рулить )) Еще бывает, как в статье, говоришь ему, как делать, а он кивает и делает вообще иначе, не то не там и не так. А потом смотрит и кивает, как он не прав. И че с ним делать? :))
когда я писал в контексте ИИшки о том, почему не взлетели CASE средства программирования в конце 90х-начале нулевых, вспомнил, что главным стоппером там стала необходимость создания и поддержки такого объема документации, что это стало слишком дорого.
проще стало нанять снова кожаных, чтобы они продолжали кодить, чем поддерживать реально полную документацию по которой CASE система напишет код.
То есть тезис "полноты" документации может быть душно оспорен и может обсуждаться.
но это не умаляет важности тезисов статьи для jun-mid и местами sinor менеджеров.
не все знают всех приемов работы с требованиями, перечисленными в статье, так что писать про такое - крайне полезно
это две крайности. обычно голодный исполнитель готов начать работать без контракта но под обещания, которым он поверит. А далее подписывается контракт, к которому приложением идет ТЗ.
А уж какой степени детализации будет то ТЗ - это история индивидуальная.
потому что теории много, а вот как это применять - фиг его знает. Как я всем говорю - вода камень точит, но где эта грань, когда пора прекращать точить камень и просто сменить место работы на то, где руководство потенциально более гибкое?
короче любопытная тема, интересно опытного человека послушать
История хорошая и важная.И действительно, имеет место быть, по моему опыту.
Но есть пара нюансов:
психологическая безопасность крайне завязана на личность лидера команды. Лидер - на своего руководителя, а они - на СЕО компании. Если СЕО манипулятор, не признает свои ошибки и тд и тп - никакой бирюзы на всех остальных уровнях ждать не стоит. Итого - речь не про лидера, а про КУЛЬТУРУ компании.
Культура компаний в РФ, несмотря на все декларации - в большинстве или 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 - вообще не называть сроки заказчику, потому что они все равно поедут. А полгода назад я был на встрече где были РПО / СТО Сбера, Авито и Альфы и говорили, что они умеют в продукт но очень страдают, что перестало получаться в сроки.
Не бизнес должен подстраиваться под РП, а наоборот. Это важно.
"Не умеешь показывать ценность результата" - если руководству неясна ценность деятельности сотрудника, а он ее все равно делает - это нехорошо :)
Нужно или вначале доказать и тогда ОК, или не делать вообще.
Тут решается точно также, как и в статье написано. И ноги - последний шаг, а не первый (потому что такое встречается достаточно часто и менять места при появлении проблем - для меня так себе стратегия. Я ее тоже пробовал, и считаю неэффективной).
Во-первых, "сложно фиксировать" и невозможно - большая разница. Есть очень мало вещей, которые вообще никак не отфиксировать, зато есть мое, как исполнителя, желание, чтобы "мне поставили официально". Задачи могут ставиться на совещаниях, в курилке, просто как идеи. Отвественность за фиксацию - на исполнителе, все так.
Во-вторых, по определию руководитель должен быть немного больше Е по Адизесу, чем исполнители. А значит, исполнителям будет казаться, что он переобувается "на лету". Так и есть, просто потому что его задача - генерить идеи. И хорошо, если из них выживет половина. Статистика стартапов - 1/10, а то и меньше. Так что тем, кому кажется, что шеф несет хрень - стоит перечитать этот абзац.
В-третьих, от руководителя скажу: бывает так, что сотрудник пытается регламентировать процесс, который фиг регламентируешь. причем шеф это видит, а сотрудник - нет. Спорить про это бессмысленно - сотруднику конечно виднее, как надо рулить ))
Еще бывает, как в статье, говоришь ему, как делать, а он кивает и делает вообще иначе, не то не там и не так. А потом смотрит и кивает, как он не прав. И че с ним делать? :))
кстати да.
когда я писал в контексте ИИшки о том, почему не взлетели CASE средства программирования в конце 90х-начале нулевых, вспомнил, что главным стоппером там стала необходимость создания и поддержки такого объема документации, что это стало слишком дорого.
проще стало нанять снова кожаных, чтобы они продолжали кодить, чем поддерживать реально полную документацию по которой CASE система напишет код.
То есть тезис "полноты" документации может быть душно оспорен и может обсуждаться.
но это не умаляет важности тезисов статьи для jun-mid и местами sinor менеджеров.
не все знают всех приемов работы с требованиями, перечисленными в статье, так что писать про такое - крайне полезно
это две крайности. обычно голодный исполнитель готов начать работать без контракта но под обещания, которым он поверит. А далее подписывается контракт, к которому приложением идет ТЗ.
А уж какой степени детализации будет то ТЗ - это история индивидуальная.
По сути спасибо огромное за разбор и вообще все познавательно.
немного понимая логику работы, допускаю, что там есть мысли через макс делать обновления сервисов, запрещенных в аппсторе, а это апк.
то есть не злой умысел, а мысли норм, просто не очень профи и все торопятся.
любопытно, пишите, интересно почитать.
потому что теории много, а вот как это применять - фиг его знает. Как я всем говорю - вода камень точит, но где эта грань, когда пора прекращать точить камень и просто сменить место работы на то, где руководство потенциально более гибкое?
короче любопытная тема, интересно опытного человека послушать
История хорошая и важная.И действительно, имеет место быть, по моему опыту.
Но есть пара нюансов:
психологическая безопасность крайне завязана на личность лидера команды. Лидер - на своего руководителя, а они - на СЕО компании. Если СЕО манипулятор, не признает свои ошибки и тд и тп - никакой бирюзы на всех остальных уровнях ждать не стоит. Итого - речь не про лидера, а про КУЛЬТУРУ компании.
Культура компаний в РФ, несмотря на все декларации - в большинстве или 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 проект. Больше того, я полезные шаблоны утащил и потом долго еще применял в других местах. А матрицей рисков и проблем пользуюсь до сих пор - простая и удобная
чтобы понять, как применять ГОСТ, у меня ушло несколько лет. Неясно, когда нужна ПЗ к ТП, когда нет. Неясно, зачем заполнять все формальные разделы ТЗ - часто выглядит излишним. Неясно, когда делать кучу других документов (привет "Описанию языков программирования"), а когда не нужно. Но вообще еще раз да - он норм. Вот ему масштабируемость можно было бы попробовать прикрутить и сделать визуализацию - было бы интересно.