emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

С сегодняшнего дня я хочу начать цикл постов об антикризисной архитектуре. И постараюсь структурировать все свои знания по этой теме. Итак, представьте, что Вы - архитектор, и Вам достался кризисный проект. Думаю, что многим не составит это особого труда…

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

Попытаемся распутать клубок и выстроить тактику поведения в таких условиях.

"Внесение изменения длится неприлично долго" - из этой фразы вытекает два важных вопроса:
1) Почему изменение нужно вносить именно сейчас? Почему нельзя было сразу сделать как нужно?
2) Почему вносить само изменение долго и дорого?

Первый вопрос лежит в Problem Space, и отностися к области анализа и управления процессами разработки.

Второй вопрос лежит в области Solution Space и относится к области Software Design.

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

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

Кроме этого, внесение изменений может встретить сопротивление, что потребует еще и навыков коммуникативной и управленческой психологии.

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

🔥14👍8

www.tgoop.com/emacsway_log/1378

1.88K viewsIvan, edited  Apr 21, 2024 at 12:50

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

Попытаемся распутать клубок и выстроить тактику поведения в таких условиях.

"Внесение изменения длится неприлично долго" - из этой фразы вытекает два важных вопроса:
1) Почему изменение нужно вносить именно сейчас? Почему нельзя было сразу сделать как нужно?
2) Почему вносить само изменение долго и дорого?

Первый вопрос лежит в Problem Space, и отностися к области анализа и управления процессами разработки.

Второй вопрос лежит в области Solution Space и относится к области Software Design.

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

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

Кроме этого, внесение изменений может встретить сопротивление, что потребует еще и навыков коммуникативной и управленческой психологии.

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

BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.