ТЗ

← →
rvs (2004-05-12 10:02) [0]

Как правильно написать ТЗ?
Следующая ситуация: необходимо дать подразделению программистов задание на программный продукт.
Как это ТЗ писать - опыта нет.
Где можно взять типовой план ТЗ?
Хотелось бы посмотреть также на какое-либо готовое ТЗ.

Поиск по интернету дает крохи информации...

← →
paul_k © (2004-05-12 10:27) [1]

Посмотри тут.

http://www.amilen.ru/doc/gost/gost.htm

← →
Sergey Masloff (2004-05-12 10:28) [2]

Блин, очередной ;-)
В курсе что нормальное ТЗ это по стоимости 20% проекта? Если тебе просто сказали "ты эта... напиши чтоли эта... как его... ТЗ... по-бырому..." то или отправляй сказавшего в пешее эротическое путешествие или пиши что в голову придет.

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

← →
Sergey Masloff (2004-05-12 10:29) [3]

Все что привел paul_k © (12.05.04 10:27) [1] я использовал. Да старо но ничего новей нет а лучше хоть чо-то чем ничего.

← →
serge35 (2004-05-12 10:36) [4]

Этапы составления ТЗ:
1. Выяснение требований к программе.
2. Составление требований и согласование с заказчиком.
3. Описание основных модулей программы и их взаимосвязь
4. Оценка стоимости разработки по каждому модулю
5. Подробное описание каждого модуля
6. Согласование описания с заказчиком.
7. Исправление описания и написание окончательной версии ТЗ.
8. Постановка задач программерам и разъяснение того, что от них требуется.

От того, как написано ТЗ зависит примерно 70% успеха программы.

← →
Sergey Masloff (2004-05-12 10:37) [5]

Имелось в виду конечно несколько десятков тысяч у.е. ;-) А то уж СОВСЕМ скромный проект получается ;-)
Кстати проект внедрен и в бюджет практически уложились и работает уже с год - вобщем первый блин (в качестве "менеджера") не комом ;-)

← →
blackman © (2004-05-12 10:56) [6]

Как писать ТЗ ?
Очень просто.
Сначала ходишь и спрашиваешь всякую ерунду у тех, кто что-то знает про ТО, ЧТО НАДО СДЕЛАТЬ.
Потом пишешь введение, где излагаешь названия тех у кого ты спрашивал. Их звания, названия и должности. Можно списать их должностные инструкции.
Этап 2:
Основная часть - излагаешь всю муру которую они тебе наговорили тщательно путая термины и определения. Не забудь заглянуть в энциклопедию и списать оттуда несколько глав.
Этап 3:
Заключение - пишешешь о том как хорошо будет жить после завершения работ по проекту. Не про деньги которые вы получите, а про коммунизм который наступит в вашей стране сразу после внедрения.
Этап 4:
Собираешь подписи начальства и ценные вказивки по переделке того, что ты написал. Естественно, что результат (текст) ТЗ изменится до неузнаваемости. Начальство никогда не знает чего хочет и все время будет менять свои вказивки, забывая о чем оно говорило вчера.
Этап 5:
Весь этот мусор, который ты написал отдаешь программисту.
Он кидает его в шкаф и начинает работать.

← →
Sergey Masloff (2004-05-12 11:02) [7]

blackman © (12.05.04 10:56) [6]
>Он кидает его в шкаф и начинает работать.
Когда проходит срок в 2 раза больший чем планировалось, все деньги давно истрачены и ничего не сделано то начинаешь думать и почему так?
Нет, по твоему сценарию я сам не раз писал ТЗ работая в гос. организациях. А потом писал отчет на 150 страниц и никого не волновало работает там что-то или нет - отчет есть и дело с концом.
Только вот когда начинаешь работать в нормальных организациях где за все приходится ОТВЕЧАТЬ а не просто отписываться - начинается совсем другая песня. Правда и оплачивается такая работа совсем по-другому.

← →
Calm © (2004-05-12 11:14) [8]

Кстати,
ГОСТ 34.602-89. "Информационная технология. Техническое задание на создание автоматизированной системы"

рекомендует ТЗ писать самому разработчику при участии заказчика.

← →
serge35 (2004-05-12 11:22) [9]

> рекомендует ТЗ писать самому разработчику при участии заказчика.

А всех менеджеров вообще уволить!
Или платить меньше, чем разработчику.

← →
Jeer © (2004-05-12 11:29) [10]

Calm © (12.05.04 11:14) [8]
> рекомендует ТЗ писать самому разработчику при участии заказчика.
Это было всегда "и это правильно".

← →
GEN (2004-05-12 13:32) [11]

Jeer © (12.05.04 11:29) [10]
> рекомендует ТЗ писать самому разработчику при участии >заказчика.
>Это было всегда "и это правильно".
Совсем не обязательно - и тому имею немало примеров разработки ТЗ заказчиком при участии разработчика.

