Технологичность архитектуры (Андрей Степенко, SECR-2018) — различия между версиями

Текущая версия на 15:32, 31 августа 2021

Докладчик: Андрей Степенко

Этот доклад может быть интересен тем:

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

кто сталкивается не низкой исполнительской дисциплиной дистанционных работников,

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

Я рассматриваю устойчивость или технологичность архитектуры, которая в английском языке выражается manufacturability и означает, что ее можно повторять из проекта в проект. То есть делать по единому принципу.
Какой контекст учитывается? Существующая заказная и в значительной части продуктовая разработка полагается на большие куски готового и бесплатного кода. (Можно называть это платформами или технологиями.) Это приводит к тому, что сроки выполнения проектов для разных компаний конкурирующих на рынке могут очень сильно отличаться при наличии «библиотекарей»- экспертов кода. Конкуренция может выводить новые «элементы конструктора» готового решения в топ в течение года. Обычно это называют «скоростью обновления технологий». В данном случае нужно уточнить, И сказать про скорость обновления технологического стека. А поскольку это ключевой процесс, то он должен быть связан с другими наиболее повторяющимися процессами компании.
Такая сложность вынуждает компании заказчиков передавать инфраструктуру и интеллектуальную собственность в компанию-исполнитель и заключать с ними другие договора, нежели ранее. Условия договоров ужесточают требования к готовности к поставке и перепаду мощности, а также другие взаимно противоречивые требования. Эти требования значительно повышают требования к производственной логистике компании-исполнителя.
Так, например существуют совершенно разные циклы кодинга и тестирования для фронэнда и бэкэнда, а проектный характер работы, который приводит к большим колебаниям количества багов вынуждает переходить с аджайла на канбан и обратно по заранее не запланированному расписанию. Вопрос аджайл или канбан или водопад остаются без критериев или подходов к их применению в плоскости «а давайте еще раз попробуем». ИТ проекты наследуют 2 проблемы известных типов архитектур A и V классификации производственных систем VATI. Упрощенно один тип производственной архитектуры — это сборочные производства, а другой наоборот когда из одного изделия происходит ветвление процесса. Можно назвать это типовой структурой работ или структурой информационного потока.
C одной стороны ограничение всегда будет в начале проекта в разработке архитектуры проекта. С другой стороны, оно всегда будет в конце проекта, когда нужно делать «сборку задач» и проверять соответствие изначальному замыслу.
Согласно теории ограничений Голдрата тип ограничений задает типовые механики работы с ними. А именно координации работ в случае факапов. К сожалению, для ИТ отрасли (и продуктовой и заказной) производственная логистика и прохождение информационных потоков задает сразу 2 типа ограничения. Это производит к гарантированной разбалансировке системы управления. В материальных производствах обычно можно выстроить архитектуру, чтобы был один тип ограничений. (Именно выстроить а не «найти» ограничение.) Поэтому в логике аджайла и канбана мы никогда не найдем решения для интерактивных ограничений. А в логике ТОС и управления качеством она есть.
В докладе предлагается рейтинг, устраняющий конфликт между этими двумя ограничениями. Как правило в ИТ проектах главные люди участвуют и в запуске проекта и в его приемке. Поэтому перегруз этих людей практически гарантирован при нестабильном качестве разработки и непредсказуемых сроках, когда нужно осуществлять контроль или запуск проектов.
Предлагаемые архитектурные принципы учитывают расписание этих «наиболее загруженных ресурсов». Оценку их участия в разных активностях. Типизация этих активностей и прозрачную систему адаптации и развития компетенций, а также масштабирования компании.