Как мне удалось выяснить, я не первый кто об этом задумался. KrakenD потому и использует декларативное описание в формате JSON, чтобы он мог выполнять в т.ч. и функции BFF силами команды разработки клиентского приложения.

💬 Desktop and mobile interfaces usually compete in requirements, and the backends keep growing to fit both types of usage. Every frontend team will work in different data views to display the content, and the backend team becomes a bottleneck as it must fulfill the frontend team’s needs. In many cases, the same type of information (or view) will require different response formats and response errors for each consumer, making your backend developers spend a lot of time developing this logic. And many meetings and time making the different frontend dev teams get on the contract agreement!

# How the BFF works

KrakenD implements the BFF pattern with aggregation, allowing your frontend teams to define precisely the information you want to retrieve from the different services and how to deal with the errors.

The client receives:
- Exactly the data it needs, and no more.
- The information for a use case is taken from a single call
- Aggregated information containing all involved services
- Optionally, stub static data when there’s missing information
- Separation of concerns
- Decoupling: Do not have to worry very much about the backend changing or evolving

-- https://www.krakend.io/docs/design/backend-for-frontend/

В процессе обсуждения в чате канала ко мне в библиотеку попала новая книга "Джедайские техники конструктивного общения" Александра Орлова.

Там была одна метафора, которая заставила меня задуматься:

💬 Что делает кирпичную стену прочной? Идеальная геометрия каждого кирпичика или смесь, скрепляющая их между собой? Если вы видели, как делают кирпичную кладку, то легко можете представить, как получается ровная и прочная стена, несмотря на далекую от идеала точность изготовления отдельных кирпичей.

На первый взгляд кажется, что это утверждение противоречит приводимому мною ранее утверждению о том, что "Важно не объединение людей само по себе, а те принципы, на которых оно основано." Когда возникает противоречие, то это говорит о том, что что-то упущено из зоны внимания рассмотрения. И это что-то хорошо демонстрируется этой картинкой. Насколько важна прочность этой стены, если она не в состоянии осуществлять возложенные на неё функции?

@BorisRomanov развидел то, что упустил я - важна не стена, а фундамент! Именно о фундаменте говорится здесь:

💬 "Важно не объединение людей само по себе, а те принципы, на которых оно основано."

Автором этого утверждения является Фидель Кастро. А он умел создавать высокоэффективные команды.

Когда его группа (вместе с Эрнесто Че Геварой) из 82 голодных, изнеможённых человек добралась вброд до берегов Кубы, - их поджидали 35000 вооружённых солдат, танки, 15 судов береговой охраны, 10 военных кораблей, 78 истребителей и транспортных самолётов. И они победили. Они осуществили одно из самых немыслимых изменений в истории человечества.

На собственном примере они доказали слова "Шарль де Голль":
💬 "Исторический фатализм существует для трусов. Смелость и счастливый случай не раз меняли ход событий. Этому учит нас история. Бывают моменты, когда воля нескольких человек сокрушает все препятствия и открывает новые дороги".

P.S.: Был в моей жизни момент, когда я серьезно готовился к партизанским действиям, потому что вероятность неизбежности этого была очень высокой. Именно тогда я и познакомился с опытом кубинских партизан и революционеров. Это фразу я прочёл 10 лет назад, и она навечно врезалась в мою память.

Это точно не первая статья, искал как-то для митапа инфу.
На несколько месяцев раньше статья Phil Calçado, про его опыт в SoundCloud, где вводится сам термин BFF. По крайней мере я не нашёл более ранних упоминаний. https://philcalcado.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html

А за 3 года до этого (2012) статья Netflix, где без введения термина BFF тем не менее очень подробно разбираются предпосылки к этому паттерну и немного об их реализации. Вполне возможно, что Netflix, с их ~800 типами клиентов, были действительно первыми, кто реально столкнулся с такой проблемой в масштабах.
https://netflixtechblog.com/embracing-the-differences-inside-the-netflix-api-redesign-15fd8b3dc49d

Причина, по которой Microsoft Reference Application eShopOnContainers выбрал Envoy (взамен Ocelot) в качестве api-gateway, заключается в поддержке gRPC и WebSocket:

