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

26.04.17

Архитектура

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

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С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    1386    0    slavik27    4    

14

Управленческие аналитики для 1С:Бухгалтерии – отчеты для принятия верных решений

Отчеты и дашборды Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    1598    0    Serg_Tangatarov    2    

15

Архитектурное ревью. Процесс разработки

Архитектура решений Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    3750    0    ivanov660    10    

28

Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    1782    0    user1754524    15    

15

Опыт оптимизации системы ERP на примере железнодорожного холдинга численностью 10 тыс. человек

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

29.08.2023    2837    0    ke_almaty    0    

14

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    9515    0    1c-izhtc    37    

21

Внедрение системы технологического контроля (практический кейс)

Кейсы автоматизации Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Управленческий учет Бесплатно (free)

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

22.05.2023    1352    0    Ingraf    0    

14
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. sisdrou 23 26.04.17 17:08 Сейчас в теме
Вот интересно почитать статью более полного разбора стандартов ТЗ IEEE Std 830 и ГОСТа34 на практике.
2. Aphanas 92 27.04.17 07:51 Сейчас в теме
Кто должен заплатить за ТЗ?
3. spezc 781 27.04.17 09:36 Сейчас в теме
4. Aphanas 92 27.04.17 11:00 Сейчас в теме
(3) Как обосновать заказчику цену?

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

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

Как быть?
6. Soliton 300 27.04.17 11:33 Сейчас в теме
(4) Алексей.

Для этого случая используется вариант предпроектной оценки работ. Где-то на портале я видел такую статью. Оценка стоимости дается в КП.
7. spezc 781 27.04.17 11:36 Сейчас в теме
(4) у клиента всегда есть альтернатива.
Вариант один - заплатить за ТЗ 1млн рублей и на его основе принять решение (возможно отказаться от внедрения и сэкономить/не потерять 5 млн рублей).
Вариант два - не платить 1млн за ТЗ и потерять в будущем 5млн.
Designer1C; rusmil; sergathome; HAMMER_59; CSiER; +5 Ответить
10. Soliton 300 27.04.17 11:53 Сейчас в теме
(7)

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

http://infostart.ru/public/340027/
14. Soliton 300 27.04.17 14:25 Сейчас в теме
(7)
у клиента всегда есть альтернатива.
Вариант один - заплатить за ТЗ 1млн рублей и на его основе принять решение (возможно отказаться от внедрения и сэкономить/не потерять 5 млн рублей).
Вариант два - не платить 1млн за ТЗ и потерять в будущем 5млн.


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

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

Мне как-то пришлось выступать независимым экспертом в проекте, где уже потратили 50 млн. (первоначально бюджет оценивался в 46 млн.) и конца еще не было видно. Там была куча концептуальных ошибок. Моё предложение подготовить системное обоснование - концепт, не вызвало большого энтузиазма ни у подрядчика, ни у заказчика. Все продолжали дружно "трясти дерево" дальше...
В результате проект кое-как доделали и признали "успешным" (у каждого был свой интерес) при конечном бюджете около 90 млн.
16. МимохожийОднако 140 03.05.17 07:23 Сейчас в теме
(14) Просто твоё предложение противоречило очевидной цели - натрясти себе денег. Видимо, заказчик не был плательщиком.
15. genayo 28.04.17 10:49 Сейчас в теме
(7) Ну вот например ТЗ на внедрение 1С ERP через год превратиться в тыкву, так как функционал типовой изменится до неузнаваемости :)
sergathome; monkbest; +2 Ответить
20. sergathome 4 11.05.17 09:24 Сейчас в теме
(15)
Вот, +100500. Ахиллесова пята всех внедрений типовых 1С-систем - отсутствие ...хммм... не знаю даже как это назвать... культуры, наверное, у головного производителя. Внедренцы могут хоть обскакаться, но поддерживать такое внедрение будет также дорого, как и внедрять. Причём объяснить это квалифицированному заказчику, не сталкивавшемуся раньше с миром 1С, практически невозможно ;))
ifilll; Aphanas; +2 Ответить
31. ifilll 21.07.17 09:28 Сейчас в теме
(20) Отсутствие культуры производства, отсутствие культуры делопроизводства, в общем отсутствие культуры..
Часто по туалетам на предприятиях видно ))
8. spezc 781 27.04.17 11:38 Сейчас в теме
(4) И этот диалог я бы переделал:
Заказчик:...
Руководитель проекта:...

Если заказчик общается напрямую с программистом, то размер проекта по определению мал и смысл "ТЗ за деньги" бывает трудно донести. Тогда тут просто на свой страх и риск и с оглядкой на собственный опыт.
11. Soliton 300 27.04.17 12:05 Сейчас в теме
(8)
Для небольших работ пишется небольшое ТЗ (частное). Просто формат частного ТЗ будет меньше:
1. Цели и задачи;
2. Согласованный набор требований - протокол;
3. Краткая концепция реализации;
4. Порядок приемки работ;

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

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

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

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

Не на ветер, у него останется ТЗ на функционал и понимание сколько это стоит. Порядок цифр перед заказом задачи он все равно должен понимать. Еще есть вариант препроектного обследования после которого можно дать более точную оценку чем до проекта, но с бОльшими допусками по срокам и стоимости, но за меньшую цену чем полноценное обследование. Впрочем, предпроект не отменяет последующее обследование.
Lacrimosa0000; Aphanas; +2 Ответить
28. Aphanas 92 17.05.17 05:49 Сейчас в теме
(9)
Не на ветер, у него останется ТЗ


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

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


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

Мы этим занимаемся много лет. Мы даже авторский надзор осуществляем.
33. A_Max 19 21.10.19 10:04 Сейчас в теме
(28) Точно так же как и у строителей. Есть архитектурные бюро (по модному дизайнеры) и есть мастера. У некоторых есть и то и то, некоторые занимаются только одним.
12. boln 1040 27.04.17 12:48 Сейчас в теме
(4)
Как обосновать заказчику цену?
Это советский подход. Не "обосновывать", а торговаться о цене.
МимохожийОднако; +1 Ответить
5. boln 1040 27.04.17 11:31 Сейчас в теме
Случаются ситуации, когда одна из сторон пытается отказаться от создания ТЗ. Обычно это происходит в двух случаях:
1) Заказчик специально не устанавливает четких требований, чтобы потом бесплатно эксплуатировать разработчика «на скрытых работах» по своему разумению.
2) Разработчик надеется на постоянное продолжение работ за счет заказчика, аргументируя это некой неопределенностью.

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

На любое дополнительное движение мышью, на любую строчку кода, не прописанные в ТЗ - корректировка ТЗ с соответствующей "отдельной платой". Иначе - рабство, хорошо, если относительно мягкое.
Designer1C; +1 Ответить
13. JohnGalt 57 27.04.17 13:59 Сейчас в теме
Если ТЗ нет, расплачиваются и заказчик, и исполнитель.
17. МимохожийОднако 140 03.05.17 07:24 Сейчас в теме
Неплохая статейка для обучения и старта. Первый шажок, так сказать.
18. rus128 2 03.05.17 12:29 Сейчас в теме
Опечатка: "однозначно понимаю(т) обе стороны"
19. Soliton 300 03.05.17 14:50 Сейчас в теме
(18)
Опечатка: "однозначно понимаю(т) обе стороны"


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


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

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

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

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

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


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

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


Тоже готов поучаствовать, если это будет на 1С.
32. Designer1C 445 27.04.19 11:49 Сейчас в теме
(21)Для написания ТЗ хорошо подходят программы типа Mind Manager : в самом начале в голове пишущего хаос.
У программиста, к примеру, недостаток представлений о предлагаемой разработке
У заказчика разработки недостаток представлений о том, как это должно работать в среде 1С:Предприятия.

Mind Manager (а также : Free Mind, X-Mind) позволяют собрать все мысли в кучу. После чего эти программы позволяют структурировать свои представления о предстоящей разработке.
По мере готовности можно указать взаимосвязи между разными блоками разработки / внедрения, указать ответственных за выполнение блока, назначить даты.
В результате будет готово и ТЗ, которое можно выгрузить в DOC-файл
И даже диаграмма Ганта для MS Project
25. Soliton 300 12.05.17 14:23 Сейчас в теме
По поводу базы для написания ТЗ. Смотрел в интернете - есть простенькие программульки.

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

Если кто не против, тогда можно договориться о совместном коммерческом использовании.
30. Soliton 300 17.05.17 13:13 Сейчас в теме
По поводу разработки ТЗ на 1С.

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

Хотелось бы сделать рынок немного шире.
Оставьте свое сообщение