Comments 9
Было б интересно читать, эсли б превратить дипломную для комисии в статью для людей. АИ мог бы в этом помочь
Скорее всего выложили просто чтобы получить +1 публикацию. А так согласен, читать дипломную/магистерскую работу тут явно никто не будет. Вообще интересно их кто то читает?
Понимаю, что формат может выглядеть непривычно для Хабра, но это не дипломная и не магистерская работа - она у меня уже давно защищена. Текущая публикация - отдельный исследовательский материал по методике SDD, который решил выложить в исходном виде, чтобы зафиксировать сам подход и иметь на него открытую ссылку.
Такие тексты обычно читают те, кто занимается архитектурой процессов разработки, инженерией требований и docs-as-code практиками - аудитория не самая массовая, но для профильных специалистов тема оказывается вполне прикладной.
Спасибо за комментарий! В данном случае статья действительно сохраняет академический стиль осознанно - это публикация, основанная на исследовательской работе, поэтому текст оставлен максимально близким к исходной научной версии. Отдельно позже планирую подготовить более прикладные материалы, где подход будет разобран в практическом формате и на реальных кейсах внедрения.
Отправил в Sonnet 4.5 и попросил переписать с академического стиля на стиль Хабр статьи, действительно стало интереснее читать
У всех похожие идеи, но контроль за циклом через DoD и промпты не очень работает. Слишком плохо агенты перемещаются между абстракциями. Контекст гниёт, контекст размывается, протоколы забывается. Либо нужно больше агентов либо более формальные модели с валидацией и трассировкой. Я думаю будущее за "жёсткими" и строгими фреймворка. Я пробую делать похожий фреймворк: v-model, контекст в рамках задачи, валидация по Json схемам, отсутствие трассировки не даёт выполнить задачу, обязательные ревью - https://github.com/kpruntov/specloom
Отлично, детально, спасибо!
Возможно, мы упираемся в то же бутылочное горлышко, что и 10, и 30 лет назад - ничтожно малый процент людей любит/умеет писать технические задания (software requirements specifications) и даже читать их. Даже с помощью ИИ - допустим, постановщик (product owner) набросал основные требования → ИИ домыслил → постановщик прочитал и попросил ИИ что-то поправить, выпустил ТЗ → никто из людей, кроме постановщика, ТЗ не прочитал до конца => пользуйтесь и постарайтесь получать удовольствие от того, что получилось, впрочем, как и раньше было. Другими словами, есть опасение, что SDD будет возможно применить достаточно редко - при наличии компетентных постановщиков. И поэтому постановщики, а не синьоры будут грести деньги лопатой?
Спасибо за развёрнутый комментарий - это как раз тот риск, который я и стараюсь проговорить в статье.
SDD не предполагает, что один "постановщик" написал большой документ, а остальные обязаны его героически читать. Наоборот, идея в том, чтобы разложить знания на слои артефактов и связать их трассируемостью: домен → требования → сценарии → архитектура → проверки. В таком виде это не монолитное ТЗ на 120 страниц, а связанный контур, где каждый слой читается и ревьюится своей ролью.
Бутылочное горлышко "никто не читает SRS" действительно существует давно. Но чаще проблема не в том, что люди не умеют читать, а в том, что документ не встроен в инженерный цикл. Если требования не связаны с архитектурой, тестами и решениями - их и правда игнорируют. Когда же изменение требования автоматически тянет пересмотр сценария и следа верификации (через PR и ревью), документ перестаёт быть "бумагой ради бумаги".
По поводу применимости - да, SDD не универсальная серебряная пуля. Он разумен там, где документация - это инструмент управления изменениями, а не формальность. В маленькой команде с быстрой итерацией overhead может быть избыточным. В R&D, регуляторных или сложных интеграционных проектах - наоборот, окупается.
И, пожалуй, важный момент, методика не усиливает "власть постановщика". Она как раз снижает зависимость от одного человека, потому что знания становятся распределёнными и проверяемыми через связанный граф артефактов и ревью. Если система держится на одном авторе ТЗ - это организационная проблема, и никакой ИИ её сам по себе не решит.
Так что вопрос не в том, кто будет "грести деньги", а в том, готова ли команда инвестировать в управляемость и прозрачность решений. SDD - это инструмент для тех, кто видит в этом ценность.
SDD (Spec-Driven Documentation) – фреймворк для разработки технической документации в репозитории