Идеальное ТЗ (FD)

[kALVINS]

Добрый день уважаемые Форумчане.
Вопрос к программистам.
Каким вы видете идеальное ТЗ?
Какой уровень детализации в нем должен быть?
Видели ли вы такое на практике?
Эти вопросы были подняты в этой теме:
Ищу работу удаленно

[Dron AKA andy]

Может быть, этот вопрос все же не для раздела "Программирование"?
Может перенести в другой раздел? Вероятнее всего, "Вопросы внедрения"?

[kALVINS]

Можно и перенести, я не против.

[Dron AKA andy]

Перелетело.

[Андре]

Цитата:

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

(c) Facts and Fallacies of Software Engineering
By Robert L. Glass

[kALVINS]

Вот меня и интересует до какого уровня примитива программисты хотят видеть идеальное ТЗ! С какой степенью детализации!

[gl00mie]

Цитата:

Сообщение от kALVINS

Вот меня и интересует до какого уровня примитива программисты хотят видеть идеальное ТЗ! С какой степенью детализации!

Я видел примеры очень детализированных ТЗ, вплоть до описания, какие данные для отчетов/форм из каких полей каких таблиц надо брать, где какие группировки и фильтры должны быть, где какие кнопочки должны располагаться и как реагировать на действия с другими кнопочками, etc. НО такие ТЗ рассчитаны даже не на программистов, а на обычных, как иногда говорят, "кодеров" - студентов старших курсов или недавних выпускников, знающих, что такое ООП, и слышавших слово "Axapta". И заработки у таких кодеров соотвествующие... С другой стороны, ситуация, когда письменного ТЗ вообще нет, тоже ненормальна, потому что в среде программистов телепаты afaik довольно редки, а угодить человеку, когда не знаешь, чего он хочет, очень сложно.
Бывают примеры достаточно взвешенных подходов к написанию ТЗ, но это, наверно, скорее исключение из правил, чаще люди сами не знают, чего хотят
Наверно, идеальное ТЗ - написанное, перефразируя Эйнштейна, "настолько кратко, насколько это возможно, но не более того", т.е. достаточно детализированное, чтобы понять, чего хочет заказчик, но не перегруженное несущественными или очевидными деталями, чтобы не пытаться сделать из программиста обычного "кодера".

[kALVINS]

ТЗ кроме того что позволяет дать программисту задание на разработку, но и позволяет более полно документировать разработку, чтобы потом через полгода не нужно было вспонимать что откуда взялось
Поэтому степень детализации вопрос не только воприятия программиста.

[kALVINS]

Цитата:

Сообщение от gl00mie

Наверно, идеальное ТЗ - написанное, перефразируя Эйнштейна, "настолько кратко, насколько это возможно, но не более того", т.е. достаточно детализированное, чтобы понять, чего хочет заказчик, но не перегруженное несущественными или очевидными деталями, чтобы не пытаться сделать из программиста обычного "кодера".

А чем так плохо делать из программиста кодера? ну кроме падения заработков.

[kashperuk]

Цитата:

Сообщение от kALVINS

А чем так плохо делать из программиста кодера? ну кроме падения заработков.

Программист - творческая личность.
А кодером может и моя бабушка работать.

[Morpheus]

Цитата:

Сообщение от kALVINS

А чем так плохо делать из программиста кодера? ну кроме падения заработков.

А тем, что сначала из консультанта необходимо "сделать" архитектора...
А падение заработка программистов это сон которому не суждено стать явью...

[Андре]

Уровень детализации должен однозначно говорить о том, КАК реализовать тот или иной функционал. Если мы конечно рассуждаем о моменте перехода от ТЗ к кодированию, а не о границе между формализацией требований и написанием ТЗ.

Только проблема то как раз в том, что эти наборы примитивов у каждого свои

[EVGL]

Для меня пригодное ТЗ отвечает на два вопроса: "Зачем?" и "Что?". К сожалению, консультанты тяготеют к ТЗ типа "сделай параметр X на форме Y", не обясняя подробно, что поле X должно делать, т.е. отвечают на вопрос "Как?", но не объясняют "Зачем".

