Двойственная природа требований к программному обеспечению

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

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

СvБ


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

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

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

Что бы не говорить о слишком высоких материях, предлагаю опуститься до нашей непосредственной деятельности. Для бизнеса всегда выбор — посадить 10 человек за 10 unit’ов делать некоторую простую работу или 4 человека за 20 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, а завтра не сможете в срок сделать новый функционал из-за накопившихся проблем продукта.

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

ссылка на оригинал статьи https://habr.com/ru/post/484932/

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *