Важность этапа разработки технического задания (ТЗ)

	Комментарий модератора
	Вынесено из темы Мне нужен учебник

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

0

SVN, к чему вы это написали? Какое это имеет отношение к теме и языку Go?

0

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

0

А я вот в подавляющем большинстве случаев с такой ситуацией сталкивался: "тебе надо - ты и пиши ТЗ, а потом сам по нему и работай"…
А еще хуже, когда работаешь во временном коллективе, разрабатывающем очередную "мега-железяку". И там еще и "верблюдом" становишься, т.к. изначально никакого ТЗ не было, а было лишь "вот сделать бы эдак". Делаешь. Тут же вылезает "а чего ты еще и этого не добавил?". И бесконечные правки… В общем, таки надо в таких случаях обязательно делать, так, как опытные разработчики: ТЗ могут писать даже обе стороны, но все его обязательно согласовывают, подписывают и ставят гриф "исправления не принимаются". А после выполнения работы, если вдруг "фишечек" кому-то захотелось - ОК, новое ТЗ, дополнительный контракт и рассматриваем это не как бесконечный этап бессмысленной работы, а как новую работу, которая приведет к заданному результату.

1

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

0

Необходимость разработки ТЗ предусмотрена стандартами ГОСТ, которые должны храниться в отделе метролога. Точность и достоверность использованной информации в названном документе определяет жизнеспособность разработаной программы и не только её, а вообще любого другого продукта. Сегодня же все "стандарты" генерирует конечный исполнитель, что и приводит к неопределённости в оценке качества его работы, с одной стороны, и степени ответственности за конечный результат работы, с другой стороны...
Тот же ГОСТ определял трудоёмкость разработки, до 25% от общих затрат на разработку, включая и обоснованное прекращение работы в случае невозможности получения желаемого результата, что записывается в ТЗ и подверждается с собоих сторон от исполнителя и заказчика, соответственно.
Юридически грамотно разработанное ТЗ защитит исполнителя от произвольно трактуемых заказчиком идей, а заказчик получит требуемый продукт независимо от амбиций "смышлёного" разработчика.
Кроме всех "идей" генерируемых участниками процесса разработки необходимо учитывать многолетний предыдущий опыт работы конструкторов - до настоящего времени быстрее чем за четыре года не получится сделать что-то новое. Например, всем хорошо известная система ОС Windows разрабатывалась много лет и продолжает разрабатываться...

0

Сообщение от Curry SVN, к чему вы это написали? Какое это имеет отношение к теме и языку Go?

Про язык Go ничего не скажу, но написал чтобы нагадить, наступить на больную мозоль, чтобы напомнить про жесткие обломы, несбывшиеся надежды, визг "кинули!!!", требования оплатить 50% и еще много о чем совсем не хочется вспоминать. Мочить надо такие посты а не переносить

0

Сообщение от SVN Необходимость разработки ТЗ предусмотрена стандартами ГОСТ, которые должны храниться в отделе метролога.

Сообщение от SVN Например, всем хорошо известная система ОС Windows разрабатывалась много лет и продолжает разрабатываться

Они там зарубежом точно работают по ГОСТам, у них есть отдел метролога и именно поэтому у них получаются хорошие программы а у нас УГ. Вы мало нормативки отечественной читали, иначе бы знали что в 90% случаев её невозможно соблюдать ибо она написана так для того чтобы назначить виноватого если что-то не получится а не для того чтобы работать по ней.

0

Сообщение от SVN Необходимость разработки ТЗ предусмотрена стандартами ГОСТ

ТЗ есть всегда. Отличается детализация. Оптимальная детализация зависит (в том числе) от скорости и стоимости доставки. В некоторых случаях быстрее и дешевле написать ПО без ТЗ, чем ТЗ по нему.

1