Возможно на уровне глубочайшей компетенции, позволяющей налету рассуждать о различиях и особенностях управленческих моделей разница между процессным подходом и результативным очень ощутима и перевешивает остальные проблемы и риски менеджмента, но на мой взгляд разница, достаточная что бы говорить об отдельном подходе(модели) в статье не была продемонстрирована.
ИМХО, проблемы непонимания когда и в каком порядке использовать те или иные инструменты, описанные в разных моделях это родимое пятно от происхождения всех этих моделей: с начала люди изучает менеджмент, общую школу управления и набираются знаний о профессиональной сфере в которой они будет руководить и только потом они придумывают модели для проектного управления.
Если не забывать о главной особенности, что проект от сервиса/процесса отличается уникальностью, то очень многое становится на места, а заодно всплывает вопрос, а управление разработкой софта со стандартным функционалом для стандартной сферы применения может ли являться проектом или это сервис, знания о котором у конкретного исполнителя недостаточны.
Ведь если вы никогда не брали в руки сварочный аппарат, то попытка сварить две рандомные железяки для вас будет проектом, а для сварщика с двадцатилетним стажем, фигней не стоящей потраченного времени.
Тем кто работал исключительно в разработке может быть не очень понятно, но проект это не только необходимость проведения изыскательских работ на разных стадиях, включая формирование ТЗ, его корректировку, тестовые прогоны для доработки и опытную эксплуатацию, все эти стадии проходят автолюбители покупающие новую НИВУ в замен старой, например, и даже зная, что за машина и что от нее ждать, все эти стадии будут присутствовать. Проект подразумевает, что на практически каждом этапе требуется исследование и уникальный подход.
ИМХО разработка это не проект, вот интеграция разработанного это проект, да и то не всегда.
Кроме того при накоплении базы знаний в компании интеграторе, при внедрении этой БЗ в управленческие процессы, и их оптимизация с учетом набранного опыта нивелирует уникальность новых проектов превращая их в процесс/сервис. Стандартный, понятный, прозрачный и прогнозируемый на 99%.
И вот тут начинается вся свистопляска между правомочностью применения тех или иных моделей и подходов.
Ну и до кучи про жизнеспособность западных управленческих теорий. Как известно крупные деньги это бюджет или околобюджет и отрасль так или иначе подстраивается под те модели, что живут в кабинетах чиновников, а там зачастую жесточайшая иерархия со своим сводом правил для всех контрагентов, которые гнут под свои хотелки и подходы всех настолько в составе проектной команды оказывается генеральный директор вместе с коммерческим и начальниками департаментов, что по сути уже совсем другая песня, нежели проектная команда внутри компании.
Данный эффект для сферического коня в вакууме отлично демонстрирует движущие тенденции, но отнюдь не описывает действительность.
Во первых кризисы разного уровня для бизнеса это норма жизни, они не внезапно появляются, а перманентная среда обитания.
Во вторых бесконечного роста не существует, как не существует своевременного роста по мере развития профессиональных качеств сотрудников. Рост бывает когда освобождается место или когда открывается новое место, чем выше иерархия, тем реже это происходит, а на нижних уровнях, где высокая подвижность кадров, там этой проблемы практически нет. Из этого прямо проистекает, что у любого руководителя люди приходят и уходят потому что достигли потолка, а расти некуда в принципе.
Кроме того непотизм сильно сбивает вектора этой теории.
На мой взгляд, главная проблема, которую пытались прикрыть этой теорией это отсутствие работы со стороны высшего менеджмента и владельцев компании, они свои задачи по регулированию структуры, подруливанию конфликтных зон, пытаются переложить функцию обновления и повышения эффективности на саму структуру, т.е. хотят чтоб мертвое жило и самообновлялось, а оно вот разтакое не самообновляется. Саморефлексия это нереально сложный процесс, как для личности, так и для структуры.
Докину до кучи, ИМХО неспециалиста в Agile, мне кажется этот подход страдает теми же болезнями проектного управления: конфликты интересов команды и административной структуры, внутренний конфликт интересов члена команды и члена административной структуры, двойственность роли и должности, неоднозначность приоритезации общих регламентов компании и внутрикомандных.
Общая инрархичная структура компании довлеет над командой разработки, которая пытается в agile и натыкается на внешние директивы, приоритезацию и KPI, которые идут в разрез в внутренним подходом.
Тимлид не тянет уровень. Agile предъявляет высокие требования к компетенции тимоида как руководителя и как технолога в том продукте, что производит команда. Если глубина понимания недостаточная или не хватает навыков управления, то будет смещаться в неправильную сторону система приоритетов, постановка целей/задач и критерии эффективности/выполнения.
Тоже думаю, что основной штат управленцев крайне легко заменяется И, ведь большая часть их работы алгоритмизируется
Но они же будут до последнего мазаться и рассказывать о своей супернужностиуспеют поувольнять всех и разорить немало контор пока у совета акционеров не появится опция в виде готового продукта ERP со встроенным ИИ для снятия с директоров основного функционала по контролю и планированию. Вот тогда начнется глобальное изменение.
Все влажные фантазии в статье упираются в управленческие решения, соответствующие новому уровню технологий, а управление это самая анахроничная область ИТ.
про интерфейсы и нейралинки рассуждать дико рано до тех пор пока биотехнологии находятся на уровне вставить проводки в живые ткани. Просто как напоминание к трезвомыслию вспомните, что происходило со всеми инородными телами в вашем организме типа занос, осколков и пр., организм обкладывает все инородное изолирующими тканями и постепенно выдавливает. Пока у всех нейролинков низкий срок службы контактов ибо они перестают работать по той же причине-отторжение живыми тканями. Все громкие супертехнологии за последние 20 лет, которые обещали вот-вот прорыв и "все станет по другому" исчезли даже упоминания про них ибо разводняков в научной среде море.
Я как человек приконсувшийся к педагогике и воспитанию двух детей скажу так: вопрос Саватеева отсылает к проверке наработанных навыков разбиения общей картины на частности, навыка воспринимать характеристики объекта отдельно от него в целом. Если ребенка этому с ранних лет не учили, то сам он может к этому прийти, но как быстро это зависит от условий, в том числе качества питания. Т.е. речь именно о навыках. В данном случае догадаться это вспомнить необходимый навык. Рассуждение об интеллекте детей вообще спорная тема, многие функции еще не работают, а мозг живёт в режиме "скопировать-повторить"
Кстати одним из тестов на психиатрические заболевания является задача на группировку разных объектов по уменьшающемуся количеству групп(объедините предметы в 5 групп, в 4,.. В 2 группы), конечные группы живое/не живое в некоторых случаях психиатрических заболеваний недоступны восприятию пациентов, т.е. мир разбитый на части они воспринимают, а объединённый в целое-не очень.
Возможно на уровне глубочайшей компетенции, позволяющей налету рассуждать о различиях и особенностях управленческих моделей разница между процессным подходом и результативным очень ощутима и перевешивает остальные проблемы и риски менеджмента, но на мой взгляд разница, достаточная что бы говорить об отдельном подходе(модели) в статье не была продемонстрирована.
ИМХО, проблемы непонимания когда и в каком порядке использовать те или иные инструменты, описанные в разных моделях это родимое пятно от происхождения всех этих моделей: с начала люди изучает менеджмент, общую школу управления и набираются знаний о профессиональной сфере в которой они будет руководить и только потом они придумывают модели для проектного управления.
Если не забывать о главной особенности, что проект от сервиса/процесса отличается уникальностью, то очень многое становится на места, а заодно всплывает вопрос, а управление разработкой софта со стандартным функционалом для стандартной сферы применения может ли являться проектом или это сервис, знания о котором у конкретного исполнителя недостаточны.
Ведь если вы никогда не брали в руки сварочный аппарат, то попытка сварить две рандомные железяки для вас будет проектом, а для сварщика с двадцатилетним стажем, фигней не стоящей потраченного времени.
Тем кто работал исключительно в разработке может быть не очень понятно, но проект это не только необходимость проведения изыскательских работ на разных стадиях, включая формирование ТЗ, его корректировку, тестовые прогоны для доработки и опытную эксплуатацию, все эти стадии проходят автолюбители покупающие новую НИВУ в замен старой, например, и даже зная, что за машина и что от нее ждать, все эти стадии будут присутствовать. Проект подразумевает, что на практически каждом этапе требуется исследование и уникальный подход.
ИМХО разработка это не проект, вот интеграция разработанного это проект, да и то не всегда.
Кроме того при накоплении базы знаний в компании интеграторе, при внедрении этой БЗ в управленческие процессы, и их оптимизация с учетом набранного опыта нивелирует уникальность новых проектов превращая их в процесс/сервис. Стандартный, понятный, прозрачный и прогнозируемый на 99%.
И вот тут начинается вся свистопляска между правомочностью применения тех или иных моделей и подходов.
Ну и до кучи про жизнеспособность западных управленческих теорий. Как известно крупные деньги это бюджет или околобюджет и отрасль так или иначе подстраивается под те модели, что живут в кабинетах чиновников, а там зачастую жесточайшая иерархия со своим сводом правил для всех контрагентов, которые гнут под свои хотелки и подходы всех настолько в составе проектной команды оказывается генеральный директор вместе с коммерческим и начальниками департаментов, что по сути уже совсем другая песня, нежели проектная команда внутри компании.
Данный эффект для сферического коня в вакууме отлично демонстрирует движущие тенденции, но отнюдь не описывает действительность.
Во первых кризисы разного уровня для бизнеса это норма жизни, они не внезапно появляются, а перманентная среда обитания.
Во вторых бесконечного роста не существует, как не существует своевременного роста по мере развития профессиональных качеств сотрудников. Рост бывает когда освобождается место или когда открывается новое место, чем выше иерархия, тем реже это происходит, а на нижних уровнях, где высокая подвижность кадров, там этой проблемы практически нет. Из этого прямо проистекает, что у любого руководителя люди приходят и уходят потому что достигли потолка, а расти некуда в принципе.
Кроме того непотизм сильно сбивает вектора этой теории.
На мой взгляд, главная проблема, которую пытались прикрыть этой теорией это отсутствие работы со стороны высшего менеджмента и владельцев компании, они свои задачи по регулированию структуры, подруливанию конфликтных зон, пытаются переложить функцию обновления и повышения эффективности на саму структуру, т.е. хотят чтоб мертвое жило и самообновлялось, а оно вот разтакое не самообновляется. Саморефлексия это нереально сложный процесс, как для личности, так и для структуры.
Докину до кучи, ИМХО неспециалиста в Agile, мне кажется этот подход страдает теми же болезнями проектного управления: конфликты интересов команды и административной структуры, внутренний конфликт интересов члена команды и члена административной структуры, двойственность роли и должности, неоднозначность приоритезации общих регламентов компании и внутрикомандных.
Когда Скрам соскамился со старта)
ИМХО тут возможны два варианта:
Общая инрархичная структура компании довлеет над командой разработки, которая пытается в agile и натыкается на внешние директивы, приоритезацию и KPI, которые идут в разрез в внутренним подходом.
Тимлид не тянет уровень. Agile предъявляет высокие требования к компетенции тимоида как руководителя и как технолога в том продукте, что производит команда. Если глубина понимания недостаточная или не хватает навыков управления, то будет смещаться в неправильную сторону система приоритетов, постановка целей/задач и критерии эффективности/выполнения.
Если из каждого проекта убрать руководителей и контролеров, заменив их И, то исчезнет куча лишних задач по обеспечению контроля процессов, отчетности
Тоже думаю, что основной штат управленцев крайне легко заменяется И, ведь большая часть их работы алгоритмизируется
Но они же будут до последнего мазаться и рассказывать о своей супернужностиуспеют поувольнять всех и разорить немало контор пока у совета акционеров не появится опция в виде готового продукта ERP со встроенным ИИ для снятия с директоров основного функционала по контролю и планированию. Вот тогда начнется глобальное изменение.
Все влажные фантазии в статье упираются в управленческие решения, соответствующие новому уровню технологий, а управление это самая анахроничная область ИТ.
про интерфейсы и нейралинки рассуждать дико рано до тех пор пока биотехнологии находятся на уровне вставить проводки в живые ткани.
Просто как напоминание к трезвомыслию вспомните, что происходило со всеми инородными телами в вашем организме типа занос, осколков и пр., организм обкладывает все инородное изолирующими тканями и постепенно выдавливает. Пока у всех нейролинков низкий срок службы контактов ибо они перестают работать по той же причине-отторжение живыми тканями.
Все громкие супертехнологии за последние 20 лет, которые обещали вот-вот прорыв и "все станет по другому" исчезли даже упоминания про них ибо разводняков в научной среде море.
Я как человек приконсувшийся к педагогике и воспитанию двух детей скажу так: вопрос Саватеева отсылает к проверке наработанных навыков разбиения общей картины на частности, навыка воспринимать характеристики объекта отдельно от него в целом. Если ребенка этому с ранних лет не учили, то сам он может к этому прийти, но как быстро это зависит от условий, в том числе качества питания. Т.е. речь именно о навыках. В данном случае догадаться это вспомнить необходимый навык. Рассуждение об интеллекте детей вообще спорная тема, многие функции еще не работают, а мозг живёт в режиме "скопировать-повторить"
Кстати одним из тестов на психиатрические заболевания является задача на группировку разных объектов по уменьшающемуся количеству групп(объедините предметы в 5 групп, в 4,.. В 2 группы), конечные группы живое/не живое в некоторых случаях психиатрических заболеваний недоступны восприятию пациентов, т.е. мир разбитый на части они воспринимают, а объединённый в целое-не очень.