Кто нить встречал идеальное тз? для 1с или вообще. Чото мне кажется идеальным будет если в тз будет код который через буфет перенести в 1с и вуаля. Если его нет, то постановщик всегда дурак.

всю ветку не читал. КГ/АМ уже было?

Давай выкладывай, чего там у тебя случилось и кто тебя обидел?

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

(0) Я встречал.

где граница прог/постановщик

(3)
Определись для себя - что ты хочешь от фрилансера?

(5) Ровно посередине.

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

(4) поделишься хотяб структурой?
ПС есть конечно ГОСТы, но они мохнатых готов и там воды 90%

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

(0) Пример-то есть? Когда исполнитель тупит.

(3) Начитался сказок про то, как устроился работать и нанял фрилансеров из регионов? Ну вот обратная сторона сказки. Сидеть на попе ровно пока другие вкалывают не получится.

(9) Например использую такую:

Введение
Назначение технического задания
Перечень бизнес-процессов
Бизнес-требования. Ограничения
Методологические основы
Основные данные
Описание реализации бизнес-процесса в системе
Документы системы
Отчетные и выходные формы
Архитектурная реализация

(12) просто знаешь что это у меня займет 2-3 часа, а приходится 2-3 дня переписываться "а зачем вам это надо, нельзя снимать с поддержки, давайте уговорим клиента на типовой документ, а откуда это брать..."

(13) чем кстати рисовать БП красивше? я пока остановился на ментальных картах MindManager.

(14) Пока твой фрилансер не въедет в специфику клиента - так и будет. Либо будет другой вариант - вроде бы, сделано по ТЗ, но не то.

(14) Дай китайцам удалённый доступ к компу и пусть они сами ТЗ обсуждают. Что ты как маленький? :)

(13) Задача - необходимо в документ добавить реквизит "Экспедитор", тип реквизита "СправочникСсылка.Физлица". Теперь давай распишем это ТЗ по твоей портянке...
(14)Если у тебя это займет 2-3 часа - какой смысл отдавать на аутсорс? сделай сам. Хочешь, что бы человек тебя понял - не умничай со всякими там ТЗ - объясняй па "пальцах", что и как тебе надо.

(17) :) хочу оставить себя в цепочке

(0) Есть стандарты написания ТЗ если они написано по стандартам, то значит оно нормальное. А вообще ТЗ должен писать разраьотчик или его руководитель, в ТЗ должны быть описаны все методы и решения которые применяются в работе и пишеться оно не для того чтобы кому то было понятно что по нему делать, а для того чтобы решение было прозрачно и потдерживаемо.

(19) В каком качестве?

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

выбирай :)

(18) когда по телефону и на пальцах, то пишут лижбы отделаца и потом тебя же тыкают - у вас же не было ТЗ по схеме (13) чо хотите...

(21) в качестве р/с
(22) обидно что зная сколько бы я один за это взял никак не равно двум половинам на постановщика и кодера. получается бюджет надо повышать

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

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

(23) >>то пишут лижбы отделаца..
Если человек так пишет, то он так будет писАть вне зависимости от наличия\отсутствия ТЗ.

(26) в идеале манагеры ТЗ не пишут

(0) А зачем вам ТЗ? Какие цели вы хотите достичь его написанием?
Если что, существуют технологии разработки, не предусматривающие ТЗ. Всякие там Agile

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

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

(0) наз таких шли да и все

(30) Ну вот пусть сначала замучает себя описывая необходимые возможности.

(31) не в сказке живем, чего поделать уж.
предпроектные обследования и диалоги с заказчиками никто не отменял. если у вас это упрощено до диалога менеджер-прог, в этом вряд ли виноваты ГОСТы или кто-то, кроме вашего начальства. на неконкретных постановщиков задачи тоже есть методы воздействия, вопрос в том, насколько нужны эти холивары.

(15) У нас в Арисе схемы рисуются
(18) Так и расписывается

ТЗ необходимо делать на любые , даже мелкие доработки печатных форм. Для того что бы иметь актуальную документацию конфигурации.

