gifts2017

Еще раз про техническое задание

Опубликовал serg (sergL) в раздел Управление - Техническое задание

 

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

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

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


На самом деле все и всегда решается на личных отношениях программиста и заказчика. Когда есть обоюдное желание и стремление получить результат, будет происходит предварительное согласование работ, когда программист реализует, то о чем договорились будет период отладки, то есть по «месту работая напильником собирать самолет». Как договориться о деньгах есть два проверенных способа:

1.      Динамический исходя из стоимости часа работы.

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

 

Ни какой гарантии, что клиент заплатит за работу при наличии ТЗ нет и не будет.

 

 

Прочитав комментарии понял, что не совсем четко донес основную мысль статьи. Здесь не обсуждается, надо или нет писать ТЗ, надо или нет заключать договор. Конечно надо. Но относиться к этому серьезно нельзя. Очень серьезно надо относится к созданию нормальных, творческих отношений с клиентом. И если эти отношения не складываются, нельзя продолжать работы, не смотря не на какие суммы и договоры с клиентом надо расставаться, на рынке полно работы через некоторое время .

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

4 сентября 2008 года подаем в суд. На сегодняшний день суд продолжается, по мнению юриста предстоят еще 3-4 судебных заседаний, и суд примет решения в нашу пользу только по подписанным актам выполненных работ. Между каждым заседание 1,5 – 2 месяца. Потом есть вероятность, что клиент подаст на апелляцию и все начнется с начала. Так что деньги мы получим скорее всего к концу 2014 году. Возникает вопрос, а ради чего.

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

 

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Юрий Буляков (Yurisel) 20.03.10 08:21
Полностью согласен с мнением автора. Я сам в техзадании обычно ограничиваюсь проработкой концепции проекта. Главное отразить общую картину, чтобы было понятно заказчику, что он получит в результате. Детали прорабатываешь уже в процессе выполнения проекта. А толстые тома, которые иногда мне попадают на рецинзирование, там как правило за частностями теряется общее, а бывает что его и вообще нет.
sashankz; +1 Ответить
2. Евгений Люлюк (Evg-Lylyk) 20.03.10 16:51
Согласен с автором.

Справка, документация полезны, а техзадание больше нужно когда предполагаются конфликты, претензии.
У меня был случай когда я делал техзадание, которое в последствии делал другой программист. Мозг он мне на счет него вынес :) прилично "не ясно написано", "не все моменты узнал" в результате что то сделал в разрез задания (естественно никто не пошел даже на дополнение к заданию). ТЗ часто просто повод взять деньги, нужно на крупных проектах (где много разработчиков) и там где этого требует заказчик.
3. A A (aiw) 21.03.10 00:43
а я не согласен. иногда клиент по ходу дела начинает петлять - то то добавь, то это наоборот сделай и т.д.....
так вот ТЗ вылечили практически все проблемные ситуации... просто их теперь нет - проблем
o.nikolaev; +1 Ответить
4. Вячеслав Кадацкий (marsohod) 21.03.10 01:32
Никакой гарантии, что клиент заплатит за работу при наличии ТЗ нет и не будет.
Согласен. Обратное тоже верно: даже при отсутствии ТЗ разработка может быть оплачена клиентом полностью. Около года назад у меня так и было: написал индивидуальную конфу для местного института вообще без ТЗ. И оплатили.
5. Павел Духанин (Traas) 22.03.10 12:04
В статье опущено одно определение. Масштаб проекта. Одно дело. если ты пишешь обработку или отчет простенький, и другое - если разрабатываешь учетную систему... Хотя и там и там ТЗ больше добро чем зло. формулируя и согласовывая ТЗ и Заказчик и Исполнитель начинают понимать ЧТО в конечном итоге получится и КАК ЭТО будет работать, что в будущем поможет и в расчетах....
gadjik; alex_bob; larisab; artamon; o.nikolaev; +5 Ответить
6. Ярослав Радкевич (WKBAPKA) 22.03.10 12:09
ситуации бывают разные, но в принципе без ТЗ нельзя... с другой стороны писать тома как для заказчика так и для исполнителя не совсем целесообразно... это связано в первую очередь с тем, что на этапе технического задания могут быть не учтены важные детали которые по ходу дела выплывут... с другой стороны остается в этом случае вопрос оценки проекта... опять же все зависит от задачи.. .как по мне, так ТЗ должно быть кратким, а оплата поэтапная... за каждый этап 100% предоплаты... тогда исполнитель не работает авансом и клиент рискует не всей суммой проекта. закончился этап, акты подписали, получили предоплату, дальше работаем...
7. Ярослав Радкевич (WKBAPKA) 22.03.10 12:12
например, какое ТЗ должно быть написано при постановке управленческого учета? регламентированные документы которые должны быть разработаны и есть это ТЗ... хотя это может быть этапом... однако в практике часто выясняешь детали на этапе формирования отчетности... ;)
8. com1hi (1c.petya) 22.03.10 13:13
100% истина в том, что - население умственно недоразвито - действует без Договоров.
Выводы:
1. Лень писать ТЗ, так как не могут понять, для чего это нужно.