The reference microservice application eShopOnContainers is currently using features provided by Envoy to implement the API Gateway instead of the earlier referenced Ocelot. We made this design choice because of Envoy's built-in support for the WebSocket protocol, required by the new gRPC inter-service communications implemented in eShopOnContainers.
-- https://learn.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/implement-api-gateways-with-ocelot

Как я выяснил, KrakenD поддерживает их только в Enterprise версии.

Из полностью свободных аналогов с поддержкой gRPC и WebSocket выделяются Envoy и Apisix.

Какому решению (из перечисленных или сторонних) вы отдаете предпочтение? Интересуют решения, позволяющие работать как с кубиком, так и без него.

Коллеги, если кто-то ищет проверенного высококвалифицированного специалиста по DDD, микросервисам, Clean Architecture на Golang - обращайтесь ко мне в личку, пока кандидатура не ушла. Имеет успешный практический опыт лида, программиста, архитектора и глубокую теоретическую подготовку. Его не нужно обучать и после него не нужно переделывать.

Единственное ограничение - работа из-за границы, платежи на зарубежный счет. Не налоговый резидент (но гражданин) РФ.

Не дешевый, но очень выгодный. Ручаюсь.

Идет мужик по лесу, смотрит - другой мужик лес рубит топором.
- Что делаешь?
- Лес рублю.
- Бензопила же рядом лежит. Возьми её - быстрее будет.
- Я не умею ею пользоваться.
- Инструкция лежит же рядом. Возьми, прочитай.
- Мне некогда - лес рубить надо.

К чему я вспомнил этот анекдот? Состояние кода может замедлить разработку более, чем на порядок, и продолжать замедлять по экспоненте.

В процессе программирования программист вводит символы с клавиатуры не более 10% времени (зачастую - не более 1% времени). Остальное время он читает существующий код и борется со сложностью.

Плохой код пишется одним программистом, однократно, не более 10% времени. А читается он всеми программистами команды, многократно, постоянно, более 90% времени программирования. Т.е. однократно написанный одним программистом плохой код будет замедлять всю команду более 90% её времени.

Таким образом, фраза "некогда писать правильно" является самообманом. Если у команды медленный темп разработки, то он более чем на 90% времени вызван медленным чтением и затрудненным пониманием написанного ранее кода. Именно поэтому скорость разработки деградирует обычно в геометрической прогрессии.

Самообманом является и фраза "потом исправим". Как сказал Randy Shoup, если у вас нет времени сделать это правильно, то с чего вы взяли, что у вас будет время сделать это дважды? Тем более, что потом скорость разработки будет ниже, а напряжение - выше.

Количество введенных символов слабо коррелирует со скоростью разработки. Например, ребята, увлекающиеся спортивным прохождением кат по программированию, заметили, что используя TDD они пишут в разы больше объем кода, но проходят каты процентов на 10% быстрее, чем без ТДД.

Все просто - используя TDD, появляется слабосвязанный код (иначе его сложно было бы протестировать), который легче читать и понимать.

Но я сейчас не об этом. А о том, что для того, чтоб писать высокоэффективный код, нужно обладать определенными знаниями.

Я вспоминаю, когда я начал работать с литературой по Software Design, то мой код начал существенно преображаться. Мой старый код вызывал у меня стыд. Я взял паузу в программировании Open Source проектов и засел за книжки. Я понимал, что лучше "прочесть инструкцию к бензопиле", нежели продолжать "рубить топором" то, что потом все-равно переделывать.

К тому моменту я уже начал немного разбираться в том, чем хороший код отличается от плохого. И я хотел, чтоб то же самое испытал мой товарищ, который продолжал "рубить топором" и не находил времени на прочтение "инструкции к бензопиле".

Хороший код отличается простотой, и выполняет главный императив разработки - управление сложностью. Но хороший код не спасает от еще одной сложности, про которую недавно написал @BorisRomanov (начиная отсюда). На эту же тему писал Егор Толстой и даже сам E. Dijkstra:

💬 "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
—Edsger W. Dijkstra, 1984 On the nature of Computing Science (EWD896)

Менеджмент не сможет оценить качество кода, если не обладает соответствующим образованием. Но менеджмент рано или поздно заметит разницу в темпах разработки между вашей командой и другими командами, и начнет доверять вам больше. Если, разумеется, у вас хватит выдержки дотянуть до этого момента. Тут главное - взобраться на горку.