После ТЗ рождаются иструкции, актуализированные бизнес процессы, функциональные требования.

(36) Глупость все это (имхо). Работа ради работы нафиг не нужна (имхо).

(37) Ну да зачем выстраивать систему.

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

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

(0) Как сказал мне один очень умный рук проектов в свое время:
"Толя, никогда не работой с идиотами", чему собственно я и придерживаюсь до сих пор ;-)

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

А вообще- с прогером надо сработатся, чтобы он понимал тя с полуслова, как и ты его- иначе написание ТЗ превращается в муку, правда и сдача работ по ТЗ это тоже мука ;-)

(30) Это сильно зависит от степени подробности. ТЗ легко может быть трудозатратней работы.

кг/ам

(42) А кто сказал что оно должно быть проще? Потому руководитель и получает больше чем программер.

(0) счасливчик, ему ТЗ еще пишут. попробуй со слов понять и простить зачеркнуто выполнить

(14) Значит из твоего ТЗ не понятна конечная цель. Найди того, кто не будет думать, а будет писать. А потом сам пообновляй раз в квартал полученное. Поймешь, почему фрилансеры тебя хорошему учат )

(46) +100500.

(25) ТЗ: Сделать кнопку "Сделать все хорошо!". При ее нажатии должен автоматом исправляться весь учет и сдаваться все необходимые отчеты без участия человека. И чтобы без штрафов. Иди делай.

(48) ТЗ по ГОСТу и я подумаю

(44) Во-первых, это сказано в (30). Во-вторых, руководитель получает больше совсем не потому, да и тз более трудозатратные, чем сама работа - это всё же редкость.

(49) Ты специалист или кто? Может за тебя еще и все написать? :)

(51) я не против

Охаять можно всё, но если в ТЗ написано, что вводится и что получается, то именно это при приёме программы и проверяется.

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

соглашаемся

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

Но если в ТЗ писать как сделать, это может привести к удорожанию. Если не написать цель, а только то, что нужно сделать, например, добавить реквизит, сделать такую-то проводку, то у программиста появляется масса вопросов - а зачем? Он сам вынужден выяснять цель проекта.  

Если программисту цель не ясна, то результат строго по ТЗ может не соответствовать ожиданиям заказчика, т.к. у него в голове была другая цель.

(0) До любого одинесника можно докопаться и опустить его до уровня барана. Главное, задать грамотно вопрос!

(54) А все от того что никто из вас не знал что такое ТЗ особенности реализации отражаются в тех документации в прилдожении - в ТЗ только требования на пользовательсвокм уровне.

(3) ну так делегируй фри кроме кода написать ТЗ, если оно конечно не состоит из добавления реквизита и вывод его на форму )

(59) Только потом не надо удивляться, что фри попросит денег ещё и за создание ТЗ. ;)

(60) это я думаю даже не обсуждается

(58) да что ты говоришь:

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

wiki:%D2%E5%F5%ED%E8%F7%E5%F1%EA%EE%E5_%E7%E0%E4%E0%ED%E8%E5

Работал в конторе-франче с мегаизвестным названием. Видел их ТЗ. Лучше - не встречал: минимализм + наглядность + эффектность, диаграммы eEPC, стройность структуры. Использую как шаблоны для написания текущих ТЗ, выкинув рассусоливания типа "сокращений", "целей системы" и прочего шлака, ненужного для ежедневного использования.

Так вот: копаясь в свойствах документов, в одном из ТЗ встретил организацию Oracle )))

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

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

(64) я более доверяю ВИКИ, не же ли твоим субъективным доводам по поводу "Что это такое и как это должно быть".

"побольше стандарты смотри" - Если не поленишься и пройдешь по ссылке, то увидишь .что ГОСТ там прилагается.

(66) Чему я доверяю я уже написал а на вопрос ты так и не ответил где и в каком стандарте написано что в ТЗ должны быть описаны методы решения?

(67) а где написано, что НЕ ДОЛЖНЫ?

(68) Ндаа похоже ты буквы читать научился, а смысла написанного так и не понял.

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

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