2. Без детального ТЗ, и, соответственно, Договора выигрыш получает недобросовестная сторона.
Так заказчик может начать говорить, что надо было сделать ещё 100 связанных задач, если изначально устная договорённость может давать различные трактовки.

3. Умственно недоразвитое население не знает ни нормативов сроков, ни договоров, ни детального ТЗ - поэтому выходит всё через Ж0пу.

Что мешает заключать договора согласно ГК?
LordChesterfield; +1 Ответить
9. Виталий Сысоев (Vital451) 24.03.10 07:27
1. Договор нужен всегда, это единственное доказательство что ты им что-то делал.
2. По окончании задания (или периода обслуживания) требовать акт выполненных работ.
3. Можно перестраховаться, ограничивая в коде период дейсвия функционала, а при оплате снять ограничение. Муторно конечно, но или вы с деньгами и они работают, или и вы без денег, но и они остануться на чем сидели.
LordChesterfield; +1 Ответить
10. o.nikolaev.infostart (o.nikolaev) 24.03.10 10:07
Это больше похоже на запись в блоге а не на статью :)
11. Андрей Колесников (nuendel) 24.03.10 14:17
Полностью согласен ...
Перенёс материал к себе на ресурс

Есть ещё один способ оценки: количество строк кода + сложность выводимых форм.
12. Vitaliy (idef) 24.03.10 16:44
(0) Ни какой гарантии, что клиент заплатит за работу при наличии ТЗ нет и не будет.
А ТЗ и не представляет из себя никакой гарантии. Кто вам такое сказал?

Здесь на ИСе уже все разжевали много раз.
Большинство все-таки за ТЗ. Потому что ТЗ это то с помощью чего исполнитель и заказчик находит решение возникших проблем. Естественно, что каждой задаче свое ТЗ. Иногда можно обойтись и без ТЗ.
Но попробуйте начать внедрение большого проекта, да еще и не типового? Без единой схемы?!
LordChesterfield; larisab; +2 Ответить 1
13. Вячеслав Кадацкий (marsohod) 25.03.10 09:48
(12) "... Без единой схемы?!"
Нет, конечно. Речь в данном случае не об этом. Безусловно, беседуя с заказчиком приходится что-то писать карандашом или ручкой... т.с. "на салфетках" :)
В дальнейшем эти записи могут вылиться в ТЗ, а могут и не вылиться. Оплата, как было отмечено, от этого не зависит.

