Зачем нужна "Спецификация на разработку" ?

В нашей фирме сложилась практика, что спецификация нужна только АБАП-ерам, поэтому большинство функционалов всеми правдами и неправдами стараются обойти эту "формальность", зачастую заручаясь поддержкой руководителей проектов и даже зам. ген. директора. Обосновывают обычно нехваткой времени, а также небольшим размером разработки или незначительными изменениям существующей разработки!
Я понимаю, что работать можно по разному и хочу поднять этот вопрос перед руководством: СО СПЕКАМИ или БЕЗ СПЕК!

Но хочу им привести все доводы ЗА и ПРОТИВ этих двух подходов. Хочется ничего не упустить, особенно аргументы зачем это нужно ИМ (функционалам и PM) в случае ЗА !? А также чего они лишаются, в случае ПРОТИВ.

В этом прошу вашей коллективной помощи, уважаемые, ибо это может пригодиться нам всем!

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

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

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

Пяток небольших изменений и от исходной разработки ничего не осталось.

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

Какой-то опрос необъективный. ТС однозначно "ЗА".
Нужно объективное мнение или тупо "как убедить PMа в необходимости спецификаций"?

Написать качественную спецификацию -- тяжелый труд. Если у консультанта объективно нет времени на написания спецификации и принимается решение переложить детальную проработку задачи на разработчика, то действительно лучше не писать ничего, чем "лишь бы что-нибудь написать".

Моя позиция такова: либо спецификации пишутся качественно, с проработкой всевозможных ситуаций и фиксированием абсолютно всех доработок, либо их написание пустая трата времени.

Это нужно и программистам и функциональным консультантам и руководству. Чем убедительнее будут "+" именно для руководства, тем больше шансов сделать спецификацию обязательной.

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

Что касается программиста. Когда нужно доработать существующую программу, н на спецификацию не смотрит. Спрашивает у функциональщика "Чё нужно? На пальцах, плз...". Подозреваю, что к ТЗ будет возврат, когда возникнет вопрос "А почему так" и нужно будет выяснить, что это: вольность программиста, его ошибка или так заложено в ТЗ изначально.

Что касается руководства. Руководство мыслит глобально. На какой участок какой объем разработок запланировать. И сколько это будет стоить (в человеко-днях и др.). Единственной основой для начального определения объема разработок является Спецификация на разработку. Без нее получается +/- километр. Не запланируешь толком какие люди, на какой срок, нужно ли привлекать кого-то стороннего. Чтобы отдел работал эффективно, передача дел должна быть проще. Без ТЗ этого не выйдет. Если функциональщик - "0" в проблеме, то приходится программисту во многом самостоятельно разбираться, а это время. Объем разработки, может, невелик, да время гораздо больше уйдет.

У кого нибудь практикуется это в полной мере? Как и кто за этим должен следить?

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

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

Разумеется сам я ЗА! Но это решать не мне. Я хочу руководителей поставить перед выбором, но аргументированно!
Я готов работать без спецификаций, но в таком случае хочу выдвинуть всречные условия, например, не требовать от нас плана по срокам разработки, отсутствие гарантий качества разработки, взаимозаменяемости разработчиков и т.д.

Для начала надо-бы определиться с терминами. Что такое спецификация разработки и чем она отличается от ТЗ ?
По ответам видно, что нет единого понимания.

+1 Timon&Pumba, строчил такой же вопрос.
Отличие вообще есть, или это одно и тоже?

Решение За:
1.Алгоритмы согласованы между между внешними и внутренними консультантами.
2.Обеспечение одинаковой работы по преобразованию данных в разных задачах.
3.Постановка обеспечивает возможность анализа ошибок в разработке.
4.Улучшается качество алгоритмов, т.к. есть возможность обсудить их до реализации.

Решение Против:
1.Без документации существенно повышаются затраты на поддержку со стороны как разработчиков, так и консультантов.
2.Невозможно соспоставить алгоритмы в разных задачах
3.Передача разработки на сопровождение или доработку другому консультанту затруднена

в принципе это как раз то, что говорили ранее.

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

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

лично для себя веду спецификации своих разработок, иногда спецификации состоят из нескольких строк текста.