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

27.03.10

Архитектура

 

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

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

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


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

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

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

 

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

 

 

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

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

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

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

 

См. также

Как мы автоматизировали башню раздачи воды

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    1422    0    slavik27    4    

14

Управленческие аналитики для 1С:Бухгалтерии – отчеты для принятия верных решений

Отчеты и дашборды Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    1640    0    Serg_Tangatarov    2    

15

Архитектурное ревью. Процесс разработки

Архитектура решений Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    3828    0    ivanov660    10    

29

Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    1823    0    user1754524    15    

15

Опыт оптимизации системы ERP на примере железнодорожного холдинга численностью 10 тыс. человек

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

29.08.2023    2859    0    ke_almaty    0    

14

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    9588    0    1c-izhtc    37    

21

Внедрение системы технологического контроля (практический кейс)

Кейсы автоматизации Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Управленческий учет Бесплатно (free)

Стабильное качество выпускаемой продукции и ее соответствие нормативным документам (ТУ, ГОСТам, СМК) для активного предприятия является конкурентным преимуществом, так как оно подчеркивает, что на предприятии отлажены контрольные процедуры на входящее сырье, производство полупродуктов и готовой продукции, доставки. В своей практике я принимал участие во внедрении цифровых инструментов в сельском хозяйстве, где показателями зерна служат влажность, засоренность, крупность и т.д.; в металлургии — перед литьем в формы надо проверить сплав на содержания железа, алюминия, магния и т.д.; в кабельной промышленности в дополнение к физическим свойствам типа геометрии, длины, шероховатости, надо выдерживать и электротехнические показатели. 

22.05.2023    1384    0    Ingraf    0    

15
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Yurisel 48 20.03.10 08:21 Сейчас в теме
Полностью согласен с мнением автора. Я сам в техзадании обычно ограничиваюсь проработкой концепции проекта. Главное отразить общую картину, чтобы было понятно заказчику, что он получит в результате. Детали прорабатываешь уже в процессе выполнения проекта. А толстые тома, которые иногда мне попадают на рецинзирование, там как правило за частностями теряется общее, а бывает что его и вообще нет.
MegaKent; +1 Ответить
2. Evg-Lylyk 4559 20.03.10 16:51 Сейчас в теме
Согласен с автором.

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

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

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

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

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

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

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

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

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

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

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

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

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