Техническое задание для программиста? Какое оно? #118981

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

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

Даааа ужж. Неужели никто оформляет задачи письменно для программеров?

Задание для программиста которым мы пользуемся имеет такую структуру например для документа:1. Таблицы реквизитов шапки и таблицы2. Макет формы диалога. ( MS VISIO)3. Описание событий при работе с формой ( предопределенные события, события привязанные к элементам диалога).4. макет печатной формы ( если есть).5. Описание модуля проведения либо в виде текста либо в виде блок схемы.

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

То 2. Давай определимся с понятиями - кто такой "программер" и кто ставит ему задачи. Если речь идет о пользователе по отношению к программеру, то ТЗ пишет сам программер на основе технических требований пользователя и согласовывает его с ним. Если речь идет о системном аналитике по отношению к программеру (кодеру), то ТЗ пишет системный аналитик.

Глянь сюда может полегчает http://www.xprogramming.ru/

"Идеальное техническое задание - это написанная программа."и как его подписывать ?

Умник какой! ТЗ пишет программер (нач отдела) другим программерам (своим подчиненным)

Актом приемки-сдачи работ

ТЗ любят франчи. Они за это бабло срубают и потом ещё выставляют счета "так как этого не было в ТЗ!"

это вы так работаете? или пытаетесь так работать?

2 Все нормуль... это нужно и фра, и фри, и фикси...Хорошо, когда знаешь что делаешь и для чего, не так ли?Ну, и бабло, конечно... и взаимные претензии и прочее - устраняются многи проблемыНадо госты смотреть, видимо... счас не могу

5 баллов !no comments

у тя нет их ТЗ? посмотреть хотябы! Мы канешн не франчи но всетаки

Ты фри, фра или фикси?

-> 2

Азбука составления ТЗ:http://www.networkdoc.ru/doc/gost.html

2 было парочку. но я сёдня туту к тёще через час, не заезжая домой. В понедельник подними ветку, напомни - я найду дома.

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

Засунь эти госты в ж.пу

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

2 практика работы фикси показывает что составление ТЗ сваливают на исполнителя, что глупо. Короче сколько фикси не работал - никогда не получалось нормальное ТЗ написать (или чтобы мне написали). Так, миниТЗ бывают. Но чтоб реально большое ТЗ под проект - неа. Хотелось бы, но ..1) Негибко (приходится всёравно походу переделывать).2) Долго (за это время полфункционал напишешь).

маладес сам ТЗ не пользуется а нам дает госты почитать "ГОСУДАРСТВЕННЫЙ СТАНДАРТ СОЮЗА ССР"

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

дай плиз комментарий к

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

Ты их читал ? Что в них не понятно ?

ну можно так выразиться! Смысл не меняется!

ГОСТы очень помогают, во всяком случае там ясно что за чем писать и если пунктов не пропускать получиться полное описание того что хочется увидеть в резате :)

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

комментарии к 1. Гибко. Опыт показывает что с Заказчиком нужно обсуждать прежде всего формы ( тогда уже и пояснения к ним прочитают). Проверено - факт. Главное его быстро переработать в задание для программиста.2. Вообще, действительно долго. ТЗ на разработку отдельного модуля занимает около 50 % от кодирования. Но, в защиту написания ТЗ замечу:1. Потом меньше придется переделывать ( т.к. заказчик уже будет иметь представление о том что он увидит на экране и как он с этим будет работать).2. Кодирование пройдет быстрее т.к. задание на программирование уже отвлечено от предметной области, структура модуля , связи уже продуманы.

Собственно для это ГОСТы и придумали :)))

2 где-то я такой же пост уже видел :) вот помню была статья еще в начале 90-ых в одном из журналов по теме разработки ПО, называлась "Я постановщик" там очень хорошо все описывалось, вот только где ее сейчас найти.

Составить такое задание по времени столько-же сколько написать программу. Так что стоимость разработки удваивается.Вот, примеры моих заданий:1. Создать базу договоров.2. Создать платежный календарь, связать с базой договоров.

2 Да лано, всегда сто раз захотят "этого добавить, этого переделать" и в конце обязательно вылезет парочка "а мы думали что это будет иначе" :)А вообще для прикрытия задов суперская вещь.

Я пишу задание из 2 частей - описание объекта настройки (это на языке пользователя, он это читает и подписывает (Не только для того, чтоб себя обезопасить - заказчику просто полезно глазами прочитать и ещё раз подумать над тем, чего он хочет)) и описание настройки для кодера - примерно в формате , только без картинки формы, достаточно просто описания.Но это в идеале, для совсем простых случаев (или если сам собираешься делать) хватает первой части...

Первая часть называется технические требования. Вторая техническое задание. Это все по ГОСТ. Жизненный цикл проекта состоит:1. Описание бизнес-процессов как есть.2. Описание бизнес-процессов как надо3. Технические требования к системе4. Техническое задание5. Технический проекти т.д.Еще более общо проектированию должен предшествовать этап НИ и ОКРВы все эти этапы делаете или некоторые выполняются пунктиром?

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

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

при отделении заказчика от спеца (мечта любого франя) без бумажки (как ее не назови) не обойтисьстоимость - утраивается, учетверяется, упятеряется - в результате - "крупный проект" - по терминологии Тота**художнику ТЗ нужно для него же самого - легче писать, имея некий планхоть на туалетной бумаге - именно такой я только что закончилсам написал - сам выбросил :)**если с клиентом начинаются вариации на тему "сам дурак", значит не сложилось, либо клиента меняй, либо над собой работай

А я о чем? Клиент, если сочтет, что переплатил, будет орать "КИИИНУУУЛИИИ!" в любом случае. И что же теперь, даром с ним работать? Или сделать за тарелку супа и потом за "так" дорабатывать? Нафиг такого клиента! Чем точнее клиент представляет, что и в каком виде ему нужно, тем меньше платит. А со жлобами ни фра, ни фри работать не хотят, фики тож не задерживаются, если студенты только, за стипендию. Так потом опять крики... Нееет, или платишь за решение свои проблем как договоришься, или считай на счетах и гроссбухе.

а еще я не люблю франей за то, что в объявах на джоб.ру они пишут о себе "прямой работодатель"

Можно и Актом приемки-сдачи работ, но лучше накладной на отгрузку тиражного решения. Все больше убеждаюсь, что классическая схема проекта Заказчик-Исполнитель это отстой. Напрасная трата денег Заказчика и разбазаривание интеллектуальных ресурсов Исполнителя.Предлагаю такую схему. Исполнитель приходит к Заказчику со своим готовым решением. Заказчик говорит почему ему не подходит это решение. Исполнитель выпускает новую версию своего решения, где максимально старается удовлетворить потребности своих заказчиков. И продает ее.Есть еще пятничная идея. Приравнять проект к созданию блок-бастера. Есть продьюсер(Заказчик, куратор), который платит, Есть режисер(Руководитель проекта) который снимает, Есть звезды(программисты) которые снимаются. Есть очень приблизительный бюджет. Получается в качестве гарантии успешности проекта выступают не тонны бумаги, а команда знаменитостей.

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

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

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

Все так делают. А может это неправильно? Если что то забыли почему виноват только Заказчик? Почему все риски должен на себя брать один Заказчик?

потому что так выгодно исполнителю, т.е. нам. :)))

А мне как Заказчику не выгодно. С удовольствием бы отдал кучу работы на сторону. Но не ммогу найти Исполнителей. Желание денег вижу. Желание работать нет.

Эт факт...) они могут потом очень долго еще что нить придумывать...а нам на халяву делать что ли???))

найми Китайцев.

"Все так делают" - любимая фраза. Предлагаю по другому. Вначале деньги, а потом обсудим техзадание.

А если сумма окажется меньше чем реальная стоимость работы???

Вобщем - диалектическая борьба противоположностей, блин...

Это документ, в котором написано что-то согласно тех. требованиям типа:-----(кусок из стр. 39 из 76 + приложения)-----5.6.6 Передача филиалу.Вводится путем введения документа накладная. Ввод документа должен обеспечивать введение номера документа, даты документа, кому передаются материалы (элемент справочника контрагент), если , основание получения, ввод места хранения, ввод процента накладных расходов, ввод материалов (из справочника материалов), ввод количества (число), расчет средней цены списания (стоимости материала) и ее ввод, расчет и ввод полной стоимости. При введении документа или его открытии должна обеспечиваться возможность просмотра формы печати накладной и вывода ее на печать, в последней строке табличной части выводятся в графе материальные ценности накладные расходы с процентом, в графах цена и сумма с учетом НДС выводится рассчитанная исходя из общей стоимости материалов и процента накладных расходов стоимость накладных расходов. Форма печати документа - М-15 (см. приложение 2). При сохранении документа формируются и записываются в журнал проводок проводки:по каждому виду материалов делаются проводкиНЖ Содержание Дт Кт Кол. СуммаМА Материалы переданы филиалу 79.2 10.х Количествоматериалов Стоимость материаловПосле обработки всех материалов если процент накладных расходов больше 0Вычисляется Дт сальдо по счету 16 (ДтСальдо16),  Вычисляется общая сумма накладных расходов: Сумма списания = СуммаСписания умножить на Процент накладных расходов разделить на стоНачало цикла  Последовательно выбирается счет 16 по аналитике статьи затрат (справочник статьи затрат)  Определяется дебетовое сальдо по аналитике (ДтСальдо16Аналитика))Если ДтСальдо16Аналитика равно 0, то Сумма Списания1=0, иначеСуммаСписания1=Округлить (СуммаСписания*ДтСальдо16Аналитика/ ДТСальдо16 )              Если СуммаСписания1 больше ДтСальдо16Аналитика, то                    СуммаСписания1=ДтСальдо16АналитикаНЖ Содержание Дт Кт Кол. СуммаМА материалы филиалу 16 счет 79.2 16 Количествоматериалов СуммаСписания1Если по данному складу установлен признак обязательного резервирования, тоНЖ Содержание Дт Кт Кол. СуммаРЗ Снятие резерва Рз.Мт Количество -----

После этого по данному ТЗ формируется тех. проект, где написано что-то типа:---7.7.7 Передача филиалуВводится путем введения документа накладная.Периодичность нумерации документов – в течении года, в рамках нумератора «М15».Структура документа:Название – ПередачаФлШапка: Склад Спр. «МестаХранения» Склад, откуда передаются материалыФилиал Спр. «Филиалы» Филиал, куда передаются материалыРазрешение Док. «РазрешениеНаОтпуск» Разрешение, по которому отпускаются материалы (если по складу установлен признак резервирования)Затребовал Спр. «Сотрудники» Кто затребовалРазрешил Спр. «Сотрудники» Кто разрешилПроцНаклРасх Число 5/2 Процент накладных расходовТабличн. часть: Материал Спр. «Материалы» Количество Число 10/3 ЕдиницаИзмерения Спр. «ЕдиницыИзмерения» единица измерения материалаЦена Число 15/2 цена материала (расчетная)Сумма Число 17/2 Сумма материалов (СтоимСписания)При выборе материала происходит расчет средней стоимости материала (цена). Существует режим, который позволяет исчислить среднюю стоимость для всех материалов. Форма печати документа (М-15) представлена в приложении 3. При печати документа в последней строке табличной части выводится в графе «материальные ценности» - «накладные расходы» с указанием процента, в графах цена и сумма выводится рассчитанная исходя из общей стоимости материалов и процента накладных расходов стоимость накладных расходов.При проведении документа:- По каждому материалу определяется СчетМатериала в зависимости от группы материала.по каждому виду материалов делаются проводки:Стр НЖ Содержание Дт СубконтоДт1 СубконтоДт2 СубконтоДт3 Сумма      Кт СубконтоКт1 СубконтоКт2 СубконтоКт3 Кол-во* МА Отпуск мат. в филиал 79.2 Филиал СтоимСписания      СчетМатериала Материал Склад КоличествоЕсли выбрано «Разрешение», то производится снятие резерва:Стр НЖ Содержание Дт СубконтоДт1 СубконтоДт2 СубконтоДт3 Сумма      Кт СубконтоКт1 СубконтоКт2 СубконтоКт3 Кол-во* РЗ Снятие резерва ТМЦ       Рз.Мт Материал МестоХранения Филиал КоличествоПосле обработки всех материалов если процент накладных расходов больше 0Вычисляется сальдо по дебету счета 16 (ДтСальдо16).Вычисляется общая сумма накладных расходов: СуммаНаклРасх = СуммаСписания умножить на ПроцНаклРасх разделить на 100.Определяется, сколько надо списать по сч. 16 СписатьПо16 = MIN(ДтСальдо16, СуммаНаклРасх).{Начало цикла}Последовательно выбирается счет 16 по аналитике статьи затрат (справочник статьи затрат) ...{и так далее}....

Да, кусок техпроекта был из стр. 51 из 157 + приложения.

не парьтесь.Даже "рыба" ТЗ с типовым примером стоит не малого балба.

Пиво начало десйствовать - "балба"="бабла"

Джинн, вот говоришь разное а мыло то не светишь.Вот Фингя, соображает, да не туда. Зажал информацию, а не хорошо.Скучно и Бориса в ветке нет.