ИМХО, проблемы непонимания когда и в каком порядке использовать те или иные инструменты, описанные в разных моделях это родимое пятно от происхождения всех этих моделей: с начала люди изучает менеджмент, общую школу управления и набираются знаний о профессиональной сфере в которой они будет руководить и только потом они придумывают модели для проектного управления.
Когда и что использовать точно не проистекает из общей менеджмент теории. Ее бы, конечно, знать не помешало, но тех, кто имеет хоть какое-то менеджерское образование (я, например, заканчивал факультет "Менеджмент" в ГУ-ВШЭ) ИМХО в разы меньше, чем тех, кто в курсе темы управления проектами. Так что это чересчур оптимистичный тейк.
Если не забывать о главной особенности, что проект от сервиса/процесса отличается уникальностью, то очень многое становится на места, а заодно всплывает вопрос, а управление разработкой софта со стандартным функционалом для стандартной сферы применения может ли являться проектом или это сервис, знания о котором у конкретного исполнителя недостаточны.
Бесспорно, управление процессом требует своих фреймворков и в управлении проектами не нуждается. Но не всю разработку софта можно сделать только на управлении процессами, особенно, когда есть интеграции и внедрение. Вы об этом также упомянули далее.
Ну и до кучи про жизнеспособность западных управленческих теорий. Как известно крупные деньги это бюджет или околобюджет и отрасль так или иначе подстраивается под те модели, что живут в кабинетах чиновников, а там зачастую жесточайшая иерархия со своим сводом правил для всех контрагентов, которые гнут под свои хотелки и подходы всех настолько в составе проектной команды оказывается генеральный директор вместе с коммерческим и начальниками департаментов, что по сути уже совсем другая песня, нежели проектная команда внутри компании.
Все же обычно чиновники не настолько погружены в процесс управления, чтобы там что-то сильно диктовать. Так что в их требования безусловно нужно вписываться, но это часто не мешает выстроить свой управленческий фреймворк. В коммерческих организациях все сильно попроще и даже большая часть проектной деятельности нерегламентирована.
2. Как смещение фокуса на артефакты влияет на ежедневные действия команды разработки или проектной команды? Можете описать день/неделю работы в вашей системе и в Scrum – чем они будут различаться? (Кстати, почему-то scrum обошил стороной в своей статье, а разве нет этот подход/методлология сейчас самый популряный в разщличных вариациях)
Для ежедневных действий будет некоторое сходство со Scrum. В руководстве по методу указаны артефакты и ритуалы для всех временных горизонтов (уровней), в т.ч. для ежедневного, но все же фокус именно на реализацию проектов, а не организацию процесса по разработке ПО. Про Scrum я уже написал в ответе на один из вопросов - он слишком узкий для того, чтобы быть проектным фреймворком, кроме того, он построен в результатоориентированной логике, так что критиковать его было бы бессмысленно ). В целом я не думаю, что много кто использует чистый Scrum, скорее отдельные элементы или вариации на тему.
3. Как ваш метод помогает в приоритизации задач и распределении ресурсов по сравнению с уже ставшим "классическим" спринтовым планированием? И вообще, что-то про планирование особо не увидел в вашей методологии, а я считаю это одним из ключевых моментов в любой методлоогии управления проектами.
Я думаю, что он никак его дополнительно не улучшает. Задачи полностью заместить "производственный" фреймворк в принципе нет. Фреймворк управления идет поверх него. Тем не менее в методе есть артефакты - план фазы / этапа / релиза. Такой категории, как спринт в методе нет. Планирование выполняется в поточном режиме как в Kanban. Данная статья не является полным описанием методологии. Оно есть в руководстве, котое можно найти в моем тг-канале.
5. Если у нас есть несколько команд (разработка ПО, интеграция, тестирование), как ваш метод организует их взаимодействие? Чем это отличается от использования Scrum of Scrums или масштабированных фреймворков?
Я не изучал Scrum of Scrums. Взаимодействие организовано через систему ритуалов (у нас они являются частью так называемых событий). Подробнее, о тех событиях, которые мы используем можно почитать в руководстве.
6. И вообще, где подробное описание методологии? По Scrum есть официальные руководства и статье, доступные всем желающим. Ваша методология, я так понимаю, закрытая и платная – "закажите у меня, и вы не прогадаете?"
Сама методология бесплатная. Посмотрите, пожалуйста в тг-канале. Если не найдете, то напишите мне лично в тг @malakhov_andrey.
Надеюсь, автор придет в сознание перейдет к конструкивному диалогу, иначе забавно видеть - пытается продвинуть свои идеи, но при возникновении вопросов занимает оборнительную позицию и пытается оскорбить вопрошающего.
Сознание меня не покидало. На конструктивные вопросы и замечания буду давать конкретные ответы. Цель - прояснить свою позицию для тех, кому она интересна, а не тем, кто хочет обесценить или потроллить. Поэтому на ваши конкретные вопросы я ответил.
Пока выглядит, как в известном меме "в мире есть 20 стандартов, а я сделаю один, нормальный. И теперь в мире 21 стандарт". А здесь пока вещь в себе, без руководства и описания.
В общем, хотелось бы видеть конкретные, четкие ответы на вопросы выше, без софистики и переходы на личности.
Спасибо за переход к конкретике и конструктиву. Я не сомневался, что мне придется отстаивать преимущества своего метода с аргументами, а не только с пеной у рта. Отличного дня!
Но я сделаю вид, что не заметил Вашей пассивной агрессии, Вашего высокомерного "кто не дурак, тот меня поймет". "Интересный", конечно, подход: цель-то статьи продвинуть свою методологию, а когда пошли вопросы по ней, переход на личности (известно же, когда не хватает аргументов, переходят на личности).
Мне не близка критика без аргументов, которую я увидел в вашем посте. Просто нет столько времени, чтобы пытаться другими словами сказать то, что уже сказал, особенно, когда звучат обесценивающие нотки про "ответов нет". На конкретные вопросы отвечу.
И тут вообще не увидел, чем отличается ваша "методология" от известных и распространненных других, например от Scrum или упоминаемого Вами Prince2.
Об этом статья. Для начала полноценного участия в дискуссии предлагаю прочитать руководство по моему методу. Его можно здесь забрать. @PMLogixBot,а также посмотреть вебинар, по мотивам которого родилась эта статья https://vkvideo.ru/video-211146584_456239038?
Особенно слабо выглядит вот эта фраза:
"Как понять, что действительно важно? .... И тут нужно понять, что из этого набора важно именно в вашей организации и нужно ли добавить свои уникальные аспекты."
То есть, чтобы понять, нужно понять (спасибо, кэп)
В тексте статьи конкретно описано, как понять, см. часть про определение аспектов управления.
Далее по вашим конкретным вопросам:
1. В Scrum тоже есть набор обязательных артефактов. Чем ваша работа с артефактами отличается от этой практики?
Точно подмечено, что Scrum хорош тем, как работает с артефактами, НО он очень узок в покрытии аспектов (нет рисков, содержания и качества, ресурсов и т.д. и т.п.), а также охватывает крайне короткий горизонт планирования. Если угодно мой подход можно интерпретировать, как использование конкретики Scrum: артефакты + события + регулярность (привязка к структуре проекта) к более широкому спектру аспектов и как краткосрочным, так и долгосрочным критериям успеха и рискам проектов.
Мне сложно уследить за вашей мыслью. Задачи хаить не было, была задача конструктивно показать недостатки, проявляющиеся на практике при использовании процессноориентированных стандартов управления проектами. И я их описал с примерами, настолько красочно, насколько смог.
То, что ни в одной моей статье вы не нашли ни одного ответа скорее говорит о том, что вы не пытались ничего извлечь, ну или задать конкретные вопросы, ответ на которые вас интересует. Я даю конкретные практические рекомендации и примеры, но они требуют релевантного опыта и насмотренности, чтобы ими воспользоваться. То, что у статей десятки сохранений, говорит об их пользе.
Про отличия методологий читайте статью внимательно. Все написано черным по белому. Если совсем не видите разницы, то я сдаюсь. В этом случае я категорически вам не рекомендую читать другие статьи, и что-то искать в них. Скорее всего результат будет тем же, т.е. нулевым.
В статье объяснено, почему мой подход является результатоориентированным, а не процессноориентированным. Но, если вы не поняли разницы, то я бессилен.
Речь не о цели метода. Конечно же любой метод нацелен на получение результата, а об его архитектуре, в которой результатам (артефактам) уделяется особое внимание.
Во многом Prince2 несмотря на использование процессов, как объекта архитектуры не исключает важной роли результатов (артефактов). Даже выделяет отдельный принцип "фокус на результате". Так что я развил и усилил этот принцип.
Если ваши вопросы и тейки будут нацелены на понимание разницы и плюсов предлагаемого подхода, буду рад прояснить непонятные моменты. Но я не вижу смысла перессказывать другими словами то, что я уже написал. Как говорится "Sapienti sat".
Эта тема - источник бесконечных споров, какой строй в каком контексте, временах, условиях будет эффективным. Конечно, это все важно, важно учитывать мнение, важно делегировать власть, ответственность и т.д., но это не исключает необходимости договариваться, формировать правила и действовать по согласованным правилам. Да, демократический централизм это рабочий вариант, но где-то он сработает, а где-то нет. А я говорю о том, что должны быть правила и как эти правила, по которым строится проектное управление, должны работать. В любом государстве есть свое законодательство. И если переложить тему статьи на модель управления государством, то мы говорим про то, как устроены законы, а не то, как организован, например, процесс принятия решений. Это все может быть организовано как угодно, в зависимости от того, как в компании договорились.
Кажется, вы не до конца или не совсем внимательно прочитали статью. Потому что я достаточно подробно описал, каким требованиям должен соответствовать работающий фреймворк управления. А во-вторых это не программный продукт. Лучше напишите, с чем конкретно вы согласны. И что критического в том, что я предлагаю свой подход, если он работает и проверен?
Все верно, проблемы могут быть из-за нечеткости проектной, развивающей и операционной деятельности. Первые 2 пункта - change, последний - run. Я, кстати, не так давно опубликовал статью про структурированный подход к отделению проектов от непроектов. Почитайте, вдруг будет полезно https://habr.com/ru/articles/905442/
Это тема стратегии, маркетинга и продакт-менеджмента. Мы занимаемся темой Execution. Это значит, что с первыми пунктами уже как-то разобрались ) Не в свои темы не лезем.
Это уже совсем экзистенциальный разговор. Я предполагаю, что кто-то что-то сделал в введенном вами контексте Ютуба. Ваш комментарий не в плоскости управления проектами, а в плоскости создания нового, инноваций. Тут нет гарантий, только метод проб и ошибок. Технология работы с продуктами и инновациями тоже есть, можно хотя бы того же Стива Бланка почитать. Но это не технология управления проектами. Она заточена на реализацию более менее понятного, а не "пока неизвестно чего".
Главное не смотреть на "сапожника без сапог" сверху вниз. Потому что таких большинство, из которых большинство никогда не в этом не признается. Поэтому сам факт признания - это крутой шаг вперед. Что касается вопросов, будет здорово, если конкретизируете вопросы, тогда могу добавить деталей.
Вопрос понятен. Тут стоит разграничивать понимание предмета проекта (то, что из себя представляет ютуб) и умение управлять проектом. Скажу на своем примере - когда чувствую, что не хватает компетенции (что-то принципиально новое), то иду к экспертам, которые давно в рынке, деали что-то подобное, работали на референтную компанию. Чуйка новое/старое меня не подводила. Логика проста - делали ли что-то подобное в прошлом. Если нет, идите к экспертам, не тратьте время на собственные эксперименты. Кстати, я тоже не особо верил, что RUTUBE и VK Video взлетят. Но в текущей ситуации, кажется они неплохо себя чувствуют, и я ими пользуюсь.
Я этим давно профессионально занимаюсь, это мой бизнес, и я с клиентами годами работаю, значит они видят ценность. Отзывы можно посмотреть на сайте pmlogix.ru. или узнать лично, если будет реальный запрос. Вы можете что-то постулировать про меня, но думаю, что можете сильно промахнуться так не в курсе ни моих возможностей, ни моей деятельности.
Можно разбить понятие компетенции на - язык, знание инструментов, знание, как в целом система работает. Языку обучить не так сложно, но нужно его постоянно использовать, кроме того, он должен быть приземлен к терминологии компании, если она прижилась и работает. Инструментам тоже несложно обучить, если есть качественный онбординг, обучение и наставник, дающий обратную связь. Как все инструмены собрать в систему - тут нужна экспертиза методолога, у которого должен быть кругозор по разным фреймворкам, методам и их релевантности в конкретном контексте. Но большинству компетенции по системе не нужны. В итоге, если система грамотно собрана, то участникам достаточно общаться на одном языке и грамотно использовать инструменты. Это более чем реальная задача )
В моей практике это все же скорее исключение, нежели чем правило. Но если отдельная задача (доработка) начинает обрастать дополнительными требованиями, превращаясь в проект, то владелец процесса - ответственный за delivery или проектный офис должен поднять флаг и вынести ее повторно на рассмотрение на ЛПР или комитет, который присваивает категорию инициативам (проект, большая задача, задача).
Да, а главное объективно. За базар нужно так или иначе отвечать ) Хотя, конечно, итоговая точка это, когда конкретный элемент мигрируемой системы заработал в целевой системе и больше не используется в исходной.
Когда и что использовать точно не проистекает из общей менеджмент теории. Ее бы, конечно, знать не помешало, но тех, кто имеет хоть какое-то менеджерское образование (я, например, заканчивал факультет "Менеджмент" в ГУ-ВШЭ) ИМХО в разы меньше, чем тех, кто в курсе темы управления проектами. Так что это чересчур оптимистичный тейк.
Бесспорно, управление процессом требует своих фреймворков и в управлении проектами не нуждается. Но не всю разработку софта можно сделать только на управлении процессами, особенно, когда есть интеграции и внедрение. Вы об этом также упомянули далее.
Все же обычно чиновники не настолько погружены в процесс управления, чтобы там что-то сильно диктовать. Так что в их требования безусловно нужно вписываться, но это часто не мешает выстроить свой управленческий фреймворк. В коммерческих организациях все сильно попроще и даже большая часть проектной деятельности нерегламентирована.
Все верно. Мы тут поэтому используем термин "стандарт". Но я слышал очень многих, кто так говорит!
(продолжение ответа)
Для ежедневных действий будет некоторое сходство со Scrum. В руководстве по методу указаны артефакты и ритуалы для всех временных горизонтов (уровней), в т.ч. для ежедневного, но все же фокус именно на реализацию проектов, а не организацию процесса по разработке ПО. Про Scrum я уже написал в ответе на один из вопросов - он слишком узкий для того, чтобы быть проектным фреймворком, кроме того, он построен в результатоориентированной логике, так что критиковать его было бы бессмысленно ). В целом я не думаю, что много кто использует чистый Scrum, скорее отдельные элементы или вариации на тему.
Я думаю, что он никак его дополнительно не улучшает. Задачи полностью заместить "производственный" фреймворк в принципе нет. Фреймворк управления идет поверх него. Тем не менее в методе есть артефакты - план фазы / этапа / релиза. Такой категории, как спринт в методе нет. Планирование выполняется в поточном режиме как в Kanban. Данная статья не является полным описанием методологии. Оно есть в руководстве, котое можно найти в моем тг-канале.
Я не изучал Scrum of Scrums. Взаимодействие организовано через систему ритуалов (у нас они являются частью так называемых событий). Подробнее, о тех событиях, которые мы используем можно почитать в руководстве.
Сама методология бесплатная. Посмотрите, пожалуйста в тг-канале. Если не найдете, то напишите мне лично в тг @malakhov_andrey.
Сознание меня не покидало. На конструктивные вопросы и замечания буду давать конкретные ответы. Цель - прояснить свою позицию для тех, кому она интересна, а не тем, кто хочет обесценить или потроллить. Поэтому на ваши конкретные вопросы я ответил.
Спасибо за переход к конкретике и конструктиву. Я не сомневался, что мне придется отстаивать преимущества своего метода с аргументами, а не только с пеной у рта. Отличного дня!
Мне не близка критика без аргументов, которую я увидел в вашем посте. Просто нет столько времени, чтобы пытаться другими словами сказать то, что уже сказал, особенно, когда звучат обесценивающие нотки про "ответов нет". На конкретные вопросы отвечу.
Об этом статья. Для начала полноценного участия в дискуссии предлагаю прочитать руководство по моему методу. Его можно здесь забрать. @PMLogixBot,а также посмотреть вебинар, по мотивам которого родилась эта статья https://vkvideo.ru/video-211146584_456239038?
В тексте статьи конкретно описано, как понять, см. часть про определение аспектов управления.
Далее по вашим конкретным вопросам:
Точно подмечено, что Scrum хорош тем, как работает с артефактами, НО он очень узок в покрытии аспектов (нет рисков, содержания и качества, ресурсов и т.д. и т.п.), а также охватывает крайне короткий горизонт планирования. Если угодно мой подход можно интерпретировать, как использование конкретики Scrum: артефакты + события + регулярность (привязка к структуре проекта) к более широкому спектру аспектов и как краткосрочным, так и долгосрочным критериям успеха и рискам проектов.
(продолжение следует)
Мне сложно уследить за вашей мыслью. Задачи хаить не было, была задача конструктивно показать недостатки, проявляющиеся на практике при использовании процессноориентированных стандартов управления проектами. И я их описал с примерами, настолько красочно, насколько смог.
То, что ни в одной моей статье вы не нашли ни одного ответа скорее говорит о том, что вы не пытались ничего извлечь, ну или задать конкретные вопросы, ответ на которые вас интересует. Я даю конкретные практические рекомендации и примеры, но они требуют релевантного опыта и насмотренности, чтобы ими воспользоваться. То, что у статей десятки сохранений, говорит об их пользе.
Про отличия методологий читайте статью внимательно. Все написано черным по белому. Если совсем не видите разницы, то я сдаюсь. В этом случае я категорически вам не рекомендую читать другие статьи, и что-то искать в них. Скорее всего результат будет тем же, т.е. нулевым.
В статье объяснено, почему мой подход является результатоориентированным, а не процессноориентированным. Но, если вы не поняли разницы, то я бессилен.
Речь не о цели метода. Конечно же любой метод нацелен на получение результата, а об его архитектуре, в которой результатам (артефактам) уделяется особое внимание.
Во многом Prince2 несмотря на использование процессов, как объекта архитектуры не исключает важной роли результатов (артефактов). Даже выделяет отдельный принцип "фокус на результате". Так что я развил и усилил этот принцип.
Если ваши вопросы и тейки будут нацелены на понимание разницы и плюсов предлагаемого подхода, буду рад прояснить непонятные моменты. Но я не вижу смысла перессказывать другими словами то, что я уже написал. Как говорится "Sapienti sat".
Эта тема - источник бесконечных споров, какой строй в каком контексте, временах, условиях будет эффективным. Конечно, это все важно, важно учитывать мнение, важно делегировать власть, ответственность и т.д., но это не исключает необходимости договариваться, формировать правила и действовать по согласованным правилам. Да, демократический централизм это рабочий вариант, но где-то он сработает, а где-то нет. А я говорю о том, что должны быть правила и как эти правила, по которым строится проектное управление, должны работать. В любом государстве есть свое законодательство. И если переложить тему статьи на модель управления государством, то мы говорим про то, как устроены законы, а не то, как организован, например, процесс принятия решений. Это все может быть организовано как угодно, в зависимости от того, как в компании договорились.
Опечатку поправил, благодарю!
Кажется, вы не до конца или не совсем внимательно прочитали статью. Потому что я достаточно подробно описал, каким требованиям должен соответствовать работающий фреймворк управления. А во-вторых это не программный продукт. Лучше напишите, с чем конкретно вы согласны. И что критического в том, что я предлагаю свой подход, если он работает и проверен?
Все верно, проблемы могут быть из-за нечеткости проектной, развивающей и операционной деятельности. Первые 2 пункта - change, последний - run. Я, кстати, не так давно опубликовал статью про структурированный подход к отделению проектов от непроектов. Почитайте, вдруг будет полезно https://habr.com/ru/articles/905442/
Это тема стратегии, маркетинга и продакт-менеджмента. Мы занимаемся темой Execution. Это значит, что с первыми пунктами уже как-то разобрались ) Не в свои темы не лезем.
Спасибо, мы правда не занимаемся разаботкой стратегией, а помощи в их реализации через проекты, программы, оргизменения. Точно подмечено!
ИТ-инструменты или о чем речь? Конкретизируйте, пожалуйста, не совсем понимаю вопрос.
Это уже совсем экзистенциальный разговор. Я предполагаю, что кто-то что-то сделал в введенном вами контексте Ютуба. Ваш комментарий не в плоскости управления проектами, а в плоскости создания нового, инноваций. Тут нет гарантий, только метод проб и ошибок. Технология работы с продуктами и инновациями тоже есть, можно хотя бы того же Стива Бланка почитать. Но это не технология управления проектами. Она заточена на реализацию более менее понятного, а не "пока неизвестно чего".
Главное не смотреть на "сапожника без сапог" сверху вниз. Потому что таких большинство, из которых большинство никогда не в этом не признается. Поэтому сам факт признания - это крутой шаг вперед. Что касается вопросов, будет здорово, если конкретизируете вопросы, тогда могу добавить деталей.
Вопрос понятен. Тут стоит разграничивать понимание предмета проекта (то, что из себя представляет ютуб) и умение управлять проектом. Скажу на своем примере - когда чувствую, что не хватает компетенции (что-то принципиально новое), то иду к экспертам, которые давно в рынке, деали что-то подобное, работали на референтную компанию. Чуйка новое/старое меня не подводила. Логика проста - делали ли что-то подобное в прошлом. Если нет, идите к экспертам, не тратьте время на собственные эксперименты. Кстати, я тоже не особо верил, что RUTUBE и VK Video взлетят. Но в текущей ситуации, кажется они неплохо себя чувствуют, и я ими пользуюсь.
Я этим давно профессионально занимаюсь, это мой бизнес, и я с клиентами годами работаю, значит они видят ценность. Отзывы можно посмотреть на сайте pmlogix.ru. или узнать лично, если будет реальный запрос. Вы можете что-то постулировать про меня, но думаю, что можете сильно промахнуться так не в курсе ни моих возможностей, ни моей деятельности.
Зовите тех, кто может внедрить язык, инструменты и систему. Нас, например ) Было бы желание. А то так можно бесконечно сетовать, что этого нет!
Можно разбить понятие компетенции на - язык, знание инструментов, знание, как в целом система работает. Языку обучить не так сложно, но нужно его постоянно использовать, кроме того, он должен быть приземлен к терминологии компании, если она прижилась и работает. Инструментам тоже несложно обучить, если есть качественный онбординг, обучение и наставник, дающий обратную связь. Как все инструмены собрать в систему - тут нужна экспертиза методолога, у которого должен быть кругозор по разным фреймворкам, методам и их релевантности в конкретном контексте. Но большинству компетенции по системе не нужны. В итоге, если система грамотно собрана, то участникам достаточно общаться на одном языке и грамотно использовать инструменты. Это более чем реальная задача )
В моей практике это все же скорее исключение, нежели чем правило. Но если отдельная задача (доработка) начинает обрастать дополнительными требованиями, превращаясь в проект, то владелец процесса - ответственный за delivery или проектный офис должен поднять флаг и вынести ее повторно на рассмотрение на ЛПР или комитет, который присваивает категорию инициативам (проект, большая задача, задача).
Да, а главное объективно. За базар нужно так или иначе отвечать ) Хотя, конечно, итоговая точка это, когда конкретный элемент мигрируемой системы заработал в целевой системе и больше не используется в исходной.