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

«Техническое задание нужно ВАМ, а не НАМ»

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

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

Приведу небольшой пример диалога:

_____

Заказчик: — Нам необходим простой «Монитор производства», в котором мы видели бы текущее состояние производства.

Я: — Что должен содержать монитор?

— Текущие производственные заказы и их состояние.

— Под состоянием вы понимаете признак производственного документа или текущая операция? 

— Ээээ… [думает]… Текущая операция.

— Вы ведёте учёт по полуфабрикатам и по операциям?

— Только полуфабрикаты, но хотим учитывать и операции.

Дальше диалог сводится к длительному обсуждению количественного учёта, отображению рабочих центров, производства брака и пр.  Всего этого Заказчик не предполагал до начала беседы, но полагал, что знает все свои потребности (и я его понимаю). 

_____

На основании приведённого диалога:

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

Чтобы прийти к данному виду потребуется ряд рабочих встреч. 

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

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

Оценка драйверов и саботажников проекта

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

Добавлю лишь слова Доктора Курпатова, что «80% времени топ-менеджеры тратят на интриги».

ТЗ по подсистемам или единое?

Однозначного ответа нет. Совокупность выявленных факторов может подтолкнуть как комплексному, так и лоскутному варианту разработки ТЗ (scrum, agile).

К комплексному ТЗ склоняют факторы:

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

К лоскутному ТЗ склоняют факторы:

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

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

Подробнее на данную тему почитайте в этой статье. 

Подготовка стартовой документации до начала ТЗ

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

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

В финансовом плане вы не пострадаете (если комплексное ТЗ), но вам будет сложнее сдержать слова по прогнозу сроков и бюджета проекта, при отсутствии подписанной бумажки ТТ с начальными «хотелками».    

«Мины на исследовании бизнес-процессов»

Так я назову взрывные и неадекватные реакции сотрудников на которые вы напарываетесь в процессе исследования бизнес-процесса.

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

Согласитесь, уже вызывает напряжение? А представьте реакцию сотрудника, который получает «откаты» от поставщиков. Каждый взрывается в силу своего характера, кто-то будет кричать, что ему некогда, кто-то будет неразговорчив, кто-то врать.

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