Труднее обстоит дело, когда вы не можете передавать знания команде личным примером, например, на позиции лида или архитектора. Для менеджмента ваши "инструкции к бензопиле" - просто отвлекание команды "от рубки леса". Возникает дилемма: спасать менеджмент от самого себя, вопреки его воле, понимая, что он никогда это не оценит, или же проявить внешний конформизм, осознавая, что
💬 "Те компании, которые не осознают, что знания являются средством производства более важным, чем земля, труд или капитал, постепенно умрут и никогда не поймут, что их погубило."
—Ларри Прусак

Хотелось порассуждать дальше, но закончилось место. Ладно, потом...

Что такое настоящий бизнес-анализ, как я это вижу

Опишу линейно, хотя там есть несколько циклов:
1. Взять первичный запрос, сформулировать в виде проблемы, также если у инициатора есть видение решения, тоже сформулировать
2. Определить, о каком участке бизнеса идёт речь, построив модель контекста
3. Построить онтологию и модель деятельности на этом участке
4. Выявить организационные роли в окружении участка бизнеса и их интересы, оценки текущей реализации интересов
5. Построить проблемное месиво и структурировать его через причинно-следственные связи (дерево текущей реальности), найти корневые причины, экономически измерить ущерб, наносимый последствиями
6. Построить дерево будущей реальности, выйдя на целевые эффекты
7. Сформулировать ограничения на решение
8. Из интересов оргролей сформулировать требования к решению
9. Разработать несколько вариантов решений, для каждого оценить стоимость и риски
10. Обосновать выбор конкретного решения
11. Принять участие в заказе, реализации и приёмке решения
12. Оценить эффект от решения, соотнести его с плановым

#бизнес_анализ

Случайно наткнулся на видео, в котором Александр Покрышкин рассуждает о лидерстве, об инструкциях и менеджменте, о роли теории, об искусстве побеждать. О том, как побеждать в условиях, когда инструкции и менеджмент препятствуют победе.

Когда-то я услышал фразу, что заяц не может научить охотиться. Сегодняшний рынок знаний переполнен всяким хламом о лидерстве от зайцев. Поэтому, я всегда читал в первоисточнике тех людей, лидерские способности которых не вызывают сомнений. Особый интерес вызывает путь тех людей, которые выбились в лидеры не благодаря природным способностям, а вопреки им. Взять, например, Ивана Кожедуба:

"В начале военной карьеры Ивана Никитовича преследовали неудачи, его даже чуть было не перевели на пост оповещения. Только заступничество командира полка майора И. Солдатенко помогло ему остаться в полку. Свою первую победу летчик одержал в ходе 40-го боевого вылета, сбив немецкий пикировщик."
—"Кожедуб Иван Никитович" / Киселев О. Н.

Раз уж затронул тему лидерства, то нелишне было бы в очередной раз упомянуть книгу "Becoming a Technical Leader" by Gerald M. Weinberg.

Кстати, глава о лидерстве в этой книге начинается со слов Лао Цзы:

If you are a good leader,
Who talks little,
They will say,
When your work is done,
And your aim fulfilled,
"We did it ourselves."
- Lao Tse

А так же книгу "Дао Лидера" Джона Хейдера, которая является современной интерпретацией "Дао Де Цзин" Лао Цзы и учит лидерству на основе диалектической философии. Ну и подборку по лидерству от "Harvard Business Review".

В этот день 6 марта 1913г родился советский легендарный лётчик-ас, Александр Покрышкин 🫡

Фильм "Хозяин неба" (1985г)

💬 The more I struggled against becoming a leader, the more I was setting my own direction—and the more I was becoming a leader.

💬 Whenever I want to learn about something, I arrange to teach a course on the subject. After I've taught the course enough to learn something, I write a book.

💬 Leaders are leaders of change – change in other people, change in working groups, and change in organizations. Above all, leaders are leaders of change in themselves. To become a leader, you have to understand how change happens; yet it's difficult to see change in yourself.

-- "Becoming a Technical Leader" by Gerald M. Weinberg.

Z-lib позволяет создавать персонализированный бот.

💬 Bot is a fast and convenient way to download books. And now our users can get and configure their own personal bot. To do this visit our library website > Edit Profile or click on the bot icon at the bottom of the website page.
https://www.tgoop.com/zlibrary_official/6

За что отвечает архитектура?

