Часть 2

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

Ссылки: Нассим Талеб - "Рискуя собственной шкурой"

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

[Проектирование систем. Часть 1]

"Если мы не можем что-то объяснить 6-летнему ребенку, то мы этого не знаем" (с) - Альберт Эйнштейн (на этот раз действительно он).

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

Первое, что необходимо понять, зачем мы все это делаем. В чем суть проекта?

Представим, что мы проектируем систему для учета и продажи сахарных (oh sick!) петушков. Заказчик опросил всех знакомых детей и с полной уверенностью в проекте готов выделить X рублей на разработку системы.

От заказчика получаем требования:
1. В любой момент времени мы должны знать сколько именно петушков готовы к раздаче и сколько находится на сборке в заботливых руках конвейерных роботов. Точность инвентаризации (количество товара "на лицо") в реальном времени не ниже 99%.

2. Управление каналами продаж: ярмарки, онлайн, оптовые закупки. Время оформления онлайн не более 3 минут.

3. Заказчик хочет видеть затраты на производство петушка и прибыль/убыток по каналам.

4. Заказчик хочет знать, насколько происходящее сейчас не соответствует тому, что он представлял вчера.

5. Прочие требования

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

Предположим, что цель в формировании масштабируемого бренд-бутика "Сахарный Друг", который к 2028 году войдет в топ-3 российских производителей ремесленных леденцов, сохраняя разницу операционная прибыль/вычеты более 15% (простите дети - EBITDA >=15%) и долю повторных покупок не ниже 40%. Обращу внимание, что цель выражена конкретно в числах, она измерима.

Миссия: Возрождение сладких традиций в новом обличии и привнесение теплого ощущения детства через каждый леденец (а почему нет?)

Концепция: Ремесленные петушки для ностальгии, модерн-петушки для современных детей - сезонные вкусы (облепиха, смородина, мохито). Живой процесс на ярмарках: люди видят, как петушки готовятся. Маркетологи описывают процесс как "звук кипящего сиропа, аромат карамели, мастер крутит длинную карамельную нить, формует петушка. Покупатель получает еще теплый леденец и делает фото в фирменной фотозоне".
Брендинг: в стиле 60х для "вкуса детства" и современный петушок для сезонных вкусов (самокатчик, геймер, промт-инженер)

Далее мы переходим к ознакомлению с доменной областью (областью проблемы), уточняющим вопросам по требованиям и пониманию ключевых процессов.
Для этого можно пользоваться своим опытом, опытом привлекаемых экспертов, клиентским опытом или LLM (GPT и его вариации).
Извлекаем из доменной области дополнительные вопросы о регулировании: нужен ли "Честный знак" или GS1-штрих-код. Необходимо ли соблюдать GDPR/152-ФЗ по персональным данным онлайн и оптовых продаж? Необходимо ли кассовый модуль согласно 54-ФЗ РФ?
...
Продолжение в части 2.

[Проектирование систем. Часть 2]

Глоссарий
Нефункциональные требования (НФТ) - требования, которые прямо не указывается в сценариях использования системы. Например: требования к производительности, обращения с персональными данными, доступности.

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

MVP - minimal viable product - минимально жизнеспособный продукт, включающий реализацию основных функций системы; своего рода демонстрационный вариант. Иногда MVP перерастает в полноценный продукт, иногда – отбрасывается.

Стейкхолдер - заинтересованное в проекте лицо. Интересы стейкхолдеров в отношении реализации системы могут быть диаметрально противоположны.

Декомпозиция - процесс разбиения функционала системы на взаимосвязанные блоки. Как правило, разбиение осуществляется для снижения когнитивной нагрузки на разработчиков и соблюдения НФТ. Декомпозиция может показаться простым (это неправда) и интуитивно понятным процессом (это правда).
----------------------------------

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

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

Опыт говорит, что реализация системы наименее трудоемкий и более предсказуемый процесс, чем согласование требований и их перекладывание в проектировочное решение. Проблема в том, что не всегда удается задать правильные вопросы до начала разработки. А когда система находится в разработке - задавать такие вопросы бывает поздно. В этом противоречии проявляется ценность подходов детального проектирования или MVP.

