Как надо?
Это очень странно, и вообще не интуитивно, но лучше всех описал работающий подход к strategic execution автор "экстремального программирования" Кент Бек. Скажи мне это кто двадцать лет назад — я бы рассмеялся ему в лицо. Опишем его тезисно.
1. Для начала — надо осознать, что вы не Ванга, и вы понятия не имеете куда заведет вас будущее. Что означает одно — переделки неизбежны. Не знаешь, что делать — делай как можно проще. Это единственный работающий способ удешевить неизбежную переделку; чем меньше написал — тем меньше переделывать. Чем проще написал — тем проще.
2. Попытки нагородить невъебических абстракций защитившись от неизвестного будущего увеличивают стоимость этих переделок, и цену которая платится в начале. Как и попытки сразу написать функциональность, которая не нужна сейчас, но "точно понадобится в будущем". Как и попытки сразу сделать, чтобы оно работало быстро. You ain't gonna need it.
3. YAGNI это не столько не делать впрок то, что сейчас не нужно. Главное в нем, это инкрементальный дизайн и рефакторинг, являющийся частью каждой задачи. То есть, вы не спрашиваете большого дядю — "соизволит ли сэр выделить время на рефакторинг". Будучи взрослым, вы принимаете это решение сами, и каждый день. Следуя YAGNI, инженер не оперирует концепцией "технического долга" в принципе. Она лишена какого-либо смысла и пользы. Вместо этого, он вводит абстракции по мере необходимости, тут же проверяя их реализацией.
Дизайн-рефакторинг, выполняемый рутинно и постоянно, не склонен приводить вас к ситуации, когда переделка слишком дорога, и отложенный дизайн никогда не рассматривается как "долг". Почему? You ain't gonna need it, какой это долг.
Описанная "контролируемая итерация" возможна только в случае, когда инженеры участвуют в принятии ключевых решений в планировании. План разработки — это архитектура, растянутая по времени. Другими словами, если нет интегрированного подхода к управлению, описанного в этом посте, и оргструктура изолирует компетентных инженеров от принятия ключевых решений — вы попросту не сможете полноценно применить YAGNI.
Это очень странно, и вообще не интуитивно, но лучше всех описал работающий подход к strategic execution автор "экстремального программирования" Кент Бек. Скажи мне это кто двадцать лет назад — я бы рассмеялся ему в лицо. Опишем его тезисно.
1. Для начала — надо осознать, что вы не Ванга, и вы понятия не имеете куда заведет вас будущее. Что означает одно — переделки неизбежны. Не знаешь, что делать — делай как можно проще. Это единственный работающий способ удешевить неизбежную переделку; чем меньше написал — тем меньше переделывать. Чем проще написал — тем проще.
2. Попытки нагородить невъебических абстракций защитившись от неизвестного будущего увеличивают стоимость этих переделок, и цену которая платится в начале. Как и попытки сразу написать функциональность, которая не нужна сейчас, но "точно понадобится в будущем". Как и попытки сразу сделать, чтобы оно работало быстро. You ain't gonna need it.
3. YAGNI это не столько не делать впрок то, что сейчас не нужно. Главное в нем, это инкрементальный дизайн и рефакторинг, являющийся частью каждой задачи. То есть, вы не спрашиваете большого дядю — "соизволит ли сэр выделить время на рефакторинг". Будучи взрослым, вы принимаете это решение сами, и каждый день. Следуя YAGNI, инженер не оперирует концепцией "технического долга" в принципе. Она лишена какого-либо смысла и пользы. Вместо этого, он вводит абстракции по мере необходимости, тут же проверяя их реализацией.
Дизайн-рефакторинг, выполняемый рутинно и постоянно, не склонен приводить вас к ситуации, когда переделка слишком дорога, и отложенный дизайн никогда не рассматривается как "долг". Почему? You ain't gonna need it, какой это долг.
Описанная "контролируемая итерация" возможна только в случае, когда инженеры участвуют в принятии ключевых решений в планировании. План разработки — это архитектура, растянутая по времени. Другими словами, если нет интегрированного подхода к управлению, описанного в этом посте, и оргструктура изолирует компетентных инженеров от принятия ключевых решений — вы попросту не сможете полноценно применить YAGNI.
Telegram
Gaperton's Tech Corner
Кароч, на макро-уровне суть strategic execution состоит в том, что три вещи должны находится в балансе.
1) Портфель стратегических инициатив. Для того, чтобы их иметь, топ-менеджмент должен иметь видение куда в принципе идет индустрия, понимать слабые места…
1) Портфель стратегических инициатив. Для того, чтобы их иметь, топ-менеджмент должен иметь видение куда в принципе идет индустрия, понимать слабые места…
👆Осталось только паттерны оргструктуры описать, при которых эта философия описанная в постах выше превратится из теории в практику. И они нам известны :)
Еще, можно показать, как YAGNI применяется не на микроуровне а на уровне плана проекта. Это трудно.
Ну, и описать трассировку целей из которых вообще костяк плана делается.
Попробуем, хуле. Но потом. #техническийдолг
Еще, можно показать, как YAGNI применяется не на микроуровне а на уровне плана проекта. Это трудно.
Ну, и описать трассировку целей из которых вообще костяк плана делается.
Попробуем, хуле. Но потом. #техническийдолг
А пока — перевод блог-поста случайного автора. Которому повезло общаться с Кентом Беком лично. #мопеднемой
RRF and YAGNI in Practice: A Lesson with Kent Beck — Andrew W. Lee
У Кента есть своя система подхода к разработке программного обеспечения. Он называет ее RRF, что расшифровывается как 1) сделай это работающим, 2) сделай это правильно, а затем 3) сделай это быстрым. Келли Саттон, еще один инженер компании Gusto, прекрасно раскрывает суть RRF в своем посте о значительном сокращении времени сборки для CI (хотя он называет это WRF).
"Заставить работать" означает выпустить что-то, что не ломается. Код может быть уродливым и сложным для понимания, но мы предоставляем ценность для клиента, и у нас есть тесты, которые дают нам уверенность. Без тестов трудно ответить на вопрос "Работает ли это?".
"Сделать все правильно" означает, что код можно поддерживать и легко изменять. Его могут читать люди, а не только компьютеры. Новые инженеры могут легко добавить функциональность в код. При возникновении дефекта его легко выявить и исправить.
Наконец, мы "делаем его быстрым". Мы делаем код производительным.
💬 Можно думать об RRF как о шаблоне плана в три этапа, каждый из которых подразумевает рефакторинг. Если применять его на среднем и верхнем уровне — вас ждет фиаско. У вас непременно образуется "технический долг" :) R и R должны делаться микроитерациями. С откладыванием F на макро-уровне тоже есть нюансы — вся архитектура может развалиться. Для макроуровня нужен подход чуть сложнее, чем это.
Этот фреймворк опирается на смирение. Как? Потому что нам хочется верить, что мы умны, и это так, но мы недостаточно умны, чтобы решать несколько сложных задач одновременно. Когда мы пытаемся это сделать, мы, как правило, придумываем некачественные решения - или, как в моем случае, создаем ненужный стресс.
💬 Вот. 👆Вот тут он прав. Этот фреймворк говорит — избегай premature design, и premature optimization. Он не говорит — сначала пиши тормозное говно. Он говорит — сначала реши задачу по-простому. Реши. Потом правильно. Потом быстро.
Я только что присоединился к новой команде, которая работала над запуском нового продукта. Предстояло многое сделать, и каждый инженер работал над независимыми проектами. Будучи новичком, я хотел произвести впечатление на свою команду и руководителя.
Мой первый проект заключался в создании системы обмена лог-файлами со сторонним партнером, чтобы их системы могли получать данные. Руководитель группы разработал техническое задание, и в мои обязанности входило разработать проект и реализовать его. Предложенный мной проект системы был принят, и я приступил к работе.
Создать модели ActiveRecord и миграции было достаточно просто. Но когда дело дошло до реализации классов и заданий для генерации лог-файлов, я застрял, просто сидя за своим столом и глядя на пустой файл в RubyMine. На высоком уровне я знал, как это должно работать, а также входы и выходы. Но я был заморожен, пытаясь продумать, как реализовать это наиболее оптимально. Я начинал писать несколько строк, спрашивал себя, оптимально ли это, затем удалял их и начинал сначала.
И так я продолжал думать. Я все пытался найти способ реализовать это: чтобы это было оптимизировано для производительности с самого начала, чтобы классы и API имели смысл, и чтобы это работало. Но я был заблокирован.
Я встретился с Кентом на коуч-сессии. Я рассказал ему о проекте, о том, что я пытался сделать и где я застрял - хотел реализовать систему, которая работала бы, но при этом была бы производительной.
И он сказал: "YAGNI"
"Что?"
"Тебе это не понадобится - все эти производительные штучки".
"Но Кент..."
"Когда тебе это понадобится, ты сможешь к этому вернуться. Требования изменятся. Так что сейчас тебе это не нужно".
Поэтому сначала я решил запустить его и сосредоточиться только на этом. Вначале это было непросто, потому что работа в таком режиме казалась неинтуитивной. Но потом я его запустил. После этого я привел его в порядок и рефакторизовал, чтобы он выглядел чистым. Потом я закончил, хотя в то время он все еще казался незавершенным.
(продолжение в комментариях)
RRF and YAGNI in Practice: A Lesson with Kent Beck — Andrew W. Lee
У Кента есть своя система подхода к разработке программного обеспечения. Он называет ее RRF, что расшифровывается как 1) сделай это работающим, 2) сделай это правильно, а затем 3) сделай это быстрым. Келли Саттон, еще один инженер компании Gusto, прекрасно раскрывает суть RRF в своем посте о значительном сокращении времени сборки для CI (хотя он называет это WRF).
"Заставить работать" означает выпустить что-то, что не ломается. Код может быть уродливым и сложным для понимания, но мы предоставляем ценность для клиента, и у нас есть тесты, которые дают нам уверенность. Без тестов трудно ответить на вопрос "Работает ли это?".
"Сделать все правильно" означает, что код можно поддерживать и легко изменять. Его могут читать люди, а не только компьютеры. Новые инженеры могут легко добавить функциональность в код. При возникновении дефекта его легко выявить и исправить.
Наконец, мы "делаем его быстрым". Мы делаем код производительным.
💬 Можно думать об RRF как о шаблоне плана в три этапа, каждый из которых подразумевает рефакторинг. Если применять его на среднем и верхнем уровне — вас ждет фиаско. У вас непременно образуется "технический долг" :) R и R должны делаться микроитерациями. С откладыванием F на макро-уровне тоже есть нюансы — вся архитектура может развалиться. Для макроуровня нужен подход чуть сложнее, чем это.
Этот фреймворк опирается на смирение. Как? Потому что нам хочется верить, что мы умны, и это так, но мы недостаточно умны, чтобы решать несколько сложных задач одновременно. Когда мы пытаемся это сделать, мы, как правило, придумываем некачественные решения - или, как в моем случае, создаем ненужный стресс.
💬 Вот. 👆Вот тут он прав. Этот фреймворк говорит — избегай premature design, и premature optimization. Он не говорит — сначала пиши тормозное говно. Он говорит — сначала реши задачу по-простому. Реши. Потом правильно. Потом быстро.
Я только что присоединился к новой команде, которая работала над запуском нового продукта. Предстояло многое сделать, и каждый инженер работал над независимыми проектами. Будучи новичком, я хотел произвести впечатление на свою команду и руководителя.
Мой первый проект заключался в создании системы обмена лог-файлами со сторонним партнером, чтобы их системы могли получать данные. Руководитель группы разработал техническое задание, и в мои обязанности входило разработать проект и реализовать его. Предложенный мной проект системы был принят, и я приступил к работе.
Создать модели ActiveRecord и миграции было достаточно просто. Но когда дело дошло до реализации классов и заданий для генерации лог-файлов, я застрял, просто сидя за своим столом и глядя на пустой файл в RubyMine. На высоком уровне я знал, как это должно работать, а также входы и выходы. Но я был заморожен, пытаясь продумать, как реализовать это наиболее оптимально. Я начинал писать несколько строк, спрашивал себя, оптимально ли это, затем удалял их и начинал сначала.
И так я продолжал думать. Я все пытался найти способ реализовать это: чтобы это было оптимизировано для производительности с самого начала, чтобы классы и API имели смысл, и чтобы это работало. Но я был заблокирован.
Я встретился с Кентом на коуч-сессии. Я рассказал ему о проекте, о том, что я пытался сделать и где я застрял - хотел реализовать систему, которая работала бы, но при этом была бы производительной.
И он сказал: "YAGNI"
"Что?"
"Тебе это не понадобится - все эти производительные штучки".
"Но Кент..."
"Когда тебе это понадобится, ты сможешь к этому вернуться. Требования изменятся. Так что сейчас тебе это не нужно".
Поэтому сначала я решил запустить его и сосредоточиться только на этом. Вначале это было непросто, потому что работа в таком режиме казалась неинтуитивной. Но потом я его запустил. После этого я привел его в порядок и рефакторизовал, чтобы он выглядел чистым. Потом я закончил, хотя в то время он все еще казался незавершенным.
(продолжение в комментариях)
🫁 Введение в оргструктуры для инженеров
Да какая нахер разница, что там за оргструктура, скажете вы. И будете в корне неправы. Для начала, поймем откуда берется проблема, и в чем ее природа. Это важно, потому что мы собираемся ввести то, что в литературе практически не встречается. Системный метод анализа структур.
Когда вы работаете в одиночку, никакая "оргструктура" вам очевидно не нужна. Вы можете выполнять какой угодно процесс, и у вас не будет проблем при переключении между его шагами, потому, что состояние хранится в вашей памяти, и вам не надо объяснять самому себе что и как делать.
Когда вы работаете в паре, это почти то же самое что и работать в одиночку. Почему? Общаясь с партнером, легко добиться полной синхронизации состояния мозгов. Это как кластер из двух компьютеров с общей памятью.
Когда вас трое, уже начинаются проблемы. Синхронизация начинает давать сбои, и становится заметно, что общей памяти у вас нет. У каждого она своя, и вы пытаетесь ее синхронизировать обмениваясь сообщениями. И третий — он все время лагает. Тройка — неустойчивая группа, которая часто находится в состоянии 2+1.
А когда вас шестеро, все становится интереснее. Включаются социальные механизмы, которые работают независимо от вас и ваших знаний о них. Группа из шести уже умеет вырабатывать нормы общения, выдвигать временного лидера, разбиваться на конфигурации (2+2+2, 3+3), и все это умеет происходить само, в полностью автоматическом режиме. 4, 5, и 6 человек формируют устойчивые группы, которые внутри распадаются на пары и тройки. Группы большего размера структурируют свое общение таким образом, что оно в основном происходит в рамках групп 2-6 человек.
Так как общей памяти и чтения мыслей у людей нет, и они синхронизируются обмениваясь сообщениями, любой коллектив самоорганизуется в структуру из ячеек внутри которых общение более активно, и вырабатывает групповые нормы (протоколы) этого общения, хотите вы этого, или нет. Если вы не создадите оргструктуру, она создаст сама себя.
За нижнюю границу размеров малой группы большинство специалистов принимает три человека, поскольку в группе из двух человек — диаде— групповые социально-психологические феномены протекают особым образом. Верхняя граница малой группы определяется ее качественными признаками и обычно не превышает 20-30 человек. Оптимальный размер малой группы зависит от характера выполняемой совместной деятельности и находится в пределах 5—12 человек. В меньших по размеру группах скорее возникает феномен социального пресыщения, группы большего размера легче распадаются на более мелкие микрогруппы, в рамках которых индивиды связаны более тесными контактами. В этой связи принято выделять группы первичные, то есть наименьшие по размеру и далее не делимые общности, и вторичные группы, формально представляющие собой единые общности, но включающие в себя несколько первичных групп.
В этом месте мы прекратим углубляться в социологию малых групп, и вернемся к Strategic Execution. Нас групповая динамика интересует в очень узком смысле — мы должны организовать большую группу людей таким образом, чтобы она эффективно достигала нужных нам общих целей.
Стенфордский Strategic Execution Framework выделяет структуру, что есть совокупность формальных групп и норм/протоколов общения (процессов), и культуру, что есть неформальные нормы поведения и ценности. Структура-культура образует пару, определяющую способность организации исполнять стратегию, которую называют природой организации ("Nature").
Я предлагаю очень простой взгляд на пару структуру-культуру. Смотрите на формальные и неформальные нормы, правила, обязанности, и полномочия как на набор стимулов, вознаграждающих и наказывающих определенное поведение участников организации. Именно этот подход позволяет анализировать оргструктуры. И да, мы будем придерживаться терминологии SEF. "Структура" — это не набор квадратиков. Это совокупность всех формальных правил структурирующих общение. "Культура" — тоже правила, но неформальные. И то и другое — создает стимулы, приводящие организацию в движение. Именно они вас и интересуют.
Да какая нахер разница, что там за оргструктура, скажете вы. И будете в корне неправы. Для начала, поймем откуда берется проблема, и в чем ее природа. Это важно, потому что мы собираемся ввести то, что в литературе практически не встречается. Системный метод анализа структур.
Когда вы работаете в одиночку, никакая "оргструктура" вам очевидно не нужна. Вы можете выполнять какой угодно процесс, и у вас не будет проблем при переключении между его шагами, потому, что состояние хранится в вашей памяти, и вам не надо объяснять самому себе что и как делать.
Когда вы работаете в паре, это почти то же самое что и работать в одиночку. Почему? Общаясь с партнером, легко добиться полной синхронизации состояния мозгов. Это как кластер из двух компьютеров с общей памятью.
Когда вас трое, уже начинаются проблемы. Синхронизация начинает давать сбои, и становится заметно, что общей памяти у вас нет. У каждого она своя, и вы пытаетесь ее синхронизировать обмениваясь сообщениями. И третий — он все время лагает. Тройка — неустойчивая группа, которая часто находится в состоянии 2+1.
А когда вас шестеро, все становится интереснее. Включаются социальные механизмы, которые работают независимо от вас и ваших знаний о них. Группа из шести уже умеет вырабатывать нормы общения, выдвигать временного лидера, разбиваться на конфигурации (2+2+2, 3+3), и все это умеет происходить само, в полностью автоматическом режиме. 4, 5, и 6 человек формируют устойчивые группы, которые внутри распадаются на пары и тройки. Группы большего размера структурируют свое общение таким образом, что оно в основном происходит в рамках групп 2-6 человек.
Так как общей памяти и чтения мыслей у людей нет, и они синхронизируются обмениваясь сообщениями, любой коллектив самоорганизуется в структуру из ячеек внутри которых общение более активно, и вырабатывает групповые нормы (протоколы) этого общения, хотите вы этого, или нет. Если вы не создадите оргструктуру, она создаст сама себя.
За нижнюю границу размеров малой группы большинство специалистов принимает три человека, поскольку в группе из двух человек — диаде— групповые социально-психологические феномены протекают особым образом. Верхняя граница малой группы определяется ее качественными признаками и обычно не превышает 20-30 человек. Оптимальный размер малой группы зависит от характера выполняемой совместной деятельности и находится в пределах 5—12 человек. В меньших по размеру группах скорее возникает феномен социального пресыщения, группы большего размера легче распадаются на более мелкие микрогруппы, в рамках которых индивиды связаны более тесными контактами. В этой связи принято выделять группы первичные, то есть наименьшие по размеру и далее не делимые общности, и вторичные группы, формально представляющие собой единые общности, но включающие в себя несколько первичных групп.
В этом месте мы прекратим углубляться в социологию малых групп, и вернемся к Strategic Execution. Нас групповая динамика интересует в очень узком смысле — мы должны организовать большую группу людей таким образом, чтобы она эффективно достигала нужных нам общих целей.
Стенфордский Strategic Execution Framework выделяет структуру, что есть совокупность формальных групп и норм/протоколов общения (процессов), и культуру, что есть неформальные нормы поведения и ценности. Структура-культура образует пару, определяющую способность организации исполнять стратегию, которую называют природой организации ("Nature").
Я предлагаю очень простой взгляд на пару структуру-культуру. Смотрите на формальные и неформальные нормы, правила, обязанности, и полномочия как на набор стимулов, вознаграждающих и наказывающих определенное поведение участников организации. Именно этот подход позволяет анализировать оргструктуры. И да, мы будем придерживаться терминологии SEF. "Структура" — это не набор квадратиков. Это совокупность всех формальных правил структурирующих общение. "Культура" — тоже правила, но неформальные. И то и другое — создает стимулы, приводящие организацию в движение. Именно они вас и интересуют.
❓Справка. Что такое Strategic Execution Framework
Это вот такая модель 👆, которая увязывает воедино разные механизмы организации, с целью показать как оно работает. Она являлась центральной моделью Стенфордской программы Advanced Project Management (я это в свою очередь знаю потому, что Stanford Certified Project Manager)
Глядя на эту картинку, вы скорее всего не найдете в ней смысла. Это нормально. Там много шестеренок, и это требует объяснения. Волноваться не надо — ее понимание это бонус, который ни необходим, ни достаточен. Модель — очень крута, как общий фреймворк размышлений об организационном поведении. Но фокус на этой модели скорее полезен для булшытинга, что не входит в наши намерения.
🤗 Веселое задание. Найдите на картинке пару структура-культура из предыдущего поста.
🤔 Нет у вас никакой стратегии, если ее пункты не выражены в виде портфеля проектов и программ, над которыми вы работаете. Найдите, как это показано в диаграмме.
И я сразу скажу в чем ее слабое место если мы говорим о разработке софта. В ней отсутствует архитектура. Которая, во первых, связана со структурой через Conway's Law [1], и может как помогать реализации портфеля проектов (Portfolio), так и мешать ему. Слишком важный фактор чтобы его игнорировать.
Мы исправим этот недостаток SEF. Собственно, уже начали.
[1] Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
— Melvin E. Conway
Это вот такая модель 👆, которая увязывает воедино разные механизмы организации, с целью показать как оно работает. Она являлась центральной моделью Стенфордской программы Advanced Project Management (я это в свою очередь знаю потому, что Stanford Certified Project Manager)
Глядя на эту картинку, вы скорее всего не найдете в ней смысла. Это нормально. Там много шестеренок, и это требует объяснения. Волноваться не надо — ее понимание это бонус, который ни необходим, ни достаточен. Модель — очень крута, как общий фреймворк размышлений об организационном поведении. Но фокус на этой модели скорее полезен для булшытинга, что не входит в наши намерения.
🤗 Веселое задание. Найдите на картинке пару структура-культура из предыдущего поста.
И я сразу скажу в чем ее слабое место если мы говорим о разработке софта. В ней отсутствует архитектура. Которая, во первых, связана со структурой через Conway's Law [1], и может как помогать реализации портфеля проектов (Portfolio), так и мешать ему. Слишком важный фактор чтобы его игнорировать.
Мы исправим этот недостаток SEF. Собственно, уже начали.
[1] Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
— Melvin E. Conway
Please open Telegram to view this post
VIEW IN TELEGRAM
Еще одна концепция, которая нам понадобится для анализа оргструктур — это трение. Этот термин придумал Клаузевиц в 19 веке, описав ее в своем труде "О войне" (интересующимся рекомендую прочитать введение, это познавательно; но большого значения этому труду придавать не надо). Удивляться "военному" не надо. Подход, который мы применяем — это синтез организационного поведения, "экономического" взгляда на систему как набор стимулов, анализ потоков информации, и принципов военной школы управления.
Если реальное бытие войны отличается от основной ее идеи воздействием политики, то для объяснения расхождения замысла с исполнением в боевых действиях Клаузевиц устанавливает понятие трения. Чем менее сработался сложный механизм армии, тем сильнее трение. Война представляет своего рода плотную среду, в которой достигнуть цели можно лишь при добавочном усилии. И чем войска менее втянуты в войну, тем сильнее трение, и тем большие недолеты в каждом отдельном случае дают предпринимаемые нами действия.
Под "трением" в широком смысле Клаузевиц понимал сопротивление организации как системы выполнению замысла руководителя. В преодолении "трения" он видел главную задачу командира. Ну, типа, организация — это такой механизм, и в нем возникает трение.
Нас "трение" интересует как свойство пары структура-культура, мешающее стратегическому исполнению. Мы будем искать причины возникновения "трения", и структурные подходы чтобы его снизить.
Please open Telegram to view this post
VIEW IN TELEGRAM
🧐 Почему все понимают структуры неправильно
С социальной механикой прям беда — наши мозги устроены таким образом, чтобы не замечать ее глядя на нее в упор. Остановимся на cognitive bias, который в данном случае мешает танцору, и затем выдвинем контринтуитивный тезис.
Фундамента́льная оши́бка атрибу́ции (англ. fundamental attribution error) — понятие в социальной психологии, обозначающее переоценку личностных и недооценку обстоятельственных причин при интерпретации поведения человека[1].
Это склонность человека объяснять поведение других их индивидуальными особенностями, а своё поведение — ситуацией, внешними обстоятельствами. Термин был предложен в 1977 году американским социальным психологом Ли Россом[en][2].
Так вот, ребятки. Мы склонны считать, что индивидуально-психологические особенности работников что-то решают. На это валят всех собак. Вокруг этого строят найм. На самом деле, еще ранние эксперименты по организационному поведению установили, что это не так. Социальные факторы доминируют над индивидуально-психологическими в организационном контексте. Но благодаря "фундаментальной ошибке атрибуции", мы этого в упор не видим.
Пара структура-культура влияет на конфликты, трение, мотивацию, и прочие аспекты организационного поведения гораздо сильнее, чем личные качества сотрудников.
Так что можете не трудиться, тщательно подбирая сотрудников чтобы они "подходили к культуре организации". Это лютый, бешеный антинаучный бред.
На самом деле, ваша корпоративная культура определяется в конечном счете всего двумя вещами. За что вы нанимаете (продвигаете). И за что вы увольняете (наказываете). То есть — социальными стимулами. В широком смысле — расклад обязанностей-полномочий уже задает стимулы, не только поступки как таковые. А люди — они скоты крайне адаптивные. Культура пластична, и психически здоровый человек довольно быстро приспосабливается к чему угодно. И культура — это совсем не то, что вы говорите. Это то, что люди считывают между строк (мы все прекрасно умеем это делать от природы не отдавая себе в этом отчета).
Хватит страдать хуйней, и доебываться к людям, в общем. Поправьте вместо этого забор, то есть — вашу структуру. От нее, на самом деле, все ваши проблемы.
С социальной механикой прям беда — наши мозги устроены таким образом, чтобы не замечать ее глядя на нее в упор. Остановимся на cognitive bias, который в данном случае мешает танцору, и затем выдвинем контринтуитивный тезис.
Фундамента́льная оши́бка атрибу́ции (англ. fundamental attribution error) — понятие в социальной психологии, обозначающее переоценку личностных и недооценку обстоятельственных причин при интерпретации поведения человека[1].
Это склонность человека объяснять поведение других их индивидуальными особенностями, а своё поведение — ситуацией, внешними обстоятельствами. Термин был предложен в 1977 году американским социальным психологом Ли Россом[en][2].
Так вот, ребятки. Мы склонны считать, что индивидуально-психологические особенности работников что-то решают. На это валят всех собак. Вокруг этого строят найм. На самом деле, еще ранние эксперименты по организационному поведению установили, что это не так. Социальные факторы доминируют над индивидуально-психологическими в организационном контексте. Но благодаря "фундаментальной ошибке атрибуции", мы этого в упор не видим.
Пара структура-культура влияет на конфликты, трение, мотивацию, и прочие аспекты организационного поведения гораздо сильнее, чем личные качества сотрудников.
Так что можете не трудиться, тщательно подбирая сотрудников чтобы они "подходили к культуре организации". Это лютый, бешеный антинаучный бред.
На самом деле, ваша корпоративная культура определяется в конечном счете всего двумя вещами. За что вы нанимаете (продвигаете). И за что вы увольняете (наказываете). То есть — социальными стимулами. В широком смысле — расклад обязанностей-полномочий уже задает стимулы, не только поступки как таковые. А люди — они скоты крайне адаптивные. Культура пластична, и психически здоровый человек довольно быстро приспосабливается к чему угодно. И культура — это совсем не то, что вы говорите. Это то, что люди считывают между строк (мы все прекрасно умеем это делать от природы не отдавая себе в этом отчета).
Хватит страдать хуйней, и доебываться к людям, в общем. Поправьте вместо этого забор, то есть — вашу структуру. От нее, на самом деле, все ваши проблемы.
🪄О корпоративной культуре. А она точно не выдумка HR-ов?
Чтобы провести границу между пиздаболами, которые постоянно говорят это слово, от которого давно звенит в ушах, и реальным явлением, я покажу вам одно видео.
https://www.youtube.com/watch?v=o8BkzvP19v4
То, что вы видите — изумительно, и оно называется "социальная конформность". Но что вы видите в эксперименте — это куда больше, чем оно. Смотрите до конца. Это никакая не абстракция. Это объективно существующее явление. Вот это вставание со стула — это неформальная поведенческая норма, т.е. "культура" согласно нашему определению. Обратите внимание, как быстро удалось ее привить, ничего не объясняя, и как она сохранилась при полной замене людей.
В компании, в которой вы сейчас работаете, есть свой набор приседаний, который настолько привычен, что вы их даже не замечаете. Новый сотрудник так же быстро обучается выполнять эти ритуалы, как и девушка в эксперименте.
Эти приседания, которые организация порой протаскивает сквозь поколения менеджмента — и есть "культура". Она существует, независимо от вас и ваших знаний о ней.
"Культура" это набор неформальных, неписанных правил, ценностей, и норм, и ее напрямую не видно. Нужна ниибацо тренировка чтобы ее замечать и реконструировать из мелочей. Но для того чтобы к ней адаптироваться — этого не нужно, оно само происходит, на автомате.
И да, культура невидима. И — на самом деле, очень пластична. Она реагирует на стимулы.
Если вы хотите управлять коллективом по настоящему, вы должны научиться а) это замечать, б) понимать каким образом "структура" и поведение руководителей создает стимулы, определяющие вот это все, и в) менять это безобразие. Хорошая новость: как только вы научитесь это видеть — это просто.
Пиздаболов из HR заткнуть не забудьте, они шумят и мешают. Им слово "культура" необходимо затолкать обратно в глотку, откуда оно вылетает. Ничто, вероятно, не нанесло так много вреда индустрии, как нелепые, дикие теории HR, которым нечем заняться.
Чтобы провести границу между пиздаболами, которые постоянно говорят это слово, от которого давно звенит в ушах, и реальным явлением, я покажу вам одно видео.
https://www.youtube.com/watch?v=o8BkzvP19v4
То, что вы видите — изумительно, и оно называется "социальная конформность". Но что вы видите в эксперименте — это куда больше, чем оно. Смотрите до конца. Это никакая не абстракция. Это объективно существующее явление. Вот это вставание со стула — это неформальная поведенческая норма, т.е. "культура" согласно нашему определению. Обратите внимание, как быстро удалось ее привить, ничего не объясняя, и как она сохранилась при полной замене людей.
В компании, в которой вы сейчас работаете, есть свой набор приседаний, который настолько привычен, что вы их даже не замечаете. Новый сотрудник так же быстро обучается выполнять эти ритуалы, как и девушка в эксперименте.
Эти приседания, которые организация порой протаскивает сквозь поколения менеджмента — и есть "культура". Она существует, независимо от вас и ваших знаний о ней.
"Культура" это набор неформальных, неписанных правил, ценностей, и норм, и ее напрямую не видно. Нужна ниибацо тренировка чтобы ее замечать и реконструировать из мелочей. Но для того чтобы к ней адаптироваться — этого не нужно, оно само происходит, на автомате.
И да, культура невидима. И — на самом деле, очень пластична. Она реагирует на стимулы.
Если вы хотите управлять коллективом по настоящему, вы должны научиться а) это замечать, б) понимать каким образом "структура" и поведение руководителей создает стимулы, определяющие вот это все, и в) менять это безобразие. Хорошая новость: как только вы научитесь это видеть — это просто.
Пиздаболов из HR заткнуть не забудьте, они шумят и мешают. Им слово "культура" необходимо затолкать обратно в глотку, откуда оно вылетает. Ничто, вероятно, не нанесло так много вреда индустрии, как нелепые, дикие теории HR, которым нечем заняться.
YouTube
Social Conformity - Brain Games
Для введения достаточно. Дальше будем разбирать паттерны орг-структур. Надо разобрать то, что работает, и то, что не работает. И почему. Разбирать будем как и обещали — через анализ стимулов. Тут такое дело — без примеров вообще ничего не понять.
Знаете, что самое смешное? В силу чудовищной пластичности и адаптивности людей, в менеджменте работает все. Любой дикий бред. Поэтому, нам пригодится концепция трения. Его мы будем минимизировать. Мы не строим общей теории. Мы смотрим на проблему под очень узким углом. Strategic Execution. Как нам организовать групповой танец большого количества людей так, чтобы они выполнили наше намерение с наименьшими затратами энергии?
Знаете, что самое смешное? В силу чудовищной пластичности и адаптивности людей, в менеджменте работает все. Любой дикий бред. Поэтому, нам пригодится концепция трения. Его мы будем минимизировать. Мы не строим общей теории. Мы смотрим на проблему под очень узким углом. Strategic Execution. Как нам организовать групповой танец большого количества людей так, чтобы они выполнили наше намерение с наименьшими затратами энергии?
⚖️ Конвейер, и баланс ответственности с полномочиями
Ответственность идет в паре с правом принимать решения. Человек может отвечать только за то, что он в состоянии и вправе изменить.
Это главный принцип, которым мы должны руководствоваться когда делаем оргструктуры. Интереснее всего даже не примеры, когда он явно и глупо нарушается, но другое. Когда ответственность попилена таким образом, что по факту никто не отвечает за результат, и ключевая ответственность просачивается сквозьпальцы квадратики оргструктуры.
И самый знаменитый пример -- это старый добрый конвейер из "аналитиков", которые готовят спецификации, "разрабов", которые пишут код, и "тестировщиков", которые его тестируют. Пусть у нас три отдела по этим трем специальностям, с тремя руководителями. Как эта структура работает, и какие в ней естественные стимулы для руководителей отделов?
[Анализ] ➡️ [Разработка] ➡️ [Тестирование]
Для целей нашего примера, рассмотрим Чистый Конвейер в Вакууме. Три отдела, и это все.
Первое. Эта нарезка на отделы создает стимул нарезать план работ на последовательность трех таких задач.
Руководитель группы "Анализ" мотивирован выдать спецификации покрасивее и подлиннее. Как только он это сделал -- его ответственность заканчивается.
В теории, спецификации должны проверяться Разработкой. Но у нас смесь проектов, и из-за недостатка координации так выходит, что некоторые спеки ждут в очереди Разработки долгое время прежде чем их подхватят. Возникает задержка. В которой в этой структуре ни один из руководителей не виноват.
Задача от аналитиков, полежав в очереди два месяца, попадает в разработку. Разрабы понимают, что в спеке написано много лишнего, что они и так знают (аналитик не знал кто возьмет задачу и что он знает о предметной области), а чего они не знают и что нужно -- не написано, и еще написано немного хуйни про которую они знают что она точно неправда.
В этот момент, руководитель Разрабов получает по башке что задачу надо делать срочно, и он, вместо того чтобы завернуть ее аналитикам (те уперлись в растопыр -- они свою работу сделали), сходил сам к заказчику, кое-что уточнил, и делает как он считает правильным. Эти изменения идут мимо трекера задач.
Сделанная задача попадает в QA. У QA уже жопа в огне -- задержка сроков пошла, тестировать надо. Они открывают спеку аналитиков из трекера задач, пытаются тестировать, и выясняют, что оно работает ваще не так. Интересуются у разрабов, не сошли ли они с ума. Разрабы объясняют, что нет, а тестировать надо вот так и так. QA крутят пальцем у виска, как-то тестируют.
Три отдела делают одновременно много проектов. Из-за затыков в конвейре, сроки проектов предсказать невозможно. Проекты систематически вылетают за назначенные от балды дедлайны.
Директорат говорит, что эта ситуация больше невыносимо, и они сейчас подожгут всем в R&D пердаки, если это не прекратится.
Руководители Анализа, Разрабов, и Тестировщиков утверждают, что все они сделали все правильно, и даже проявили инициативу. Идея что никто не виноват приводит руководство в бешенство, и они раздают пизды всем троим без разбора. Тогда трое показывают пальцами друг на друга.
Чтобы прикрыть жопу, руководитель разрабов начинает отказываться брать спеки в работу, если в них не прописаны мельчайшие детали [👈 запомните, это всегда дурной знак]. Руководитель аналитиков заставляет всех писать очень подробные спеки. Подробные спеки делаемые в спешке начинают содержать еще больше неточностей и ошибок. Вся система встает раком, в полный паралич.
Большие Боссы, устав от этого, пытаются опять найти виноватого. Не находят, и видят, что все -- и разрабы, и аналитики, и тестировщики требуют нанять больше людей. Директорат смотрит на это, и не понимает, как к этому пришло.
Занавес. Вы только что наблюдали пример структуры с высоким присущим ей трением в действии.
З.Ы.: Приведенный расклад -- не выдумка, я его однажды наблюдал в реальной организации, и перед тем как порешал -- тщательно изучил как оно работает в этом заповеднике. Это, вероятно, самый экстремальный случай вставания конвейра раком, что я видел.
Ответственность идет в паре с правом принимать решения. Человек может отвечать только за то, что он в состоянии и вправе изменить.
Это главный принцип, которым мы должны руководствоваться когда делаем оргструктуры. Интереснее всего даже не примеры, когда он явно и глупо нарушается, но другое. Когда ответственность попилена таким образом, что по факту никто не отвечает за результат, и ключевая ответственность просачивается сквозь
И самый знаменитый пример -- это старый добрый конвейер из "аналитиков", которые готовят спецификации, "разрабов", которые пишут код, и "тестировщиков", которые его тестируют. Пусть у нас три отдела по этим трем специальностям, с тремя руководителями. Как эта структура работает, и какие в ней естественные стимулы для руководителей отделов?
[Анализ] ➡️ [Разработка] ➡️ [Тестирование]
Для целей нашего примера, рассмотрим Чистый Конвейер в Вакууме. Три отдела, и это все.
Первое. Эта нарезка на отделы создает стимул нарезать план работ на последовательность трех таких задач.
Руководитель группы "Анализ" мотивирован выдать спецификации покрасивее и подлиннее. Как только он это сделал -- его ответственность заканчивается.
В теории, спецификации должны проверяться Разработкой. Но у нас смесь проектов, и из-за недостатка координации так выходит, что некоторые спеки ждут в очереди Разработки долгое время прежде чем их подхватят. Возникает задержка. В которой в этой структуре ни один из руководителей не виноват.
Задача от аналитиков, полежав в очереди два месяца, попадает в разработку. Разрабы понимают, что в спеке написано много лишнего, что они и так знают (аналитик не знал кто возьмет задачу и что он знает о предметной области), а чего они не знают и что нужно -- не написано, и еще написано немного хуйни про которую они знают что она точно неправда.
В этот момент, руководитель Разрабов получает по башке что задачу надо делать срочно, и он, вместо того чтобы завернуть ее аналитикам (те уперлись в растопыр -- они свою работу сделали), сходил сам к заказчику, кое-что уточнил, и делает как он считает правильным. Эти изменения идут мимо трекера задач.
Сделанная задача попадает в QA. У QA уже жопа в огне -- задержка сроков пошла, тестировать надо. Они открывают спеку аналитиков из трекера задач, пытаются тестировать, и выясняют, что оно работает ваще не так. Интересуются у разрабов, не сошли ли они с ума. Разрабы объясняют, что нет, а тестировать надо вот так и так. QA крутят пальцем у виска, как-то тестируют.
Три отдела делают одновременно много проектов. Из-за затыков в конвейре, сроки проектов предсказать невозможно. Проекты систематически вылетают за назначенные от балды дедлайны.
Директорат говорит, что эта ситуация больше невыносимо, и они сейчас подожгут всем в R&D пердаки, если это не прекратится.
Руководители Анализа, Разрабов, и Тестировщиков утверждают, что все они сделали все правильно, и даже проявили инициативу. Идея что никто не виноват приводит руководство в бешенство, и они раздают пизды всем троим без разбора. Тогда трое показывают пальцами друг на друга.
Чтобы прикрыть жопу, руководитель разрабов начинает отказываться брать спеки в работу, если в них не прописаны мельчайшие детали [👈 запомните, это всегда дурной знак]. Руководитель аналитиков заставляет всех писать очень подробные спеки. Подробные спеки делаемые в спешке начинают содержать еще больше неточностей и ошибок. Вся система встает раком, в полный паралич.
Большие Боссы, устав от этого, пытаются опять найти виноватого. Не находят, и видят, что все -- и разрабы, и аналитики, и тестировщики требуют нанять больше людей. Директорат смотрит на это, и не понимает, как к этому пришло.
Занавес. Вы только что наблюдали пример структуры с высоким присущим ей трением в действии.
З.Ы.: Приведенный расклад -- не выдумка, я его однажды наблюдал в реальной организации, и перед тем как порешал -- тщательно изучил как оно работает в этом заповеднике. Это, вероятно, самый экстремальный случай вставания конвейра раком, что я видел.
❗️В структуре, нарезанной в конвейер по специальностям, нет руководителя, ответственного за результат целиком. И спрашивать с руководителей отделов за оный результат бесполезно. Они вообще, если разобраться, ни за что конкретное толком не отвечают.
🤡 При давлении сверху, структура мотивирует участников переходить в режим взаимных обвинений. Эта структура реагирует на пиздюли плохо.
👆Поведение конкретного конвейра в конкретной организации может отличаться от описанного, однако -- описанные факторы и стимулы создаются самой природой данного паттерна структуры. Люди ставятся в положение, в котором они вынуждены играть определенную социальную игру. Структура -- это правила этой игры. А культура -- обычаи (для драматизма, мы наложили на конвейер топменеджмент с "культурой контроля" и мотивацией через пиздюли). Стремясь выиграть -- они сводят все на говно.
Конвейер имеет свойство образовываться сам собой, эволюционно. У нас стартап, в котором всего трое. Аналитик, программер, тестировщик. У нас успешный стартап. Мы расширяем R&D. Эти трое становятся руководителями отделов, потому, что умные, и потому, что заслужили. Должность руководителя используется как награда. А Васе мы пожалуем звание Генерала.
Это -- одна из причин, почему поведение конвейров надо хорошо понимать и знать. И не судите тех, кто их устроил, слишком строго. Конвейры образуются в ходе нормального процесса эволюци организации. Более того. Так как мы уже знаем, что группа из двоих ведет себя примерно как один -- конвейер 2 + 2 + 2 работает вполне норм. Он начинает сбоить, когда в него вливают больше ресурсов. Чем больше, тем хуже.
🔬 Комментарий по методологии
1. Мы смотрим на происходящее как на социальную игру.
2. Структура задает формальные правила игры, и ставит людей в роли, с присущими им интересами.
3. Культура есть "обычаи игры".
4. Структура и заданные ей границы ролей во многом определяет способ коллективного реагирования участников на разного рода стимулы и ситуации.
5. Социгра, возникающая в паре структура-культура, склонна иметь устойчивые состояния, к которым она стремится вне зависимости от личностей участников. Мы пытаемся находить эти состояния.
6. Структура обладает высоким "трением", когда возникающая в ней игра склонна входить в состояния, в которых участникам уже побоку что там за проекты должны делаться.
Please open Telegram to view this post
VIEW IN TELEGRAM
Когда агилисты пугают всех "вотерфолом" -- что они на самом деле имеют в виду, это эффекты структурного паттерна "конвейер". Он, как мы понимаем -- бессмертен. Только от него есть куда более прямые лекарства, чем скрам.
Чтобы понять как конвейер неминуемо вызывает вотерфол -- представьте себя на месте манагера, который рисует план проекта. Так как ему надо задачки отдать манагерам отделов -- то план почти неминуемо будет нарезан по границам ответственности отделов, на сиквенсы анализ -> кодирование -> тестирование.
Вот так у вас получается "вотерфол". Структура влияет на план, а план -- это трейс выполнения процесса, развернутого по времени. В итоге, оргструктура пробивает своими корнями всю кухню нахер от потолка до туалета.
Клево, правда?
Wake up neo The Matrix has youЯ думаю, нет. Повременим. Хотя матричные структуры -- это полезная тема, к которой мы еще придем. Можно очень много без них. Мы, для начала, починим "конвейер" без матриц с руководителями проектов. Так можно было, да.
Принципов нарезки на отделы, в общем, конечное количество. По специальности. По предметной области (по крупным доменам функциональности, по отделам-внутренним заказчикам, по продуктам и целевой аудитории). По архитектурным границам. Есть разнообразные матричные схемы, в которых группы формируются динамически под проекты. Смотреть на это надо как на набор паттернов с присущими им свойствами, которые можно комбинировать, и из которых вы собираете решение для конкретно вашей организации. И -- границами отделов все не исчерпывается. "Структура" это не только квадратики, но и "процесс" -- типовые полу-формальные протоколы обмена сообщениями поверх них (то есть -- что происходит между квадратиками). 👈 Это мы уже с социально-игрового на другой взгляд на структуру переключились. Он тоже полезен. Явление сложное, одним видом модели не описывается.
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
На сегодня все. Дальше разберем нематричные способы чинить проблемы конвейера. Мне надо подумать, на какие простые паттерны и независимиые темы можно это разложить.
Кстати, чтобы добавить ада в конвейер -- в него надо добавить отдел Архитектурной Астронавтики. Это будет ваще ураган. Еще надо разобрать примеры, когда такие отделы стоят не в конвейре, а сбоку, когда смысл их существования -- совать всем палки в колеса.
Кстати, чтобы добавить ада в конвейер -- в него надо добавить отдел Архитектурной Астронавтики. Это будет ваще ураган. Еще надо разобрать примеры, когда такие отделы стоят не в конвейре, а сбоку, когда смысл их существования -- совать всем палки в колеса.
Случайный блог пост #перевод #мопеднемой
👩🚀 The Serverless Architecture Astronaut -- Paul Swail
В быстро меняющемся мире технологий я нахожу утешение в том, что вновь открываю для себя вечные реалии разработки программного обеспечения, которые сегодня так же актуальны, как и 20 лет назад, когда я начинал свою карьеру.
Одним из таких примеров является статья Джоэла Спольски об архитектурных астронавтах, опубликованная в апреле 2001 года:
Когда вы забираетесь слишком далеко вверх в абстракции, у вас заканчивается кислород. Иногда умные мыслители просто не знают, когда остановиться, и создают эти абсурдные, всеобъемлющие, высокоуровневые картины вселенной, которые хороши и прекрасны, но на самом деле ничего не значат. Таких людей я называю архитектурными астронавтами.
Знаете кого-нибудь, кто подходит под это описание?
Стыд и позор: в течение нескольких лет в середине и конце 2000-х годов таким человеком был я 🙈 (увы, статья Джоэла мне тогда не попалась).
В то время я работал в компании, занимавшейся разработкой программного обеспечения, которая создавала системы линейного бизнеса для корпоративных клиентов B2B. Мы создали несколько приложений, использующих очень похожие паттерны, и один из главных архитекторов компании пришел ко мне с идеей о создании внутренней структуры разработки, которая помогла бы ускорить разработку подобных проектов для наших будущих клиентов. Так что молодой наивный я был очень взволнован и принялся за работу, создавая этот сильно абстрагированный DSL, который генерировал код для CRUD-фронтенда и бэкенд-компонентов для каждой сущности в доменной модели. С этим фреймворком наши разработчики будут работать так быстро!
Мы опробовали фреймворк на нескольких клиентских проектах, и я уверен, что вы можете догадаться, как все прошло. Абстракции оказались слишком дырявыми, чтобы соответствовать требованиям конкретного проекта, разработчики расстроились, сроки сдачи прошли, клиенты раздражались. Я сгорел, и по сей день, вспоминая об этом, испытываю приступы тревоги.
Это был урок, который я усвоил с большим трудом, но я и сегодня вижу в себе многие черты архитектурного астронавта. Я могу сказать, что в бессерверном пространстве, где легко доступны многие новые инструменты, сервисы и паттерны, такие как асинхронные событийно-управляемые архитектуры и микросервисы, архитектурный астронавт еще более востребован.
Вот несколько примеров поведения архитектурных астронавтов, которые я наблюдал в реальности:
- Создание супер общих моделей данных, ссылающихся на умозрительные возможности расширения в будущем, что приводит к предварительной когнитивной нагрузке на разработчиков.
- Компромисс между медленным пользовательским опытом и элегантной развязанностью бэкенда микросервисов.
- Навязчивый поиск возможностей повторного использования, например, написание лямбда-функции таким образом, чтобы ее можно было вызывать разными способами.
- Доведение принципа единой ответственности до крайности с помощью микрогрануляризации. Одна функция Lambda на микросервис, все в собственных репозиториях и отдельных аккаунтах AWS. (см. Наносервисы).
Читая этот список, можно заметить, что либо разработчики, либо конечные пользователи (или и те, и другие) вынуждены жить с негативными последствиями решения архитектора. Как же избежать превращения в астронавта архитектуры?
(продолжение в комментариях)
👩🚀 The Serverless Architecture Astronaut -- Paul Swail
В быстро меняющемся мире технологий я нахожу утешение в том, что вновь открываю для себя вечные реалии разработки программного обеспечения, которые сегодня так же актуальны, как и 20 лет назад, когда я начинал свою карьеру.
Одним из таких примеров является статья Джоэла Спольски об архитектурных астронавтах, опубликованная в апреле 2001 года:
Когда вы забираетесь слишком далеко вверх в абстракции, у вас заканчивается кислород. Иногда умные мыслители просто не знают, когда остановиться, и создают эти абсурдные, всеобъемлющие, высокоуровневые картины вселенной, которые хороши и прекрасны, но на самом деле ничего не значат. Таких людей я называю архитектурными астронавтами.
Знаете кого-нибудь, кто подходит под это описание?
Стыд и позор: в течение нескольких лет в середине и конце 2000-х годов таким человеком был я 🙈 (увы, статья Джоэла мне тогда не попалась).
В то время я работал в компании, занимавшейся разработкой программного обеспечения, которая создавала системы линейного бизнеса для корпоративных клиентов B2B. Мы создали несколько приложений, использующих очень похожие паттерны, и один из главных архитекторов компании пришел ко мне с идеей о создании внутренней структуры разработки, которая помогла бы ускорить разработку подобных проектов для наших будущих клиентов. Так что молодой наивный я был очень взволнован и принялся за работу, создавая этот сильно абстрагированный DSL, который генерировал код для CRUD-фронтенда и бэкенд-компонентов для каждой сущности в доменной модели. С этим фреймворком наши разработчики будут работать так быстро!
Мы опробовали фреймворк на нескольких клиентских проектах, и я уверен, что вы можете догадаться, как все прошло. Абстракции оказались слишком дырявыми, чтобы соответствовать требованиям конкретного проекта, разработчики расстроились, сроки сдачи прошли, клиенты раздражались. Я сгорел, и по сей день, вспоминая об этом, испытываю приступы тревоги.
Это был урок, который я усвоил с большим трудом, но я и сегодня вижу в себе многие черты архитектурного астронавта. Я могу сказать, что в бессерверном пространстве, где легко доступны многие новые инструменты, сервисы и паттерны, такие как асинхронные событийно-управляемые архитектуры и микросервисы, архитектурный астронавт еще более востребован.
Вот несколько примеров поведения архитектурных астронавтов, которые я наблюдал в реальности:
- Создание супер общих моделей данных, ссылающихся на умозрительные возможности расширения в будущем, что приводит к предварительной когнитивной нагрузке на разработчиков.
- Компромисс между медленным пользовательским опытом и элегантной развязанностью бэкенда микросервисов.
- Навязчивый поиск возможностей повторного использования, например, написание лямбда-функции таким образом, чтобы ее можно было вызывать разными способами.
- Доведение принципа единой ответственности до крайности с помощью микрогрануляризации. Одна функция Lambda на микросервис, все в собственных репозиториях и отдельных аккаунтах AWS. (см. Наносервисы).
Читая этот список, можно заметить, что либо разработчики, либо конечные пользователи (или и те, и другие) вынуждены жить с негативными последствиями решения архитектора. Как же избежать превращения в астронавта архитектуры?
(продолжение в комментариях)
Serverless First
The Serverless Architecture Astronaut
This archetype of a technical decision maker can be toxic to a project. Here’s how to avoid becoming one. |
A daily email newsletter on building software with serverless
A daily email newsletter on building software with serverless
Возьмем вот этот чудовищный конвейер. Самое интересное, что его якобы полная неработоспособность -- это иллюзия. Нет, на самом деле R&D не был парализован. Как же оно работало?
Ну, внутренние заказчики -- они же не идиоты. Они работают с R&D давно, и разумеется знают всех инженеров кто шарит пофамильно и в лицо. На публику, они будут устраивать истерики и скандалы, и ебать CTO мозги. А на деле, когда надо что-то сделать -- они огородами прокрадутся в R&D, сделают обаятельное лицо, и начнут строить глазки нужным инженерам, склоняя их что-то сделать. И -- им сделают.
Другими словами, люди просто обойдут идиотскую структуру, которая не работает, выстроив свою, подпольную и неформальную (что в терминах SEF называется "культура").
Это вызывает искреннее удивление у многих начинающих менеджеров. Как это? Мы же сказали им делать через жопу, а они... Делают не так?! Что ж это... Анархия штоле?!!
👆Именно поэтому способность долбоебов привести организацию к краху сильно переоценена. Организация, как правило, сопротивляется, стремясь игнорировать их усилия.
И именно поэтому в менеджменте работает все, что угодно. Люди, которые хотят сделать работу, постараются обтечь вокруг любой дикой хрени, придуманной руководством. Так, что долбоебы зачастую даже не имеют понятия, как на самом деле и почему сработали их долбоебские планы. Но -- делают выводы, записывают результаты на свой долбоебский счет (на растущем рынке это не трудно, там палку в землю воткни и она вырастет), и учат других долбоебов правильно говорить на долбоебском.
И поэтому мы вместо "работает" или "не работает" оперируем концепцией "трения". Все работает. Трение разное.
Я предлагаю как следует обдумать это. И критически переосмыслить решительно все, что вы слышали или читали о менеджменте.
Я скажу так. По серьезному сломать что-то в организации так же трудно, как и починить. В действительности, надо очень постараться, чтобы оказать на нее вообще хоть какой-то эффект. Это надо уметь. Многие стараются, и им не удается даже поцарапать. Большая часть всех известных манагерских рецептов -- плацебо. Уж не знаю, хорошо это, или плохо. А реального менеджера видно в кризис.
❗️Когда видите, что что-то работать не должно, но почему-то работает -- всегда выясняйте, как, и почему. В паре "структура-культура" второе слово обозначает "неформальные правила", и оно там не для красоты.
❓Начинаете улавливать всю тонкость этого дела? Все, решительно все — совсем не то чем кажется. У всего есть двойное дно. А под ним — тройное.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Gaperton's Tech Corner
⚖️ Конвейер, и баланс ответственности с полномочиями
Ответственность идет в паре с правом принимать решения. Человек может отвечать только за то, что он в состоянии и вправе изменить.
Это главный принцип, которым мы должны руководствоваться когда делаем…
Ответственность идет в паре с правом принимать решения. Человек может отвечать только за то, что он в состоянии и вправе изменить.
Это главный принцип, которым мы должны руководствоваться когда делаем…
Тем временем, я много думал, читая на ночь пейджер твиттер. И решил, что дальше мы будем разбираться, как чинить наш конвейер его прямой противоположностью -- "вытягивающим принципом". Тем самым, из настоящего тоетовского канбана. Это тема трудная, мне надо придумать как это по простому объяснить. Судя по количеству отборной хуиты в сети по этим ключевым словам, мало кто понимает, что это такое на самом деле. Мы это исправим. Там на самом деле все очень просто. Надо только понять, как эту простоту передать.
На всякий случай -- напомним, почему тупое перетаскивание подходов из производства не работает на R&D и проектной деятельности вообще.
Цель массового производства -- изготовление потока максимально одинаковых изделий (по готовым "технологическим картам"). Цель и результат каждого проекта -- уникальны. Поэтому подходы из производства будучи бездумно перенесены на проектную деятельность приводят к катастрофическим результатам.
R&D -- это вам не любая "проектная деятельность". Его суть -- это problem solving, а не копание канав или строительство домов. А результат -- те самые "технологические карты". Поэтому подходы из "обычной" проектной деятельности будучи бездумно перенесенными на R&D приводят к катастрофическим результатам.
Понимаете, к чему я? Нельзя просто так взять, и применить Канбан в R&D. А вот вытягивающий принцип как элемент структуры -- можно.
❗️В списке долбоебских идей, если таковой будет когда-то составлен, попытки натягивать опыт производства на problem solving займет твердое место в первой тройке. Занимающийся этим долбоеб как правило одинаково не смыслит ни в производстве, ни в problem solving. Прям маркер -- слышите такое, надо бежать роняя тапки. Поэтому я стремаюсь даже говорить слово "канбан". Боюсь что все решат, что я говорю на долбоебском.
На всякий случай -- напомним, почему тупое перетаскивание подходов из производства не работает на R&D и проектной деятельности вообще.
Цель массового производства -- изготовление потока максимально одинаковых изделий (по готовым "технологическим картам"). Цель и результат каждого проекта -- уникальны. Поэтому подходы из производства будучи бездумно перенесены на проектную деятельность приводят к катастрофическим результатам.
R&D -- это вам не любая "проектная деятельность". Его суть -- это problem solving, а не копание канав или строительство домов. А результат -- те самые "технологические карты". Поэтому подходы из "обычной" проектной деятельности будучи бездумно перенесенными на R&D приводят к катастрофическим результатам.
Понимаете, к чему я? Нельзя просто так взять, и применить Канбан в R&D. А вот вытягивающий принцип как элемент структуры -- можно.
❗️В списке долбоебских идей, если таковой будет когда-то составлен, попытки натягивать опыт производства на problem solving займет твердое место в первой тройке. Занимающийся этим долбоеб как правило одинаково не смыслит ни в производстве, ни в problem solving. Прям маркер -- слышите такое, надо бежать роняя тапки. Поэтому я стремаюсь даже говорить слово "канбан". Боюсь что все решат, что я говорю на долбоебском.
🚜 Вытягивающий принцип
Конвейер состоит из узлов, каждый из которых это очередь задач и обработчик, который берет из нее задачи. 💤🔜 1️⃣. У обычного обработчика очереди есть неприятное свойство, известное по колцентрам [1]. Если темп поступления задач хоть немного превышает темп их вынимания из очереди (один сотрудник колцентра не вышел вовремя на работу), то очередь начинает расти, а задержка на одной задаче -- начинает расти до неприличных величин (вашего заказчика бесит именно она).
В трехступенчатом конвейре три очереди, и он выглядит так:
👉💤 🔜 1️⃣ 🔜 💤 🔜 2️⃣🔜 💤 🔜 3️⃣ 🔜🎉
Чтобы работа началась, мы либо кладем задачу в первую очередь, и когда она заканчивается -- она порождает задачи в следующей очереди. Либо, если мы планируем проект -- мы одновременно кладем задачи во все три очереди, где они дожидаются своего часа. Это "заталкивающий принцип", push.
У него еще более неприятные свойства. Производительность конвейра определяется самым медленным его узлом. При малейшей разбалансировке конвейра одна из трех очередей задач начнет расти. Рост любой из очередей -- рост общей задержки по проектам. Наивная оптимизация конвейра с добавлением ресурсов в узел с наибольшей очередью часто создает затык в очереди следущего узла. Задержка в обработке задачи в нашем деле означает пропорциональный рост стоимости исправления в ней ошибок. Если в конвейре будет несколько проектов, предсказать срок их завершения -- математически не самая простая задача. Одно это должно дать повод избегать глубоких конвейеров.
[1] Хотите знать больше о свойствах очередей и конвейеров? Я вас боюсь. Но добро пожаловать в увлекательный мир теории массового обслуживания, являющейся подразделом исследования операций.
"Вытягивающий принцип" (pull) -- это разворот управления в конвейре. Начинаем мы с того, что ставим задачу в его конец. Звено три знает, что должно быть сделано до, и ставит задачи в звено два. И так далее. Затем -- они ждут когда предыдущие звенья закончат, и делают свою работу.
💤 🔙 1️⃣ 🔙 💤 🔙 2️⃣ 🔙 💤 🔙 3️⃣ 👈
⬇️
💤 🔜 1️⃣ 🔜 💤 🔜 2️⃣ 🔜 💤 🔜 3️⃣ 🔜🎉
Чем это лучше? В случае производства, это позволяет радикально упростить планирование и выдачу нарядов, сделав управление распределенным. И снизить затраты на логистику (у них очередь задач -- это физический склад, аренда которого дорогое удовольствие). О чем, собственно и есть lean и kanban, но все эти рассуждения абсолютно неприложимы к разоаботке. У нас склад -- это бэклог в трекере задач, и хранение тикетов ничего не стоит. Поэтому, мы не будет тратить время на то, как и почему работает канбан (я про настоящий, на производстве, который в отличии от выдумок агилистов полезен, и гениален -- в комментах объяснил на пальцах).
Есть, однако, нюанс. В случае R&D -- это замыкает обратную связь на том, кто ставит задачу. "Спросил-получил", против "выстрелил и забыл". И это может многое изменить.👇
Конвейер состоит из узлов, каждый из которых это очередь задач и обработчик, который берет из нее задачи. 💤🔜 1️⃣. У обычного обработчика очереди есть неприятное свойство, известное по колцентрам [1]. Если темп поступления задач хоть немного превышает темп их вынимания из очереди (один сотрудник колцентра не вышел вовремя на работу), то очередь начинает расти, а задержка на одной задаче -- начинает расти до неприличных величин (вашего заказчика бесит именно она).
В трехступенчатом конвейре три очереди, и он выглядит так:
👉💤 🔜 1️⃣ 🔜 💤 🔜 2️⃣🔜 💤 🔜 3️⃣ 🔜🎉
Чтобы работа началась, мы либо кладем задачу в первую очередь, и когда она заканчивается -- она порождает задачи в следующей очереди. Либо, если мы планируем проект -- мы одновременно кладем задачи во все три очереди, где они дожидаются своего часа. Это "заталкивающий принцип", push.
У него еще более неприятные свойства. Производительность конвейра определяется самым медленным его узлом. При малейшей разбалансировке конвейра одна из трех очередей задач начнет расти. Рост любой из очередей -- рост общей задержки по проектам. Наивная оптимизация конвейра с добавлением ресурсов в узел с наибольшей очередью часто создает затык в очереди следущего узла. Задержка в обработке задачи в нашем деле означает пропорциональный рост стоимости исправления в ней ошибок. Если в конвейре будет несколько проектов, предсказать срок их завершения -- математически не самая простая задача. Одно это должно дать повод избегать глубоких конвейеров.
[1] Хотите знать больше о свойствах очередей и конвейеров? Я вас боюсь. Но добро пожаловать в увлекательный мир теории массового обслуживания, являющейся подразделом исследования операций.
"Вытягивающий принцип" (pull) -- это разворот управления в конвейре. Начинаем мы с того, что ставим задачу в его конец. Звено три знает, что должно быть сделано до, и ставит задачи в звено два. И так далее. Затем -- они ждут когда предыдущие звенья закончат, и делают свою работу.
💤 🔙 1️⃣ 🔙 💤 🔙 2️⃣ 🔙 💤 🔙 3️⃣ 👈
⬇️
💤 🔜 1️⃣ 🔜 💤 🔜 2️⃣ 🔜 💤 🔜 3️⃣ 🔜🎉
Чем это лучше? В случае производства, это позволяет радикально упростить планирование и выдачу нарядов, сделав управление распределенным. И снизить затраты на логистику (у них очередь задач -- это физический склад, аренда которого дорогое удовольствие). О чем, собственно и есть lean и kanban, но все эти рассуждения абсолютно неприложимы к разоаботке. У нас склад -- это бэклог в трекере задач, и хранение тикетов ничего не стоит. Поэтому, мы не будет тратить время на то, как и почему работает канбан (я про настоящий, на производстве, который в отличии от выдумок агилистов полезен, и гениален -- в комментах объяснил на пальцах).
Есть, однако, нюанс. В случае R&D -- это замыкает обратную связь на том, кто ставит задачу. "Спросил-получил", против "выстрелил и забыл". И это может многое изменить.👇
-- Ну вот смотри, -- со вздохом говорит программист, беря в руку 20 страниц документа от аналитика, -- Вот это... [он начинает отсчитывать листы, кладя их на стол] ...мне не интересно. Это все я и без него знаю. Кстати, он там ошибся вот здесь и вот здесь, на самом деле оно не так. Но мне это не важно. И вот это. [он выбрасывает листы снизу, оставляя в руке два]. Вот эти два листа -- это все, что мне от него было нужно, и... -- он передает листы мне. Там обведено два абзаца, и начеркано красным.
-- То что я обвел -- это он молодец, это мне надо. Но мне надо больше, и он этого не написал.
-- И что ты сделал?
-- Как что? Позвонил Гале, и уточнил это все минут за 15. Таки что я хочу сказать? Такой
Как же это исправить?
Вытягивающий принцип в данном случае состоит в том, что задачи эскалируются в анализ разработкой с конкретным заданием, а не попадают туда сразу снаружи. Это позволяет избежать ненужной работы.
Здесь мы разворачиваем "хвост" конвейра, "матрично" объединяя его с началом (аналитики временно руководят QA, и мы делаем это легальным на уровне структуры). То есть, квадратики вроде все те же. А вот расклад обязанностей-полномочий и протокол общения поверх них уже другой. Разница в том, что ответственность с полномочиями приведены в баланс в сравнении с наивным конвейром.
В данном случае, вытягивающий принцип в том, что аналитик как бы заказывает работу у разрабов, и пользуется результатом, а не "выстрелил ⛹️♂️, пули ушли ⚽️, проблемы на вашей стороне 🥅".
Это в общем уже не "аналитик". Но внедрение этих принципов в структуру дало измеряемое снижение средней задержки по задачам вдвое, и кратное сокращение количества баг-репортов, так что...
❗️Должен предостеречь от тупого копирования того, что написано выше. Тупо скопированное тупо работает. Интеграция вытягивающего принципа в процессы - тонкая работа. С другой стороны, если ошибетесь -- ничего страшного не случится. Как мы знаем из предыдущего поста -- на это все просто положат болт
Что этот пост однако должен наглядно показать -- структура это куда больше чем квадратики и названия. Она настраивается раскладкой ответственности и полномочий. А. Ну и то, что наивный конвейер --
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Gaperton's Tech Corner
🤔 Все организовано через жопу, и работать не должно. Как же оно работает?
Возьмем вот этот чудовищный конвейер. Самое интересное, что его якобы полная неработоспособность -- это иллюзия. Нет, на самом деле R&D не был парализован. Как же оно работало?
Ну…
Возьмем вот этот чудовищный конвейер. Самое интересное, что его якобы полная неработоспособность -- это иллюзия. Нет, на самом деле R&D не был парализован. Как же оно работало?
Ну…
> Что этот пост однако должен наглядно показать -- структура это куда больше чем квадратики и названия. Она настраивается раскладкой ответственности и полномочий. А. Ну и то, что наивный конвейер -- 💩 , конечно. В очередной раз.
🔃 Обратная связь
Еше один взгляд на структуру -- это масштабируемый механизм обработки информации и решения проблем. Чтобы она работала в этом качестве как смазанный механизм -- каждое звено в ней должно (1) уметь принимать решения, что-то добавляя в процесс и ошибаясь, и (2) естественным образом нести ответственность за результат этих решений, чтобы иметь возможность видеть как сработали решения, и исправлять ошибки. Для этого в системе должны быть обратные связи.
Например, программисты получают обратную связь в виде багов от QA. В наивном конвейре она тоже имеет пакостные режимы -- QA мотивированный количеством багов (на вес) может завалить разрабов тупым говном, при этом не тестируя софт в режимах в которых он будет использоваться, и не тестируя его по существу (для чего надо вообще понимать как это будет использоваться и зачем). Это произойдет если у QA убрать обратную связь, заменив ее идиотскими стимулами.
❗️Любой KPI основанный на метриках можно максимизировать в ущерб делу. Он создает странные стимулы, склонные работать совсем не так как хотелось авторам. Не делайте так.
😱 R&D -- это проектная деятельность с уникальным результатом, и решение проблем. Каждый раз разных. KPI не работает потому, что никак не учитывает эту уникальность. Он убивает обратную связь с уникальным результатом. Те же проблемы, что с производственной аналогией. Пичаль.
❗️Видите линейную цепочку с разорванной (или очень длинной и медленной) обратной связью, как наивный конвейер -- ну, привет. Не делайте так. Обратная связь в конвейере есть — она просто очень длинная. Сделали говно. Оно не подошло. Зато закодировали отлично, и протестировали как-то. Такие ошибки надо находить раньше, это дешевле.
😏 А хотите по настоящему, по долбоебски? Каждый второй долбоеб пытается строить конвейр, обвесив его KPI, воображая себя крупным промышленником. Вам нужно так же.
❓ Любой продукт интеллектуального труда содержит ошибки. Есть ли у вас в организации обратная связь для задач от продактов? Как она работает? Насколько она длинная?
Стоящий сбоку отдел Архитектурной Астронавтики, работа которого заставлять всех танцевать вприсядку -- еще один вопиющий пример органа, который принимает решения космического масштаба, не испытывает на себе их последствий, и не несет прямой ответственности за их результаты. Все, конечно, решает не название отдела, а ответственность-полномочия, и протокол, которым его работа вплетена в общий танец. И общее правило очень простое.
❗️Если вы не представляете себе этого протокола -- вы не можете проанализировать его свойства, не сможете никому объяснить как они должны работать, и впустую увеличиваете энтропию в организации и "трение". Вам не нужен такой отдел. Учитывая, насколько трудно разбираться в том, как оно на самом деле работает -- эксперимент без понимания тут так себе критерий истины. Мы научимся правильно вводить такие отделы для cross-cutting concerns.
🔃 Обратная связь
Еше один взгляд на структуру -- это масштабируемый механизм обработки информации и решения проблем. Чтобы она работала в этом качестве как смазанный механизм -- каждое звено в ней должно (1) уметь принимать решения, что-то добавляя в процесс и ошибаясь, и (2) естественным образом нести ответственность за результат этих решений, чтобы иметь возможность видеть как сработали решения, и исправлять ошибки. Для этого в системе должны быть обратные связи.
Например, программисты получают обратную связь в виде багов от QA. В наивном конвейре она тоже имеет пакостные режимы -- QA мотивированный количеством багов (на вес) может завалить разрабов тупым говном, при этом не тестируя софт в режимах в которых он будет использоваться, и не тестируя его по существу (для чего надо вообще понимать как это будет использоваться и зачем). Это произойдет если у QA убрать обратную связь, заменив ее идиотскими стимулами.
❗️Любой KPI основанный на метриках можно максимизировать в ущерб делу. Он создает странные стимулы, склонные работать совсем не так как хотелось авторам. Не делайте так.
😱 R&D -- это проектная деятельность с уникальным результатом, и решение проблем. Каждый раз разных. KPI не работает потому, что никак не учитывает эту уникальность. Он убивает обратную связь с уникальным результатом. Те же проблемы, что с производственной аналогией. Пичаль.
❗️Видите линейную цепочку с разорванной (или очень длинной и медленной) обратной связью, как наивный конвейер -- ну, привет. Не делайте так. Обратная связь в конвейере есть — она просто очень длинная. Сделали говно. Оно не подошло. Зато закодировали отлично, и протестировали как-то. Такие ошибки надо находить раньше, это дешевле.
😏 А хотите по настоящему, по долбоебски? Каждый второй долбоеб пытается строить конвейр, обвесив его KPI, воображая себя крупным промышленником. Вам нужно так же.
Стоящий сбоку отдел Архитектурной Астронавтики, работа которого заставлять всех танцевать вприсядку -- еще один вопиющий пример органа, который принимает решения космического масштаба, не испытывает на себе их последствий, и не несет прямой ответственности за их результаты. Все, конечно, решает не название отдела, а ответственность-полномочия, и протокол, которым его работа вплетена в общий танец. И общее правило очень простое.
❗️Если вы не представляете себе этого протокола -- вы не можете проанализировать его свойства, не сможете никому объяснить как они должны работать, и впустую увеличиваете энтропию в организации и "трение". Вам не нужен такой отдел. Учитывая, насколько трудно разбираться в том, как оно на самом деле работает -- эксперимент без понимания тут так себе критерий истины. Мы научимся правильно вводить такие отделы для cross-cutting concerns.
Please open Telegram to view this post
VIEW IN TELEGRAM
Gaperton's Tech Corner
Думаю, мы можем это обобщить в форме одного предложения.
🧐 Любая нелепая структура может работать вопреки своей глупости на волонтерских началах.
Назовем это Первым Законом Структур имени Маши Сошниковой, имеющей привычку доказывать это делом. Этот закон устанавливает связь между структурой и культурой (в определении SEF).
Вероятно, поэтому многие организации так тщательно ищут уникальных людей, способных хоть что-то сделать в их рамках. И не могут найти. Но иногда находят.
Я собственно стараюсь показать, что сделать так, чтобы суперлюди для этого не требовались -- возможно. Правильная организация ими не питается, перерабатывая в биореакторе на метан. Она их умеет производить.
Happy weekend, дорогие товарищи. Да прибудет с вами матан.
🧐 Любая нелепая структура может работать вопреки своей глупости на волонтерских началах.
Назовем это Первым Законом Структур имени Маши Сошниковой, имеющей привычку доказывать это делом. Этот закон устанавливает связь между структурой и культурой (в определении SEF).
Вероятно, поэтому многие организации так тщательно ищут уникальных людей, способных хоть что-то сделать в их рамках. И не могут найти. Но иногда находят.
Я собственно стараюсь показать, что сделать так, чтобы суперлюди для этого не требовались -- возможно. Правильная организация ими не питается, перерабатывая в биореакторе на метан. Она их умеет производить.
Happy weekend, дорогие товарищи. Да прибудет с вами матан.