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

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

---

О причине противоречия

Начну издалека — с XVIII века. Развитие и обобществление производства вкупе с конкуренцией подстёгивают производителей раз за разом модернизировать и автоматизировать производство. Паровые машины, Жаккардовый ткацкий станок, конвейеры, производственные линии и роботы — все эти улучшения играют свою экономическую роль — дают конкурентное преимущество, являясь предпосылкой к ещё большему обобществлению труда, а именно, объедению цепочек производств. В результате производства расширяются, могут планировать своё развитие и автоматизацию, чтобы получать ещё большую прибыль.

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

Чтобы не говорить о слишком высоких материях, предлагаю опуститься до нашей непосредственной деятельности. Для бизнеса всегда выбор — посадить 10 человек за 10 unit'ов делать некоторую простую работу или 4 человека за 25 unit'ов будут автоматизировать эту работу, а потом обслуживать. И ваше чёткое понимание тонкостей нужд бизнеса и инженерных требований может помочь сделать этот выбор в сторону интенсивного пути развития. И что же значит для заказчика выбор такого пути?

Часть дня мы работаем на себя, а часть дня на работодателя или заказчика. Позволю себе это выразить следующей формулой стоимости:

, где

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

В случае разработки ПО есть нюансы — если софт является сервисной частью бизнеса, непрерывно развивающейся, то приходится делать некоторые работы на прямую не связанные с решением бизнес-задачи. Почувствуйте разницу — то что могло быть потрачено на несколько людей меньшей квалификации, тратится "на работу ради будущей работы". Если перенести это на формулу, то это означает что мы проводим работы в пользу постоянного капитала c, должны потратить средства из чьих-то зарплат v, из прибыли m или за счёт стоимости товара W. Следует рассмотреть подробнее.

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

• m — заказчик может поступиться своей прибылью. Имя этому инвестиция, т.е. контролируемый риск получения большей прибыли. При этом риск должен быть осознан. Если вы решили за чужие деньги научиться делать огромные комплексы — это неконтролируемый риск. Другое дело, в рамках ретроспективы, например, провести небольшой эксперимент, оценить результаты и двигаться поступательно дальше.

  
  

• W — заказчик может поднять цену своих продуктов и услуг. Монополии вполне могут себе позволить повысить стоимость и скорее всего так и делают. Но скорее всего заказчик всегда ужат конъюнктурой рынка.

  
  

• v — Можно поступиться чьей-то зарплатой, и тут есть варианты.
  1) Вы пожертвуете своей. Будете перерабатывать или делать Open Source проект, который поможет вам на работе.
  2) Вы автоматизируете чью-то работу, что позволит использовать меньше людей.

  
  

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

  
  

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

Антагонизм требований

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

• Сторона бизнеса (PO, SH) хотела бы произвести работы так, чтобы потратить на это наименьшее количество ресурсов. Представить эту позицию к сожалению, очень несложно, ведь она проникла не только в нашу жизнь, но и фольклор IT — сова эффективный менеджер самый яркий пример.
• Исполнителям (Team) необходимо провести такой набор работ, чтобы обеспечить решение ключевых аспектов архитектуры для решения бизнес-задачи, без накопления технического долга, в идеале и инструментарий для более быстрого решения задач. Бизнес команды — поставка программного обеспечения, а архитектура — имеющийся в её распоряжении постоянный капитал.

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

• Что именно мы делаем для заказчика, какая ожидается польза?
• Частота применимости данного решения.
• Вероятность изменения/расширения требований.
• Есть ли связь с другими системами/сервисами/контекстами?

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

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

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

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

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

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

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

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

От баланс требований к балансу работ

В разговоре о жизненном цикле ПО модные коучи и тренеры Agile не вспомнят известную диаграмму И.Адизеса.

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

За ось абсцисс взята сложность бизнесовых фич. За ось ординат — сложность архитектурных работ. Под сложность имею в виду банально story points. Откладывая исполнение фич на этом графике можно видеть, насколько адаптивное к последующим изменениям ПО вы выпускаете.

• Чем правее относительно ОТЦ последняя точка графика, тем раньше продукт принесёт пользу и тем сложнее его будет развивать под сложные задачи.
• Чем левее относительно ОТЦ последняя точка графика, тем больше вы увлеклись платформингом, и рискуете не предоставить работающее ПО к сроку.
• Соответственно стоит придерживаться равномерного развития, т.е. движения вдоль оси.

На рисунке выше моё представление о том, как выглядит связь потраченного времени на реализацию бизнес-возможности X и архитектуру Y, где ось Z отражает полезность продукта.

Заключение

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

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

О связи тулинга и бизнеса рекомендую посмотреть в докладе Кирилла Скрыгана Platform (IDE) wars.