Систематизация опыта подготовки технического задания

Управление - Техническое задание

Решил «закинуть» на портал свою статью пяти-шестилетней давности. Статья писалась для внутреннего употребления в нашей компании – обобщил и систематизировал свой опыт. Думаю, кому-то она будет полезной. В процессе подготовки статьи немного отредактировал первоначальный вариант.

1. Зачем пишут ТЗ

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

Почему это нужно сделать?

Для этого существуют следующие причины:

1) Написание документов позволяет взглянуть на задачу «со стороны» потому, что при написании документ «отделяется» от автора и начинает жить своей самостоятельной жизнью. Автор и другие участники могут увидеть в замысле слабые места или пропущенные моменты.

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

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

4) Заказчику заранее важно увидеть, как будут тратиться его деньги.

В таблице ниже дано описание того, что дает ТЗ заказчику и разработчику:

Что дает ТЗ Заказчику

Что дает ТЗ Разработчику

Определение цели

Осознать, что именно ему нужно

Понять суть задачи

Описание Продукта

Представить, как будет выглядеть готовый продукт

Показать заказчику «внешний облик» продукта

Планирование проекта

Определиться, когда будут выполнены работы и когда будут получены результаты

Оценить трудозатраты и потребности в ресурсах.

Бюджет проекта

Определить бюджет проекта

Определить бюджет проекта

Ход работ проекта

Контролировать ход работ проекта

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

Передача результата работ

Испытать Продукт по программе испытаний в соответствии со спецификацией требований

Подготовить Продукт к испытаниям в соответствии со спецификацией требований

Управление изменениями в проекте

Управлять изменениями требований, возникающими в процессе работ, разрабатывая дополнительные ТЗ на изменения в Продукте

Управлять изменениями требований, возникающими в процессе работ, разрабатывая дополнительные ТЗ на изменения в Продукте

Случаются ситуации, когда одна из сторон пытается отказаться от создания ТЗ. Обычно это происходит в двух случаях:

1) Заказчик специально не устанавливает четких требований, чтобы потом бесплатно эксплуатировать разработчика «на скрытых работах» по своему разумению.

2) Разработчик надеется на постоянное продолжение работ за счет заказчика, аргументируя это некой неопределенностью.

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

2. Что пишут в ТЗ

2.1 Стандарты ТЗ

Форма и содержание ТЗ создается на основании установленных шаблонов. Это сокращает затраты, время и систематизирует работу. Как правило, для создания ТЗ используются следующие виды стандартов:

1) Международные стандарты

2) Государственные стандарты

3) Корпоративные стандарты

Кратко опишу стандарты, используемых для написания ТЗ:

Международные стандарты.

Наиболее известным международным стандартом является стандарт IEEE Std 830. Стандарт IEEE Std 830 предполагает, что детальные требования могут быть обширными и не существует оптимальной структуры для всех систем. Стандарт рекомендует структурировать детальные требования таким образом, чтобы структура каждого раздела требований была наиболее оптимальной для понимания. Стандарт предлагает различные способы структурирования детальных требований для различных классов систем.

Государственные стандарты.

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

В большинстве проектов внедрения 1С:Предприятия данный стандарт является избыточным и сложным для понимания даже для разработчиков АС. Однако, когда разработка ТЗ всё-таки ведется по данному ГОСТу предлагается полностью сохранять структуру документа в соответствии с установленным стандартом. При этом по «пустым» разделам просто вносить комментарии типа: «По данному разделу требования отсутствуют».

Корпоративные стандарты.

Корпоративный стандарт существует на отдельном предприятии или в холдинге. Обычно корпоративный стандарт берет за основу любой из двух предыдущих стандартов и дорабатывается с учетом особенностей данного предприятия и его бизнес-процессов. В проектах внедрения 1С чаще всего используется корпоративный стандарт в виде упрощенного варианта ГОСТа34.

2.2 Разделы ТЗ

В индустрии внедрения ИС создано множество корпоративных стандартов на разработку ТЗ. Каждый стандарт содержит в себе специфический опыт ключевых сотрудников предприятия. Однако, на мой взгляд, есть разделы, которые обязательно должны присутствовать в каждом ТЗ. Эти разделы включают в себя:

1) Описание целей и задач, которые должна решать информационная система (ИС);

2) Описание функциональных требований к ИС.

3) Описание процесса передачи ИС заказчику.

4) Описание сроков и стоимости работ.

Рассмотрим каждый пункт по отдельности.

2.2.1 Описание целей и задач

Это самый важный раздел ТЗ. В нем дается ответ на вопрос: «Зачем вообще все это будет делаться?». Многие специалисты очень формально подходят к этому разделу и формулируют цели в виде двух трех коротких предложений общего содержания. Эта большая ошибка. В этом разделе заказчик и разработчик должны установить четкие ориентиры, которые правильно и однозначно понимают обе стороны.

Раздел должен содержать в себе:

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

2.2.2 Описание функциональных требований к ИС

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

Понятие система включает в себя следующие составные элементы:

1) Если это программно-аппаратный комплекс (ПАК), тогда в систему входит:

  • Платформа программы 1С:Предприятие;
  • Конфигурация программы;
  • База данных;
  • Документация на ПАК;
  • Рабочие станции;
  • Серверы с серверным оборудованием;
  • Внешнее оборудование (считывающие, передающие устройства и т.п.),

2) Если это автоматизированная система, тогда она включает в себя:

  • ПАК;
  • Пользователи, работающие с ПАК;
  • Документация на АС;

2.2.3 Описание процесса передачи ИС заказчику

В этом разделе ТЗ описываются:

  • правила передачи результатов работ;
    • что будет предъявлять каждая сторона (изделие, документация, квалификация персонала и т.д.);
    • что и каким образом будет испытываться;
    • что будет определять, что испытания прошли успешно;
  • порядок процесса передачи результатов работ;
    • кто будет участвовать в данном процессе;
    • какая квалификация должна быть у каждого участника процесса;
    • какова должна быть последовательность действий в процессе;
    • кто и как будет определять, что испытания прошли успешно;
  • порядок разрешения конфликтных ситуаций в процессе передачи работ;

2.2.4 Описание сроков и стоимости работ

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

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

3. Как разрабатывают ТЗ

Процесс написания ТЗ можно разделить на следующие этапы:

1) Планирование работ;

2) Сбор информации;

3) Анализ и синтез информации;

4) Написание документа;

5) Согласование документа;

3.1 Планирование работ

Перед написанием ТЗ следует подумать, как лучше организовать работы, чтобы получить качественный документ с наименьшими затратами. Написание ТЗ лучше выполнять не спеша, чтобы задача постепенно «созревала» в вашем мозгу. Желательно, чтобы сбор информации и написание ТЗ выполнял один и тот же человек. Опыт показывает, что попытка сэкономить время путем распределения работ между несколькими участниками, может привести к потере качества документа, а значит и качества изделия.

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

3.2 Сбор информации

Существует несколько видов источников информации:

1) Методическая или техническая документация по данной задаче или аналогичной задаче, уже имеющаяся у заказчика;

2) Методическая или техническая документация по аналогичным задачам из других источников;

3) Проведение интервью с ответственными исполнителями заказчика;

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

Перед началом интервью специалист обязательно должен составить план интервью, в котором он устанавливает:

  • Название проекта;
  • Стороны проекта;
  • Участников интервью;
  • Время и место интервью;
  • Вопросы для интервью;

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

3.3 Анализ и синтез информации

Под анализом и синтезом информации я понимаю процесс «разбора» требований на элементарные кусочки и последующей «сборки» стройной системы требований. «Разборка» требований на элементарные куски позволяет провести их инвентаризацию и классификацию. В процессе анализа собранной информации выявляются ошибки и противоречия, находятся повторяющиеся элементы типа «в лоб» или «по лбу». По выявленным проблемам принимаются соответствующие меры: либо все исправляется по собственному разумению, либо производится повторное интервью.

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

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

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

