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