Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 26
Статья называется "Идеальная методология...", самой методологии в статье нет, есть только описания, какая же она крутая, прямо ух. Ну и, конечно, "подписывайтесь на мой телеграм".
Ну Семен Семеныч...
за водой не заметили ребенка - отчасти согласен, чтобы сделать статью краткой и неунылой, я часть сократил.
Но если вы ждете от меня описания всех проектных артефактов - смысла в этом ровно ноль, и я написал ниже, почему: вы (или любой другой комментатор) мне в 2 счета докажет, что эта документация для его проектов не нужна/лишняя.
Тогда зачем описывать детальные артефакты, когда они для каждой компании уникальны?
Сам подход , где есть процесс/роли/шаблоны - обычный.
Подход, где он
а) визуализирован наглядно
б) максимально наполнен
в) при этом гибкий и масштабируемый
уникален.
просто нет других таких методологий. ГОСТ масштабируется, но далеко неочевидно.
Так что есть куда расти крупнякам - я бы на их месте смотрел сюда, а не нанимал десятки администраторов проектов для сведения отчетности по отделам.
А мелким надо понимать, что им не ПМБоК нужен, а совсем другая, простая история.
PS: а про канал сказано в начале ровно один раз - честно говоря, не виду проблемы сказать что это статья реально по мотивам моего поста там. И там он популярен. Могу дать пруф :)
Вы серьезно позиционируете ценность статьи в тезисе "нужно делать так, чтобы методика была наглядно визуализирована, максимально наполнена и при этом гибка и масштабируема"?
Заработали почетный орден Винни-Пуха "Нужно делать так как нужно, а как не нужно - делать не нужно".
Ирония понятна, может так и звучит, но я о другом
Все вместе эти шаги не только убирают хаос (потому что описанный процесс управления убирает бардак), но и снижают стоимость обучения персонала + его конечную цену (людей можно брать дешевле).
и если тут все очевидно, и базара ноль, у меня вопрос: Если это настолько элементарно, почему этого никто не делает?
Почему сейчас, работая как приглашенный эксперт я вижу какую то кашу из документации, которую каждый РП делает так, как ему хочется? И это касется не только SMB, это вполне себе большие конторы и в госухе и в коммерции.
Расскажите, если знаете ответ, мне искренне интересно.
Так вы же сами написали, почему нет.
"Высокая стоимость создания" и "Высокая стоимость эксплуатации".
В совокупности с непредсказуемостью пользы.
Аргумент "Петр Жарков на хабре написал, что это идеальная методика" на ЛПР работает плохо. Хорошо работает "вот тут внедрено и по результатам независимого аудита сэкономило компании стотыщмильенов за год".
А я не призываю такое внедрять. Я буду рад, если РП и начинающие РПО просто прочитают и отложат в голове что "бывает и так" , а потом что-то из этого внедрят у себя.
Визуализацию
Шаблон, в котором будет написано, что и как писать
Разные пакеты документов для разного размера проектов
А уже если вдруг кто-то придет из крупняка и расскажет, что это все фигня - вот у них... Я с удовольствием признаю, что это не идеал.
Любую best practice можно раскритиковать. Но это не повод ничего не делать вообще.
Так у вас в статье нет ничего неочевидного, что надо было бы внедрять.
Чтобы вот РП или начинающий РПО пришел, прочитал статью и сказал "О, я этого не знал, сейчас пойду внедрю". Если, конечно, вы под "начинающим РПО" подразумевали не вчерашнего выпускника детского сада.
Знаете, ингода надо напоминать что делать нужно не по XYPP/SRAM/KOBAN, а делать нужно как нужно.
Видимо, открою небольшую тайну. Но каждый человек, делая что-то, считает, что именно так и нужно сейчас делать вследствие всей известной ему совокупности факторов.
Вы перступно упрощаете.
Очень часто человек делает что-то не потому, что это ему нужно, а потому, что ему сказали делать так, или "тут так принято", или боится наказания за то, что сделает иначе. И нет, все эти причине автоматически не делают ситуацию нужной нашему субъекту.
Вижу реально большую заслугу автора в ключевой фразе "Все равно помнить про идеал". Это очень важно. Поэтому общая оценка высокая.
Выходя с такими текстами почти философского уровня как-то, нмв, несерьезно рекламировать свой ТГ канал "во первых строках письма" (с).
Согласен с замечанием о том, что на идеал нужна ссылка. А то фразы типа "я когда-то видел и до сих пор использую" выглядят как попытка позиционировать себя как эксперта-методолога. Который хочет заработать...
Аудитория Хабра такова, что как только будет ссылка на идеал комментаторы напишут, что он неидеален, потому что неприменим для их деятельности. И даже будут правы, скорее всего. Потому что для производственных проектов - одни этапы и их наполнение, для проектов разработки ПО - вторые, а для внутренних команд разработки - третье.
А должно быть что-то у всех.
Цель статьи - показать как это может выглядеть "по максимуму" - раз, и что это отличается от PMBoK (хотя и полностью ему соотвествует) - два.
В остальном - спасибо за комментарий. Первоначально пост и правда был на канале, что уж тут сделаешь и да , я даю на него ссылку, там вся аудитория с Хабра, так то :)
А может быть это потому, что он не идеален?
идеал недостижим, если вспомнить про цену.
Задача этой статьи:
показать РПшникам и РПОшникам, которые не видели подобного максималистского подхода, что он бывает и что гдето - это best practises
что корпоративная методология - это не PMBoK и не ГОСТ и не P3, а что-то индивидуальное, что им не противоречит.
ну и лично для меня важно: я в РФ не видел ни одной методологии, где была бы вшита масштабируемость. Если кто-то это увидит и внедрит - я буду очень рад, считаю это важным для больших отделов.
Я в книге "Управление проектным бизнесом" просто указал границы применимости. И как только происходит "У нас другие условия", то ответ простой "да, у вас другие условия, адаптируйте".
https://pulsemanagement.org/
ГОСТ 34.601-90 действительно неплох (заменен на ГОСТ Р 59793-2021), есть стадии работ, есть ссылка на то какие документы должны быть на каждой стадии по ГОСТ 34.201-2020 и ГОСТ 19.101-2024.
Дальше по каждому документу сделать (найти) шаблон и можно работать без проблем.
все верно. моя статистика такая:
чтобы понять и освоить методологию, которая описана в статье, у меня ушел 1 проект. Больше того, я полезные шаблоны утащил и потом долго еще применял в других местах. А матрицей рисков и проблем пользуюсь до сих пор - простая и удобная
чтобы понять, как применять ГОСТ, у меня ушло несколько лет. Неясно, когда нужна ПЗ к ТП, когда нет. Неясно, зачем заполнять все формальные разделы ТЗ - часто выглядит излишним. Неясно, когда делать кучу других документов (привет "Описанию языков программирования"), а когда не нужно. Но вообще еще раз да - он норм. Вот ему масштабируемость можно было бы попробовать прикрутить и сделать визуализацию - было бы интересно.
Статья выглядит, как похвастались и прорекламировали ТГ-канал. Спасибо, было интересно (нет).
«Когда-то давно я столкнулся с почти совершенной корпоративной методологией внедрения ИТ-проектов. Она была полной, удобной, масштабируемой и понятной даже джуну (которым я тогда был).»
«Это была интерактивная Квест-карта (напомню, это 2007 год!) по всем этапам жизненного цикла проектов Компании от инициации до передачи в поддержку со всеми необходимыми подпунктами в строгой очередности, со всеми необходимыми артефактами.»
«И все это было на одной веб-страничке!»
После этих слов ожидаешь: «Вот она!». И дальше мчишься сломя голову делать такое, или что-то подобное. Но, нет... Вы с упоением рассказываете какой вкусный пирог Вы попробовали, долго рассуждаете об основах кулинарии, достоинствах и недостатках разных кухонь (кафе, ресторанов), но рецепт чудо-пирога так и не приводите. Востину, «Морковка спереди, морковка сзади», а больше ничего.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Идеальная методология внедрения проектов (для РП и РПО)