← →
blackman © (2004-05-12 13:44) [12]

>Правда и оплачивается такая работа совсем по-другому.
Правда ? Давно живу, но такого еще не видел :)
Правда никогда и не видел нормальных организаций. :)

← →
Sergey Masloff (2004-05-12 13:46) [13]

blackman © (12.05.04 13:44) [12]
$-)

← →
Nous Mellon © (2004-05-12 13:52) [14]

> первый блин (в качестве "менеджера") не комом ;-)

А екзешником! :)

← →
Algol (2004-05-12 14:53) [15]

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

← →
Mike_Goblin © (2004-05-12 17:02) [16]

Начальство надо терзать не на предмет ТЗ, оно его не составляло, не составляет и не будет.
Кроме начальства кстати есть еще и непосредственные пользователи ПО
PS есть такая дисциплина как управление требованиями (Requirement Managment), которая и учит работать с требованиями заказчика

← →
blackman © (2004-05-12 17:25) [17]

>управление требованиями (Requirement Managment), которая и учит работать с требованиями заказчика

А я про что ?
Этап 2:
Основная часть - излагаешь всю муру которую они тебе наговорили тщательно путая термины и определения

← →
Algol (2004-05-12 17:49) [18]

> Requirement Managment

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

← →
blackman © (2004-05-12 17:52) [19]

>Algol (12.05.04 17:49) [18]
Аналогично.

← →
Calm © (2004-05-12 17:53) [20]

> Это было всегда "и это правильно".

Безусловно.
Не раз убеждался в этом.

← →
serge35 (2004-05-12 17:55) [21]

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

← →
Mystic © (2004-05-12 17:56) [22]

Рекомендую использовать XP. По крайней мере на стороне заказчика.

← →
Calm © (2004-05-12 18:06) [23]

> они считают, что чем больше они заплатят, тем лучше будет
> программа.

Ух, всем бы таких заказчиков...

← →
paul_k © (2004-05-12 18:24) [24]

Ловишь того человека, который ЗАИНЕТЕРЕСОВАН в твоей разрботке. Вот от него и тех с кем он тебя сведет получишь максимум информации о требованиях к будующей программе. При отсутствии такого человека (или нескольких) за работу можно даже не братся. Вероятность положительного результата стремится к нулю, так как кроме тебя эта разработка не нужна никому. Ну разве что для самого главного босса, чтоб он пальцы гнул показывая за чашкой коньяку на красивую, абсолютно безсмысленную диаграмму такому же как он самому главному боссу .
Разделяешь работу на этапы.
Пишешь кусок ТЗ скажем с описанием пользовательского интерфейса и отправляешь на рассмотрение - согласование по инстанциям... и месяц ещё пишешь ту часть, которая тебе нужна (всяческие алгоритмы структуры данных и так далее). Так как согласовывающие инстанции совершенно не хотят вникать в твою "писанину" то они её утверждают. Прицепляешь следующий кусок написанный и опять на согласование. На 5-й или 6- й итерации твои труды наконец-то прочитают и спросят что - нибудь. через месяца 3 - 4 (или больше) "плодотворной" работы (из них около 2/3 срока на согласования утверждения и прочее) получаешь документ в котором более или менее детально проработана твоя будующая программа и главное - самый главный начальник если напряжется может понять что он получит в результате разработки. Если он этого не поймет и не утвердит большой синей печатью то все... денег вероятнее всего не будет.

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

← →
Mystic © (2004-05-12 18:38) [25]

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

← →
Calm © (2004-05-12 18:45) [26]

> Все равно в ТЗ все описать никогда не удастся...

Отнюдь.

> После подписания ТЗ заказчик и клиент превращаются во врагов,
> каждый из которых выискивает свой смысл во фразе из ТЗ.

Дык писать надо простыми предложениями и короткими словами.
И приложение к ТЗ делать с разъяснениями терминов.

← →
Algol (2004-05-12 18:47) [27]

> переписывания всего по новой "за те-же деньги"

Кстати это самое обычное дело. Почти ни один новый проект без этого не обходится. Ибо заказчик пока не пощупает не поймет чего же ему надо. До него это доходит только тогда, когда он видит разницу между тем, что выводит программа и тем что ему представлялось в радужных мечтах. Вот тут-то его и пробивает %)

← →
Digitman © (2004-05-12 18:55) [28]

> Он кидает его в шкаф и начинает работать

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

отседова. дабы поставить раком программеров и иже с ними, выплывает другой страшный по реализации и стоимости геморрой - план-график) ... вот это уж ДЫРА - похлеще иных дыр будет))))

Я бы посоветовал:

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

2) требовать реализации на каждый метод класса как минимум один unit-тест, проверяющие работу метода (для логики)

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

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

> Mystic © (12.05.04 18:57) [29]
> Я бы посоветовал:
>
> 1) выделить минимальную функциональность примерно на месяц
> разработки, обсудить ее с исполнителем и передать ее на
> исполнение по разумению последнего

Я тут эскизы форм основных 3-ю неделю рисую (ну правда в празники никто не работал)... А ты на эскиз - месяц всего. Хотя от объемов работы зависит очень сильно.

> 2) требовать реализации на каждый метод класса как минимум
> один unit-тест, проверяющие работу метода (для логики)

Требовать? у самого главного босса??? а у нас по советской привычке даже последняя уборщица себя таковой считает... Ну ну..
Сам пишеш большой такой талмуд под названием "методика тестирования" ("методика испытаний") и тоже утверждаешь его у "самого главного босса и иже с ним"

> Digitman © (12.05.04 18:55) [28]
> выплывает другой страшный по реализации и стоимости геморрой
> - план-график) ... вот это уж ДЫРА - похлеще иных дыр будет))))

Это смотря как лн составлен.. Пример из жизни
- а можно сократить сроки?
- Можно, если Вы согласовывать и утверждать документы будете не 20 дней а 2 часа.
- нет, не надо сокращать.
вот и все.. и план не может выйти из графика ибо запас на каждый более менее важный пункт - 20 рабочих дней, на бюрократию.

> Я тут эскизы форм основных 3-ю неделю рисую (ну правда в
> празники никто не работал)... А ты на эскиз - месяц всего.
> Хотя от объемов работы зависит очень сильно.

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

2Mystic
А все для него-же, для босса (точнее для боссов) ибо расплывчатых фраз они не понимают а фразу "на усмотрение исполнителя" понимают как "то есть так как я подумал" причем что он там думал узнаешь где-нибудь в середине внедрения, причем в лучшем случае.
Опять же - чем подробнее ТЗ тем дешевле стоит исполнитель, и тем легче его сменить, если он
> Digitman © (12.05.04 18:55) [28]
>(запил, проклятый, иль в бочку полез по случаю
> вожжи под хвост, иными словами - заартачился и нифига работать
> не желает, выискивая идиотские причины а-ля "пиво увчера
> изряднго тепллое было ... и ваще - нафих вас всех")

но это уже другой вопрос, управленческий...

← →
Sergey Masloff (2004-05-12 19:30) [35]

Digitman © (12.05.04 19:05) [30]
>от такие дела)... там где фигурирует и рождается ТЗ - там >торчит преогромнейшая задница, за которой тянется огромная куча >серьезных док-тов, НЕ позволяющих НИКОМУ сделать НИ шага вправо->влево ... без коррекции) ... во бумажное исполнение которых >должны быть привлечена куча бумаготворческих работников ...

Не всегда и не везде. Расскажу как примерно было у меня. Бумаготворческих почти не было. Был (с нашей стороны) я который написал (в сотрудничестве с пользователями для которых был функционал). Потом на основе стандартов написал "заготовку" ТЗ и отдал "исполнителям" на изучение. После нескольких итераций (и множества упреков в мой адрес типа какого хрена эта ерунда на бумаге) получилось весьма четко описаное ТЗ. После чего я сделал следующий ход: просто устроил встречу на которой сказал - я понимаю что всего не опишешь. Давайте так - если после ввода в эксплуатацию в течение пары месяцев мы поймем что чего-то не хватает или что-то не так то вы доделываете (или полностью переделываете) это бесплатно. Но только в том случае если это в пределах 10% всего бюджета. Если больше - я делаю все чтобы было заключено доп. соглашение за отдельные деньги. Реальную трудоемкость я представляю так что...
Джентельменское соглашение было достигнуто. И войны в результате не было. Было отличное взаимовыгодное сотрудничество. Кстати сейчас идет речь о новой очереди проекта которая сулит им заказ на сумму минимум в 3 раза большую так что я думаю они не в обиде за то что им пришлось доделать бесплатно немало не описанного в ТЗ ;-)

> paul_k © (12.05.04 19:24) [34]

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

Вообще, в книгах по ХР этот процесс довольно-таки хорошо описан.

P. S. Да, есть еще такой геморрой, как оценка стоимости... Зачастую неизвестно чего...

← →
serge35 (2004-05-13 13:35) [37]

Оценка стоимости - это легко.

> Оценка стоимости - это легко.

ну ты сказал...

Когда учился на 3-ем курсе устроился пропрактиковаться и заработать немного денюжек в одну контору среднего размера.
Так мне их ген. директор предлагал платить от объема строк кода. На полном серьезе!

А ты говоришь, легко.

← →
serge35 (2004-05-13 14:06) [39]

Переводчики до сих пор так работают - по количеству переведенных слов и страниц.

Могу порекомендовать RUP :)

Например, книгу Лармана "Применение UML и шаблонов проектирования".

ТЗ Найти похожие ветки