Я скажу так: если нет каких-либо особенных предпочтений конечного пользователя, детально описывать интерфейс не нужно. Толковый программист сам найдет наилучшее представление. Описать надо алгоритм, логику, разобрать на примерах типовой case.

[belugin]

вот некоторые наброски -- давно чесались руки что-то такое написать

[blokva]

Цитата:

Сообщение от belugin

вот некоторые наброски -- давно чесались руки что-то такое написать

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

[itfs]

Насчет "не стоит повторяться" это вы идеализируете, все зависит от размера документа. В пределах неск. страниц действительно повторяться не стоит, а вот через 10-ть, память уже отказывает. И потом типичны случаи:
- Так этого там не было,
- Как не было? Посмотри 1-й абзац.
- А ... извини не связалось.

С уважением, itfs.

PS. Может указать, что ТЗ должно быть компактным? не более n страниц. Если более, то это не одно а m = x div n тз.

[blokva]

Цитата:

Сообщение от itfs

Насчет "не стоит повторяться" это вы идеализируете, все зависит от размера документа. В пределах неск. страниц действительно повторяться не стоит, а вот через 10-ть, память уже отказывает. И потом типичны случаи:
- Так этого там не было,
- Как не было? Посмотри 1-й абзац.
- А ... извини не связалось.

С уважением, itfs.

Все правильно, но если ТЗ на 10 страниц, то это уже в принципе не верно, если доработка огромная, то ее необходимо...опять же структурировать и разбивать на максамально-независимые задачи, вот в них то и не стоит "повторяться"

[belugin]

Цитата:

По поводу мыслей по ссылке...я например считаю, что нельзя "учитывать уровень програмиста", надо подтягивать этот уровень до некого среднего по группе, причем как силами более опытных программеров, так и силами аналитмков.

Я согласен, что менять уровень надо. Однако считаю что этот средний уровень может быть разным и учет этого факта может сэкономить много времени на объяснении программистам одного и тогоже.

Цитата:

Насчет "не стоит повторяться" это вы идеализируете, все зависит от размера документа. В пределах неск. страниц действительно повторяться не стоит, а вот через 10-ть, память уже отказывает. И потом типичны случаи:

• конечно. (если возвести принцип в абсолют, то тз надо архивировать раром и в этом виде читать - а так какая-то избыточность будет всегда)
• если память отказывает, надо продублировать окно ворда в котором находится ТЗ, а не исходный текст. Еще можно сделать ссылку из пункта а в пункт б.
• в любом случае если автор обнаруживает что копирует большой кусок а потом меняет там пару слов, то может быть ему стоит подуметь, не отрефакторить ли это дело (кстати, интересно, есть ли где нибудт библиотека рефакторингов для ТЗ типа "Выделить понятие", "Выделить подзадачу" и т.д.)

[MironovI]

Детализация должна быть такой, чтобы менеджер проекта, прочитав ТЗ, мог сказать за сколько он это продаст, остальное побоку

[mazzy]

Цитата:

Сообщение от MironovI

Детализация должна быть такой, чтобы менеджер проекта, прочитав ТЗ, мог сказать за сколько он это продаст, остальное побоку

Почти согласен.
Но не все "побоку".

ТЗ нужен нескольким сторонам.
1. ТЗ нужно, чтобы менеджер проекта мог сказать за каике деньги он продаст
2. ТЗ нужно, чтобы программист мог сказать в какие сроки он выполнит
3. ТЗ нужно, чтобы клиент мог сравнить факт с планом (помимо достоверности сроков и денег)

Поэтому ТЗ не должно опускаться на уровень таблиц и полей (это задача программиста)
Поэтому ТЗ не может содержать только декларации "всем будет хорошо" (заказчик потом не сможет сравнить)

Я согласен с belugin.
ТЗ должно:
1. описывать как пользователи смогут использовать то, что получится в результате, в своей деятельности
2. описывать принцип взаимодействия пользователей и системы
3. описывать принпип работы того, что должно получится в результате
4. описывать алгоритмы тестирования (в идеале, ТЗ должно содержать набор данных и алгоритмы для unit-тестирования)