3.4 Написание документа

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

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

3.5 Согласование документа

Умение согласовывать готовый документа является не менее важным, чем умение разработать и написать этот документ. В соответствии с ГОСТ 34.602-89 предлагается следующий порядок согласования ТЗ:

1. Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки; тактико-технического задания и т. п.).

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

2. Необходимость согласования проекта ТЗ на АС с органами государственного надзора и другими заинтересованными организациями определяют совместно заказчик системы и разработчик проекта ТЗ на АС.

Работу по согласованию проекта ТЗ на AC осуществляют совместно разработчик ТЗ на АС и заказчик системы, каждый в организациях своего министерства (ведомства).

3. Срок согласования проекта ТЗ на АС в каждой организации не должен превышать 15 дней со дня его получения. Рекомендуется рассылать на согласование экземпляры проекта ТЗ на АС (копий) одновременно во все организации (подразделения).

4. Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием. Решения по замечаниям должны быть приняты разработчиком проекта ТЗ на АС и заказчиком системы до утверждения ТЗ на АС.

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

6. Согласование проекта ТЗ на АС разрешается оформлять отдельным документом (письмом). В этом случае под грифом “Согласовано” делают ссылку на этот документ.

7. Утверждение ТЗ на АС осуществляют руководители предприятий (организаций) разработчика и заказчика системы.

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

9. Копии утвержденного ТЗ на АС в 10-дневный срок после утверждения высылаются разработчиком ТЗ на АС участникам создания системы.

10. Согласование и утверждение дополнений к ТЗ на АС проводят в порядке, установленном для ТЗ на АС.

11. Изменения к ТЗ на АС не допускается утверждать после представления системы для ее очереди на приемо-сдаточные испытания.

12. Регистрация, учет и хранение ТЗ на АС и дополнений к нему проводят в соответствии, с требованиями ГОСТ 2.501.

К сожалению, данный порядок не раскрывает методологии проведения согласования. Хорошая методология согласования ТЗ позволяет упорядочить и существенно сократить процесс согласования. Это особенно важно, когда заказчик или его представители начинаю «ходить кругами», бессистемно плодить претензии, перескакивая с одного уровня документа на другой. Это приводит к многократным и бессистемным переделкам ТЗ, что с большой вероятностью может просто «похоронить» документ.

Для систематизации этого процесса предлагается установить следующие правила согласования ТЗ.

Перед началом согласования ТЗ разрабатывается документ «План согласования ТЗ». В Плане фиксируются участники, сроки, правила и форма согласования ТЗ. План обязательно следует подписать сторонами проекта. Форма согласования ТЗ должна включать в себя:

  • ФИО участника;
  • Должность или роль в проекте;
  • Пункт ТЗ, по которому есть замечание;
  • Описание замечания и предложения по его исправлению;

Процесс согласования должен проводиться по следующим правилам:

  1. Согласование общей структуры документа (наличие всех необходимых разделов и групп требований);
  2. Согласование детальных требований по разделам (полнота, точность определений, их непротиворечивость и т.п.);
  3. Согласование формы написания документа (грамматика, синтаксис, пунктуация и правила оформления и т.п.).

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

См. также

Комментарии
1. Андрей Ст (sisdrou) 24 26.04.17 17:08 Сейчас в теме
Вот интересно почитать статью более полного разбора стандартов ТЗ IEEE Std 830 и ГОСТа34 на практике.
2. Алексей Апанасович (Aphanas) 109 27.04.17 07:51 Сейчас в теме
Кто должен заплатить за ТЗ?
3. Ildar Gabdrakhmanov (spezc) 308 27.04.17 09:36 Сейчас в теме
4. Алексей Апанасович (Aphanas) 109 27.04.17 11:00 Сейчас в теме
(3) Как обосновать заказчику цену?

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

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

Как быть?
5. Николай Больсунов (boln) 935 27.04.17 11:31 Сейчас в теме
Случаются ситуации, когда одна из сторон пытается отказаться от создания ТЗ. Обычно это происходит в двух случаях:
1) Заказчик специально не устанавливает четких требований, чтобы потом бесплатно эксплуатировать разработчика «на скрытых работах» по своему разумению.
2) Разработчик надеется на постоянное продолжение работ за счет заказчика, аргументируя это некой неопределенностью.

В этой ситуации противоположная сторона должна обязательно настоять на создании ТЗ с четкими границами и определениями задач.
Абсолютно согласен. Сам один раз лет 15 назад побывал в ситуации №1 - больше никому не желаю.

На любое дополнительное движение мышью, на любую строчку кода, не прописанные в ТЗ - корректировка ТЗ с соответствующей "отдельной платой". Иначе - рабство, хорошо, если относительно мягкое.
6. Николай Филиппов (Soliton) 162 27.04.17 11:33 Сейчас в теме
(4) Алексей.

Для этого случая используется вариант предпроектной оценки работ. Где-то на портале я видел такую статью. Оценка стоимости дается в КП.
7. Ildar Gabdrakhmanov (spezc) 308 27.04.17 11:36 Сейчас в теме
(4) у клиента всегда есть альтернатива.
Вариант один - заплатить за ТЗ 1млн рублей и на его основе принять решение (возможно отказаться от внедрения и сэкономить/не потерять 5 млн рублей).
Вариант два - не платить 1млн за ТЗ и потерять в будущем 5млн.
rusmil; sergathome; HAMMER_59; CSiER; +4 Ответить 3
8. Ildar Gabdrakhmanov (spezc) 308 27.04.17 11:38 Сейчас в теме
(4) И этот диалог я бы переделал:
Заказчик:...
Руководитель проекта:...

Если заказчик общается напрямую с программистом, то размер проекта по определению мал и смысл "ТЗ за деньги" бывает трудно донести. Тогда тут просто на свой страх и риск и с оглядкой на собственный опыт.
9. DAV DAV (DAV) 27.04.17 11:39 Сейчас в теме
(4)
Как обосновать заказчику цену?

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

(4)
Заказчик: Наверное, я мог бы заплатить за ТЗ, но если в результате разработки ТЗ окажется, что проект мне не по карману или он нереализуем, получится, что я выбросил эти деньги на ветер?

Не на ветер, у него останется ТЗ на функционал и понимание сколько это стоит. Порядок цифр перед заказом задачи он все равно должен понимать. Еще есть вариант препроектного обследования после которого можно дать более точную оценку чем до проекта, но с бОльшими допусками по срокам и стоимости, но за меньшую цену чем полноценное обследование. Впрочем, предпроект не отменяет последующее обследование.
Lacrimosa0000; Aphanas; +2 Ответить 1
10. Николай Филиппов (Soliton) 162 27.04.17 11:53 Сейчас в теме
(7)

Например статья:
Проблемы оценки ИТ-Проектов. Александр Чавалах.

http://infostart.ru/public/340027/
11. Николай Филиппов (Soliton) 162 27.04.17 12:05 Сейчас в теме
(8)
Для небольших работ пишется небольшое ТЗ (частное). Просто формат частного ТЗ будет меньше:
1. Цели и задачи;
2. Согласованный набор требований - протокол;
3. Краткая концепция реализации;
4. Порядок приемки работ;

Все это может занять 1-2 странички - это неважно.

