Автор: Олег Бунин
Этой статьей я не хочу доказать, что написание технического задания - зло и корень всех бед, нет, ни в коем случае. Все и всегда относительно, а в нашем случае - зависит от задачи. Я хочу показать, что классические схемы разработки программного обеспечения работают не всегда, не всегда эффективны, часто приводят к ненужным конфликтам между менеджерами и исполнителями. Особенно это касается разработки веб-приложений. Я расскажу об экстремальном программировании, но не так, как пишут в книжках, а исходя из реалий - из того, что попробовали команды под моим руководством. О тех методиках, которые работают.

http://www.computerra.ru/think/286727/

пустышка... как и все в этой компьютерре.

(0) статью не читал, но ТЗ (красиво оформленное, с рюшечками и пр.) - не пишу, буду писать только за бабки, причем возьму за ентот "реферат" почасово, ибо нефиг

сам себе ТЗ не пишу, но в некоторых случаях всё же бывает накидаю чё-нить, чтоб бабла побольше было :))

(0) Я тоже всегда выступал против ТЗ. Но перефразируя Черчилля: ТЗ - это худшая форма постановки задач, но ничего лучше пока не изобретено. Хотя экстремальное программирование со своими постоянными итерациями - это действительно мощная альтернатива водопадной модели.

(4) ты что-то очень интересное написал, но после слов "экстремальное программирование" я ничего, увы, не понял. т.е. может я это как-то по-другому назваю :)

(5) Пройдись по ссылке в (0).

(3) ну сам себе в вольной форме а-ля "записки сумасшедшего" - это да :)
(6) ага

(5) или помучай яндекс по этим словам.

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

Автоматизация хаоса
Экстремальное программирование
v8: Экстримальное программирование
v8: альтернативная методика программирования
OFF: Что такое экстремальное программирование?

Статья типа "Что нам стоит дом построить?! Нарисуем, будем жить!"

(9) неужели вы ещё не привыкли некоторых посылать на йух?

(9) согласен, но... старая школа, вообщем все на взаимном уважении и доверии и... поменьше ненужных бумажек :)

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

Ларман Крэг
Применение UML и шаблогов проектирования.
ISBN 5-8459-0250-9
PS Сейчас занимаюсь внедрением, где нельзя в принципе составить ТЗ. Ибо бизнес-процессы не формализованы. Грубо говоря, клиент сам не знает, как надо...

шаблогов -> шаблонов

(13) понимаешь, я просто решаю задачу чуть по-другому, ну нет четкого ТЗ, просто структура должна появиться у меня в голове, она должна просто родиться и все. ТЗ для этого (письменное) мне только будет мешать
(15) вот, как раз в тему, +1

(15) Все собаки твои.
(17) А кто сказал, что ТЗ надо сразу писать жестко и не вносить туда изменения ... за счет заказчика?

(18) никто не сказал, я просто не люблю канцелярскую работу, ну не бюрократ, понимаешь? это все творчеству только помеха, а писать в стиле типовых... да я себя ненавидеть буду...

(19) Тогда все собаки твои.

+(20) Отымеют по полной в творческом порыве.

(18) конечно мои. За это нам и платят приличные деньги :)

(20) я не ем собак, я не вьетнамец. просто типа договорились на ПРОГРАММУ (а что оно такое заказчик не знает, но хочет знать цену), я говорю примерный срок и цифру, когда по моему мнению я наработал эту цифру - говорю заказчику, он платит, продолжаем дорабатывать. при этом ессно все порядочно, не нужно неверно трактовать (это я на всякий случай уточнил)

(22) Да что-то в большинстве таких случаев не платят, а наоборот, недоплачивают или кидают со словами "не-е-е-е-е, не то!".

(23) на ПРОГРАММУ ... взвесьте мне, пожалуйста 100 гр еды. Это прокатит для простых очевидных случаев. Их не так уж и много.

(24) меня кинули за 6 лет работы (ну я не общий стаж посчитал ессно, а РАБОТУ) и 4 года работы на фри, только один раз, на 300 у.е., причем с этой конторой наработал тысяч пять. вот так.

(25) нет, речь типа "автоматизируйте нам учет на кондитерской фабрике"...

(27) Автоматизировали? Не-е-е-е-е-е, не то! Денег не дадим!

(28) да, основное - да, теперь уже бантики-хотелки

(26) Это с Марса статистика. Клиент, который хз что хочет, любит и будет кидать.
(29) Какие бантики, суть не та ... потому что никто ничего не понимал в процессе разработки.

(30).1 можно я просто улыбнусь? :)
2. отчего же? я  - понимал, пусть и не сразу :)

(31) Можно. Только вот платить такой клиент любит по результату. А из-за топтания на месте результат стоит больших усилий. Не за работу ты получал деньги, а за "дружбу" с начальством, которое тебе платило из чужих денег, денег владельцев.

(32) вот ты неправ, круто ошибся. из крупного  - вообще не припомню, а мелочи типа стобаксовой доработки - не по теме. я НИКОГДА не давал откатов, если ты об этом и другим образом тоже не "дружил", договариваюсь исключительно с хозяевами и все проходит через них, исполнители - просто помогают разобраться в задаче.
не торопись ярлыки клеить.

(33) Значит были ТЗ. Без ТЗ платят по результату.

Ни один вменяемый хозяин не будет платить хз за что.

(34) так мне тоже не за большие зеленые глаза платили, только причем ТЗ? да, был результат, хозяин доволен - деньги у меня. ну и так ясно же.
(35) конечно. тоже мне открытие :)

(36) Ё-моё! Без ТЗ обычно тебе сегодня скажут одно, завтра другое, послезавтра третье. Ты делаешь, исправляешь и тратишь кучу сил. Затраченные силы и результат несоразмерны обычно. Вот это и есть корень конфликта.

Более-менее крупную задачу без ТЗ не решить, без бумаг не осилить.

результат - это решение основных вопросов, намеченных заранее, просто формочки покнопочно и полный перечень отчетов поколоночно никто не рисовал. да, мне доверяют решать, что в каком порядке делать и каким образом, в-основном все подходит, коррективы конечно вносим. и в 95% желание клиента - "сделайте мне учет" и усе...
(37) я там выше писал о ВЗАИМНОМ уважении и порядочности...
вот так и работаем

(38) значит или задачи мелкие или ты ошибаешься :)

(38) Так значит ТЗ в виде основных вопросов было? Что же ты тогда голову морочишь?!
Порядочность заканчивается тогда, когда начальник Вася не может воровать из-за твоей программы.

(41) не на бумаге и в неофициальном формате, записывал и брал на бумажных носителях образцы первички, любимые распечатки и т.п., и то не все, остальное - в голове  :)

(40) Я просто не раз на такое нарывался. Просто убежден, что отсутствие бумаг - начало скользкой дорожки. Фиксировать каждый чих в большом проекте - правило! Иначе потом воришка Вася откажется от своих слов и ты будешь выглядеть дураком.

(42) Значит людям было вообще все пофигу.

(43) я тебе больше скажу, все крупные проекты (дальше без валидола не читать!!!) по цене решались исключительно устно и (еще хуже сейчас будет, совсем стращно) аванчы я беру крайне редко
(44) ага, всем. классно объяснил "внушаить" :)

Правило такое: большой проект - ТЗ + фиксировать все шаги, иначе подставят по полной.

(46) ага. большой проект - убедиться во вменяеммости заказчика, иначе я отказываюсь. все проще :)

(45) В общем, не рекомендую ориентироваться людям на твой опыт. Практика показывает совсем обратное, особенно в крупных компаниях.

(47) Ну да, везде дураки подписывают договора с ТЗ, а у тебя все плюшево. Мож даже и так, но вот советовать делать как ты другим не стоит.

(48) ага, вот здесь согласен, на 100%
"Эй вы, задние, делай как я - это значит, не надо за мной! Колея эта только моя, выбирайтесь своей колеей" (с) Высоцкий
и пусть это будет выводом в ветке :)

(43) у моих клиентов все так же, как у инсайдера. Нет формализованных бизнес-процессов, но конторы из-за роста без адекватного учета начинают задыхаться. Несколько проектов завалил. Причины - незаинтересованность/саботаж/непонимание что надо делать со стороны клиента. Сейчас пытаюсь такие варианты отсекать в самом начале. Авансы не беру. Не кидали.

(51) спасибо, а то уже забил меня почти Леха :) ну просто Эверест непонимания...

(51) Найдешь другие варианты, пиши. Саботаж был, есть и будет везде... потому что везде воруют, приписывают, обманывают и прога им будет как кость в горле.

(52) Хе-хе. Да он же пишет, что как раз провалы и были!

(52) просто мы с тобой - "мелочь пузатая". Одиночки, не работавшие в команде (я по крайней мере). А в команде без формализации, "выложенной" на бумагу (сайт и т.п.) не обойтись

На самом деле есть только один вариант обойтись без ТЗ - иметь офигенный авторитет. Тогда даже самые злобные саботажники пикнуть испугаются.

