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

Публикация № 615888

Методология - Проектирование - Техническое задание

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

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 23 26.04.17 17:08 Сейчас в теме
Вот интересно почитать статью более полного разбора стандартов ТЗ IEEE Std 830 и ГОСТа34 на практике.
2. Aphanas 145 27.04.17 07:51 Сейчас в теме
Кто должен заплатить за ТЗ?
3. spezc 696 27.04.17 09:36 Сейчас в теме
4. Aphanas 145 27.04.17 11:00 Сейчас в теме
(3) Как обосновать заказчику цену?

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

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

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

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

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

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


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

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

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

Если заказчик общается напрямую с программистом, то размер проекта по определению мал и смысл "ТЗ за деньги" бывает трудно донести. Тогда тут просто на свой страх и риск и с оглядкой на собственный опыт.
11. Soliton 233 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 145 17.05.17 05:49 Сейчас в теме
(9)
Не на ветер, у него останется ТЗ


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

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


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

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

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

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


Спасибо. Поправил.
21. dddxddd 12.05.17 12:29 Сейчас в теме
Просто мысль по теме.
Даже на инфостарте много статей про ТЗ и его необходимость, но никто ни разу не выложил простенькую конфигурацию для написания пусть простенького, но стандартизованного ТЗ.
22. Aphanas 145 12.05.17 12:43 Сейчас в теме
(21), нельзя автоматизировать хаос
sergathome; +1 Ответить
23. dddxddd 12.05.17 13:39 Сейчас в теме
(22)Вообще-то речь о написании ТЗ, а не об автоматизации хаоса у заказчика.
Если вопрос писать или не писать ТЗ оставляем за скобками, то сам процесс написания это шаблон (кейс - по модному) определенных действий. А результат написания, т.е. сам текст ТЗ, это заполненный шаблон документа, а если уж совсем по "взрослому", то содержание этого документа, определяется ГОСТ-ом.
Именно эти факты я и имел ввиду говоря о простенькой конфигурации в которой бы был реализован один или несколько кейсов подготовки и оформления ТЗ. А еще тут на инфостарте есть много конфигураций для планирования и контроля исполнения задач, но в большинстве своем все эти "задачники" с безголовыми задачами, т.е. не привязанные к конкретному ТЗ.
Поэтому Ваше утверждение "нельзя автоматизировать хаос" в разрезе моего поста, надо переформулировать "все не хотят или не могут устранить хаос в вопросе написания простых ТЗ для 1С-ных поделок"
Вот так как-то.
24. Soliton 233 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 53 16.05.17 08:28 Сейчас в теме
(24)
Кстати, есть идея это дело довести до ума. Когда-то остановился на том, что нужно писать её не на 1С.


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

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

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

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

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

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

См. также

Про спагетти, или как исследовать бизнес-процессы организации Промо

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

23.02.2017    28089    Gavrik    10    

Пишем ТЗ через сценарии

Техническое задание Бесплатно (free)

От того, насколько одинаково понимают ТЗ заказчик и исполнитель, зависит успех проекта. Включение моделей на UML и BPMN в состав ТЗ помогает упростить взаимопонимание с заказчиком и обеспечить минимум доработок за счет полного покрытия всех процессов функциональностью системы. О том, как грамотно составить ТЗ и увязать требования заказчика с детализированными моделями, на митапе Saint Petersburg.Online рассказал Сергей Наумов.

05.03.2021    1419    SergeyN    4    

Чего хочет разработчик от ТЗ? Примеры из практики

Техническое задание Бесплатно (free)

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

16.10.2020    6313    stas_ganiev    36    

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

Техническое задание Бесплатно (free)

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

28.05.2020    9675    sapervodichka    75    

Как оценивать задачи программисту 1С Промо

Техническое задание Россия Бесплатно (free)

Оценивать задачу всегда сложно. У меня не всегда получается оценивать задачи адекватно (во всяком случае, не всегда моё ощущение адекватности совпадает с ощущениями других участников процесса). Именно по причине того, что вопрос для меня актуальный, хочу поделиться своими размышлениями, субъективным опытом в этом вопросе. Речь пойдет только о технической оценке.

11.08.2016    35440    SamBadi    55    

Модернизация КА 2.4 под маркетинговую компанию. Часть 1

Управление взаимоотношениями с клиентами (СRM) Техническое задание v8 КА2 Россия УУ Бесплатно (free)

Выполнил для компании, которая занимается маркетингом и продвижением продуктов, проектирование и модификацию конфигурации КА 2.4 и справочника «Проекты». Теперь в конфигурации «Проекты» имеют особенную роль и на основании выполненной доработки руководство компании принимает решения по продолжению, закрытию или продвижению проекта/ов, поиск путей решения возникающих вопросов. При необходимости доработку можно реализовать под ERP конфигурацию. Архитектура решения выполнена «рядом» с основной конфигурацией. В настоящее время конфигурация поддерживается, модификация ведется в актуальной версии КА 2.4.10 на платформе 8.3.14.1630.

29.10.2019    6299    BraunAlex    1    

Impact mapping: чем он может быть вам полезен

Техническое задание Бесплатно (free)

Привет, коллеги! Сегодня хочу поговорить про один из инструментов Владельца продукта - Impact mapping (карта влияния). Чем он хорош и почему его стоит использовать.

26.07.2019    6950    slozhenikin_com    14    

Как проектировать отчетность

Техническое задание Управление проектом Управленческие v8 УУ Бесплатно (free)

Эта статья написана по итогам мастер-класса для руководителей проектов и аналитиков, в рамках перехода на продуктовый подход к разработке. В ней мы постарались ответить на вопрос: "Как снизить риск потери доверия к данным информационной системы со стороны топ-менеджмента, грамотно выстроив процесс проектирования и разработки отчетности?"

16.10.2018    10052    weissfeuer    2    

ГОСТ 34.602-89. ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ Промо

Техническое задание Россия Бесплатно (free)

Настоящий стандарт распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы» (далее - ТЗ на АС). Дата введения с 01.01.1990г

29.06.2005    37077    support    11    

На чьей стороне мячик? Алгоритм определения исполнителя задачи

Техническое задание Управление бизнес-процессами (BPM) Бесплатно (free)

Я считаю, что мало кому удалось избежать ситуации, когда его назначали исполнителем работы, мягко скажем, не его уровня. На мой взгляд, такое особенно часто встречается среди технических специалистов. Причем, в случае возражения, обычным аргументом противоположной стороны является: "Нам так раньше всегда делали!". Эта публикация является попыткой описать формализовано процесс определения исполнителя с точки зрения логики. Посвящается тем, кто, будучи невежественным в вопросе, смеет указывать, кому его решать. А также тем, кто это терпит.

14.08.2018    7743    itriot11    42    

Первый шаг к успешному проекту автоматизации

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Россия Бесплатно (free)

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

30.03.2018    10557    Aprsoft    1    

Должностная инструкция специалиста по 1С

Техническое задание Бесплатно (free)

Описание функциональных обязанностей для трёх категорий специалистов 1С: Администратор платформы, Программист, Администратор конфигурации (Методист).

14.12.2017    30256    Vikki-di    21    

Направления работы программиста 1С Промо

Техническое задание Бесплатно (free)

Направления работы программиста 1С, как продолжение темы функциональных обязанностей.

08.11.2012    44222    adhocprog    63    

Внедрение МСФО: план-график выполнения проекта по автоматизации МСФО

Техническое задание Управление проектом МСФО (GAAP) МСФО (GAAP) БУ Бесплатно (free)

В данной статье будут детально рассмотрены задачи, которые предстоит выполнить в процессе запуска проекта автоматизированной подготовки отчетности МСФО

23.10.2017    10680    user743750    1    

Концепция автоматизации многопрофильного Холдинга в системе АУБ на платформе 1С

Техническое задание Управление проектом Финансовый учет и бюджетирование (FRP) Управление холдингом (CPM) Учетная политика Бухгалтерский учет Управленческий учет (прочее) Финансовый учет и бюджетирование (FRP) Управление холдингом (CPM) Учетная политика v8 Россия УУ Бесплатно (free)

Это схема и обоснование концепции системы АУБ (Автоматизация Управления Бизнесом, авторская разработка) для автоматизации многопрофильного холдинга на платформе 1С. Система изначально проектировалась для многопрофильного холдинга, что определило особенность ее концепции - три уровня автоматизации. Система АУБ не является готовым решением, это определенная концепция (видение, подход) к автоматизации управленческого учета и расширяемый базис наработок реализованных в этой концепции. В конкретном проекте автоматизации, с учетом специфики управления предприятием, делается индивидуальная «функциональная сборка» с использованием готовых, существенно модифицируемых и заново разрабатываемых подсистем. Таким образом, концепция и расширяемый базис наработок системы АУБ, представляют своего рода конструктор, из которого компонуется решение в конкретном проекте, при этом заново разрабатывается лишь функционал, отражающий новую специфику. На практике концепция использовалась, например, в отраслевом решении для производства ЖБИ и добычи нерудных материалов.

02.03.2017    19206    aaw    3    

Проектное внедрение прав доступа в системах 1С

Техническое задание Управление бизнес-процессами (BPM) Управление проектом v8::Права 1cv8.cf Бесплатно (free)

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

17.01.2017    18010    Gavrik    4    

Есть 2 подхода к внедрению информационных систем. На примере 1С УПП 8 Промо

Управление проектом Техническое задание v8 УПП1 Россия Бесплатно (free)

С детальным ТЗ? Или без серьезного ТЗ? Какой лучше? И где успех более вероятен?

26.01.2012    81284        54    

Наблюдения, которые указывают на решимость предприятия к изменениям

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

Раздается звонок. - Здравствуйте, это Сергей? Меня зовут (не вникайте в название, но это плоды секундной фантазии), я директор по производству на . У меня есть ряд проблем с производственным планированием. Могли бы мы с вами встретиться? На встрече присутствовал CH3NO2, генеральный директор и, случайно заглянувший, собственник бизнеса. Мне предоставили список технических требований к производственному планированию, наличие которого положительно сказывается как на предметный разговор. В ходе беседы познакомились, поделились коммерческой и организационной информацией, очертили первые шаги.

06.12.2016    19514    Gavrik    19    

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

Техническое задание Управление проектом Бесплатно (free)

Хочу рассказать об очень интересном проекте, с которым мы недавно столкнулись. В этом проекте необходимо было сделать огромный объем работы за очень короткий промежуток времени, поэтому мы его условно назвали «Марафон со спринтерской скоростью».

26.09.2016    14676    R.Tsarenko    27    

Дропшиппинг или "виртуальные" склады поставщиков в 1С

Техническое задание Оптовая торговля Розничная торговля Учет ТМЦ Оптовая торговля Розничная торговля Учет ТМЦ v8 УТ10 УУ Бесплатно (free)

Сейчас всё больше компаний работают по системе дропшиппинг (прямые поставки, когда поставщик отправляет товар непосредственно клиенту, а не продавцу) или продают товар со склада поставщика не закупая его себе на склад (под конкретные заказы покупателей). При этом зачастую есть необходимость хранения остатков и цен поставщика, выгрузки их на сайты и другие информационные ресурсы, рассылки в своих прайс листах. В статье рассматриваются варианты отражения подобных операций в управленческих конфигурациях 1С без привязки к конкретной конфигурации. С некоторыми различиями данные схемы можно применить в Управлении торговлей 10 и 11, Рарус:Альфа-авто, Комплексной автоматизации, УПП и др. т.е. в целом в любой конфигурации с возможностью ведения управленческого учета и механизма заказов.

02.09.2016    30484    de0nis    19    

Как заставить разработки работать

Техническое задание Управление проектом 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

В процессе внедрения и сопровождения автоматизированных учетных систем приходится сталкиваться с рядом проблем, среди которых: • Пуск системы в эксплуатацию проходит очень болезненно для пользователей, его приходится прерывать и откладывать на более поздние сроки по ряду причин (функционал системы недостаточно развит, некоторые функции не работают или работают неправильно, некоторыми функциями пользоваться очень сложно, и пользователи постоянно путаются и делают все неправильно, система абсолютно непонятна пользователям, и они не знают, что делать в той или иной ситуации); • Уход ведущего разработчика может парализовать внедрение и сопровождение системы; • Процесс внедрения напоминает метания из угла в угол в темной комнате в поисках выхода; • При обновлении сопровождаемых систем происходят поломки некоторых функций, в результате чего работу пользователей приходиться приостанавливать и в срочном порядке исправлять ошибки; • Уход пользователя, который был единственным, кто работал в системе на определенном рабочем месте, парализует работу системы; Собственный и заимствованный опыт позволили выработать подходы к решению некоторых из них. Ими я и хотел бы поделиться в этой статье. Если вы никогда не занимались внедрением автоматизированных учетных систем, не сталкивались с перечисленными проблемами и не пытались найти их решение, вам эта статья будет неинтересна, а может, и непонятна.

30.03.2016    21510    liurn    26    

Предприятие требует проект автоматизации? Начните правильно!

Техническое задание Управление проектом 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

На нулевом этапе мы не имеем никакого представления о порядке работ, бюджете и сроках достижения статуса «Работает как надо!». Единственное, чем мы можем обладать, — пониманием, что бизнес-процесс работает неэффективно. К сожалению, часто руководители этого не видят или не хотят видеть. Работу необходимо начинать с составления Технических требований проекта 1С автоматизации (оптимизации или бережливого производства).

23.12.2015    24524    Gavrik    5    

Большой проект: документация

Техническое задание Управление проектом Бесплатно (free)

Оставим за рамками нашей темы поиск потенциального клиента. Мы его нашли. Вот он - Большой клиент. Чего мы хотим? Хотим заработать. И чтобы этот Большой клиент был у нас не один. А к нам большинство таких клиентов пришли по рекомендации, а для рекомендаций положительных нужно, чтобы Большой клиент был очень доволен сотрудничеством с нами. Но и мы хотели бы быть довольны работой с ним. Вот о том, какими документами мы этого добиваемся, я и попытаюсь рассказать. *** Статья написана на основе доклада, прочитанного на Конференции IE 2013 Revolution (7-8 ноября 2013 года). Также она опубликована в журнале Инфостарта № 3

23.03.2015    21130    UR1    5    

Автоматизация работы фрилансера

Техническое задание Управление взаимоотношениями с клиентами (СRM) Управление проектом Управление взаимоотношениями с клиентами (СRM) УУ Бесплатно (free)

Появилось желание рассказать о социальном интранете - Битрикс24. Я опишу опыт внедрения и использования данного продукта от лица фрилансера 1С.

25.09.2013    25767    randa    45    

Алгоритм работы с техническим заданием заказчика

Техническое задание Бесплатно (free)

Эта статья основана на личном опыте разработчиков компании Neti и расскажет Вам о том, как анализировать и оценивать технические задания, а также как предоставлять результаты разработки заказчику.

24.09.2013    35014    Neti    21    

Пример ТЗ и ТП на небольшую доработку

Техническое задание v8 БП2.0 Россия Бесплатно (free)

Привожу пример технического задания и технического проекта на небольшую доработку к БП. Документы делались исходя из схемы: Обследование- ТЗ - ТП - Разработка.

14.12.2012    67801    SergAn    10    

Как разработать Техническое задание. Часть 2. Виды работ при сборе требований к системе учета и информации для описания бизнес-процессов.

Техническое задание Россия Бесплатно (free)

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

11.04.2012    37357    chavalah    34    

Разработка технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?

Техническое задание Россия Бесплатно (free)

В данной статье я попытался подробно рассмотреть проблему разработки Технических заданий. Тема стара, как и проблема. Но она до сих пор часто решается "как получится". Как сказал Генри Шоу "Мелочи тревожат нас больше всего: легче увернуться от слона, чем от мухи".

03.04.2012    78579    chavalah    56    

РД 50-34.698-90 - АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ

Техническое задание Россия Бесплатно (free)

Методические указания распространяются на автоматизированные системы (АС), используемые в различных сферах деятельности (управление, исследование, проектирование и т. п.), включая их сочетание, и устанавливают требования к содержанию ВСЕХ документов, разрабатываемых при создании АС.

06.01.2010    15897    nnn123    1    

ГОСТ 34.602-89 (Техническое задание на создание автоматизированной системы)

Техническое задание Управление проектом Производство готовой продукции (работ, услуг) Производство готовой продукции (работ, услуг) 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

"Листая старые страницы" времен универа нашел несколько, которыми можно поделиться, не рискуя получить по бошке. :) В общем-то, ничего нового, но думаю, многим может пригодиться.

08.06.2009    33722    Оболтус    20    

7 Граблей или история одного IT-директора

Техническое задание Россия Бесплатно (free)

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

08.06.2009    37608    GSoft    82    

Переход с 1С:Предприятие 7.7 на 8.0. Всегда ли это нужно?

Перенос данных из 1С7.7 в 1C8.X Техническое задание О жизни Россия Бесплатно (free)

Уже несколько лет ведется усиленная рекламная компания по распространению «восьмерки» на российском рынке. Хотелось бы рассмотреть, насколько такой переход бывает необходим, и что ожидает фирму, решившуюся на этот шаг.

06.02.2008    29369    O-Planet    74    

Жизнь без технического задания

Техническое задание Россия Бесплатно (free)

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

05.04.2007    23493    support    5    

ГОСТ 24.201-79. ТРЕБОВАНИЕ К СОДЕРЖАНИЮ ДОКУМЕНТА «ТЕХНИЧЕСКОЕ ЗАДАНИЕ»

Техническое задание Россия Бесплатно (free)

Постановлением Государственного комитета СССР по стандартам от 31 января 1979 г. № 383 срок введения установлен с 01.07 1980 г. Настоящий стандарт распространяется на техническую документацию на автоматизированные системы управления (АСУ) всех видов, разрабатываемые для всех уровней управления народным хозяйством (кроме общегосударственного), и устанавливает общие требования к содержанию документа «Техническое задание» (ТЗ) на создание АСУ, кроме АСУ технологическими процессами. В зависимости от вида и назначения АСУ требования, устанавливаемые в настоящем стандарте, допускается конкретизировать в нормативно-технической документации.

29.06.2005    25988    support    6    

ГОСТ 19.201-78. ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ.

Техническое задание Россия Бесплатно (free)

Настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения. Стандарт полностью соответствует СТ СЭВ 1627-79.

29.06.2005    34856    support    4