Требования должны быть зафиксированы. Формат - опционален, но предпочтительнее использовать стандартные форматы и нотации для диаграмм. В современной практике популярны диаграммы C4 (из-за их простоты. На превью текста можете убедиться, что понять их достаточно просто. Это демонстрационный вариант схемы, не решение), UML диаграммы (как правило неполный набор). Кроме того, данные нотации легко описываются в текстовом виде позволяя хранить их в системах контроля версий, оперативно изменять или пользоваться AI для их построения.

Визуализация - ключевой процесс проектирования, коммуникации и мышления. Несмотря на очевидность этого факта, команды время от времени этим пренебрегают. В результате имеем всем знакомые проблемы с "извините, мы неправильно поняли/я представлял это иначе/я думал, что мы друг друга поняли".

Опираясь на описанные сценарии, НФТ и пожелания бизнеса, можно переходить к началу декомпозиции системы.

...
Продолжение в части 3.

[Проектирование систем. Часть 3]

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

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

Если мы имеем плохо определенную ответственность компонентов, например, если чайник будет отвечать еще и за охлаждение продуктов, то продукты быстро испортятся, а нагревание воды замедлится из-за холодильного отсека по соседству. В итоге мы получаем конфликт процессов внутри одного компонента - коррозии и конденсате, приводящим к порче данных (протухание продуктов) и неадекватной связанности самих процессов, которая выливается не только в технический, но и коммуникационный конфликт: вы хотите нагреть воду, а я охлаждаю молоко, в этот момент мы перестаем нравиться друг другу.

Более прикладной пример: для получения заказа с маркетплейса с последующим отказом (от заказа), может быть построена следующая последовательность:
1. Сервис "витрина товаров", функция: вывод списка товаров на сайте.
2. Сервис "корзина", функция: добавление понравившихся товаров в список потенциальных покупок.
3. Сервис "оплата", функция: предоставление оплаты по карте или СБП.
4. Сервис "логистики", функция: оптимальный маршрут доставки в удобное для вас отделение.
5. Сервис "решение конфликтов", функция: возврат средств, анализ отказа.
Большинство декомпозированных систем отлично работают!
...на диаграммах в изоляции от реального мира.

Но на практике возникает ряд вопросов:
- Кто должен контролировать эти процессы и управлять ими (оркестрировать)?
- Если нужно рекомендовать товары на основе истории взаимодействия с системой, где разместить этот функционал — в сервисе просмотра товаров? Возможно.
- А что, если рекомендательная система будет настолько ресурсоемкой, что просмотр будет недоступен для части пользователей?
- Может объединить сервис корзины с просмотром товара и назвать его сервис заказа? Ведь если нет товара, то зачем отдельная корзина?
- Если это сервис заказа, должен ли он включать оплату? Что вообще означает "заказ" для данной системы?

Таким образом, интуитивно понятный процесс декомпозиции нередко превращается в истеричную борьбу с лишней сложностью: запутанным кодом внутри компонентов, дополнительными затратами на переделывание (рефакторинг), конфликтами производительности, доступности, безопасности.
Одним словом - контекст! Контекст - совокупность тех нюансов, которые способны изменить типовую (референсную) декомпозицию до неузнаваемости.
Нюансы контекста становятся почвой для появления методик поиска мифической "оптимальной" декомпозиции систем.

О конкретных способах декомпозиции - в части 4

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

[Agile и процедуры проекции. Часть 1]

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

За последние 5 лет (Agile существует более 20 лет), слышал разные мнения по поводу применения семейств методологий, многие из них распространенные заблуждения, которые мы могли наблюдать, читая форумы по топику гибкой разработки: Agile не требует настроенных процессов коммуникации, Agile для быстрой разработки любой ценой, Agile - это про коллективную ответственность и тому подобное.

Эти представления имеют право на существования и могут быть эффективны для определенных ситуаций при балансе прочих атрибутов гибких методологий.

В принципах Agile, если читать исходник манифеста, много полезных, правильных и иногда очевидных вещей, но они воспринимаются изолированными друг от друга, под ними не чувствуется фундамента.

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

Формулировка кажется очевидной для enterprise-разработчика, но к ней я пришел практически и не благодаря принципам Agile, а занимаясь оптимизацией процессов производства ценности продуктовыми и проектными командами.

Определение содержит 3 основные части:
1. Своевременная адаптация систем
2. Изменяющаяся бизнес-среда
3. Ресурсные ограничения

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

2. Чтобы система могла эффективно реагировать на изменение бизнес-среды, команда должна обладать экспертными знаниями предметной области:

во-первых, чтобы сделать действительное проектировочное решение (ДПР - решение, удовлетворяющее основным ценностным сценариям заложенным бизнесом в систему)

во-вторых. чтобы видеть мотивы или корневую проблему, которая порождает поток изменчивых дополнительных требований

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

3. Системы не разрабатываются вне контекста, поэтому каждое изменение должно быть оценено с точки зрения адекватности для бизнеса и ресурсов, а это невозможно сделать в отрыве от истории изменений, документации, описании архитектурных свойств, планирования и оценки влияния изменений на состояние системы.

От спринта к спринту система изменяется и решение вопроса переноса системы из состояния 1 в состояние 2 невозможно без зафиксированных процедур переноса в желаемое состояние. В большинстве случаев Agile спринты короткие, что позволяет не допустить серьезного изменения среды между спринтами и делает процесс изменения состояния более предсказуемым. Это верно для тех ситуаций, когда команда знает о вложенной в спринт ценности для бизнеса на текущий момент, т.е. имеет представление о потенциальной (и, желательно, измеримой) дельте. Нужно принимать во внимание то, что величина дельты (положительного изменения системы) истекает со временем за счет изменения бизнес-среды.

Не задаваться вопросом переноса состояния системы - серьезная ошибка. Процедуры переноса - основа развития для технических и социотехнических систем вообще. Отсутствие зафиксированных и реализованных операций переноса - отсутствие Agile

[Agile и процедуры проекции. Часть 2]

Чтобы проще понять сложность процедур переноса, можно рассмотреть пример: мы прочитали книгу про высоконагруженные системы и теперь нам необходимо построить высоконагруженную систему.

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

После проектирования мы имеем точку "старт", откуда начнем применять процедуры переноса на объект - в структуру системы и инфраструктуру. Все мы прекрасно понимаем, что количество проблем, с которыми мы столкнемся в процессе переноса концепта на железо, стремится к бесконечности. Можно решать проблемы на ходу, но это подобранные эмпирически процедуры, менее полноценные из-за их сподручности, они несистемны.

Для увеличения шансов процедур переноса, необходимо иметь представление о текущем (точка старта) и будущем (объект-результат) состояниях системы, перечень операций, которые необходимо применить к ней, план и понимание ценности спринта всей командой. Добавленная ценность (дельта) должна быть измерима в результате.

Процедуры переноса подразумевают настроенные процессы и их формализацию, документирование, эффективную коммуникацию с визуализацией на общем "холсте" и оптимальное умение перерабатывать требования в поведение антихрупкой системы.

Для наших команд перенос состояния выглядит следующим образом:

1. Получение бизнес-требований
2. Коммуникация с клиентом для подтверждения мотивов требований, преобразование бизнес-требований в поведение системы и определение ключевой ценности спринта, формализация измеримых метрик желаемого результата
3. Проработка нового поведения с командой с обязательным выносом командного мышления на вышний носитель (draw.io, miro, ms whiteboard, любые другие удобные команде средства), соотнесение нового поведения с проектировочным решением, определение технической "разницы" между версиями систем, по необходимости составление ADR
4. Анализ соответствия нового поведения архитектурным свойствам системы
5. Декомпозиция задачи, составление плана
6. Разработка
7. Тестирование, замеры, фиксирование результатов

Agile - зрелое понятие для взрослых команд, ориентированных на эффективность, а баланс в применении ценностей и принципов манифеста, как и их набора, определяется реальной целью команды, текущим моментом времени и выделенными на проект ресурсами.

[Проблема психологической инерции и ТРИЗ]

Обычное состояние нашей психики - сопротивление работе, требующей усилий. Зачем тратить лишние силы, если ежедневные проблемы так или иначе решаются. Если на любой вопрос так или иначе последует ответ или череда уточняющих предложений, а технические задачи решаются проверенным способом или даже инструментом - лбом.

Психологическая инерция - комфортное для человека явление, направленное на сбережение сил и уменьшение стресса.

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

Мы хватаем привычные термины и готовые паттерны вместо того, чтобы увидеть суть задачи.
Один из способов, который может помочь менять привычный ход мысли - это ТРИЗ.

