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

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

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

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

Я буду рассказывать не про пользовательские сценарии, а про немного более широкое понимание сценариев в том виде, как их описывает Алистер Коберн в своей книге «Современные методы описания функциональных требований».

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

Идея доклада возникла у меня в 2016 году, когда я рассказывал про UML на конференции Инфостарта. Одна коллега обратилась ко мне с вопросом после доклада. Она сообщила, что работает в государственной компании, ей нужно писать техзадание по стандарту ГОСТ 34, и спросила, как ей совместить моделирование и техзадание. Мы с ней немного подискутировали, и по итогам обсуждения я решил агрегировать свой опыт системной работы и с моделями, и с заданиями и представить в виде доклада.

 

 

Сегодня мы:

  • Во-первых, немного поговорим про то, зачем вообще нужно техзадание – отделим продуктовые этапы от процедуры управления проектом.
  • Я расскажу, с чего я начинал. У меня опыт в нашей отрасли – 15 лет, шишек я набил много. Надеюсь, вы мои шишки учтете и повторять их не будете.
  • Поговорим про методические основания разработки техзадания – про то, как подобрать хорошую структуру для техзадания. Какие разделы в него включать, какие не включать.
  • Поговорим про моделирование – совместим структуру ТЗ с моделями и получим успешные подходы к разработке техзадания
  • Я подготовил специально для вас несколько примеров в Enterprise Architect, покажу, как выглядит модель, которую я включаю в техническое задание.
  • И покажу вам сами документы. Я знаю, что большинство слушателей Инфостарта – это специалисты, которые работают “in-house”, поэтому я специально подобрал такие примеры, которые хорошо подойдут для общения с внутренним заказчиком.

 

Зачем нужно ТЗ

 

 

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

Из текущего опыта скажу, что у меня были отличные проекты вообще без техзадания, когда техзадание даже не делалось. И были проекты абсолютно провальные, когда техзадание на 200 листов, расписанное во всех деталях, но все равно заказчик находил лазейки, апеллировал к договору и приходилось многое доделывать и переделывать. Важно понимать, что техническое задание относится к продуктовому этапу, а управление рисками проекта (тем, чтобы минимизировать доделки, доработки) относится к процедуре управления проектами. Так вот, техзадание – это абсолютно не про то, чтобы «прикрыться».

 

 

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

 

Мои «фейлы»

 

 

Для начала посмотрим на пару моих «фейлов».

Когда я только начинал работать, я при написании техзадания не продумывал структуру. Писал его в таком ключе: документ такой-то – столько-то трудозатрат. Добавить такой-то реквизит, движение по такому-то регистру сведений, регистру накопления и т.д.

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

 

 

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

Мне очень понравился Rational Unified Process от IBM. Это очень интересная штука – одновременно и методология, и готовый продукт, где вы настраиваете свой процесс. Но как заказчику объяснить, что мы работаем по такой технологии. Здесь на начальной стадии у нас больше аналитики работают, меньше программисты и т.д.

Заходило очень сложно. К счастью, я тестировал это все на лояльных заказчиках. Но даже с ними было тяжело, потому что все эти модные слова вроде BRD (бизнес-требования) и т.д. заказчики не очень понимают.

 

Методические основания разработки ТЗ

 

 

Давайте посмотрим на то, как сформировать оптимальную структуру технического задания. Есть два госстандарта, которые описывают то, как можно разрабатывать техническое задание – это ГОСТ 19.201 и ГОСТ 34.602. Причем, оба стандарта на разработку техзадания. Разница этих государственных стандартов в том, что:

  • ГОСТ 19.201 – это техническое задание на программный продукт, на программу.
  • ГОСТ 34.602 – это техническое задание на создание и развитие автоматизированной системы.

Давайте немного детальнее разберемся со структурой этих госстандартов.

 

 

Основные разделы госстандарта 19.201 видны слева.

Самый главный раздел – это «Требования к программе или программному изделию». Там указываются:

  • требования к функциональным характеристикам, перечисляются функции программы;
  • в разделе «Требования к надежности» указывается, сколько программа должна устанавливаться без отказов и т.д.

В моей практике только один раз ГОСТ 19.201 подходил к заказу. У меня был интересный заказчик – он попросил сделать систему для расчета того, сколько материалов нужно для производства торта. Это смешно звучит, но, когда я вник в проблему, оказалось, что математически размер торта невозможно посчитать, исходя из его веса, потому что плотность этажей может быть разной. Там была типичная программа-калькулятор: вводишь тип изделия и его вес – получаешь размеры. В моей практике это, пожалуй, единственный случай, когда ГОСТ 19.201 подходил.

Дальше я покажу разницу между ГОСТ 19.201 и ГОСТ 34.602.

 

 

Если посмотреть на ГОСТ 34.602, здесь уже требования не к программе, а к системе.

В разделе «Требования к системе в целом» приводятся:

  • требования к численности и квалификации персонала;
  • требования к структуре и функционированию системы;

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

 

 

На этом слайде я попробовал вывести условную разницу между двумя ГОСТ-стандартами. Слева – стандарт ГОСТ 19.201, а справа – ГОСТ 34.602.

Обратите внимание, красным я выделил отличия, которые у нас есть только в стандарте ГОСТ 34.602. Это:

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

 

 

Давайте все-таки разберемся, что мы делаем – программы или системы? Чем отличается подход к разработке автоматизированной системы от подхода к разработке программного продукта?

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

Но я считаю, что, информационная системы – это очень простая и понятная штука. Когда меня дети спрашивают: «Чем ты, папа, занимаешься?», я отвечаю: «Я делаю три вещи: первое – программу, второе – инструкции по эксплуатации этой программы, и третье – учу людей эксплуатировать программу по этим инструкциям».

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

Поэтому, исходя из определения, используйте ГОСТ 34.602. Рекомендую.

 

 

Я знаю, что очень многие боятся ГОСТ-ов. Думают, что они уже давно устарели.

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

 

Модели и требования

 

 

Теперь немного поговорим про моделирование.

  • Техзадание – это документ, который содержит требования.
  • Требования – это характеристика будущей системы, описание того, как система должна действовать.
  • Модель, в свою очередь – это упрощенное представление некоторого объекта.

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

А зачем вообще заниматься моделированием?

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

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

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

 

 

Вот, опять же, сказка о трех поросятах, только представленная уже в виде классов. У нас есть суперкласс «Животное», от которого свои свойства наследуют «Поросята» и «Волк». Они как-то между собой взаимодействуют, взаимодействуют с классом «Дом».

Согласитесь, все понятно.

 

 

Пару слов о том, что такое моделирование.

  • Когда вы делаете модель, модель делается в какой-то нотации. Нотация – это набор символов и правил использования этих символов.
  • Модель, в свою очередь, это упрощенное представление реального объекта, построенного на базе этого набора символов и правил их использования.
  • А диаграмма – это уже конкретный рисунок, схема из геометрических фигур.

Если представлять совсем упрощенно, вы помните уроки труда в школе, когда вы какую-то деталь раскладываете на три проекции. Моделирование на наших проектах – это то же самое. Вы предприятие раскладываете по некоторым осям координат.

 

 

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

Бизнес-процесс – это последовательность действий. Последовательность действий, в свою очередь, является сценарием. У нее есть некоторые входные данные для этого сценария, порядок обработки этого сценария и какой-то результат. Поэтому для моделирования бизнес-процессов, на мой взгляд, очень подходит модель Use-Case языка UML.

 

 

Дальше – каждый сценарий мы детализируем на последовательность действий. Я применяю такую нотацию, как на экране:

  • слева у нас объекты метаданных;
  • посередине – деятельность;
  • отмечаем исполнителя;
  • и те правила, по которым он работает.

Эти дорожки я могу менять от проекта к проекту. Где-то я добавляю в правую колонку правила или регламенты, где-то – требования к системе: так очень удобно делать трассировку требований.

 

 

Вот реальный кейс, который мы делали для одного заказчика.

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

 

 

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

Я использую два уровня сценариев.

  • Первый уровень сценария – это верхнеуровневые сценарии. Бизнес-процессы компании.
  • И второй уровень – это поведение форм или обработок в рамках бизнес-процессов. Т.е сценарии взаимодействия пользователей с системой.

Когда я делаю техзадание:

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

Коллеги, сразу хочу вас предупредить – когда будете знакомиться с UML, в российском интернете очень много трактовок, очень много холиваров. Не обращайте на это внимания ни в коем случае. На одном из сайтов люди написали FAQ, что UseCase-диаграммы не предназначены для моделирования функций. Я в свое время очень много времени потратил, пытаясь разобраться в этой информации, отделить зерна от плевел.

Эта ситуация связана с тем, что очень много разных переводов. Когда я знакомился с UML, я читал много книг. В разных книгах переводы могут немного отличаться. Из-за этого появляются эти разночтения. Поэтому если нужно вам использовать диаграмму вариантов использования для моделирования функций – используйте. Ничему это не противоречит. Функция – это некая последовательность действий, которую выполняет система, поэтому не обращайте внимание на эти холивары, используйте UseCase-диаграммы, как вам нужно. Еще раз подчеркну, UML – это язык, по которому вы можете строить свою нотацию. В этой нотации вы уже описываете модель.

 

Успешные подходы к разработке ТЗ

 

 

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

При разработке 4-го раздела техзадания по ГОСТ 34.602 «Требования к системе в целом» мы разворачиваем требования в сценарии верхнего уровня – в бизнес-процессы, приводим диаграмму всех автоматизируемых бизнес-процессов.

 

 

А далее, в разделе «Требования в функциям (задачам)» мы уже приводим конкретный бизнес-процесс и каждый бизнес-процесс детализируем до объектов метаданных (как на правой картинке).

 

 

Идеальная структура техзадания с моей точки зрения выглядит таким образом:

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

В такой структуре – даже если заказчик совершенно не знаком с 1С, и ему непонятно, что такое объекты метаданных, первые два уровня он точно поймет. Описание шагов бизнес-процесса ему будет понятно. А вот уже дальше, когда ему понятна большая часть – ему понятно практически 80% техзадания, даже если он не знает, что такое 1С, что такое объекты метаданных. И уже он охотнее пойдет к вам навстречу, охотнее будет выяснять, что же вы имели в виду в других пунктах, так как большую часть он понимает.

 

 

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

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

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

 

Демонстрация реальных кейсов ТЗ

Давайте посмотрим несколько реальных кейсов. Как раз тот самый пример, который я показывал в рамках демонстрации.

 

 

Обратите внимание на структуру техзадания.

  • У нас есть требования к автоматизированной системе (или требования к функциональности).
  • Дальше идет процесс. Он содержит описание функций. И под описанием функций пошли уже требования к объектам метаданных.

 

 

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

 

 

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

 

 

Дальше – общая структура автоматизируемых бизнес-процессов.

 

 

Один самый сложный бизнес-процесс расшифрован до объектов метаданных.

 

 

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

 

 

И дальше идет описание разрабатываемых объектов – как они будут выглядеть и как будут использоваться.

Давайте посмотрим, какие приемы я использовал в Enterprise Architect для разработки состава сценариев, которые я потом включил в техническое задание.

Во-первых, я сюда из Excel экспортировал требования, которые заказчик писал в тех или иных протоколах.

 

 

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

Потом отдельно проработал функциональную структуру.

 

 

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

 

 

И самый сложный бизнес-процесс детализировал до первого уровня.

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

 

Резюме

 

 

Подведу резюме.

  • На мой взгляд, за основу техзадания всегда лучше всего брать ГОСТ.
  • Техзадание нужно сделать заказчику понятным. Как я показывал, на примере группировки, чтобы как минимум 80% техзадания заказчик понимал, а остальное уже можно уточнить в рамках переговорного процесса.
  • Мне очень нравится UML. По моему опыту, это отличная нотация, но я не отвергаю BPMN – он тоже хорошо заходит пользователям, особенно, если какая-то большая система, всегда можно взять верхний уровень сделать в IDEF0, и декомпозировать его в BPMN. Это тоже интересная модель, экспериментируйте, выбирайте лучшие для вас нотации.
  • Формально, техзадание – это документ с требованиями. Но если в него включать модель, как я делал, это очень упрощает нахождение взаимопонимания с заказчиком, и, в принципе, это не противоречит ГОСТ-стандарту. Вы просто иллюстрируете требования, поэтому вас никто не будет упрекать в том, что у вас техзадание по ГОСТ-стандарту. По крайней мере, у меня за 15 лет практики такого ни разу в жизни не было, хотя я работал с государственными компаниями. Включение модели в техзадание идет проекту только на пользу – позволяет находить взаимопонимание с заказчиками. И, как я уже говорил, прямо в ГОСТ-стандарте написано, что он позволяет менять трактовку – можно удалять, добавлять разделы. Также рекомендую не обращать внимание на какие-то формальные правила применения UML, как их трактуют на разных ресурсах.
  • Делайте так, чтобы было понятно заказчику, находите взаимопонимание с заказчиком. Главное – результат!

Я вам всем желаю успешных проектов! Спасибо за внимание!

 

Вопросы:

 

  • Как применим такой подход формирования ТЗ и сбора требований для гибкого процесса ведения проектов по Agile?
  • Если вы будете работать по так называемому Agile, совершенно не понимая, куда вы идете, то вы никуда не придете. Я не зря включил в доклад модель RUP (Rational Unified Process), потому что в рамках гибких практик очень удобно сделать общее техзадание, чтобы ограничить тот скоуп, куда мы идем. Дальше в рамках каждого спринта делаете частное техзадание, где описываете то, что вы будете делать. Причем в рамках RUP у нас процесс «Бизнес-моделирование» и «Управление требованиями» идет сквозь все этапы – даже находясь на N-нной итерации, вы планируете уточнение требований и архитектуры. Мне эта картинка очень нравится, потому что она реально отображает то, как идут проекты в жизни – не важно, вы работаете по «водопаду» или по Agile, все равно, какие-нибудь уточнения всегда будут. В целом, я считаю, что тот подход, который я презентовал вполне применим и для Agile.
  • Вы говорили, что в процессе детализации требований и определения объектов метаданных переходите на контекст системы объектов метаданных. И разговариваете с заказчиком не в терминах бизнеса «Заказ», а в терминах «Заявка новая 4» и т.д. Не является ли это проблемой в будущем для проектов, которые направлены не на создание новой системы с нуля, а на модификацию существующего решения?
  • Особенно, когда проекты на модификацию существующего решения, я всегда углубляюсь до объектов метаданных, потому что тогда люди понимают, что «Заказ покупателя» – это форма, в которую нужно добавить поля или изменить ее поведение. Заказчику это понятно. По моему опыту, проблема с непониманием на уровне объектов метаданных может возникнуть только тогда, когда мы внедряем систему там, где 1С еще не было, потому что тогда им менее понятно, что это такое. Но, так как техзадание сгруппировано так, что 80% они понимают, договориться про оставшиеся 20% уже не проблема. Опять же, как я рассказывал, я пытался уйти от техзадания и объектов метаданных, пытался делать бизнес-требования и т.д. У меня это был неудачный опыт. Возникало непонимание того, как система будет выглядеть. Поэтому все-таки я вернулся к тому, чтобы включать объекты метаданных в техзадание.

 

  • При описании новой функциональности вы всегда делаете эскизы экранных форм?
  • Покажу на готовом примере. У меня однажды заказчик попросил описать весь объем проекта – что будет использоваться. Мы описали в таком формате: существующий справочник, назначение, доработка – есть/нет. Если нет доработки – картинку не вставляем. Если доработка есть – она описывается.

 

 

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

  • Как убедить заказчика оплачивать создание ТЗ?
  • Не работайте с теми, кто не оплачивает создание ТЗ. Я тоже раньше думал, что ТЗ нужно только для того, чтобы прикрыться, и моя работа состоит только в том, чтобы дорабатывать или создавать какие-то объекты метаданных. Нет, мы создаем систему, которая состоит из программы, инструкции и обученного персонала по работе с этой системой. Это очень важно понимать. И если вам заказчик не готов оплачивать этапы по сбору требований, проектированию системы, по вводу ее в эксплуатацию - не работайте с этим заказчиком, потому что денег вы там точно не заработаете, получите только проблемы.
  • ТЗ нужно создавать даже для маленьких задач?
  • Я думаю, что да. Но каждое предприятие само для себя выбирает, где находится граница между обычной заявкой на техподдержку и проектной работой.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Saint Petersburg.Online. Больше статей можно прочитать здесь.

Приглашаем всех принять участие в тематических митапах Инфостарта и INFOSTART EVENT 2021 (6-8 мая, СПб).

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. kite2 43 05.03.21 14:04 Сейчас в теме
Техническое задание можно использовать для того, чтобы прикрыться. А можно и для того, чтобы оценить объем работ. Это все в случае сдельной оплаты. Если сидите на окладе, то речи о том, чтобы прикрыться уже не идет. Тут оно нужно чтобы заказчик исполнитель понимали друг друга и по 10 раз не переспрашивали.

У меня были разные случаи:

1) Заказчик не хотел платить, на что ему было сказано, что все сделано по ТЗ. Не нравится - пишите ТЗ сами или не подписывайте мое.
2) ТЗ было написано, чтобы оценить объем работ. Кстати действительно очень помогает, если работа сдельная и ты понимаешь то, что делаешь, а не делаешь это в 1-й раз.
3) Работа по ТЗ на окладе. Тут все просто. Чтобы никто не отвлекался, люди тратят время и пишут ТЗ 1 раз. Потом я не задаю по 10 раз одни и те же вопросы в разных вариациях. Взял ТЗ. Изучил. Потом только спросил то, что непонятно.
2. rpgshnik 2522 06.03.21 04:17 Сейчас в теме
В автоматизации Бизнеса ТЗ уже моветон при взаимодействие с Заказчиком. Возможно оно ещё имеет смысл при взаимодействие в своей кухне автоматизации при постановке задачи от Архитектора/Аналитика в виде ТЗ Разработчику.

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

Философия Аджайл рулит, методология Скрам спасёт автоматизацию, а ТЗ это только прикрыть свою попу и сказать "а воооот об этом мы не договаривались".

Так, что актуально только ФТ.
perepetulichka; Terve!R; +2 1 Ответить
3. user1077162 1 13.03.21 10:00 Сейчас в теме
Спасибо за статью! ТЗ необходимо на крупных проектах с большим количеством участников, так как повышается, например, организационная сложность. Много времени может быть потрачено на коммуникации с руководством и сотрудниками внутри отделов и между отделами.

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

См. также

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

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

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

23.02.2017    28078    Gavrik    10    

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

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

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

16.10.2020    6286    stas_ganiev    36    

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

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

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

28.05.2020    9648    sapervodichka    75    

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

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

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

29.10.2019    6288    BraunAlex    1    

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

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

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

11.08.2016    35415    SamBadi    55    

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

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

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

26.07.2019    6937    slozhenikin_com    14    

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

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

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

16.10.2018    10042    weissfeuer    2    

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

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

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

14.08.2018    7740    itriot11    42    

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

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

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

29.06.2005    37070    support    11    

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

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

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

30.03.2018    10553    Aprsoft    1    

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

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

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

14.12.2017    30208    Vikki-di    21    

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

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

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

23.10.2017    10674    user743750    1    

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

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

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

08.11.2012    44216    adhocprog    63    

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

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

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

26.04.2017    25301    Soliton    33    

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

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

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

02.03.2017    19197    aaw    3    

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

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

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

17.01.2017    18007    Gavrik    4    

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

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

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

26.01.2012    81260        54    

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

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

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

06.12.2016    19508    Gavrik    19    

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

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

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

26.09.2016    14676    R.Tsarenko    27    

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

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

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

02.09.2016    30453    de0nis    18    

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

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

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

30.03.2016    21508    liurn    26    

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

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

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

23.12.2015    24509    Gavrik    5    

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

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

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

23.03.2015    21130    UR1    5    

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

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

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

25.09.2013    25762    randa    45    

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

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

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

24.09.2013    34997    Neti    21    

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

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

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

14.12.2012    67727    SergAn    10    

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

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

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

11.04.2012    37344    chavalah    34    

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

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

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

03.04.2012    78511    chavalah    56    

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

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

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

06.01.2010    15896    nnn123    1    

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

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

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

08.06.2009    33580    Оболтус    20    

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

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

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

08.06.2009    37599    GSoft    82    

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

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

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

06.02.2008    29360    O-Planet    74    

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

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

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

05.04.2007    23491    support    5    

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

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

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

29.06.2005    25978    support    6    

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

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

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

29.06.2005    34842    support    4