В интернете искал там очень большие статьи. Предлагают работу где я должен писать технические задания.

Пятнично

(0) Соглашайся

(2) и Врагу не пожелал бы
всегда виноват будешь

http://3.bp.blogspot.com/_UWPsw_DgfYM/R4EmhL6j4CI/AAAAAAAAAkA/vGL51gB64fg/s1600/realizat.gif

работа интересная

(3) Полностью согласен!

(0) Подскажите как разбить атом, в интернете слишком много книг, перелагают работу на БАК.

(0) Молоко за вредность будут давать?

1. покаяться за "ваша программа не работает"
2. исправить
3. goto 1

(3) Хы, хы, хы... Это вы их готовит не умеете. У меня обычно заказчик всегда виноват. :) И не подкопаешься.

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

(10) +1

я вчера в стоматологии такое подписал - если что всегда "сам дурак"

(12) Ясен пень — ты же сам пришёл именно в эту клинику.

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

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

(11) Только при наличии качественного (0), иначе никакого удовольствия, один геморой

(15)+1

(0) кури ГОСТы!!1 Без этого сейчас - никуда!!11адынадын ))) азаза

(10) Это скилл его нарабатывать нужно. Ну и некоторые качества в себе подавлять.

(0)
1) Причина т.е. чем вызвана необходимость доработки .
2) Как пользователь сейчас решает эту проблему и как видит ее решение с помощью автоматизации .
3) Какие , чьи интерфейсы , роли должны быть изменены.

(3) Что мешает подписывать задания у заказчиков?

(0)Адовая работа.

(21) Чаще всего заказчики подписывают по принципу "отвали, не мешай работать".
А потом вопят

(0) Всё здесь: https://goo.gl/VfJqI5

>> Из чего состоит техническое задание для 1с

Преимущественно из псевдоинтеллектуального бреда и нелогичных умозаключений в совокупности с неприменимыми рекомендациями профнепригодных недоспециалистов по структуре хранения и алгоритмов обработки данных.

Обязательно идите. Будете много общаться, много ездить, уровень свободы максимальный - все равно никто из участников процесса не врубается в происходящее.

(19) >>Ну и некоторые качества в себе подавлять.
Часто приходится подавлять голос разума )))))

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

(25)Смешно)

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

Основные разделы - 2 и 3. По ним по идее даже без раздела "данные" грамотный разработчик может обойтись

(0) посмотри 1С:ПрофКейс

(0) Из экспозиции, завязки, кульминации, развязки и эпилога.

(29) Если не хочешь геморроя, достаточно пункта 2...

(0) помню, писал ТЗ, 2 месяца потратил, Word изучил в совершенстве, получилась толстенная книга в 150 страниц. Несколько раз перепечатывал с уточнениями, потом всё-таки утвердили.

А делать не стали, заказчик передумал почему-то.

(0) из текста.
Техническое задание это просто описание работы которую надо выполнить с необходимой детализацией.

А уж какая детализация вам необходима - решаете сами в каждом конкретном случае.

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

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

Главное знать для чего оно нужно, а уж как написать, это приложится.

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

(34)Бред

(0) Из завязки, кульминации и развязки.

(0) самое главное понимать степень формализации твоих отношений как с заказчиками так и с исполнителями.

если отношения подразумевают человеческие отношения и желание получить результат - это одно ТЗ

если все упирается в попилы и процесс - это совсем другое ТЗ нужно

так, что сабж не раскрыт и ответа на него невозможно дать...

(0) Техзадание состоит из требований. Требования группируются по разделам. Перечень разделов смотри в ГОСТ34.602.
Состав разделов и какие разделы надо включать, а какие не надо, зависит от сущности автоматизируемой системы/процесса. В обязательном порядке в любом ТЗ должны быть разделы Назначение и Цели создания. Далее по ситуцаии - если ТЗ на систему/подсистемы целиком, то обязательны требования к системе в целом, если это допилки к опилкам, то можно сразу к требованиям к функциям переходить. Требования должны быть сформулированы так, чтобы из текста было понятно, как понять, реализовано оно в итоге или нет. То есть - точность, атомарность, однозначность, уникальность и прочая изменемость. Все требования должны быть уникально пронумерованы, чтобы можно было в переписке и разговорах легко ссылаться на конкретные пункты, а не цитировать стену текста.

Весьма здраво вводная часть о том, как писать ТЗ, написана, как это не странно, в введении к IEEE830 - читать обязательно и крайне важно понять, о чем там. Так же в IEEE830

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

+(39) так же в IEEE830 приведена своя структура разделов, которая, хотя и тоже имеет право на жизнь, с гостом не дружит и, как следствие, при следовании структуре этого стандарта можно попасть в непонятное (хотя и не обязательно).

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

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

ТЗ нужно только для того, чтобы, чем больше бумаги, тем чище жопа, а еще для того, чтобы госконтракты затаскивать.
В реальности же ТЗ - это, в общем-то, фикция и оно к результату мало отношения имеет.
Потому, что:
1. Каким бы идеальным ТЗ ни было, программисты сделают то, что возможно в данной конкретной ситуации (технической, экономической, политической и т.д.), из того, что умеют. Ни какое ТЗ новых мозгов имеющимся программистам не добавит и невозможное возможным не сделает.
2. единственная методология проектирования и разработки, которая реально дает надежный результат - это "блинная диета". Когда разработчика, заказчика и аналитика (переводчика между ними) запирают в комнате и под дверь просовывают блины до тех пор, пока эта команда не выдаст какой-то результат. Блины потому, что это единственная еда, которую можно просунуть, не открывая дверь. Всё. Все остальные методологии, технологии, скрамы-херамы дают результат только тогда, когда в ядре этой методологии-технологии где-то под тонной умных слов закопана блинная диета (как во многих ajile-штуках).

(42) ТЗ вообще нужно только для того, чтобы попу прикрывать и ни для чего больше.

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

+(44) То есть ТЗ нужно только для заказной разработки - я об этом говорю.
Для внутренней (собственно) тех, кто предлагает писать ТЗ, надо брать за яйца и застреливать сразу без разбирательств. Они враги.

(36) Что конкретно не так?

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

(45)
Ты, видать, ничего сложнее ПоступленияТоваров не писал.

Да же не то чтобы "не писал" - отношения не имел.

(48) у тебя со зрением что-то, раз тебе это видать

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

(45) После расстрела, когда придет очередной руководитель-всезнайка и спросит: фейхуа это всё? Всё надо не так, а задом-наперед, тот, что всё же написал хоть какое, даже слабое ТЗ на полстранички, будет наблюдать за вашими пассами по части вырывания волос с филейной части. И продолжит работу, в отличие от участия в Вашей дискуссии с начальниками.

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