Я считаю, что программист или инженер должны уметь писать ТЗ быстро и качественно, всегда писать ТЗ, даже если за него не платят.
Это вопрос культуры и умения качественно работать. Просто где-то нужно пройти такую школу.
12. Николай Больсунов (boln) 935 27.04.17 12:48 Сейчас в теме
(4)
Как обосновать заказчику цену?
Это советский подход. Не "обосновывать", а торговаться о цене.
МимохожийОднако; +1 Ответить
13. Виктор Григоренко (JohnGalt) 2 27.04.17 13:59 Сейчас в теме
Если ТЗ нет, расплачиваются и заказчик, и исполнитель.
14. Николай Филиппов (Soliton) 162 27.04.17 14:25 Сейчас в теме
(7)
у клиента всегда есть альтернатива.
Вариант один - заплатить за ТЗ 1млн рублей и на его основе принять решение (возможно отказаться от внедрения и сэкономить/не потерять 5 млн рублей).
Вариант два - не платить 1млн за ТЗ и потерять в будущем 5млн.


Отчасти, Вы правы,
Но, всё-таки, тот, кто заказал ТЗ на 1 млн. рублей уже понимает зачем ему нужно внедрение на 5 млн. Чтобы доказать ненужность внедрения на 5 - 50 млн. рублей достаточно заказать экспертное обоснование за гораздо меньшие деньги.

Хотя, у каждого свои тараканы...

Мне как-то пришлось выступать независимым экспертом в проекте, где уже потратили 50 млн. (первоначально бюджет оценивался в 46 млн.) и конца еще не было видно. Там была куча концептуальных ошибок. Моё предложение подготовить системное обоснование - концепт, не вызвало большого энтузиазма ни у подрядчика, ни у заказчика. Все продолжали дружно "трясти дерево" дальше...
В результате проект кое-как доделали и признали "успешным" (у каждого был свой интерес) при конечном бюджете около 90 млн.
15. Геннадий Николаев (genayo) 28.04.17 10:49 Сейчас в теме
(7) Ну вот например ТЗ на внедрение 1С ERP через год превратиться в тыкву, так как функционал типовой изменится до неузнаваемости :)
sergathome; monkbest; +2 Ответить 1
16. Александр Дмитриев (МимохожийОднако) 117 03.05.17 07:23 Сейчас в теме
(14) Просто твоё предложение противоречило очевидной цели - натрясти себе денег. Видимо, заказчик не был плательщиком.
17. Александр Дмитриев (МимохожийОднако) 117 03.05.17 07:24 Сейчас в теме
Неплохая статейка для обучения и старта. Первый шажок, так сказать.
18. Ruslan Odessa (rus128) 2 03.05.17 12:29 Сейчас в теме
Опечатка: "однозначно понимаю(т) обе стороны"
19. Николай Филиппов (Soliton) 162 03.05.17 14:50 Сейчас в теме
(18)
Опечатка: "однозначно понимаю(т) обе стороны"


Спасибо. Поправил.
20. Сергей Любезнов (sergathome) 11.05.17 09:24 Сейчас в теме
(15)
Вот, +100500. Ахиллесова пята всех внедрений типовых 1С-систем - отсутствие ...хммм... не знаю даже как это назвать... культуры, наверное, у головного производителя. Внедренцы могут хоть обскакаться, но поддерживать такое внедрение будет также дорого, как и внедрять. Причём объяснить это квалифицированному заказчику, не сталкивавшемуся раньше с миром 1С, практически невозможно ;))
ifilll; Aphanas; +2 Ответить 1
21. Сергей Д (dddxddd) 12.05.17 12:29 Сейчас в теме
Просто мысль по теме.
Даже на инфостарте много статей про ТЗ и его необходимость, но никто ни разу не выложил простенькую конфигурацию для написания пусть простенького, но стандартизованного ТЗ.
22. Алексей Апанасович (Aphanas) 109 12.05.17 12:43 Сейчас в теме
(21), нельзя автоматизировать хаос
sergathome; +1 Ответить 1
23. Сергей Д (dddxddd) 12.05.17 13:39 Сейчас в теме
(22)Вообще-то речь о написании ТЗ, а не об автоматизации хаоса у заказчика.
Если вопрос писать или не писать ТЗ оставляем за скобками, то сам процесс написания это шаблон (кейс - по модному) определенных действий. А результат написания, т.е. сам текст ТЗ, это заполненный шаблон документа, а если уж совсем по "взрослому", то содержание этого документа, определяется ГОСТ-ом.
Именно эти факты я и имел ввиду говоря о простенькой конфигурации в которой бы был реализован один или несколько кейсов подготовки и оформления ТЗ. А еще тут на инфостарте есть много конфигураций для планирования и контроля исполнения задач, но в большинстве своем все эти "задачники" с безголовыми задачами, т.е. не привязанные к конкретному ТЗ.
Поэтому Ваше утверждение "нельзя автоматизировать хаос" в разрезе моего поста, надо переформулировать "все не хотят или не могут устранить хаос в вопросе написания простых ТЗ для 1С-ных поделок"
Вот так как-то.
24. Николай Филиппов (Soliton) 162 12.05.17 14:16 Сейчас в теме
(21)
Просто мысль по теме.
Даже на инфостарте много статей про ТЗ и его необходимость, но никто ни разу не выложил простенькую конфигурацию для написания пусть простенького, но стандартизованного ТЗ.


