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