(53) канэшна :) вот сколько раз на такое наступал, а потом эпитеты от МОЛов "таких как вы стрелять надо"
короче "Я здесь непрошенный гость, я здесь как в горле кость" (с) 9-й район (старый состав)
(55) я хоть и работал в команде, но на меня просто быстрокидали весь проект и потом я тянул его сам...
конечно согласен, так мы же и не автоматизируем Газпром :)

(55) Мелочь пузатая фабрику не автоматизирует, не сможет.

(58) ой ли? :)

(58) да, не сможет. Я на фабрику и не претендую. А вот на ВУЗ - да :)

(59) Значит это хрень, а не задача, так ... кусочек.

(60) Весь? Или 99% в экселе осталось?

+59 (в плане писькомеряния, не воспринимать серьезно, хотя это правда) один из моих не особенно прибыльных клиентов на начальном этапе, был Укртелеком (думаю понятно из названия, размерчик конторы) :)

(62) Рамер компании понятен. Непонятен размер задачи.

В общем либо блат, либо хз что. Дал челу Укртелеком его автоматизировать без ТЗ!!! Офигеть!

(61) гадом буду, крест на пузе (с) один из бывших директоров :)
полностью автоматизировал, в частности, вышеприведенную конд. фабрику (небольшая, тонн примерно 200 тыс. в год, а то и больше), не "АВК", но и не ларек
(64) вот потому там и смайлик был, хотя там прикольно было, но не особо много, честно :)

(62) сейчас пока все в екселе и вёрде. Но я надеюсь, что загну под 1С.
Сейчас расписание бывает появляется за день до учебного события. Главное, есть понимание руководства, что именно ексель мешает двигаться дальше

(67) ексель у моих почти что не юзается, и это не единственный случай. ибо мелкий офис - зло :))

(66) Вот это ужо подозрительно, что госконтора такого масштаба отдала деньги челу без ТЗ, договора и пр. Бред! Юротдел не пропустил бы просто так.

(67) Так бы сразу и сказал, а то ... все автоматизировал.

(68) Ты либо гонишь, либо что-то умалчиваешь.

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

(70) это твои домыслы. Я такого не писал

+(71) ИМХО, личная связь у тебя есть серьезная, потому так и работаешь.

(73) Ну автоматизировать мелкий кусок в ВУЗе ... студенты это делают даже на лабах.

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

(76) Не, фигня какая-то. Надо быть очень неординарным, чтобы тебе вот так вот верили и под тебя гнулись. Иначе саботаж, конфликты. Пожирнее рыбы то сопротивление встречают. Конторы порой крупные не могут пробить сопротивление, а тут один чел ... без ТЗ.

Спать пойду. Не смущай народ былинами :).

(77) почему "гнулись"? я никого не наклоняю, есть же цивилизованный способ - договориться :)
самое смешное, что в ряд контор приходил после того, как там побывали и фра и фри и фикси. все уходили. в ряде крпных оставался админ и то нечасто.
(78) ну что мне сделать? ну правду хотел - я сказал, ну если не нравится - напиши мне речь :))
P.S. у нас недорого программеров ценят, потому и без крпных просто не жить было бы :(

(78) моха, а может это зависть?

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

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

(80) Это опыт. Если кто хочет, то пусть работает без ТЗ, но парить мозг не надо.
(82) Ты что-то важное не сказал, ИМХО.

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

(80) Еще ... без ТЗ можно не задачу решать, а ублажать локальные задачки отдельных сотрудниковв не последнего звена. Это реально, но это не автоматизация, ИМХО.

(0) полный бред...
серьезный сайт без ТЗ не сделать

другой вопрос когда ТЗ можно разделить на маленькие части

например:

1. Согласование цветовой гаммы
2. Согласование основных технических возможностей (поиск, выгрузка из 1с и т.д.)
3. Согласование Главного меню
4. Согласование 1 страници
...
99. Сдача работы

но в такой схеме нужно каждый шаг расценивать отдельно а скопом оценить работу не возможно...

Нормальная статья... Фиксировать и формализовывать требования к ПО надо, а писание ТЗ программистом самим для себя - это пустая трата времени.

(+86) ИМХО Чем раньше заказчик увидит куда всё движется тем лучше для всех.

(0) Неплохая статья. Немного экстремальная, но такой подход практикуется. Вот только денег за такие внедрения нужно брать больше, посокольку риски тоже высокие.

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

(88) >>Вот только денег за такие внедрения нужно брать больше, посокольку риски тоже высокие.

Неизвестно где еще риски выше. Можно слепить по ТЗ "от и до", но т.к. среда разработки/платформа/архитектура была выбрана неверно может получиться полное г.

(82) Для такой работы нужны непосредственный контакт с первым лицом и его полная вменяемость. Мечта...

В системе Microsoft Solution Framework (MSF) практикуется циклический процесс разработки/внедрения и ТЗ как такового нет, есть другие документы. В PMBOK тоже нет понятия ТЗ. Хотя эти системы и не предусматривают экстремального программирования.

(89) Когда лепишь ТЗ можно выявить возможные риски, покрайней мере это нужно делать. Если всетаки твое ТЗ оказалось Г., то в при экстремальном программировании результат будет не лучше.

(90) + 1000000000000000000000000000000000000

(91) Не может быть регламентирующих документов вообще, просто они названы по-другому.

(94) Ессно. В MSF функции ТЗ разбиты на разные документы, которые составляются на разных этапах разработки.

(95) Так, ё-моё! Убрать ТЗ под ковер и сказать "у нас его нет!"  - решение проблемы ввода задним числом доков по ПиТу! Те же грабли, только в профиль!

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

(92) Это всё риски будут вида "тестирование сферического коня в вакууме".

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

(97) Остается еще, правда, вариант "заказчик платит не из своего кармана и он птица".

фсотне!

давайте в терминах разберемся - если иметь ввиду ТЗ как его понимает, например, ГОСТ, то создавать его имеет смысл только в относительно крупных проектах, ИМХО. С другой стороны в качестве ТЗ можно понимать требования к ПО, зафиксированные в той или иной форме. Хотя бы в форме тех же "приемочных тестов".

(97) Всё он нормально пишет. И ТЗ для приемки нах. не надо. Можно написать тестовый сценарий со сквозными примерами и идти по ним. Заказчик если не идиот знает какие цифири должны получиться.

(98) Ну ВР уже упоминал что метод написания ТЗ несовершенен, но это единственное что у нас есть.

в той же КТ была статья про поиск "серебрянной пули" (вот тут: http://offline.computerra.ru/2006/649/281662/). Вот от туда:

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

(102) Конечно не надо! Только вот потом заказчик на приемке скажет: НЕ ТО!!! Иди доказывай, что ты сделал то, что он тебя просил.

(102) ок! традиционная задача - партионный учет. откуда заказчик знает, какие цифры должны получиться?

Да и вообще, чего мелочимся то!? Вот задача: "Сделайте мне хорошо!". Идите, программируйте без ТЗ или чего-подобного.

(102) при отсутсвии опыта в общении с РАЗНЫМИ заказчими так можно говорить, в противном случае либо ТЗ либо пошагавое внедрение (много мелких ТЗ)

(105) Заипись... А раньше вы чем с заказчиком занимались, до приемки? Тестовые сценарии согласовываются с обоих сторон.

(106) Вы меня удивляете ей богу... заказчик не знает что 2+2 = 4?

(107) Формализация задачи нужна всегда. Чего фигню несём? И ТЗ тебя тут не спасет, если заказчик упрется.

(109) /1 Без комментариев. Наивняк!

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

(111) А если в группе, то регламент нужен еще строже.
Жрать пойду.

(110) Комментариев нет потому что сказать нечего... А сказать нечего потому что так не работал. Но мнение своё уже имеет.

Регламент - да, нужен, но регламент совместной работы, но не ТЗ, утвержденнное заказчиком.

(109)/2 да, заказчик этого не знает. решение большинства задач не настолько очевидны...

и вообще - самое главное - четкое определение и фиксация целей! т.е. для чего это все вообще делается. А когда нет цели, то все равно что делать. Пока у заказчика не кончатся деньги.

(115) Нельзя обнять необъятное. Но функционал системы можно разбить на участки, которые можно описать тестами.

(114) Это если есть "ТОЛСТЫЙ ДОГОВОР" когда деньги платяться по предоставлению о проделанной работе и оценка ее идет в нормочасах лицами производящими эти работы.

Мне-бы пару таких договоров.... Мечта....

заказчик (з) - хочу супер сайт
контора (к) - без проблем!!!
з - скока стоит?
к - 50$/ в час работы
з - базара нет!!!



А обычно бывает так:

заказчик (з) - хочу супер сайт
контора (к) - без проблем!!!
з - скока стоит?
к - Чего стоит?
з - супер сайт!!!
к - а какой?
з - ну не знаю, но супер!
к - тогда давайте распишем, что Вы хотите (и начали писать задание)

(118) А в чем тут противоречие статье в (0)? Вы сидите и формализуете требования заказчика раз он сам не может. Хотя ключевые "хочу" вы наверное от него услышите. А потом начинаются итерации описанные в (0). ИМХО Т.к. всё что заказчик хотел получить начнет складываться после того как вы представите первый вариант/итерацию.

(117) опять возвращаемся к началу: на основе чего будем писать тесты?

(113) Очень даже работал. Проходит время и заказчик с хитрой улыбкой: "не то делали, по-другому нужно". Или еще хуже, на обсуждении у руководства представитель заказчика (эмоционально): "я же 100 раз говорил, что делать нужно по-другому!".
(117) Оплата как: по результату или по часам? По результату? Тогда четко расписываем ТЗ.
(119) Ты понимаешь, что такое ТЗ? Заказчик не обязан его составлять, но подписаться под ним обязан.

(120) Ну требования к системе ведь зафиксированы? Если заказчик "хочет фифо" наверное можно написать наподобие "в систему приходуется 3 морковки, потом 3 и потом 2. В системе списывается 7 морковок, остаток 1 из такой-то партии. В списаном товаре распределение по партиям такое-то". Я конечно утрирую но общий смысл думаю понятен...

(122) где и как зафиксированы требования к системе? в виде устных договоренностей?

(122) ГДЕ зафиксированы?

(123) Ждешь что сейчас сверкнет заветное слово "ТЗ"? :)) Конечно в виде документа с согласованием обоих сторон. Другой вопрос его наполнение. Автор в (0) и пишет о том что ТЗ "подробненько" писать иногда бессмысленно, всего не предусмотришь, а время потратится оно устаревает т.к. заказчик уже еще что-то хочет. Нужны ключевые вещи. Чем раньше заказчик поймет куда всё идет, тем лучше.

(122) Общий смысл? Он у каждого свой. Даже ТЗ не всегда....
Пример. Невинная фраза из ТЗ:

"Все количество распределяется по всем покупателям поровну с округлением до 1 шт. Погрешность округления относится на последнего покупателя"

приводит к очень интересным результатам.

Итак, на 100 покупателей поступило 40 штук. Поровну означает 40/100 = 0,4 штуки. С округлением до одной штуки получается 0, то есть все 40 штук получит последний покупатель.

Еще веселее, если на 100 покупателей поступило 60 штук. Тогда все покупатели, кроме последнего, получат по одной штуке, а последний... -39 (минус тридцать девять) штук.

Программа соответствует ТЗ.

(126)+ Это из одной старой статьи А. Орлова

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

(126) И разработчик будет прав. Доработка за счет заказчика. Но нормальные люди вовремя заметят, оповестят и минимизируют ущерб.

(125) тогда возвращаемся к (101) и начинаем разбираться с терминами. Что автор в (0) имел ввиду под "ТЗ"?

(126) Я думаю это вряд ли то что заказчик ожидает.
(128) Чего так нервничаем? Ну утверждаете - флаг вам в руки.

(129) Такого разработчика надо за яйца вешать.

(130) Я не знаю. Я же не автор из (0). Допустим сейчас я работаю по документу "Спецификация требований".

(131) Часто заказчик даже не удосуживается представить себе "вживую" то, что он в ТЗ пихает.

Вот ссылка на статью http://klerk.ru/soft/1c/?848

(131) /1 (132) /1 - если задача большая, то такие грабли возможны. Доработка за счет заказчика. Надо смотреть, что подписываешь.
(132) /2 Мда, а чем она отличается от ТЗ?

(133) И так бывает. Допустим текущие требования должны выполняться на 3 разных системах, написанные на разных языках и платформах. Ни о какой привязке к 1С естественно речи нет. Ну и чего теперь? Я должен написать ТЗ для себя? И куда мне это ТЗ себе я должен засунуть?

(133) Можно сделать итерацию и дать посмотреть. Скажут что "не то" и уточнят.

(135) в папочку. чтобы через неделю (месяц, год) тупо не вспоминать: "ё-моё, чтож я наделал-то" :)

(137) бугага...

(121) "Проходит время и заказчик с хитрой улыбкой: "не то делали, по-другому нужно"
Вот потому и не то, что зафиксировали ТЗ и жестко по нему работали. Без обратной связи. Для решения этих проблем и была придумана итеративная разработка. Нет там ТЗ.

(139) Прикидываешься? Делали, постоянно оглядываясь и перетряхивая ТЗ. Контакт был полный, т.к. это мои очень хорошие знакомые. И потом вдруг ... с хитрой улыбкой.