ТРИЗ или "Теория Решения Изобретательских Задач" - набор методов решения задач с помощью постановки технических противоречий, созданный советским ученым Генрихом Альтшуллером.

Говоря кратко, в ТРИЗ есть пару простых шагов, которые помогут преодолеть умственную инерцию:

1. Убираем профильные слова, чтобы уйти от привычного словаря

2. Формулируем техническое противоречие: что нужно улучшить и что при этом ломается.

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

Чем чётче вопрос, тем меньше шансов загнать систему в тупик.

Приведем пример:
Есть система, безопасность которой не удовлетворяет текущие требования, но есть строгие ограничения сложности процесса для пользователя, накладываемые UX. Проблема уже достаточно четко выражена в виде противоречия между безопасностью и UX.

Представим систему в форме, свободной от профильных понятий:

1.Мы контроллер и перед нами проходят нечто.

2.У нас нет никаких устройств, в наличии только один турникет, который мы открываем или закрываем в зависимости от чего-то (пусть это будет билет), предъявляемого нечто.

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

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

В один момент, мы можем прийти к мысли, что дополнительной информацией о нечто, является само наличное существование нечто, которое проявляется в движении, направлении и местоположении, т.е. мета-информация: поведенческий анализ, геолокация, метки-устройства, как дополнительные факторы проверки пользователя без вмешательства в UX.

В итоге мы получили ИКР - идеальное конечное решение - системы нет, но ее функции выполняются, иными словами, мы нашли решение, которое не влияет на UX, при этом отбрасывая первое, что приходит в голову: OTP, аутентификатор, email-подтверждение.

Подход не гарантирует 100% нахождение ответа во всех задачах, но позволяет посмотреть на проблему с другой стороны.

Упражнение для практики:

Когда пользователей становится много, система начинает тормозить. Добавляем серверы — растут расходы.

Отбросьте те решения, которые приходят к вам в голову сразу.

Необходимо четко обозначить техническое противоречие и выработать решение через замену профильных терминов нейтральными или абстрактными и использовав ИКР.

[Свойства систем. Observability. Часть 1/2 - Мониторинг. Жизнь и действие]

Каждая действующая бизнес-система имеет врождённые свойства (обычно, не указываемые прямо в спецификациях):

К ним могут относиться: осуществимость (feasibility), надёжность (reliability), безопасность (security), но сегодня речь пойдет про свойство, которое на первый взгляд может показаться неважным (т.к. не приносит прямой бизнес-ценности на первых этапах существования).

Речь про наблюдаемость (observability), как совокупность подходов, делающих систему «осязаемой» для разработчиков и бизнеса.

Что значит, что система "осязаема"?

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

Система живёт, действует, получает обратную связь, изменяется и на этом основываются составляющие наблюдаемости систем: мониторинг (проявление жизни и действия), логирование и трейсинг (обратная связь и изменения).

Жизнь системы проявляется в метриках её текущего состояния:

Набор USE-метрик:
– Utilization — утилизация. Сколько процентов времени ресурс занят работой.
– Saturation — насыщенность. Объём вытесненной или отложенной работы.
– Errors — метрики ошибок.

Набор RED-метрик:
– Requests Rate — частота запросов.
– Errors — показатели ошибок.
– Duration — длительность. Время, затраченное на выполнение одного запроса.

Четыре золотых сигнала от SRE Google:
– Delay — задержка. Время на доставку запроса от сервера к пользователю.
– Traffic — количество HTTP-запросов в секунду и другие показатели активности пользователей.
– Errors — количественные показатели ошибок.
– Saturation — насыщенность. «Заполненность» системы работой.

Действие системы проявляется в бизнес-эффекте или бизнес-метриках:

North Star Metrics (NSM) — концепция из продуктовой аналитики. Главная суть — выделение одной метрики, которая отражает ключевую ценность для пользователя (business SLOs).

Например, для системы подачи заявок на приобретение продуктов это количество успешно приобретённых продуктов, для системы обратной связи — комплексный показатель из отношения принятых заявок, обработанных заявок и индекса удовлетворённости.

HEART Framework (для систем, где важен пользовательский опыт):
– Happiness — удовлетворённость (опросы, NPS).
– Engagement — вовлечённость (частота взаимодействий).
– Adoption — рост числа новых пользователей или функций.
– Retention — удержание.
– Task Success — успешность выполнения задач.

