Moneyfall taming and other lost secrets of ancient ages
Оригинал взят у vit_r в Moneyfall taming and other lost secrets of ancient ages
Вчера juan-gandhi навёл на необходимость сформулировать словами ещё одну концепцию из тех, что я знаю интуитивно, но остальной народ воспринимает почему-то совсем иначе.
Инженерная проблема - это поиск наилучшего приближения для клубка задач, принципиально не имеющих решения, удовлетворяющего всем заданным условиям.
Попробую перевести на английский.
Engineering is the process of search for an optimal compromise of a tangle of interconnected problems that cannot be solved together by consideration of all given constraints.
(Определение в этой формулировке мне не очень нравится, но с этим уже можно работать. Я сейчас быстро намечу основные контуры. Для понятного описания надо копать слишком глубоко.)
В вульгарной интерпретации отсюда следует известная формула «Быстро, хорошо, дёшево: выберите два из трёх». Реальность гораздо сложнее.
Если принять предложенное определение, первым печальным фактом придётся признать, что мы работаем в зоне высокого риска. Search is not finding. То есть, можно затратить все ресурсы и ничего не найти.
Вторая проблема - проблема планирования.
Знающие люди видят, что предсказание бюджета и сроков по сложности сопоставимо с решением самой проблемы. (Люди не знающие, могут мне верить или не верить, но обсуждать это я сейчас не буду.)
Решается это или банальной магией по подобию «Мы делали подобный проект и затратили X ресурсов за Y времени. Новая проблема более-менее похожа. Накинем десять процентов и запишем в план», или путём последовательных приближений плана на будущее по результатам завершённых этапов (Moneyfall modell).
Третья основная проблема - невозможность человеку со стороны отличить специалиста от балабола.
Практически, это означает принципиальную неуправляемость. Если инженеры приходят к менеджеру и говорят, что им нужно ещё три месяца времени и миллион долларов денег, только человек, хорошо разбирающийся в предмете, поймёт, столкнулись ли люди с принципиальными трудностями, которые они смогут одолеть при выделении дополнительных ресурсов, или же у исполнителей не хватает квалификации сделать элементарные вещи, а своими требованиями они просто откладывают позор на будущее.
Понятно, что с этим надо что-то делать. Напрашивается вариант - набрать квалифицированные кадры и поставить над ними высококвалифицированных менеджеров. Но для этого набирающие должны сами иметь высокую квалификацию. Причём, не какую-нибудь, а в целевой предметной области.
Так работают немецкие частные фирмы выросшие вокруг инженеров старой закалки (пока молодая вдова не вступает в управление и не приглашает выпускников MBA, которые всё эффективно разваливают).
Если у управляющих нет необходимых для управления инженерами знаний и опыта, есть несколько подходов. Они заключаются в работе над словами «by consideration of all given constraints»
Самый распространённый - менеджерский.
Вышеприведённые слова, грубо говоря, определяют качество. Секрет ловкого менеджмента в том, чтобы обрезать его так, чтобы никто не заметил.
В ИТ это происходит сплошь и рядом. Потому что решение виртуальное и большинство ограничений или скрыты от глаз посторонних, или выражаются абстрактными словами, вроде «security, performance, montainability...»
Эффективному управлению мешает только один факт: инженер - это тот, кто отказывается снижать качество, если это снижение принципиально. Причём, отказывается вплоть до увольнения.
По счастью, инженеры - в нынешних корпоративных экосистемах вид вымирающий. Сейчас это можно видеть не только по истории с Фукусимой, где инженерные принципы встали а противоречие с самурайскими (хотя, на соседней станции настоящие инженеры были, и они построили стенку, выдержавшую цунами без проблем). Из последних скандалов хорошо подходят попытка совместить мощность дизеля с экологической чистотой у Фольксвагена или уменьшение размеров батареи с повышением её мощности у Самсунга.
В тех немецких фирмах, с которыми я работал, инженеры в программировании практически вымерли. Механика, электрика и прочие специальности ещё держатся, но на них всё сильнее давит оутсоурсинг в Китай и местные отделы качества.
Вторым подходом превращения инженерных задач в управляемые в основном страдают консультанты.
Они проповедуют, что ограничения бывают мелкие и крупные. Если мелкие отбросить, решаемые задачи становятся не связанными и их можно разложить в иерархические структуры, вполне решаемые с использованием Правильных Подходов и Правильных Тулов. (Обычно консультанты продают тулы, а подходы просто к ним привязывают. Особо наглы просто обучают Правильно Думать.)
На банальных примерах это работает великолепно. Что и объясняет повсеместное распространение этой заразы.
Проблема в том, что в реальных условиях мы не можем определить силу связей и важность ограничений до того момента, пока мы не исследовали проблему полностью до мельчайших деталей. А потом оказывается, что в великолепно организованном процессе с высочайшей интенсивностью контроля качества копеечное ограничение приводит к самоподрыву дорогущей ракеты на тридцать четвёртой секунде полёта.
Консультанты не видят тут принципиальной проблемы. Вместо этого они берут случай на вооружение и используют для рекламы Ещё Более Правильных Подходов и Ещё Более Правильных Тулов.
Я не буду тут пересказывать многочисленные посты в этом блоге и указывать пальцем на кое-кого, но те, кто здесь не впервые, могут добавить этот аспект к уже известной им информации.
Третьим типом упрощения болеют теоретики. В принципе, это технические специалисты, не имеющие достаточного опыта общения с реальной жизнью. Большинство программистов относится к этой категории.
Тут игнорируются не технические ограничения, а банальные характеристики мира.
Профессора компьютерных наук разрабатывают методы, работающие только в условиях бездонных бюджетов и неопределённых сроков. Ответственные за техзадание исходят из предположения, что все пользователи найдут время, чтобы выучить внутреннее строение их программ. Кодировщики считают, что это они должны указывать менеджерам, как тем следует ими управлять. Создатели языков исходят из того, что все проникнутся теорией категорий. Архитекторы (компьютерные) создают систему, действующую в области математических абстракций, а не на определённом железе с определённой разрядностью и ограниченным быстродействием. Отдел качества считает, что вся приходящая информация корректна и полна. Организаторы внутрифирменных процессов пишут правила для розовых пони, чьё единственное предназначение - заполнение формуляров о работе, сделанной непонятно кем...
Нельзя сказать, что все перечисленные категории - дураки. Наоборот, это высококлассные специалисты. Просто они не могут заглянуть за край тарелки. А, если могут выглянуть из своей, не видят, что у соседних за краями тоже есть что-то важное.
По сути дела, проблема не в отсутствии правильных решений. Само определение говорит, что их попросту нет.
Каким образом объяснить, как с этим жить, я ещё сам не вполне определился. Не столько по смыслу (это я более-менее понимаю уже лет двадцать), сколько по форме и методике объяснения.
Плюс, есть достаточно мощные экономические предпосылки для вымирания культуры инженеров.
Углубляться в них не буду, лучше добавлю про мотивацию, с которой всё началось.
Практически, работа инженера - это достаточно занудный монотонный труд, полный разочарований. Принципиальная недостижимость идеального результата вызывает общую неудовлетворённость. Сложность задач всегда превышает возможности, вызывая комплекс неполноценности. Результаты обычно отложены в будущее. Редко когда на месяцы, чаще на года, иногда на десятилетия как у людей, запустивших зонд к комете и увидевших её фотографии через много лет.
Тут работают или гордость за результат, или гордость за профессию, или материальное поощрение и хороший коллектив. (У инженеров общение с коллегами обычно на порядок лучше того, что типично в среде программистов.) Бывает радость от внезапных озарений и экстаз от найденных решений, но они достаточно редки среди серых будней.
При этом, любая из альтернатив инженерного подхода предоставляет гораздо больше счастливых моментов, снижает планку до уровня возможностей, позволяя легко переходить в экзальтированное состояние flow, даёт лучшие показатели по всем поверхностным параметрам, позволяет легко рисовать отчёты и даёт больше возможности для самовосхваления. (Последнее, кстати, привело к снижению процента баб в айти. В отличии от мужиков, не любят они писунами мерятся.)
Короче, любой отход от инженерных методов повышает мотивацию. Правда, при условии, что человек или игнорирует, или не знает реальное качество производимого им продукта.
Вчера juan-gandhi навёл на необходимость сформулировать словами ещё одну концепцию из тех, что я знаю интуитивно, но остальной народ воспринимает почему-то совсем иначе.
Инженерная проблема - это поиск наилучшего приближения для клубка задач, принципиально не имеющих решения, удовлетворяющего всем заданным условиям.
Попробую перевести на английский.
Engineering is the process of search for an optimal compromise of a tangle of interconnected problems that cannot be solved together by consideration of all given constraints.
(Определение в этой формулировке мне не очень нравится, но с этим уже можно работать. Я сейчас быстро намечу основные контуры. Для понятного описания надо копать слишком глубоко.)
В вульгарной интерпретации отсюда следует известная формула «Быстро, хорошо, дёшево: выберите два из трёх». Реальность гораздо сложнее.
Если принять предложенное определение, первым печальным фактом придётся признать, что мы работаем в зоне высокого риска. Search is not finding. То есть, можно затратить все ресурсы и ничего не найти.
Вторая проблема - проблема планирования.
Знающие люди видят, что предсказание бюджета и сроков по сложности сопоставимо с решением самой проблемы. (Люди не знающие, могут мне верить или не верить, но обсуждать это я сейчас не буду.)
Решается это или банальной магией по подобию «Мы делали подобный проект и затратили X ресурсов за Y времени. Новая проблема более-менее похожа. Накинем десять процентов и запишем в план», или путём последовательных приближений плана на будущее по результатам завершённых этапов (Moneyfall modell).
Третья основная проблема - невозможность человеку со стороны отличить специалиста от балабола.
Практически, это означает принципиальную неуправляемость. Если инженеры приходят к менеджеру и говорят, что им нужно ещё три месяца времени и миллион долларов денег, только человек, хорошо разбирающийся в предмете, поймёт, столкнулись ли люди с принципиальными трудностями, которые они смогут одолеть при выделении дополнительных ресурсов, или же у исполнителей не хватает квалификации сделать элементарные вещи, а своими требованиями они просто откладывают позор на будущее.
Понятно, что с этим надо что-то делать. Напрашивается вариант - набрать квалифицированные кадры и поставить над ними высококвалифицированных менеджеров. Но для этого набирающие должны сами иметь высокую квалификацию. Причём, не какую-нибудь, а в целевой предметной области.
Так работают немецкие частные фирмы выросшие вокруг инженеров старой закалки (пока молодая вдова не вступает в управление и не приглашает выпускников MBA, которые всё эффективно разваливают).
Если у управляющих нет необходимых для управления инженерами знаний и опыта, есть несколько подходов. Они заключаются в работе над словами «by consideration of all given constraints»
Самый распространённый - менеджерский.
Вышеприведённые слова, грубо говоря, определяют качество. Секрет ловкого менеджмента в том, чтобы обрезать его так, чтобы никто не заметил.
В ИТ это происходит сплошь и рядом. Потому что решение виртуальное и большинство ограничений или скрыты от глаз посторонних, или выражаются абстрактными словами, вроде «security, performance, montainability...»
Эффективному управлению мешает только один факт: инженер - это тот, кто отказывается снижать качество, если это снижение принципиально. Причём, отказывается вплоть до увольнения.
По счастью, инженеры - в нынешних корпоративных экосистемах вид вымирающий. Сейчас это можно видеть не только по истории с Фукусимой, где инженерные принципы встали а противоречие с самурайскими (хотя, на соседней станции настоящие инженеры были, и они построили стенку, выдержавшую цунами без проблем). Из последних скандалов хорошо подходят попытка совместить мощность дизеля с экологической чистотой у Фольксвагена или уменьшение размеров батареи с повышением её мощности у Самсунга.
В тех немецких фирмах, с которыми я работал, инженеры в программировании практически вымерли. Механика, электрика и прочие специальности ещё держатся, но на них всё сильнее давит оутсоурсинг в Китай и местные отделы качества.
Вторым подходом превращения инженерных задач в управляемые в основном страдают консультанты.
Они проповедуют, что ограничения бывают мелкие и крупные. Если мелкие отбросить, решаемые задачи становятся не связанными и их можно разложить в иерархические структуры, вполне решаемые с использованием Правильных Подходов и Правильных Тулов. (Обычно консультанты продают тулы, а подходы просто к ним привязывают. Особо наглы просто обучают Правильно Думать.)
На банальных примерах это работает великолепно. Что и объясняет повсеместное распространение этой заразы.
Проблема в том, что в реальных условиях мы не можем определить силу связей и важность ограничений до того момента, пока мы не исследовали проблему полностью до мельчайших деталей. А потом оказывается, что в великолепно организованном процессе с высочайшей интенсивностью контроля качества копеечное ограничение приводит к самоподрыву дорогущей ракеты на тридцать четвёртой секунде полёта.
Консультанты не видят тут принципиальной проблемы. Вместо этого они берут случай на вооружение и используют для рекламы Ещё Более Правильных Подходов и Ещё Более Правильных Тулов.
Я не буду тут пересказывать многочисленные посты в этом блоге и указывать пальцем на кое-кого, но те, кто здесь не впервые, могут добавить этот аспект к уже известной им информации.
Третьим типом упрощения болеют теоретики. В принципе, это технические специалисты, не имеющие достаточного опыта общения с реальной жизнью. Большинство программистов относится к этой категории.
Тут игнорируются не технические ограничения, а банальные характеристики мира.
Профессора компьютерных наук разрабатывают методы, работающие только в условиях бездонных бюджетов и неопределённых сроков. Ответственные за техзадание исходят из предположения, что все пользователи найдут время, чтобы выучить внутреннее строение их программ. Кодировщики считают, что это они должны указывать менеджерам, как тем следует ими управлять. Создатели языков исходят из того, что все проникнутся теорией категорий. Архитекторы (компьютерные) создают систему, действующую в области математических абстракций, а не на определённом железе с определённой разрядностью и ограниченным быстродействием. Отдел качества считает, что вся приходящая информация корректна и полна. Организаторы внутрифирменных процессов пишут правила для розовых пони, чьё единственное предназначение - заполнение формуляров о работе, сделанной непонятно кем...
Нельзя сказать, что все перечисленные категории - дураки. Наоборот, это высококлассные специалисты. Просто они не могут заглянуть за край тарелки. А, если могут выглянуть из своей, не видят, что у соседних за краями тоже есть что-то важное.
По сути дела, проблема не в отсутствии правильных решений. Само определение говорит, что их попросту нет.
Каким образом объяснить, как с этим жить, я ещё сам не вполне определился. Не столько по смыслу (это я более-менее понимаю уже лет двадцать), сколько по форме и методике объяснения.
Плюс, есть достаточно мощные экономические предпосылки для вымирания культуры инженеров.
Углубляться в них не буду, лучше добавлю про мотивацию, с которой всё началось.
Практически, работа инженера - это достаточно занудный монотонный труд, полный разочарований. Принципиальная недостижимость идеального результата вызывает общую неудовлетворённость. Сложность задач всегда превышает возможности, вызывая комплекс неполноценности. Результаты обычно отложены в будущее. Редко когда на месяцы, чаще на года, иногда на десятилетия как у людей, запустивших зонд к комете и увидевших её фотографии через много лет.
Тут работают или гордость за результат, или гордость за профессию, или материальное поощрение и хороший коллектив. (У инженеров общение с коллегами обычно на порядок лучше того, что типично в среде программистов.) Бывает радость от внезапных озарений и экстаз от найденных решений, но они достаточно редки среди серых будней.
При этом, любая из альтернатив инженерного подхода предоставляет гораздо больше счастливых моментов, снижает планку до уровня возможностей, позволяя легко переходить в экзальтированное состояние flow, даёт лучшие показатели по всем поверхностным параметрам, позволяет легко рисовать отчёты и даёт больше возможности для самовосхваления. (Последнее, кстати, привело к снижению процента баб в айти. В отличии от мужиков, не любят они писунами мерятся.)
Короче, любой отход от инженерных методов повышает мотивацию. Правда, при условии, что человек или игнорирует, или не знает реальное качество производимого им продукта.