Здравствуйте, Кэр, Вы писали:

Кэр>Будет что-то конкретное в коде — часто этого достаточно. Если принципиально то, что была выбрана именно кнопка, а не пункт меню и это знание хочется сохранить и использовать в дальнейшем — имеет смысл задокументировать это. Если нет — то найдутся и более достойные применения этому времени.

А что жалеть время тех, у кого работа такая — анализ того,
что хочется клиенту и формализация этого дела в виде требований?
Мы ведь о промышленной разработке речь ведем

Здравствуйте, bkat, Вы писали:

Кэр>>Будет что-то конкретное в коде — часто этого достаточно. Если принципиально то, что была выбрана именно кнопка, а не пункт меню и это знание хочется сохранить и использовать в дальнейшем — имеет смысл задокументировать это. Если нет — то найдутся и более достойные применения этому времени.

B>А что жалеть время тех, у кого работа такая — анализ того,
B>что хочется клиенту и формализация этого дела в виде требований?
B>Мы ведь о промышленной разработке речь ведем

Так вы хотите чтобы аналитики анализ делали или формочку в деталях документировали? Или вы считаете, что затраты на анализ нулевые и чем бы они не занимались — пусть лучше хотя бы документы попишут? Зачем вам вообще этот документ нужен?
Его польза:
1. Хорошая база фиксирующая результата переговоров нескольких человек. Основная цель переговоров — создать код решающих конкретную задачу. Иногда целью также является следующий пункт.
2. Документ описывающий как система работает.

Больше я пользы от него не вижу. При этом у документа есть стоимость разработки и стоимость поддержки. Чем более детальный документ — тем выше стоимость изначальной разработки и уж тем более стоимость поддержки.

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

Здравствуйте, Кэр, Вы писали:

Кэр>Так вы хотите чтобы аналитики анализ делали или формочку в деталях документировали? Или вы считаете, что затраты на анализ нулевые и чем бы они не занимались — пусть лучше хотя бы документы попишут? Зачем вам вообще этот документ нужен?

Ну утрировать можно что угодно...
А на шару хорошие спеки конечно не получить.

Кэр>Его польза:
Кэр>1. Хорошая база фиксирующая результата переговоров нескольких человек. Основная цель переговоров — создать код решающих конкретную задачу. Иногда целью также является следующий пункт.
Кэр>2. Документ описывающий как система работает.

Кэр>Больше я пользы от него не вижу.

А этого мало?
Фиксация результатов переговоров нескольких человек (туда кстати куча заинтересованных групп входит) — это весьма ценно.
Если девелоперы, тестеры и те, кто потом продукт будет продавать,
в целом одинаково понимают что делают — это очень сильно облегчает жизнь.
Но если система не очень объемная, команда небольшая, все друг друга знают
и ничего не забывают, то да, можно обойтись и без документированных спеков.
В коде и в самом деле потом почти все найдется, кроме того,
что забыли реализовать, потому что мелочь скучная
Вот представь себе писателей компилятора без формальной спецификации языка.
Что-то они конечно родят, но "по уму" было бы проще.

Здравствуйте, bkat, Вы писали:

B>А этого мало?
B>Фиксация результатов переговоров нескольких человек (туда кстати куча заинтересованных групп входит) — это весьма ценно.
B>Если девелоперы, тестеры и те, кто потом продукт будет продавать,
B>в целом одинаково понимают что делают — это очень сильно облегчает жизнь.
B>Но если система не очень объемная, команда небольшая, все друг друга знают
B>и ничего не забывают, то да, можно обойтись и без документированных спеков.
B>В коде и в самом деле потом почти все найдется, кроме того,
B>что забыли реализовать, потому что мелочь скучная

Я работал в проекте где документировали практически все, вплоть до пикселей
И таких вещей как: договорились в курилке, по почте и т.д. старались не допускать.
Все это конечно муторно, но в итоге облегчает жизнь, в том числе и прикрывает пятую точку
На вопрос, а почему тут не так как мы хотели, всегда можно ткнуть носом в документик.
К тому же релизы шли в QA, а они ессно смотрят в требования\документацию.
Поэтому шанс получить баги очень высок, если сделано "как договорились в курилке" и
это никак не задокументировано. Ну объяснишь ты раз, что мол так и так, инвалид ваш баг,
в следующий раз будет уже кто-то другой тестировать, опять бага прилетит.

Но конечно да, проекты разные бывают. Есть такие где все вообще на словах.