Смежные подходы, объединяющие жизнь и действие:

Metric-driven или Observability-driven подход подразумевает:
– Высокую кардинальность метрик (низкий семплинг, то есть сбор максимума информации о каждом пользователе без усреднения).
– Установку SLIs (Service Level Indicators) — метрик, ориентированных на сценарии, например, время заполнения анкеты или время прохождения верификации.
– User Journey Monitoring — метрики на уровне end-to-end сценариев (регистрация → прохождение верификации → заполнение анкеты → открытие счёта).

Пирамида метрик (Metrics Hierarchy):
– Бизнес-метрики: выручка, количество заказов, MAU/DAU, успешные транзакции.
– UX-метрики: время отклика, процент успешных действий, показатели отказа.
– Технические метрики: CPU, RAM, Disk I/O, Network activity.

Методы внедрения наблюдаемости «жизни-действия» не ограничиваются перечисленными подходами и в реальных системах обычно перемешаны.

Для изменения системы под влиянием обратной связи, внутренних сигналов, применяется логирование и трейсинг.

Свойства систем. Observability. Часть 2 - Логирование и трейсинг. Обратная связь и изменение системы...

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

Итеративное развитие контекста сильно помогает в составлении mindmaps, диаграмм процессов и определении типовых технических проблем.

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

Страх перед регуляциями - траты на безопасность, аудит и правильную декомпозицию.
Страх конкуренции - траты на time-to-market (ci/cd, maintainability), надежность и инновационность, чтобы не быть съеденным в red ocean.
Страх потери маржинальности в среднемаржинальных/низкомаржинальных областях - выверенная финансовая/мотивационная составляющие, акцент на снижение сложности систем.

Можно попробовать исследовать системы конкурентов, насколько это возможно (1. их может не быть, 2. они могут быть закрытыми)

В то же время коллегами были предложены несколько интересных методов:
1. Наим консультантов (логично, особенно, если есть деньги)
2. Перекуп спецов у конкурентов (что же, логично, особенно, есть деньги)
3. Приглашение спецов доменной области на собеседования и выпытывать нюансы (логично, особенно, если денег нет)

Если есть мысли на этот счет, буду рад подискутировать

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

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

Настоящее ремесло - это простота, прошедшая проверку сложностью.

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

Но как показывает практика, в том числе архитектурная, эффективный процесс - это компромисс между качеством и эксплуатационной сложностью.

Для оценки необходима итеративность, потому что вновь настроенный процесс не всегда соотносится с результатом напрямую. Хорошо настроили, хорошо делали, старались и... сорвали сроки (например, из-за проблем клиента, накопившейся регрессии или избытка инженеров при реализации задач спринта)

Та самая неочевидная очевидность

Наблюдая за изменением моих представлений о рабочих процессах и методах, я замечаю, что доля подходов, основанных на динамике, постоянно растёт.

Что такое Agile? Это адаптация к изменяющемуся бизнес-окружению.

Что такое хорошее проектировочное решение? Это решение, которое выдержит течение времени.

Самый релевантный метод мысленной валидации архитектуры в моей базе знаний — метод Barry O'Reilly "Residuality Theory", заключающийся в применении к проектировочному решению стрессоров - потенциальных рисков будущего.

И, кажется, я начинаю догадываться, почему мне всё больше нравится функциональный стиль в программировании.

В императивном стиле мы работаем дискретно, описывая алгоритм шаг за шагом.

В функциональном стиле (позволю себе назвать его строгой версией декларативного) мы описываем поток — движение данных через систему.

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

Фраза «прими реальность» после этого обретает иной оттенок.

Пример императивного подхода:

        List<int> numbers = new List<int> { 1, 2, 3, 4, 5 };
        List<int> evenNumbers = new List<int>();

        foreach (int n in numbers)
        {
            if (n % 2 == 0)
            {
                evenNumbers.Add(n);
            }
        }
        foreach (int n in evenNumbers)
        {
            Console.WriteLine(n);
        }

Функциональный подход:

 var numbers = new List<int> { 1, 2, 3, 4, 5 };

        var result = numbers
            .Where(IsEven)     
            .Select(Square)     
            .ToList();

        result.ForEach(Console.WriteLine);

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

Представляем нашего телеграм-маскота:

[Антихрупкость систем]