1. За выявление наиболее существенных требований и за разрешение противоречивых (конфликтующих или обратно-коррелирующих требований).

2. За устранение напряжения между требованиями и конструкцией (это когда то, что хотим, - не можем, а то, что можем, - не хотим).

3. За выбор способа разрешения неопределенности требований путем выбора соответствующей SDLC-модели разработки. Т.е. за выбор соотношения предиктивного и адаптивного способов разрешения неопределенности.

4. В случае выбора адаптивного способа обработки неопределенности (итеративная SDLC-модель разработки и её производные) - за достижение Quality Attribute Modifiability. Т.е. за максимизацию количества открытых решений, где открытость определяется стоимостью изменения решения. Т.е. за опеспечение постоянства скорости (стоимости) разработки по мере роста размера системы. На практике график роста стоимости разработки обычно обретает характер роста близкий к логарифмическому, и задача архитектуры - предотвратить экспоненциальный рост. Достигается это путем минимизации когнитивной нагрузки, т.е. путем управления сложностью, и локализацией изменений. Если этого не сделать, то адаптивный способ разрешения неопределенности утратит экономическую целесообразность, поскольку стоимость реализации решения будет существенно зависеть от момента принятия решения.

5. В случае выбора многокомандной инкрементальной SDLC-модели разработки и её производных (Scaled Agile) - за обеспечение постоянства скорости разработки по мере увеличения количества команд разработки, т.е. за решение Проблемы Брукса. Достигается это путем минимизации коммуникативной нагрузки на команды разработки за счет выявления правильных границ Bounded Contexts.

Это те функции, для осуществления которых нанимается архитектор.

Теперь подойдем к часто обсуждаемому в профессиональных сообществах вопросу.

Давайте представим пациента, госпитализированного с острым воспалительным процессом, которому доктор назначил лечение в виде курса антибиотиков. Пока еще можно обойтись консервативным лечением, но если его не осуществить вовремя, то потребуется уже хирургическое вмешательство. А если и его не осуществить, то возможен летальный исход. И тут пациент говорит, что у него сегодня важная бизнес-встреча, и нужно бухнуть вискаря, тем самым нейтрализовав антибиотики. Что делает в таком случае доктор? Он выписывает пациента из стационара за нарушение предписанного режима, и тем самым он снимает с себя ответственность за последствия, которые от него не зависят. Потому что иначе это будет называться преступная халатность. Она не может быть оправдана тем, что доктор получил за халатность деньги (т.е. наличием корыстного умысла). Доктор-убийца никому не нужен. Он получает деньги за исполнение возложенных на него функций.

Размытость в понимании своих функций иногда на практике приводит к тому, что архитектор начинает противодействовать им, оправдываясь тем, что "кто платит, тот и танцует..." Такое, конечно, тоже может быть, только это уже не функции архитектуры. И если человек не осуществляет функций архитектуры, то называть его архитектором уже ошибочно.

Postman, кроме того, что производит инструмент для тестирования API, ещё собирает лучшие практики проектирования.

Для этого у них есть отдельная команда Postman Open Technologies, которая также собирает информацию о стандартах, отраслевых форматах и спецификациях, открытых API.

Каталог практик и паттернов оформлен как рабочее пространство Postman: https://www.postman.com/postman/workspace/postman-open-technologies-openapi-governance-templates/overview (открывается прямо в Postman!)

Смысл каталога в том, чтобы не придумывать каждый раз "как мы будем возвращать сумму платежа" или "как будем делать пагинацию", а брать готовое решение.

На текущий момент там описаны следующие паттерны:
🔸 Форматы данных:
🔹Коды стран (ISO 3166)
🔹Коды валют (ISO 4217)
🔹Дата, время и временные промежутки (ISO 8601)
🔹Числа с десятичными дробями
🔹Кастомные заголовки HTTP
🔹Расширенное описание ошибки (RFC 9457 - кстати, очень хороший формат для передачи смысла ошибки HTTP)

🔸Управление кэшированием:
🔹Параметр Cache-control
🔹Параметр Etag
🔹Параметр Expires

🔸Фильтрация:
🔹Параметры поискового запроса
🔹Точное соответствие
🔹Диапазон значений поля
🔹Выбор полей для ответа

🔸Пагинация:
🔹Заголовки page and per_page (rfc 5988)
🔹Курсор / NextRecordKey
🔹Параметры Limit и Offset

