🤔 Два месяца пишу об одном и том же. Много постов с объяснением сложных архитектурных паттернов, которые поймут три с половиной senior-разработчика. А вывод-то какой из всего этого?

📜 В начале была фича. И фича была у Product Owner'а. И фича эта была: "Хочу редактировать проект параллельно с другим пользователем, чтобы все это хранилось в единой истории, и любое изменение можно было откатить". И потянула она за собой такой объем архитектурных решений, что вокруг нее пришлось проектировать все приложение.

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

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

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

📊 Хороший аналитик не может всерьез мыслить категориями "Я пишу только требования, с остальным разбирайтесь сами". Каждая строчка требований имеет свою цену. Если аналитик не смог донести ее до бизнеса, она все равно всплывет в зарплатной ведомости команды разработки.