Н. Талеб пишет о том, что антихрупкие системы обучаются в периоды стрессов. Некритичные повреждения отсекают неэффективную массу, оставляя только то, что действительно работает.
Система, которая никогда не сталкивается со стрессом, обречена на неэффективность и смерть — у неё нет механизма адаптации к изменчивости (привет, псевдо-agile).

Отчасти цель методов хаос-тестирования заключается в ускорении эволюции систем.

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

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

Антихрупкость - это результат обучения систем через стресс.

[Зачем есть рис[к] на завтрак]

Риск — понятие, непосредственно связанное с построением концепций, планов и принятием решений, независимо от занимаемой позиции.

Risk assessment — одна из самых сложных составляющих проактивной работы и важная часть любого плана.
Составление плана — задача нетривиальная, ведь суть плана — это упорядочивание будущего.

Вы умеете предсказывать будущее? И я.

70% читателей улыбнулись.

Risk assessment связан с реестром рисков, а записи, которые мы ведем — RAR (Risk Assessment Record).

Рассмотрим пример из реестра рисков для нового продукта, принятого на поддержку:

Описание риска: риск утечки персональных данных

Категория риска: Технический

Причина возникновения: пробелы в документации по контролю доступа переданной системы

Вероятность (зависит от компании, продукта): 2/5

Влияние (зависит от компании, продукта): 5/5

Уровень риска: Вр (2) * Вл (5) = 10 (Средний)

Действия: ревью всех методов доступа из панели администратора

Ответственный: А. Баголюбов

Статус: В процессе ревью

Дата обновления: 25.10.2025

Планируемая дата закрытия: 01.11.2025

Колонка «Действия» может содержать классические Risk Actions. Например:

Описание риска: Получен новый контракт, но возможны проблемы из-за использования нового технологического стека (потенциальный репутационный ущерб)

Категория риска: Операционный

Вероятность: 3

Влияние: 5

Уровень риска: 15 (Выше среднего)

Возможные действия:

Risk Avoidance (избегание риска) — отказаться от контракта, исключив потенциальную потерю репутации, но потеряв клиента, деньги и возможность Risk Exploitation (использования шанса на расширение).

Risk Mitigation (смягчение риска) — изменить баланс между junior и senior специалистами на проекте, добавить QA для превентивного контроля конфликтов и падения качества.

Risk Transfer (передача риска) — отдать часть критического функционала на аутсорсинг или доработать open-source решение.

Risk Acceptance (принятие риска), но с Risk Contingency (планом реагирования) — разработать сценарий действий на случай конфликтов с клиентом или проблем с приложением.
Например: при возникновении проблем с продуктом привлекается внешний эксперт для консультаций.

После формирования реестра рисков его необходимо постоянно мониторить на предмет изменений статусов и дополнений.

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

- Исключение токсичного сотрудника может вызвать риск снижения темпов выпуска функционала.

- Передача ключевой функциональности на аутсорсинг создаёт риск vendor lock-in (зависимости от поставщика) и потери экспертизы внутри команды.

- Risk Exploitation может привести к риску выгорания команды из-за возросшей нагрузки — требуется грамотная оценка эффективности и состояния сотрудников.

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

Методы взаимодействия с рисками (Avoidance, Mitigation, Acceptance, Transfer и другие) применяются также при проектировании архитектуры систем.

Думать о том, как сделать продукт, функционал или процесс управления архитектурой менее рискованными, необходимо заранее, на этапе концептов и планирования:

- не собирать данные без необходимости (Risk Mitigation);

- не писать собственные криптографические алгоритмы (Risk Mitigation, Risk Avoidance);

- использовать надёжные технологические стеки для ядер бизнес-систем (Risk Mitigation);

- применять современные технологии осознанно (Risk Acceptance);

- не изобретать велосипеды в вопросах надёжности и отказоустойчивости (Risk Transfer, Risk Mitigation, Risk Avoidance);

- иметь план по использованию возможностей в соответствии с оперативными и стратегическими целями компании (Risk Exploitation).

Итого:
1. Идентифицируем (имя, описание)
2. Оцениваем (в баллах)
3. Ранжируем по уровню (приоритет)
4. Применяем политику (risk actions)
5. Мониторим

Варианта всего два:
или мы оцениваем риск —
или риск оценивает нас.