🔸Сортировка:
🔹По одному полю - параметры sort_by, sort_order
🔹По нескольким полям

🔸Версионирование:
🔹На уровне URL API
🔹На уровне отдельного ресурса
🔹Через заголовок Accept-Version
🔹Через заголовок Accept

🔸Информация:
🔹Контакты разработчиков
🔹Лицензия
🔹Условия использования
🔹Заголовок Sunset (предупреждение, что ресурс станет недоступным в определенное время)

Набор паттернов интересный, я, например, про RFC 9457, версионирование на уровне ресурсов и Sunset header раньше не слышал.

Еще одна книга от PostgresPro:

Путеводитель по базам данных. Комаров В. И. — М.: ДМК Пресс, 2024. — 520 с.

ISBN 978-5-93700-287-7

Книга рассказывает об архитектурных принципах, на которых базируются все современные системы управления базами данных, а также об алгоритмах и структурах данных, которые в них используются. Особое внимание уделено сравнению реализаций одних и тех же подходов в близких по функциональности платформах.

Эту книгу следует прочесть всем, кого не устраивает уровень подготовки на трехмесячных курсах типа «войти в айти». Практическим знаниям она даст прочный фундамент в виде понимания общих закономерностей. Книга написана для архитекторов информационных систем и ведущих разработчиков. Иными словами, для элиты и для тех, кто хочет ей стать.

https://postgrespro.ru/education/books/dbguide

Наглядно о том, чем руководство (формальное) отличается от лидерства (неформального):
https://habr.com/ru/articles/536292/

В Nokia разработали собственную мобильную операционную систему MeeGo. Но формальные руководители решили, что будут использовать Windows Phone для смартфонов Nokia.

Далее цитатами:

💬 ситуация в Nokia и в разработке MeeGo была настолько дезорганизована за последние пару лет

💬 Команда MeeGo и другие сотрудники Nokia были задеты за живое, и у них была только одна цель — закончить продукт на основе MeeGo и отправить его на полки магазинов в течение 2011 года.

💬 команда MeeGo была распущена после выпуска N9 и нескольких обновлений прошивки

💬 С 2005 года очень небольшая группа людей с ограниченными ресурсами в Nokia разрабатывала операционную систему Maemo на базе Linux и устройства на ее основе. Команда была известна как OSSO (Open Source Software Operations), и, по словам одного из членов команды, который работал там с самого начала, целью было создание продукта, который изменит мир. Команда OSSO была переименована в команду Maemo в 2007 году. А в результате партнерства Nokia и Intel в 2010 году она была переименована в команду MeeGo. С самого начала группу возглавлял Ари Якси, который ушел из Nokia в октябре 2010 года и перешел в HP для разработки операционной системы WebOS.

Здесь мы видим человека с лидерскими качествами, который силами небольшой группы собрался изменить мир. Но столкнулся с проблемами:

💬 Конечный продукт в основном производился через аутсорсинг без большой помпы и поддержки со стороны топ-менеджмента. Никто не вмешивался в процесс, и это привело к проблемам с качеством готовой продукции. Принимая во внимание небольшие ресурсы и работу с подрядчиками, самая низкая цена всегда была первым приоритетом при выборе компонентов, а остальные требования были на вторых позициях.

Тут отчетливо просматривается недооценка проекта формальным руководством.

💬 Сокращение расходов на разработку программного обеспечения не было особо мотивирующим фактором. Учитывая, что экономия была достигнута за счет менее качественных компонентов...

💬 Трудно было сохранить качество работы субподрядчиков, и контракты не контролировались должным образом. Субподрядчики могли жульничать, заменяя лучших специалистов, которые были в начале, на менее квалифицированных людей потом. Приведенные примеры включали плохой код, написанный в Индии, и проблемы со связью с китайцами и японцами из-за их плохого знания английского языка.

На эту тему была серия постов: https://www.tgoop.com/emacsway_log/1096

Которая вылилась в черновик доклада: http://kr.msk.ru/

Далее началась "Проблема Брукса", и очевидно, что формальное руководство с ним не справилось:

💬 В то же время размер команды вырос, а вместе с ней и бюрократия. Это привело к снижению гибкости и к замедлению в разработке программного обеспечения.

Далее мы видим, что разработчики осознавали ответственность за судьбу проекта больше, чем руководство. И начали защищать проект от руководства:

💬 Предложение было сразу же отвергнуто, но разработчик не сдался, поделившись примером функциональности для тестирования другими. В результате во внутренней системе Bugzilla, используемой сотрудниками Nokia для обработки ошибок, появилась цепочка длиной в несколько сотен сообщений, где руководство и разработчики спорили друг с другом по поводу этой функции. Наконец, эта функция была сделана, и в обновлении PR 1.1 она использовалась по умолчанию.

Тут просматриваются проблемы с организацией SDLC в контексте разрешения неопределенности требований:
💬 Постоянно меняющиеся требования к разработке пользовательского интерфейса вызывали внутренние проблемы в команде разработчиков

Дальнейшее развитие ситуации сравнили с историей:
💬 о человеке, работающем на нефтяной вышке, который просыпается ночью от взрыва и понимает, что вся платформа объята пламенем. Человеку удается добраться до края платформы, и ему необходимо принять решение: остаться и умереть или прыгнуть на 30 метров в темные и холодные воды. Это решение надо принять срочно.

Продолжение...

Наглядно о том, чем руководство (формальное) отличается от лидерства (неформального). Продолжение.

Была принята новая стратегия:

💬 ОС Windows Phone 7 от Microsoft, выпущенная осенью 2010 года, и ее последующие версии станут новой основной платформой для смартфонов Nokia.

Но лидеров больше интересовали интересы дела, нежели угодничество руководству - они принимают решение продолжать без руководства, которое в фигуральном смысле превратило компанию в горящую нефтяную вышку. Поэтому:

💬 Финская компания Jolla Ltd. (от фин. jolla — шлюпка), основанная бывшими разработчиками MeeGo из Nokia, вышла в свет через Twitter в июле 2012 года. Компания, в которой на данный момент [на момент публикации] работает около 60 человек, продолжает разработку операционной системы и смартфонов MeeGo, где ранее остановилась Nokia.

Вывод:

💬 Организация, однако, стала ахиллесовой пятой проекта. Под конец отдельные разработчики не имели права голоса или, что еще хуже, не знали о решениях и изменениях, которые произошли за их спиной.

💬 Появлялось все больше руководящих должностей, что в итоге не помогало двигать проект вперед и вести его к завершению.

Вполне ожидаемый результат - истребление слабоприспособленной формы хозяйствования:

💬 Пока Nokia погружалась в пучину разработки Harmattan и MeeGo, ее злейшие конкуренты Apple и Google успешно создали работающие экосистемы вокруг своих операционных систем и захватили рынок Северной Америки.

Причиной поражения в конкурентной борьбе сдала слишком долгая адаптация продукта к скоротечно изменившимся рыночным условиям. Причиной этому стал "плохой код" и Проблема Брукса.

В конечном итоге, Nokia под руководством руководителей прекратила производить смартфоны. А MeeGo, возглавляемый лидерами, продолжил свое развитие без Nokia. На его базе возникла Sailfish OS.

В 2018 году «Ростелеком» приобрел пакет акций Jolla. В 2019 году Sailfish Mobile OS Rus поменяла название на ОС «Аврора».

Поему я вспомнил об этой истории? Из обсуждений в профессиональных пабликах можно сделать вывод, что описанная в Nokia ситуация является не исключительной, а, скорее, типовой для рынка. У многих специалистов не хватает аргументов для того, чтобы предотвратить неизбежные последствия. Эта статья позволяет снабдить их хорошим аргументом - просто задайтесь вопросом: "запас финансовой прочности вашей компании больше, чем у Nokia?"

Сказ о том, как я трубку загубил, и причем здесь ИТ?

Если кто не знал - я курю трубку с 2010 года (и при этом веду спортивный образ жизни с первого класса). Так вот, была у меня трубочка, и на ней немного сошел лак. Это нормальное и естественное явление, но тогда я об этом не знал. Я ничего не понимал ни в лаках, ни в восках. Я просто хотел вернуть ей прежний блеск. Где-то я прочитал, что нужно натереть трубочку карнаубским воском. Вместо того, чтоб купить чистый карнаубский воск в виде хлопьев, я купил его смесь на основе скипидара (растворителя лака). Потому что я хотел как можно скорее получить результат. Я не мог ждать, пока я изучу что делать с твердыми хлопьями твердого карнаубского воска. Промедление было смерти подобно. Мне достаточно было увидеть в составе неизвестной смеси слово "карнаубский воск", и в условиях недостаточной информированности когнитивные искажения сделали свое дело - я был убежден в том, что это то, что мне нужно. И это освободит меня от долгого изучения правильного пути. Дело подогревалось моей хронической перегруженностью. Удивительно, но чем больше я хотел как можно скорее вернуть ей блеск, тем больше я его уничтожал.