У меня была такая конфа. Лет 10 назад мы в одной большой фирме-франчайзи баловались этим.

В принципе структура такой конфы несложная. Самое ценное - это база накопленных знаний.

Кстати, есть идея это дело довести до ума. Когда-то остановился на том, что нужно писать её не на 1С.
25. Николай Филиппов (Soliton) 162 12.05.17 14:23 Сейчас в теме
По поводу базы для написания ТЗ. Смотрел в интернете - есть простенькие программульки.

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

Если кто не против, тогда можно договориться о совместном коммерческом использовании.
26. Сергей Д (dddxddd) 12.05.17 17:36 Сейчас в теме
Продолжение мысли по теме...
(24)
Когда-то остановился на том, что нужно писать её не на 1С.

ИМХО Логичней это делать в 1С, потому что:
1. Так как тут разговор идет про автоматизацию на 1С.
2. Имея простенькую конфу, реализующую упрощенный бизнес-процесс "подготовка ТЗ" каждый может расширить ее своими особенностями.
3. Есть много реализаций учета задач, например вот, вот или вот одну из которых неминуемо захочется "прицепить" к конфе для ТЗ
4. Используя современные возможности БСП, легко организовать доступ в 1С-ную конфу представителей другой стороны.
5. Дальше идут стандартные 1С бонусы ввиде легкости отчетности, понятности, возможности доделки на ходу и т.п.

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


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

Тоже не против поучаствовать в написании такого ТЗ.
27. Евгений (Scop) 21 16.05.17 08:28 Сейчас в теме
(24)
Кстати, есть идея это дело довести до ума. Когда-то остановился на том, что нужно писать её не на 1С.


Тоже готов поучаствовать, если это будет на 1С.
28. Алексей Апанасович (Aphanas) 109 17.05.17 05:49 Сейчас в теме
(9)
Не на ветер, у него останется ТЗ


Таким образом, можно ли деятельность по написанию ТЗ превратить в отдельный бизнес?
Это было бы удобно, на мой взгляд - заказать ТЗ у специализированной фирмы.
29. Николай Филиппов (Soliton) 162 17.05.17 13:11 Сейчас в теме
(28)

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


Да, так и есть.

Мы этим занимаемся много лет. Мы даже авторский надзор осуществляем.
30. Николай Филиппов (Soliton) 162 17.05.17 13:13 Сейчас в теме
По поводу разработки ТЗ на 1С.

Коллеги, спасибо за ваши предложения - сейчас немного разгребу текучку - готов обсудить. Но на 1С решение имеет свои ограничения.

Хотелось бы сделать рынок немного шире.
31. Элипсандр Эшман (ifilll) 21.07.17 09:28 Сейчас в теме
(20) Отсутствие культуры производства, отсутствие культуры делопроизводства, в общем отсутствие культуры..
Часто по туалетам на предприятиях видно ))
Оставьте свое сообщение