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