В погоне за функцией (блеск) я пренебрёг конструкцией (которая этот блеск поддерживает). Натерев пару раз восковой смесью на основе скипидара, я обнаружил, что блеска осталось еще меньше. Но я отказывался в это верить, пока, наконец, половина трубки не осталась без лака. Ничего страшного в этом нет, и лак можно было заместить воском (некоторые даже делают так преднамеренно), но я в тот момент думал, что все испортил, и пошел на отчаянный шаг - попытался шлифануть на диске, пока не испортил покрытие окончательно. Удивительно то, что шеллачный лак у меня на тот момент был в наличии, но я не хотел тратить время на изучение способа его применения. Тогда я снял полностью покрытие наждачкой. И, вместо того, чтобы изучить про морилки и набраться недостающих знаний, я намазал трубку маслом с твердым воском графитового цвета, потому что его можно было купить в соседнем хобби-магазине Леонардо прямо сейчас, а не ждать несколько дней доставку нужной морилки. Поверхность трубки пропиталась маслом, но нужный тон цвета так и не обрела. Она настолько пропиталась маслом, что стала резиновой на ощуп, и насенение новых слоёв уже не влияло на её тон. Тогда я в сердцах её выбросил, потому что не знал о том, что бриаровая пыль используется для мелкого ремонта других трубок. Об этом я узнал потом, когда купил превосходную редкую трубку с незначительной каверной внутри мортиза, которая обычно легко шпаклюется смесью бриаровой пыли и обычного канцелярского силикатного клея (обладающего удивительной термостойкостью).

В общем, будучи ослепленным сиюминутным достижением результата, я, опытный архитектор, совершил все возможные конструктивные ошибки. Я действовал как типичный Product Owner, под воздействием системных и хорошо изученных причин. Я пренебрег долгосрочными техническими интересами в угоду краткосрочных бизнесовых интересов, и собственными руками уничтожил продукт. Я совершил все то, о чем так много говорил и предупреждал, стоило лишь мне ступить на ранее неизвестную мне конструктивную область.

Я попал в условия рядового Product Owner и поступил в точности как рядовой Product Owner. Имея доступ ко всей информации о конструкции, обеспечивающей необходимую мне функцию, я не счел нужным мириться с порогом окупаемости решения. Выбирая между "плохо, но сегодня" или "хорошо, но завтра", я ожидаемо выбрал первое. Так устроен мозг человека.

Согласитесь, что потратить несколько часов на узучение воскования и морения намного проще, чем изучать несколько лет ИТ-архитектуру. Но я, опытный архитектор, все-равно пренебрег даже этой технической малостью. Чего тогда ожидать от рядового Product Owner?

Если вы думаете, что причиной загнивания вашего проекта являются личные морально-деловые качества вашего Product Owner, то вы ошибаетесь. Эти причины системны и устраняются организацией процессов разработки таким образом, чтобы взаимокомпенсировать когнитивные искажения сторон разработки.

В продолжение темы. После института я работал в одной небольшой компании, и по объявлению нашли человека, который продавал необходимое нам б/у оборудование. Я с водителем собрался ехать на переговоры, но директор выдал мне наличную сумму новенькими банкнотами на треть меньше запрошенной, что было существенно ниже рыночной стоимости. Я попытался было возразить, но он ответил "просто достань банкноты и покажи их ему". И это сработало. Это всегда работает. Хотя он мог получить больше, если бы владел эмоциями, чем пользуются профессиональные трейдеры.

💬 It’s not about the personalities of Product versus Engineering. It’s not about short-sighted versus visionary thinking. The struggle is economic—do we make some money now or more money later? The answer is always “both”. We have to make some money now to survive. We want to make more money later. Fear versus greed. No wonder it’s so hard to get time to refactor.
-- "Behavior Change = Revenue Versus Structure Change = Option" by Kent Beck