"...А еще поняла, что если что-то непонятно в PR, то лучше спросить, чем промолчать. Однажды, задав несколько вопросов, я выяснила , что соседняя команда планирует выводить в следующем релизе изменения, которые сломают наш API. Написала аналитику, выяснила, что произошло недопонимание – обе стороны были уверены, что все ок."

"...К сожалению, коммитить спецификации в прод пока нельзя, буду работать с ними локально."

(из свежих отчётов)

...Это я к тому, что так работает (попытка внедрить) BDD/SDD на практике. (AI)спеки - что они представляют-то? Аналитик что-то накидал, openspec перевёл это в "спецификации", но у кого-то из них есть целостная модель системы, из которой они исходят? Могут показать?

Интерпретация ТЗ (богатой семантики) превращается по сути в самое слабое звено. Нагенерила нейронка 100500 спек/требований, и что толку, что они человекочитаемые, когда нету никого, у кого в голове есть системный образ, который увязывает это всё и позволяет делать полноценные ревью.

Спецификация это карта а не территория, и вместо того чтобы изучать саму систему, мы можем изучить спецификацию - в идеале. А на практике?

Я: - Обнаружил тут, что ваша система делает [что-то], но в вашей документации подразумевается [что-то другое].

Клиент: - Ага, да это не имеет значения.
или
- А мы это изменили шесть месяцев назад.

...Я: - Вы хотите, чтобы спецификация допускала [такое-то поведение]?

Клиент - эээ… не знаю, я никогда не думал об этой ситуации.

Я: - И если вы это разрешите, вам также придётся разрешить [и какое-то другое поведение]. Это имеет значение?

Клиент: - Я тоже не знаю, как обстоят дела в таком случае… Мне надо посоветоваться, не знаю сколько времени это займёт...

=

Сермяга в том, что подготовка (формальных) спецификаций -- очень сложная задача, которая требует нисходящего понимания системы, которого у аналитиков, проектировщиков и программистов обычно нет, или, что более важно, в котором они сами отчаянно нуждаются!

Поэтому все работают с неформальными спецификациями, которые неоднозначны и частичны (и это называется "гибкостью"). Неформальные спеки по своему определению "неверные, но полезные", что само по себе некоторое преимущество, но оно также приводит к созданию систем, о которых трудно рассуждать.

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

Ещё одна огромная, и сильно недооценённая польза качественных спецификаций, которые готовятся вручную, в том, что как при написании тестов часто находятся ошибки, так и при написании спек находится куча противоречий и логических несоответствий.

Что с этим делать? На Функциональных архитектурах разбирал например тему Мета-DSL, когда мы осознанно уходим в языки с бедной семантикой.

...При том, что на самом деле никакие спецификации не существуют, ибо теоретически невозможно написать абсолютно точную и последовательную спецификацию.

...И тем не менее, я продолжаю и продолжаю обучать ребят этому всему, и в современной ситуации это уже напоминает, как мастер Йода учил подпольщиков-джедаев.