P.S.
Что-то мне Ваша фраза напомнила "ни единого разрыва" :D
14. Vitaliy (idef) 25.03.10 10:40
(13)Не очень удачно выразился.
Хотел сказать, что как минимум должен быть общий план действий, последовательность и содержание работ, исполнитель и ответственный. Это может быть на салфетке или на финской бумаге А4 или на туалетной бумаге это каждый решает для себя сам. ;)
Главное то что все эти вопросы являются частично ТЗ(в том или ином виде), а ГОСТ-ом не регламентируется четко объем ТЗ.
Грубо говоря ТЗ может уместится на одной салфетке если спец такой профи - краткость сестра таланта.
К сожалению, я такого не встречал :)
15. Вячеслав Кадацкий (marsohod) 25.03.10 10:55
(13) вот, блин, к "салфеткам" придрался :D
Я же - образно...
16. Иван (1c_developer) 25.03.10 13:13
Я тоже считаю, что делать чертежи перед постройкой дома - глупость. Прораб с заказчиком всегда на месте решат куда кирпичи класть ;)
17. Vitaliy (idef) 25.03.10 14:45
(16) Угу! Прораб с заказчиком решат, а каменщик с подсобником по своему решат.
Вот так они и работали - каждый выполнял свою работу. Главное - добросовестно.
И придраться не к чему - стена то стоит. :D
18. blackoperator (fastwriter) 29.03.10 08:48
При любом, самом хорошем отношении с заказчиком есть вероятность возникновении спорных ситуаций. Например, чтобы доказать, что мы - самые крутые франчи во Вселенной, и что взятие программиста на постоянную ставку или переход к другим франчам клиенту не поможет.

Аккуратно оформленная документация, описывающая наши достижения является очень даже хорошим подспорьем в этом деле. И бывает полезно иметь документальные подтверждения проделанных работ с их кратким описанием.

Эти краткие описания не обязательно должны быть такими же подробными, как классические ТЗ. Более того, даже лучше, если они будут краткими и понятными далеким от автоматизации людям (директорам, замам, президентам компаний и др.).

Кроме того, такие краткие описания могут помочь даже руководсву самого франча быстрее вникнуть в ситуацию по работам с каким-то клиентом, если возникнет необходимость.
19. Яков Коган (Yashazz) 05.04.10 17:15
Ну всё в кучу... И деловые отношения общего партнёрства, и психологические моменты общения, и гражданско-правовые, и технологические... Ни терминологии прописанной, ни ясности изложения, один сумбур из серии "нас всё равно кинут, зачем писать ТЗ".
20. geo-nik (geo-nik) 21.06.10 18:04
21. Андрей Колесников (nuendel) 30.06.10 14:10
Полностью согласен...

Необходимое условие - у заказчика должно быть достаточно авторитетное лицо - заинтересованное в успехе проекта. А самое лучшее это как поддержка со стороны руководства, так и со стороны ведущего по теме специалиста.

Невозможно сделать и даже внедрить бухгалтерскую программу, если главбух против.
точно также нельзя ни сделать ни внедрить технологическую программу, если этому противится технолог
тоже самое по кадровикам....
22. Ivan Ivanoff (smarkuss) 26.08.10 10:59
По сути статьи не согласен.
Тех задание не есть гарантия оплаты. Оно скорее конкретизирует темпы, объемы работ и оплаты. Более ближе к гарантии оплаты находятся акты. Там конкретно указываются выполненые работы и их сумма, стоят подписи и печати.
Гарантией своевременной оплаты вашей услуги может быть желание клиента её получить и сотрудничать дальше.
Другими словами клиент должен созреть для конкретной автоматизации, тогда с ним можно практически работать. Либо дать откат лицу, принимающему решение. :D
Скорее всего в данном случае это опыт общения именно с неполностью зрелым в отношении к вашей услуги клиентом. Т. е. при определении задания о был как бы не против, ну за тоже особо не выступал.
Совет: работайте с "готовыми" клиентами.
23. assa assa (al`sera) 14.09.10 20:57
На 100% согласен.

Для многих кстати является открытием что по ГОСТ, техническое задание НЕ содержит детального описания, что и как будет сделано, а содержит лишь требования к системе по которым можно будет понять сделана система или нет
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа