Всем привет!

У меня есть публичный проект Архитектурные Этюды, в котором мы сообществом решаем реальные архитектурные задачи. Подумал сделать цикл статей, в котором представить анализ представленных проблем с учетом обсуждений участников и показать как могут выглядеть решения при всестороннем архитектурном рассмотреи. Первым кейсом выбрал «Хранение классифицированных данных», он не сложный, для многих – актуальный, поэтому выбор пал на него.

Типовая ситуация: в проект приходят умные люди, менеджеры внедряют эффективные процессы, а проект все равно превращается в болото. Фичи разрабатываются месяцами, релизы откладываются, а на ретроспективах все жалуются на зависимости. При этом на схемах все выглядит красиво: микросервисы, CI/CD, облака. Что с этим миром не так?

Понятно, что «не так» может быть что угодно и как обычно it depends, но здесь и сейчас разберем одну из возможных причин, а именно ситуацию, при которой архитекторы и техлиды работают только с одним видом сложности – технологической. Рисуют квадратики, проводят стрелочки, выбирают базы данных. Реальность разработки при этом гораздо сложнее: в любом проекте одновременно живут три вида сложности, и они постоянно влияют друг на друга.

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

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