(0) По моему, варианта ровно два. Либо повышать свой скилл написания ТЗ, либо находить фрилансера, согласного работать по твоему ТЗ, остальное правильно додумывать и не вякать.

Поскольку ТС отказывается привести конкретный пример непонимания, склоняюсь к первому варианту.

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

У бухгалтеров самые верные цифры в бух. регистрах, в оборотках.
У менеджеров/продажников - в регистрах накопления. ;)

(0) Идеальное тз - это не программный код.
Идеальное тз - текст, в котором однозначно определено, как понять: выполнено задание или нет.

(54) Зачем рабу давать свободу? Пристегнуть к батарее , дать в зубы ТЗ и вперед.

(74) Это уже сценарное тестирование.

(56) Поэтому в ТЗ должны быть описаны бизнес процессы затрагивающие доработку.

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

(0) Все, что называлось ТЗ в постах от 0 до 73 - это не ТЗ, а ТП. а вот в (74) - то, что и является целью написания ТЗ. ТЗ - это прежде всего требования в БУДУЩЕЙ системе и правила контроля и приемки, а уж никак не ее описание...

(79)+ И еще. если ТЗ написано по ГОСТ 34 - к нему никто никогда не докопается и уж тем более не обхает. Поверьте на слово...

(79) Ошибаешься, это больше похоже на "Концепцию приемки релизов и сборок", а так же на "Сценарии тестирования релизов и разработок".

(81) Не видел в ГОСТ 19, ГОСТ 34 и ИСО 12207 (на память, может другой немного номер) таких названий документов. Откуда это?

(82) Некая госорганизация связанная с российскими атомными проектами )))

(83) Ну так это внутренние документы той самой организации. Разработанные наверняка на базе ГОСТ и ИСО. А может кто-то сильно вумный из головы такое наваял. Но если это корпоративно утверждено, то это внутренние утвержденные документы, требования которых должен выполнять подрядчик или только для внутреннего потребления. Мы тоже при написании проектной и эксплуатационной документации руководствуемся внутренними требованиями компании. Но на моей памяти никогда не было придирок к документации по ГОСТ 34. И мое мнение - в ГОСТ 34 есть все для того, что бы корректно составить документацию, что бы ее все понимали, что бы никто не смел охаивать, а только ставить свою подпись или мотивированный отказ при согласовании.

(84)+ В среде 1С очень часто путают задание программисту на код и ТЗ как официальный документ на разработку.

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

(76) Неа.
Например: "Сделайте так, чтобы нам было хорошо" - это тоже ТЗ.
Причем идеальное.

(87) Это абстрактное пожелание, не содержащее задания разработчику и ничего по технической его части.
Нельзя использовать для выполнения и приемки работы.

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

(88) Вы работаете по найму?

(0) чо, ты там все так все понятно написал, а разработчик рж0т и говорит, что креатив гениален и автор молодец, но в этом задании нет ни чего технического, тема сисек не раскрыта, а цели не описаны?

ссылка-то на ТЗ будет?

(87) Реализация данного ТЗ - можно приволочь Заказчику ящик Хенесси, можно выстрелить в висок - вопрос - а что на самом деле хотел Заказчик остался нераскрытым... Это не идеальное ТЗ, это ТТ с натяжкой...

(93) да ладно вам, нормальное наркоманское ТЗ )

(93) а хенесси - рану на виске протирать, чтобы пуля инфекцию не занесла?

(94) Даже если наркоманские - не ТЗ, а только ТТ...

(95) Это по данному ТЗ не предусмотрено - либо одно, либо другое...

(97) алоизыч говорят два совместил и траванулся и застрелился )

(97) + там не просили два раза хорошо. Но опять же - это не задание, а только требования к...

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

(100) ТЗ нужно читать, а не слышать...
п.1 - не факт.
п.2 - обязательно
п.3 - это вывод из ТЗ, но тоже правильно
п.4 - не факт
п.5 - это тоже вывод, но ТЗ пишется для подрядчика, поэтому согласен на 100%

(101) п.1 спартанцы бы одобрили