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

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

Пятнично

Соглашайся

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

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

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

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

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

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

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

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

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

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

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

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

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

+1

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

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

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

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

Адовая работа.

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

Всё здесь:

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

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

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

Смешно)

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

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

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

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

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

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

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

Бред

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

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

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

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

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

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

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

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

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

Что конкретно не так?

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

Ты, видать, ничего сложнее ПоступленияТоваров не писал. Да же не то чтобы "не писал" - отношения не имел.

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

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

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

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