Talks & master-classes|Доклады и мастер-классы

The manufacturability of the architecture|Технологичность архитектуры

October 12, 11:15|12 октября, 11:15
Room IV|IV зал

Discuss the presentation|Обсудить доклад

[lang_en]

It projects inherit 2 problems of known types of architectures A and V of classification of VATI production systems. On the one hand, the limitation will always be at the beginning of the project in the development of the project architecture. On the other hand, it will always be at the end of the project when you need to build tasks. The report proposes a rating that resolves the conflict between these two constraints. As a rule, in it projects, the main people are involved in the launch of the project and its acceptance. Therefore, the overload of these people is almost guaranteed with unstable development quality and unpredictable timing when you need to monitor or launch projects.

[/lang_en][lang_ru]

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

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

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

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

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

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

Так, например существуют совершенно разные циклы кодинга и тестирования для фронэнда и бэкэнда, а проектный характер работы, который приводит к большим колебаниям количества багов вынуждает переходить с аджайла на канбан и обратно по заранее не запланированному расписанию. Вопрос аджайл или канбан или водопад остаются без критериев или подходов к их применению в плоскости «а давайте еще раз попробуем».
ИТ проекты наследуют 2 проблемы известных типов архитектур A и V классификации производственных систем VATI. Упрощенно один тип производственной архитектуры — это сборочные производства, а другой наоборот когда из одного изделия происходит ветвление процесса. Можно назвать это типовой структурой работ или структурой информационного потока.

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

Согласно теории ограничений Голдрата тип ограничений задает типовые механики работы с ними. А именно координации работ в случае факапов. К сожалению, для ИТ отрасли (и продуктовой и заказной) производственная логистика и прохождение информационных потоков задает сразу 2 типа ограничения. Это производит к гарантированной разбалансировке системы управления. В материальных производствах обычно можно выстроить архитектуру, чтобы был один тип ограничений. (Именно выстроить а не «найти» ограничение.) Поэтому в логике аджайла и канбана мы никогда не найдем решения для интерактивных ограничений. А в логике ТОС и управления качеством она есть.

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

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

[/lang_ru]

Andrey Stepenko|Андрей Степенко

Андрей Степенко. Технологичность архитектуры

strategy advisor|траблшутер, Bazalt|Базальт

[lang_en]

For 20 years I have been engaged in trabshuting in companies from 50 to 5000 people.
The last big projects in IT companies: Kaspersky and Nekreker.
In addition to IT companies, construction, new materials, microelectronics, hotels, financial services.

[/lang_en][lang_ru]

20 лет занимаюсь трабшутингом в компаниях от 50 до 5000 человек.
Последние большие проекты в ИТ компаниях: Касперский и Некрекер.
Помимо ИТ компаний строительство, новые материалы, микроэлектроника, гостиницы, финансовые сервисы.

[/lang_ru]

Sponsors & Partners|Спонсоры и партнёры

Sponsors|Спонсоры

Gold

JetBrainsFirst Line Software

Sponsors

BellSoftPVS-Studio

Embedded|Embedded

Auriga|Аурига

Partners|Партнёры

Gold|Золотой

Digital October

Main partners|Генеральные партнёры

RUSSOFT|РУССОФТAP KIT|АП КИТ

In cooperation|При содействии

ACM Special Interest Group on Software EngineeringAssociation for Computing Machinery

Technical partners|Технические партнёры

CUSTIS0x1.tvMajordomo

Organizers|Организаторы

Software Russiai-Help