Почему стоит составлять/писать ТЗ

11.03.2010 12:42 [11.03.2010 00:00] CheBurator 15

Внешний отчет, обработка

Техническое задание – закон для разработчика. В процессе разработки – основной документ, которым он должен руководствоваться. Этот документ призван:
описать цель работы. И разработчик, и заказчик должны чётко понимать, к чему они стремятся, за что один платит деньги, а другой – тратит время и напрягает мозги;
описать задачи. Прежде чем начинать работу, необходимо прикинуть, насколько она затянется, сколько потребует ресурсов. Круг задач должен быть посильным разработчику, а заказчик должен представлять, чем разработчик будет заниматься, за что платить;
регламентировать отношения. Один из самых важных моментов! Заказчик и исполнитель регламентируют объёмы, сроки, денежные суммы, порядок приёмки, форматы исходных и выходных данных и ещё множество условий, которые необходимо прописать во избежание конфликтных ситуаций.

http://beta.delta-z.com/tehnicheskoe-zadanie/




Комментарии (19)

В начало публикации

Вкл. прямой порядок комментариев

Для добавления комментария необходимо зарегистрироваться или авторизоваться.
Логин :
Пароль :
Забыли пароль?

Страницы: 1 2 Вперед →

19.
+ -
Alex_Smolensky 24.03.2010 10:51
ТЗ - рабочий документ, который необходим. Это как написание школьного сочинения - начинается с плана, где Вы решаете для себя, какие будут разделы и сколько времени Вы потратите на написание каждого раздела.
Вопрос в другом - Какого вида должно быть ТЗ.
- если работа занимает пару дней - достаточно, наличие ТЗ в голове;
- если работа рассчитана на месяцы - без ТЗ утоните в реализации хотелок.
- если налажены хорошие отношения с заказчиком, ТЗ можно писать кратким, что б съэкономить свое время и деньги заказчика;
- если заказчик конфликтный - подробное ТЗ не спасет, а лишь породит вопросы о непонятной трате Вашего времени и денег заказчика;
- ТЗ может как предотвратить конфликты с заказчиком, так и породить их

ТЗ - однозначно, должно быть. Но нет однозначной рекомендации, какое он должно быть и сколько на него нужно тратить времени. Все завист от Вас, от заказчика, от вида работ и т.п.
18.
+ -
panteranew 18.03.2010 19:59
smile;) по опыту могу сказать - не все готовы и хотят платить за ТЗ,считают что это обдираловка,хотя без ТЗ была ситуация когда договорились об одном а на деле всё наоборот - а рассчитано и уплачено за одни работы а делать пришлось в 3 разп больше,так что не хочет сторона заказчика ТЗ - досвиданья,найдутся те кто скажет ХОЧУ!!!!! smile;)
17.
+ -
миш 18.03.2010 08:29
Из своей практики хочу добавить, что полезно к ТЗ добавить функционально-структурную схему, которая лучше позволяет найти общий язык с заказчиком. Полезно установить "точку замораживания" в разработке, как говорится: "Лучшее- враг хорошего".
Если кого интересуют примеры функционально-структурных схем могу предоставить примеры.
16.
+ -
idef 17.03.2010 22:32
(15) Вы все правильно говорите, но опять же со стороны "как должно быть".
Цитата
ТЗ - цивилизованные отношения двух сторон.

А на практике приходит программист к заказчику, показывает ТЗ, а заказчик-то образованием 5 классов извините, говорит:"... Я в этом ничего не понимаю. Мне надо знать сколько денег я заработал!".
Как быть?
15.
+ -
wumka 17.03.2010 22:24
Разрешите вклиниться буху в беседу.

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

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

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

ТЗ - цивилизованные отношения двух сторон.

Ответили: (16)

14.
+ -
idef 17.03.2010 17:50
ИМХО создание ТЗ безусловно необходимо, но в определенной ситуации.
Например, работа команды разработчиков, внедренцев должна быть согласована посредством ТЗ(или каким-то другим способом) иначе весь проект ожидает провал.
В случаях небольших проектов (обычно фри) достаточно подробного описания задания и условий его выполнения с подписями сторон.
13.
+ -
src 17.03.2010 10:07
Можно только лишь написать примерный план работы, а то 2 и 3 плана с различными способами выполнения задачи. ТЗ - не может быть законом для разработчика если оно не составлено самим разработчиком. Всего не предусмотришь, руководствоваться одним лишь ТЗ - большая ошибка. Как правило выходные и входные данные очень часто изменяются. Заказчик - может не заплатить не потому, что у него есть или нет ТЗ, а потому, что ему не понравился результат и ему все равно было ли составлено ТЗ или нет.
Автор, программист? Если да, тогда 2х2 не 4?? smile:) Спасибо.
[+]: idef;

Отредактировано src 17.03.2010 10:12

12.
+ -
Трактор 17.03.2010 10:03
Предлагаю ещё одну тему. "Как с помощью ТЗ нихрена не делать"
Сейчас я работаю в штате. Получил некую задачу в виде потока сознания. Ну лень финику ставить задачу, а директор требует. Оформил этот поток сознания в виде задания и послал на согласование директору и финику с вопросом "Правильно ли я понял задачу". Чую сгинет задача по причине всеобщей лени. А мне от этого ни холодно ни жарко. Мяч не на моей стороне.
11.
+ -
Арчибальд 17.03.2010 09:42
Когда исполнитель внешний - это одно дерево, а когда внутренний? Отдал вот сегодня на согласование эскизный проект, и то не уверен, будет ли он когда-то утвержден.
По сути, составление хорошего ТЗ - это половина интеллектуальных затрат на решение проблемы. Даже описывая риски в эскизе, уже приходится выявлять будущие подводные камни - и, естественно, прикидывать "фарватер".
В конечном итоге ТЗ я себе всегда делаю - в виде перечня обнаруженных ловушек и примененных фишек + описание функционала модулей. Но оформить его должным образом оказывается задачей неподъемной.
Честно говоря, я знаю, что эта задача не "оказывается", а только кажется неподъемной. Но так не хочется насиловать себя, любимого в особо циничной, извращенной форме...
[+]: parabellum; Redokov; СергейК; Трактор;
10.
+ -
toshik 17.03.2010 09:37
Полностью поддерживаю. smile:!: Конфликтов меньше. Клиент лучше продумывает свои требования, потому что все, что за рамками ТЗ оплачивается отдельно. Кроме того, серьезных клиентов мягко сказать "удивляет" отсутствие ТЗ (желательно хотя бы отдаленно составленного по ГОСТУ). И что не мало важно, позволяет программисту лишний раз задуматься и оценить жизнеспособность своего алгоритма.
[+]: wumka;

Страницы: 1 2 Вперед →

Оценка сообщества

15

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

Рекомендую Не тратить время
Если рейтинг упадет до -5, то публикация автоматически скроется.

Другие публикации автора

См. также:

УПРАВЛЕНИЕ ПРОЕКТОМ, МЕНЕДЖМЕНТ » Разработка технического задания