Не так давно хлопцы из PMBoK потеряли кормовую базу. Главным виновником свалившегося на PMBoK несчастья стал стандарт ISO 21500:2012. После его выхода собирать деньги с доверчивых руководителей компаний стало затруднительно. Ибо пропихнуть идею прогрессивности PMBoК при наличии аналога от ISO не представлялось возможным. А тут еще Agile с социократией и холократией мозг выносят в спину дышат….
А учитывая, что далеко не все готовы принять концепцию, что управлять проектами с помощью формализованных процессов - это классная идея, позиции PMBoK стали выглядеть совсем слабыми. Нужна была новая идея, которая позволит вернуть былую привлекательность дойной корове торговой марке.
И хлопцы из PMBoK не придумали ничего лучше, чем объявить, что процессный подход устарел. Что они сейчас соберут лучших Р-методологов и Р-практиков и родят новую концепцию, построенную не на «процессах», а на «принципах».
И ладно бы они это объявили за пару месяцев до презентации нового подхода, они действительно стали изобретать новую «библию» для своих «прихожан».
И вот, пока хлопцы из PMBoK пребывали в муках творчества, ISО явил миру новую версию стандарта ISO 21502:2020 и чуть позже выйдет ISO 21500:2021, которые выбивают почву из под ног (и не только у PMBoK).
Причем, выбивает качественно. Стандарт написан так, что является прекрасным инструментом для продажи услуг консультантов по внедрению проектного подхода. Все, что смогли услышать господа из ISO внесено в документ. Тут тебе и «Бизнес кейсы», «Практики», «Получение выгод», «Конечная полезность» и новые «Области Компетенций» единственно чего там нет – это понимания смысла и ответа на вопрос: «Почему внедрив этот стандарт мы станем лидером?». Или так: «Как эти стандарты позволят нам уложить проект в сроки и бюджет?».
Все подчинено единственной задаче – захватить рынок консалтинговых услуг и заставить компании «третьего мира» следовать по новой тупиковой дороге в области проектного управления… Конкуренты никому не нужны…
И вот, что удивительно, сейчас все радостно начнут внедрять «самый прогрессивный» подход в проектном управлении. Появится возможность освоить деньги на консультантов, которые плохо понимают в производстве, но отлично понимают бизнес ISO и умеют толковать «стандарт». Ведь, еще никого не уволили за внедрение международных стандартов…
У меня всегда вызывало недоумение слепое поклонение перед авторитетами. Я искренне не понимаю, почему люди искренне верят, что компания получит конкурентной преимущество, внедрив чужую систему управления.
На практике все происходит с точностью на оборот. Бюрократия множится, трансакционные издержки в компании растут, сроки не выдерживаются и наблюдается перерасход ресурсов. (Про климат в коллективе я скромно умолчу.)
Так зачем люди занимаются подражанием? Кому нужен этот карго-культ в управлении? Нет, я понимаю, что иногда нужно для допуска к телу покупателя иметь сертификат ISO и заплатить какому-нибудь Veritas за аудит. Но люди реально пытаются перестраивать отлаженные процессы в угоду ISO не понимая смысла изменений…
Появилась целая каста «менеджеров по качеству», «риск менеджеров» и прочих «issue manager». Не смысля в производстве, они требуют от всех выполнения «процессов» (теперь это будет «практикой» или «подходом» ). При этом на вопрос о смысле кивают на «стандарты», «положения» и прочую нормативную документацию, порожденную карго-культом.
Хе-хе, Хищники новую дурилку ватную нашли для быдла...
Невозможно запихнуть в формализованные документы человека, технологии - пожалуйста, но лишь до тех пор пока эти технологии отработанны, стоит появиться чему-то новому и всё - песец пришёл к котёнку. Я уж не говорю о поиске решений за гранью известного. Блин а ведь такой поиск тоже может быть проектом. НО! Скажите мне пожалуйста, как может манагер, освоивший все эти PMBoK-и и ISO (перечитал кучу этого говнищща, первое - адское запутывание, вторые - зияющая неполнота) выйти за пределы известного???
Целеполагание на основе знания сути человека подвязанное на современные технологии - вот временное решение управленческих задач. А вот в эту сторону никто рыть и не желает, ибо априори придётся видеть в ближнем своём равного, а не быдло. А вот на это манагеры "пойтить не могут", просто потому что придётся пахать, не править...
Комментарии
Та не... Мне таки интересует за Вашу память. Зачем Ви приставали к большому дяде с молотком в руках. И рассказывали сказки за
Вэйзмир азохунвей!
Если вы держите молоток двумя руками, кто-то еще должен держать гвоздь. Итого: увеличение затрат, так как используются два работника вместо одного.
Ну вот... Вы пытаетесь отойти от стандарта в целях экономии. Как это знакомо!
Перспективный чат детектед! Сим повелеваю - внести запись в реестр самых обсуждаемых за последние 4 часа.
....которые плохо понимают в производстве, но отлично понимаю бизнес ISO и умеют толковать «стандарт» Лучше не скажешь.
+ миллион
Как-то начальство подорвалось всех на бизнес-тренинги и прочую шмутотень отправлять. Я вывернулся - мол, ночные смены, тренинги днём - буду храпеть и всем мешать.
Коллеги порассказывали, чем там занимались... ну не ложится это на нашу почву, потому что народ в массе не понимает, нафуя это всё надо. По стульям прыгали (это типа прыжки по карьерной лестнице). Разумеется, падали - это символизирует трудности, сопровождающие прыжки по карьерной лестнице.
Как-то зашёл в бухгалтерию, а там по стенам висят А4 со шляпами нарисованными.
- Зачем вам шляпы на стенах?
- Ну как же, чем больше шляпа, тем выше должность!
- А вы чо, не знаете, у кого какая должность? Вас тут три человека.
Ну, мне было объяснено, что шляпы велено рисовать на очередном занятии с заезжим коучем.
Как грицо, когда начальству нечего делать, оно
яйцалижеткоучей зазывает.И карго-культ бывает, часто бывает. Бывает, наперсток используется не для шитья, а чтобы лохов разводить. А еще бывает, что несостоявшийся художник, перепробовав все виды кисточек, жалуется, что ни нашел ни одной, которая помогла бы ему нарисовать "Мону Лизу".
Мораль - 1) инструмент не виноват, что им пользуются мошенники. 2) инструмент не виноват, что неумелый подмастерье, возомнивший себя мастером, не может добиться достойного результата.
Еще есть такая вещь как методологические ошибки. Но из-за "сияния авторитетов" их не готовы признавать.
Пример: В предыдущей версии предлагалось проектную деятельность описывать в виде формализованного процесса.
Т.е. проект - уникальное мероприятие (содержащее неопределенность), предлагается формализовать в виде процессов. Это очевидная глупость, которую (наконец-то) в новой версии исправили. Но более 10 лет всех убеждали, что "инструмент не виноват, что неумелый подмастерье, возомнивший себя мастером, не может добиться достойного результата".
Пример глупости в текущей версии:
В текущей версии осталось отдельная компетенция "управление рисками". На следующие вопросы внятных ответов как не было так и нет:
- Чем "управление рисками" отличается от "управление проектом" ?
- Зачем это надо выделять в отдельную компетенцию? Для увеличения бюрократии и бумажек?
Хотя, надо отдать должное авторам стандарта, они в новой версии написали про "интегрированное управление" и что рисками могут "управлять" исполнители работ.
Теперь можно вернуться к классической советской модели управления и говорить, что у нас "интегрированное управление" помянув в должностных инструкциях слово "риски" ))) И не городить еще одно подразделение - профит!
В целом стандарт стал больше отражать жизнь. И с его помощью станет проще описывать текущую деятельность (глупости остались, но их стало меньше).
Окончательное мнение можно будет сформировать после выхода второй части, но уже понятно, что это инструмент для обогащения консультантов, а не собственников и сотрудников компаний.
Надо отметить двойственность результата продвижения подобных стандартов. Они несомненно принесут пользу конкретному предприятию, если будут адаптированы к местной реальности. Это можно сделать если творчески подходить к делу и если стандарты будут осмыслены и внедрятся под непосредственным контролем и с участием заинтересантов - собственников бизнеса. Это возможно только для малого и среднего, может быть, бизнеса. Разрушительное же действие заложено изначально с прицелом на крупный бизнес, национальный и транснациональный. Единые стандарты позволяют: а) вскрыть бизнес, сделать его прозрачным для транснационального капитала; б) приземлить, заставить работать в общей конкурентной среде, лишив личных ключевых конкурентных преимуществ; в) поставить в позицию догоняющего, поскольку новые обновления стандарта буду разрабатываются, но о них будет узнавать первыми и, соответсвенно быть готовыми к ним первыми, - компании из (их) ближнего круга.
Таким образом европейские стандарты - это системная диверсия, имеющая долгосрочные цели. В тактической конкурентной борьбе могут оказаться кому нибудь полезными.
Здесь людей подводит тяга к простым и понятным решениям, если метдология "работает" в уме, то люди обычно предполагают, что и реальности заработает.
добавлю свои 5 копеек.
PMBoK, это не стандарт и не методология, это, так называемый, "фреймворк" - мясо, то есть тупая вики, где описано "что можно делать", но ни слова про "когда", "для чего" и "как". Попытки тупого его применения - в большинстве случаев приводят ко вполне известным последствиям. Пр этом, у буржуинов есть вполне себе методологии управления, которыми они даже успешно пользуются. Если говорить про проектное - то например тот же PRINCE2. Крайне рекомендую. При желании, там и итерационные (Agile) проекты есть как в основной методике, и так в той же DSDM. Это скелет, на который вполне себе натягивается тот-же PMBoK и уже можно чтото применять не только достаточно дейтсвенно, но и вполне осознанно, а не "научным тыком".
Но основная проблема даже не этом зоопарке, проблема в том, что подавляющее большинство "наших ПМов" и управленцев просто не понимают, что такое "бизнес" вообще и чем, например, отличается "government business" от "commerce". А уже про разницу между "процессом", "операцией"(правилом) и "процедурой" я уже даже и не спрашиваю.
ЗЫ, есть еще "коронный" вопрос:
Про матрицу ответственности RACI/DACI/PACSI (последняя - наиболее адекватная и полная, на мой взгляд) все более менее в курсе. И даже могут рассказать что и для чего, если не вдумываться. Но стоит только перейти в парадигму "решения" (когда у нас не просто пример - "копаем от сюда до вечера", а стоит именно задача целоком, когда нужно еще понять: копаем или взрываем, от "до вечера" или "до забора" и т.п.) то каковы зоны ответственности для нижеследующих (то есть кто кем является)?:
Казалось бы все просто, но вот по факту, соотнести зоны ответствености с реальным положением дел - для многих весьма не простая задача. Поэтому все эти фантики - всего лишь громкие всхваление в сторону голого "короля".
Для любой методики есть область применения, где она вполне адекватна. И есть граничные условия, без выполнения которых она не работает. Одним из таких граничных условий является корпоративная культура.
Тащить любую западную методику управления без учета корпоративной культуры - заниматься карго-культом.
Ибо все внешние признаки присутстсвуют, но не работает или работает совершенно не так..
С другой стороны, "новообращенные фанаты" пытаются применять подход во всех случаях жизни.
Возьмем любимый многими Agile. Применение - итерационное совершенствование продукта. Т.е. подход применим для многократно тиражируемого (воспроизводимого) продукта. При этом тиражирование (воспроизведение) не требует больших трудозатрат и материалоемкости. Практика ведет родословную от ИТ-разработчиков.
И вот прибегают консультанты из ИТ-компании в строительный бизнес и на полном серьезе предлагают управлять по этой методике строительным проектом промышленного предприятия...
На лицо непонимание разницы между продуктом и проектом. Т.е. методологическая ошибка.
И здесь мне очень понравился финт, который провернули разработчики нового стандарта ISO. Они все существующие подходы к управлению обозвали "практиками". И предложили применять "гибридное управление" используя любые "практики". Они спозиционировали себя как "надсистему", на нижнем уровне который можно применять все, что душе угодно.
Вот где будет раздолье для консультантов.
Можно в любой организации внедрить новый ISO и требовать его наличие у всех контрагентов для допуска к конкурсным процедурам. Клондайк!
Я не очень понимаю, что такое "корпоративная культура".
что касается методик управления - то они, как это ни странно прозвучит, одинаковы у всех. Что совеские, что азиатские, то буржуйские - все строятся на одних и тех же идеях (даже, если не принимать в расчет, что все друг у друга "заимствовали"). Разница исключительно в названиях, украшательствах/присяданиях да правилам отбора людей на роли.
Раз уж вспомнили Agile - то это ужас. Оно работает исключительно, когда 5 студентов делают один простенький сайтик и ничем другим в принципе не занимаются. Когда же штат исполнителей вырастает за несколько десятков, количество продуктов в одновременной разработке превышает 3 (при использовании одних и тех же сотрудников), а жизненный цикл продукта переходит порог в 1 год (не дай боги, если еще и несколько версий одновременно живет) - любая попытка ввести Agile это весьма изощренный способ самоубийства. То То есть сама идея Agile - "набрали небольшое количество студентов на разовую работу, в области, в которой никто не соображает" прекрасно очерчивает границы ее применимости. Однако не стоит упускать из виду тот факт, что адекватные люди и в Agile смогут чтото сделать. Просто без него они бы это сделали лучше, быстрее и проще.
Иными словами проблема методологическая. Если возвращаться к RACI/PACSI - то в российский организациях есть исполнители, есть ЛПР и так далее, но в принципе отсутствуют "лица, готовящие решения". Если перейти к военой схеме правления, то имеются бойцы, есть командиры, но нет штабов. Руководители из пальцев высасывают варианты действий, минимально озабочиваясь расчетами, рисками, планированием. И вместо анализа проработаных вариантов действий, выбора и/или комбинированию из готовых решения -в попыхах выдумывают новые. В этом и проблема. И тут соверщенно не важно, будут следовать ISO, или не будут - принципиальной проблемы отсутствия планирования/развития это не решает.
Нет. Не одинаковы. Например, в нашей стране директор может переопределить решение ведущего спеца или ГИПа, а, например, в Швеции нет. Там ему в голову не придет вмешиваться в решения, которые принял профессионал, в угоду сиюминутной прибыли.
И таких примеров вагон и маленький тележка.
Вообще, проблема делегирования - краеугольной камень всех систем управления, особенно в инженерных или, если хотите, творческих коллективах.
Если не решена эта проблема, никакие матрицы распределения ответственности работать не будут. (Там где все формализуется и описывается уставами\положениями\регламентами - эта проблема не стоит так остро. Правда, там управление превращается в синоним слова контроль. Тогда там с развитием - полный швах, но это другая тема)
И все эти вопросы, в конечном итоге, приводят нас к пониманию роли корпоративной культуры.
С точки зрения системы управления, культура - это наслоение способов выживания. Или наслоение способов удовлетворения потребностей, что в широком смысле одно и то же.
Корпоративная культура - это наслоение способов выживания сотрудников в организации.
Обычно у буржуев все зарегулировано по максимуму и любые отклонения от нормативов (даже в лучшую сторону) караются очень жестко. Поэтому ведущий спец. может что-то кому-то предложить и не более того. Исполнитель или руководитель (тот же ГИП) не имеет права на принятие управленческих решений, выше его уровня ответственности, будь он хоть умнее всех жителей планеты вместе взятых. Если ему скажут - копай зубочисткой отсюда и до вечера - то будет копать и не пикнет. Что у нас, что у них. Все остальное - лишь приплясывания вокруг да около. Это реальность, и чем крупнее организация - тем это жесче. Знаю по своему опыту.
Мматрица ответсвенности это ни в коем разе не панацея, это просто способ оценить, насколько процесс и его описание полнй и не более того.
Да, есть такое. ) Особенно в крупных конторах наподобие GE или Siemens. Но это не значит, что их регламенты перенесенные на нашу почву, например, в Силовые Машины, будут работать.
Лишь добавлю свои 2с
Нам постоянно предлагают альтернативу курам – но мы-то знаем, что это утки (анекдот про альтернативу)
PMBoK покрывает любой проект на все 100. Если ISO21500 и другие методики и фреймворки делают то же самое – отлично. PMBoK – это скелет-классика, который включает и итерации (к примеру, группа процесса “планирования”, и жёсткий waterfall (строительство домов), и agile (для софт-индустрии), типа мягкий waterfall, и гибридный подходы (hybrid), и перекрёстно-смешенный (blended), и совместные смешанные проекты с руководителями отдела, учитывает как культуры команды/заказчиков, так и нишу индустрии компании.
Что такое agile – это возможность “гибкого”(дешёвого) подхода к прыжку с минимальным весом (без планирования конечной дистанции), и с возможностью переобуться в прыжке, чтобы при приземлении не забить нос землёй (не накопить tech. debt – дефекты архитектуры, кода, качества, конечной цели работ), дабы при следующем прыжке (итерации) можно было так скакать дальше (и чтобы в каждый момент времени был якобы рабочий продукт и за это ничего никому не было). Идеальный представитель сего – это scrum, рамки которого являются частным и сильно упрощённым (компромиссным?) случаем PMBoK, потому что иначе проекту никак не продвинуться вперёд, когда оперируешь кучей неизвестных переменных, часть которых возможно будет известна только в конце (который сам по себе иллюзорен).
Другое дело, что не каждый ПМ имеет мозг в широком смысле слова. Его заменяет слепое фрагментарно-мозаичное недиалектическое мышление. А если приплюсовать отсутствие поддержки/дисциплины проектов управлением компании и самим заказчиком, общую деградацию кадров и ресурсов, сложность систем и инструментов их анализа, что влечёт к гарантированному провалу уже до этапа самого планирования.
Да, именно это и утверждали авторы этого Body of Knowledge... Но, потом, после появления ISO 21500:2012, увидев и осознав свой провал в 2019г., признали, что это Body of Confusion.
ISO переобулся первым. Да так ловко, что все остальные теперь рассматриваются как "практики'.
Парни из ISO поставили себя "над схваткой". Это выглядит прекрасным ходом, с точки зрения захвата рынка и попытки доминирования на нем.
Увы, как уже говорил, PMBoK - это не только не скелет, но даже и не хрящи - больше кожа и некое колчиество мяса. Не имея собственной методики управления - все приблуды из этого "бука" бесполезны. Равно также, как вызубривание наизусть википедии не позволит спроектировать самолет. И не понимание этого - одна из причин боли на проектах.
Как пример - когда в команде необходим тимлид и какова его основная проектная задача? В PMBoK Вы этого не найдете. Каковы критериии деления проекта на фазы? Требования к вехам проекта? Снова ничего нет. Описание и цели мероприятий по завершению фаз проекта? Аналогично - отсутствуют в PMBoK. И как этой методичкой предполагается пользоваться в реальности?
Аналогично и с agile. Очень хочется услышать предложения, как "по Agile" организаовать работы команды из 50 человек, разбитых на 5 групп, каждая из которых ведет разработку одновременно по 3м версиям продукта (поддерживаемой, текущей и перспективной), и частично завязана на результаты работ остальных групп? Я даже не прошу добалять сюда единый QA :)
И еше раз, завязывайте с waterfall - небыло и нет такой методологии. Есть уже решенная типовая задача (это то, что Вы попытались обозначить как "водопад"), если задача, пути решения которой команде не известны (то, что кто-то пытаются назвать Agile). Но проблема в том, что есть уже если не тысячи, то уж точно сотни лет отработанные методики последовательных исследований/разработки и ничего полезного из них в разные виды "модного" Agile даже не планируется добавлять. По факту - современный "майнстрим" - это изощренный способ самоубиться и не более того. Поэтому что версии PMBoK'а, что новоиспеченый ISO - пляски с бубном в надежде вызвать дождь. :)
ЗЫ. Чтобы небыло непонимания, специально обостряю полемику, чтобы четко обозначить проблемы. Да, если у человека никогда небыло опыта управления, то почитать тот-же PMBoK - очень полезно. Но знание только PMBoK - не сделает сертификатаносца даже помошником руководителя проектом. Поэтому - это не самый плохой справочник, но не более того.
PMBoK особено вреден для человека, у которого нет опыта управления.
Вместо этого лучше почитать конспект лекций "Принятие корпоративных решений". (Его можно найти в инете). Там неплохо описаны базовые вещи.
если рассматривать PMBoK как единственный источник информации - соглашусь, это вредно для любого, хоть с опытом, хоть без оного. Более того, сам это "бук" даже не обязателен. Но если человек с ним знаком, наряду с другими знаниями по управленияю - то в этом нет ничего плохого.
Перед тем, как оставить свой комментарий, я поверхностно ознакомился с руководством ISO21500 (а это тоже не framework, а лишь общие указания / методология) и не нашёл ничего принципиального отличного от указаний PMBoK. Спасибо за наводку и полемику.
Мой ВЫВОД: ISO21500 представляет собой тот же набор процессов, их названий и позволяет отслеживать прогресс по группам, учитывает риски, стоимость, градации качества, демографию и т.п. Без конкретики и конкретных примеров где конкретно указания ISO21500 вернее или полнее PMBoK, я б не стал менять своего мнения, что эти две сущности абсолютно тождественны до иллюзорности, увы.
А вот наша русская школа (которая, по моему мнению, сильно хромает в практической конкретике и требует от ПМ быть прежде всего Человеком с большой буквы, что, конечно, в кап.обществе воспроизводства маленьких и никчёмных обескураживает) – но читал, скажу, с удовольствием: Щедровицкий Г.П. Оргуправленческое мышление-идеология. Методология. Технология. 2003
Брат, поделюсь с тобой идеей, что у слона тоже есть крылья, но просто их величина равно нулю. Также и с agile – вообще всё вокруг Agile, даже классический waterfall перестаёт быть waterfall, когда количество запросов на внесение изменений (CRs) в процессе внедрения (Implementation) равен >0.
Практическая ценность “аналоговых” руководств и методик (PMI и ISO) – это использовать их как якорь для выигрывания будущих войн. А frameworkи дискретны – они нужны для выигрывания прошлых войн. Применив аналоговое руководство (с головой, т.е. разумно), в конце проекта получится framework с описанием как нужно делать данный конкретный проект в следующий раз при схожих входных данных. Где-то так. Поэтому, когда кто-то произносит “agile” – для меня это пустой звук не о чём. Тот же PMI имеет методику внедрения как уровня agile’истости в данную конкретную компанию, какого именно типа, так и в каких случаях это просто неприемлемо и оставайтесь-ка, братцы, на waterfall с вашими функциональными менегерами отделов, с вашей культурой и т.п.
Это отвечает на Ваш вопрос "когда в команде необходим тимлид и какова его основная проектная задача" – ответ: может быть никогда, а может нужна, а может это будет тимлид, но не с типично присущими ему перечнем операционных/проектных задач, ведь даже у софт-компаний SLCM разнится, а если ещё часть компании подсели на Scrum в виду невозможности иного, то там все без титулов и взаимозаменяемы.
"как "по Agile" организаовать работы команды из 50 человек..." Отвечу с моей колокольни. Ваш сценарий довольно типичный, и какую бы методологию не применяли, она будет оставаться agile в любом случае (ибо в софте waterfall отсутствует как класс пролетариат) – вопрос лишь в Blended или Hybrid виде, а также что с чем смешивать, потому что входные данные – это ваши архитектура, технология, инструментарий и version control. Любые изменения/работа по всем 5 группам должны быть скоординированы, начиная с уровня архитектуры (т.е. необходимы SME с каждых групп – они должны общаться и быть представлены тимлидами, если, конечно, нет одного главного архитектора, который планирует и мониторит вообще всё). На этот пирог наслаивается Product Manager/Owner с хотелками и т.п. Тут важно построить систему так, чтобы в любой момент времени, в результате критических итераций, иметь обратную связь нужным для принятия решений людям. А дальше сами ;0
Вы посмотрели версию 2012 г. Т.е. ISO 21500:2012
Это стандарт действительно аналог PMBoK.
Я же пишу про новые версии ISO 21502:2020 и ISO 21500:2021
p.s. поправил в исходном посте нумерацию стандартов. ISO 21502:2020 и ISO 21500:2021 но сути происходящего это не меняет )
Да, спасибо, верно. А :2020 я пока не найду, но думаю, что кардинально там нечему меняться, разве что в сторону упрощения (ибо евро/амер. когнитариат продолжает деградировать).
Разве что нашёл, что в новой инкарнации 21500 останется базовым (как и :2012, т.е., судя по всему, содержание групп/процессов/методик :2012 никуда не исчезает), но будет дополнен новым отдельным 21502 с практиками управления проектами, т.е. намечается расширение/дополнение базовой структуры процессов конкретными практиками управления проектом, адаптирующиеся к типу/нише проекта (набор комбинаций практик действительно ограничен), а также усиление веса ролей и целеполагания. Подобное провернул PMI пару лет назад, дополнив процессы agile-практиками, но очень поверхностно.
Важно понимать общую структуру:
Идея (концепт) > Процесс > Конкретная практика процесса (т.е. framework/шаблон, зависящий от набора входных параметров, кои да, можно группировать и классифицировать). Зная Идею (суть) и разбивку (целого) на процессы, можно прийти к правильной практике в данном конкретном проекте.
Буду держать руку на пульсе!
Чтобы не заниматься словоблулием, дайте критерии, по которым Вы отделяете "Agile" от "не Agile". Я пользуюсь вот этими: https://agilemanifesto.org/iso/ru/manifesto.html и https://agilemanifesto.org/iso/ru/principles.html. И по ним прекраснно видно, что это уровень кустарщины. Ну максимум для курсачей студентов младших курсов.. Неужели есть кто-то, кто действительно уверен, что разработка ПО сложнее разработки самолета? И, похоже это будет открытием, но CR (запросы на изменения) - это унылая рутина для любых разработок и любого производства, начиная от печати объявлений, и заканчивая теми же самолетами.
Еще раз, это типовая задача, для которой сотни тысяч "сертифицированных управленцев" не смогли подготовить типового решения за последние десяток лет. Это вполне достаточная характеристика для рекламируемых методов управления.
Более того, Ваши отсылка к архитктуре, инструментарию безосновательны, поскольку задача именно что типовая. может касаться случаев, когда задачи зависимы, но не взаимовлияющее друг на друга, например речь идет о командах разработки платформы+плагинов в ней, или о командах интеграции и шины данных, или же про команды каналообразования и оконечных устройств. Принципы организации подобной работы известны сотни лет (как миниумум) но это не про Agile и PMBoK, от слова совсем.
Ткните пальцем, с каких пор PMI PMBoK стал вдруг методологией? Даже авторы более чем на framework (набор инструментария) не претендуют.
Что же касается моего вопрос, то я не спрашивал "нужен или нет", я попросил четко привести критерии, когда именно нужен и для чего/почему. Любая методология дает четкий ответ на этот вопрос (пусть и несколько отличающийся между методологиями, но вполне себе логичный и системынй в рамках каждой из них).
У нас гуси с южного кордона начали прилетать – привет передали ;0
Приведённые Вами критерии являются проекцией основной идеи, причём эта проекция искажена сознанием её написавшим (в хорошем смысле слова / в целом). Для Вас выглядит кустарщиной, а для меня – первичная элегантная простая идея.
Замысел/Идея Agile: Сохранять неразрывный диалектический баланс (единство / приемлемый компромисс) всех изменяющихся сущностей на протяжении всего длительного жизненного цикла, и не в ущерб друг-другу.
Теперь высасываем из этой идеи манифесты, принципы и что важнее, и как этого достичь в условиях производственных отношений – для тех, кто не может без универсальной формальности / конкретики на все случаи жизни.
Видно, что готовность к изменениям равна наличию самой этой возможности (а далее количеству CRs), но сама такая возможность должна быть предусмотрена изначально на этапе планирования, иначе грош цена всем CR-запросам – они будут отклонены и будете следовать первоначальному плану. ПРИМЕР: Т.е., на этапе планирования мы заранее закладываем вероятностное пространство возможных изменений (готовность к девиации scope’а) в процессе доставки продукта к заказчику (архитектура, инструмент, качество и процесс, связывающий это с ресурсами воедино)
И так по каждому пункту Agile’истости. Надеюсь, моя мысль стала понятнее.
"сотни тысяч "сертифицированных управленцев" не смогли подготовить типового решения за последние десяток лет. Это вполне достаточная характеристика для рекламируемых методов управления."
Думаю, что ответ очевиден - Вы ищите универсальный дискретный ответ в нашем аналоговом макромире. Наверное, проблема в рекламе? Шучу. Наверное, поэтому роль человека никогда не заменит машину. Все производства и тождественны, и различны одновременно, поэтому топология изменений на бизнес-пути (т.е. проекты) жутко разнится. Из общего что их объединяет: $-обоснования и соотношения с целью, качественный анализ (разбивка целого на его составляющие (при этом потери неизбежны – философия умоляет знать об этом факте, а Agile просит быть к ним готовым изначально)), покрытие рисков, составления плана работ, найм и координация ресурсов, далее учёт и контроль. А иначе как по-другому? Машина пока не оцифровала всё физическое бытие во всех его проявлениях, поэтому не может выдавать правильные планы работ, к примеру, учитывать культурные различия и человеческие барьеры. Это искусство для тех, кто хочет закрыть проект без факапа.
Я настаиваю на том, что PMI/ISO это guidelines/руководство/сборник указаний/методик/методология. Возможность, стили или способы их (не)применения – чётко индивидуальны и на усмотрение данного конкретного ПМ, который как раз и руководствуется этой самой вариабельностью методики/указаний.
Но никак не альтернатива, то как framework/шаблон, который твёрд, является неизменным во всех ипостасях, со своими артефактами и жёсткими рамками – это как раз не PMI/ISO, а тот же Scrum (раз выбрал Scrum - плыви по шаблону/framework'у).
Весьма толковый стандарт управления содержится в Боевом уставе Сухопутных войск СССР (взвод, отделение, танк): хотя в прикладном плане изложена процедура подготовки и ведения боя, методика применима практически во всех областях деятельности (в первую очередь бизнес, во вторую - госуправление). Уставы более высшего разряда ("рота, батальон", и т.д.) менее применимы в элементарном управлении.
Да, армия это одна из лучших школ управления. Только армейские подходы слишком ресурсоемкие. Не всякий бизнес способен потянуть столь дорогостоящий подход.
На моё скромное мнение - все эти стандарты, они за прибыль. Дело в том, что работа по классической (waterfall) модели в текущих условиях не приносит прибыль, потому что жёстко проходит определённые стадии. В результате такой разработки моет получится как нечто выдающееся, так и нечто ужасное. Но и это не всё. Отраслевые исследования идут примерно в одном направлении, а значит получив конкретные сведения о ваших разработках конкуренты могут «срезать углы» и прийти к финишу вперёд вас, без затрат на весь процесс.
Другой проблемой классического процесса разработки можно счесть невозможность существенной корректировки требований к результату. Отчасти поэтому и возникли все эти SCRUM/Agile. Однако они, также, являются результатом повышения энтропии, когда вместо ожидаемого результата получается нечто неожиданное.
В результате появление сейчас чего-то революционного маловероятно. Потому что большинство корпорации имеет огромные библиотеки разработок и коллективы эти разработки поддерживающие. Революция – это не только нечто удивительное и полезное, но и уничтожение целых анклавов, кормившихся с хорошо известного старого. Надо ли говорить, что это повышает инерцию в принятии нового? Кроме того не все начинания ведут к успеху, а значит могут быть затратными. Вкупе с тем, что почти всех корпораций – это извлечение прибыли, любые потенциально затратные начинания будут задавлены в зародыше.
В результате всего перечисленного многие корпорации становятся коллективно управляемыми импотентами, подверженными внешнему влиянию. Именно поэтому самые тупиковые варианты развития становятся основными. Потому что они правильно поданы и обещают только прибыль.
Трудно не согласиться с Вашими посылами и выводами.
Agile'истость – как результат повышения энтропии (соответственно, повышение сложностей связей и их топологии) и стоимости поддержки / внесения изменений что называется "тупо в лоб" (waterfall).
Революционное – в окр. среде, либо в кап.человеке – да, без внешней нужды не возникнет. Нужна принципиально новая парадигма бытия, чтобы произошло некое переосмысление, которое в последствии и приведёт к революции (т.е. закреплению некого становления).
Изюмируя. Чтобы получилось что то отличное от существующего, когда система как в нашем случае зашла в закономерный тупик развития, нужен тотальный сброс и перепрошивка. Иначе застой и деградация.
То есть "до основанья все разрушим" и "мы наш мы новый мир построим" в некоторых случаях оказывается не такой уж поганой идеей с точки зрения развития системы.
Не нужны никакие революции. Если не тратить ресурсы на карго-культ, а правильно распорядиться имеющимися заделами и советским наследством, то любую компанию можно вывести в лидеры (или кратно повысить ее производительность).
Основная проблема не столько в "процессах" или "принципах", сколько в ответе на простой вопрос: "Почему люди работают в компании?"
К сожалению нужны. Эволюция всегда имеет предел.
К сожалению, с глубоким прискорбием, приходится признать, что технологии управления ленивыми, алчными и недалёкими людьми лучше всего развиты на "условном западе". Для эффективного использования советского наследства нужны советские люди на рабочих местах.
Это, как раз, не проблема. Люди работают за сумму материальных (зарплата/премия и т.п.) и нематериальных (выражение общественной значимости типа грамот, значков, участие в конференциях, публикации и т.д.) стимулов. Как только сумма этих стимулов перестаёт устраивать работников предприятие начинает умирать. К сожалению, сейчас к этому добавляется отчуждение от результатов труда, когда сотрудники не понимают как их работа влияет на результаты компании в целом.
Если Вы знаете ответы Ваших сотрудников, то что мешает построить сбалансированную систему управления в Вашей компании?
Зачем Вам революция?
В идеале, надо набор стимулов надо подбирать к каждому сотруднику отдельно. К сожалению при количестве сотрудников более 20 и наличии прослойки (HR/отдел кадров/линейный менеджер) между главой бизнеса и сотрудниками это уже невозможно. Несмотря на внешнее сходство все люди разные и невозможно предположить как то или иное распоряжение пройдёт от условного Олимпа до условного Аида. И пройдёт ли вообще. Это примерно как писать инструкции по эксплуатации или руководящие документы. Никогда не узнаешь что именно придумают люди, которые это читают. Если они, конечно, читают до конца. Есть забавный тренинговый приём: заставить людей передать по цепочке информацию. Так вот уже на 3-5 человеке информация искажается настолько, что в ней не остаётся ничего общего с исходными данными.
Как говорят старшие товарищи, после создания любой организационной структуры люди, её составляющие, стремятся ничего не делать и ни за что не отвечать. Тех, кто хочет работать из этой структуры выдавливают. Поэтому структуру надо менять по мере её порчи. А это, как ни крути, революция. Потому что ломаются налаженные связи и пути прохождения управляющих сигналов. А порчу структуры ещё и установить надо. А для этого надо, периодически, ставить в самый низ засланных казачков. В общем недешёвое это дело, управлять людьми.
Итог: люди являются самым непредсказуемым фактором в любой системе управления. А заместить их роботами на данном уровне технического развития решительно невозможно :-)
З.Ы. И я не руководитель. Я пробовал. У меня нет столько здоровья и морально-волевых качеств, чтобы руководить людьми. Я просто интересуюсь методами и практиками.
Не надо этого делать. Директивное управление работает до определенного момента. В больших компаниях нужны альтернативные подходы. И не нужно пытаться все регламентировать. Особенно в проектном (инженерном) бизнесе.
Есть способы победить "проклятье бюрократии". И это точно не процессная модель PMBoK и не "принципы" нового ISO )))
Революция, как это ни странно, к действенному способу борьбы с бюрократией не относится. Революцию можно устроить, если вы желаете смерти компании ("до основания мы разрушим", а потом придут конкуренты на и отберут у Вас бизнес). Или, если у вас нет конкурентов, то произойдет замена старой бюрократии на новую. И еще не известно, что хуже.
Людей занимающихся творческой (инженерной) деятельностью заменить будет невозможно при любом уровне технического развития. ) Т.к. никакой "искусственный интеллект" не умеет изобретать.
В открытом доступе нет информации (в виде методик) об эффективных системах управления. Т.к. это ключевое конкурентное преимущество, которое дает не только большие деньги, но и большую власть.
Просто так никто публиковать подобные вещи не будет. Небольшим исключением из этого правила является наследие СССР. Но им надо пользоваться очень аккуратно, т.к. разработки тех времен подразумевали совершенно другую культуру. В современных реалиях в исходном виде слабо применимы.
Страницы