Техническое задание на автоматизацию: каким оно должно быть, состав и технологии создания
Одна из самых больших проблем в любом, особенно, большом деле — это начать. Всегда на старте возникает масса вопросов. С чего начать? Как начать таким образом, чтобы получить тот результат, который нужен? И здесь на помощь приходит философия.
Почему так важно правильно начинать? Только одно начало ведет только к одному концу.
Это важно понимать. Например, если мы вместо бани построили сарай, скорей всего, мы с самого начала строили именно сарай. В будущем мы, конечно, можем переделать сарай в баню или баню в сарай. Но это уже другая история. А здесь смысл в том, что от того, как мы начнем, будет зависеть то, как мы закончим. Как бы это ни казалось тривиально, но многие люди просто не задумываются о подобных вещах.
Согласно диалектике результат, например, внедренная IT-система (важно, не просто реализованная, но внедренная!), это — развернутое начало.
Как видите, и философия, и жизнь подсказывают одно: начало и результат всегда связаны. И если мы говорим о результате, мы также говорим о начале. При этом начало нам очень и очень важно.
Все начинается с идеи
В начале было слово…
В начале создания любого программного обеспечения нужно слово. Это бриф. Иначе говоря — идея. Когда мы хотим создать любое программное обеспечение, сначала нужно сформировать идею.
Эта идея может быть описанием процесса, какой-то задачей, описанной в сжатом виде. Такое описание должно быть коротки, занимать не более 1–2 абзацев (1 т символов) и четко выражать суть того, что мы хотим получить в результате.
Для примера, идеей может быть: «Разработать IT-систему для контроля взаиморасчетов» или «Разработать IT-систему для автоматизации продаж». Также это может быть описание процесса, например, в таком виде:
«При необходимости в товаре которого нет в наличии продавец создает документ заявка на закупку и направляет его на согласование закупщику. Закупщик проверяет необходимость в закупке данного товара и если закупщик разрешает закупить товар согласно заявке на закупку, то продавец информируется о разрешении закупить товар, и закупщик создает заказ поставщику. Иначе заявка аннулируется с комментарием содержащем причину отказа в закупке. Продавец информируется об отказе в закупке».
Таким образом, в самом начале нам нужно сжато и четко сформулировать идею. Именно от нее мы будем отталкиваться в дальнейшем и на нее ориентироваться, чтобы получить нужный результат.
Как формулировать идею
Идея — это не так просто, как может показаться. Здесь очень важно четко сформулировать, что именно вы хотите получить. Я предлагаю для этого как можно подробнее узнать у ведущего специалиста или ответственного лица, что именно ему необходимо. После чего нужно сформулировать идею не только сжато, но обязательно в такой форме, которая будет понятна этому человеку. После этого сформулированная идея обязательно согласовывается.
Очень важно в процессе формулировки идеи не уйти в сторону и не углубляться в ненужные на этом этапе подробности. Часто уже на этом этапе люди пытаются расписывать подробные брифы. В итоге, основное внимание уделяется подробностям и нюансам. На самом деле, это не правильно.
Пример (отсюда)
Главное — это идея, т.е. четкое понимание целей, которые вы хотите достичь в результате реализации проекта. Она может быть описана текстом, может быть сразу в виде графического процесса. Самое главное — четкое и однозначное понимание результата. Подробности оставьте для последующих этапов.
А что если мы хотели совсем не то, что в итоге получилось?
Этот вопрос-возражение нередко задают заказчики. Обычно он звучит так:
«Мы хотели CRM-систему, а написали, что нужна ERP» или «Нам нужна была CMS для сайта, а мы написали CRM».
Ошибки в терминологии — распространенная проблема. А в сфере IT терминология сложна и очень важна. Потому лично я посвящаю правильной терминологии множество публикаций.
Чтобы избежать проблем и недопонимания, лучше всего изучить терминологию заранее. Не поленитесь лишний раз убедиться, что вы в идее правильно называете конечный продукт.
Ну, а если в процессе согласований не возникло каких-то сложностей, и вы получили результат, который помогает решать поставленные задачи, скорей всего, вы просто ошибочно использовали термины. И когда говорили «CRM» на самом деле имели в виду ERP или наоборот.
Еще раз: уделяйте максимум внимания терминам. Уточняйте их значение в статьях на моем сайте, при общении со специалистами, в справочниках. Это поможет точнее сформулировать цель, избежать разногласий и составить корректное техническое задание.
Графическое описание процесса
После того, как заказчик сформулировал идею, нам нужно провести более подробное интервью, разобраться в важных нюансах, после чего создается графическое описание процесса.
О том как описать процесс вы можете почитать здесь
Почему так важен процесс? Подробно об этом вы можете почитать в моей статье »Бизнес-моделирование», где описаны основные подходы. Также вас может заинтересовать статья »Про процессный подход», где вы также можете подробно прочитать о том, почему важны процессы и как с ними работать.
В двух словах, нам необходимо разложить поставленную задачу на какой-то определенный процесс или процессы. Лично я рекомендую для этого использовать формат BPMN. На данный момент — это стандарт, который наиболее проработан с точки зрения автоматизации бизнеса.
Подробнее о BPMN вы также можете почитать в моих публикациях.
Сравнение нотаций IDEF3, IDEF0, BPMN и DFD
Как описать бизнес-процесс в формате нотации BPMN и других.
Независимо от выбора инструмента, диаграмма должна отвечать на вопрос «Как мы хотим получить тот или иной результат».
Например, если мы говорим о продажах, по ней должно быть понятно, что является началом, допустим, заявка клиента, и концом процесса. Это может быть отгрузка, заключение контракта и пр.
Еще один пример — Запись клиента на услуги. Здесь также нужно описать последовательность действий, начиная с момента обращения клиента до момента непосредственно записи на услугу.
Текстовое описание
Теперь, когда мы описали процесс графически, обсудили его, получили согласие, приходит время, как говорится, «добавлять на кости мясо». Т.е. на полученный каркас в виде общей диаграммы мы начинаем «наращивать» детали, как именно будет выполняться работа на каждом из этапов.
В графической модели мы не можем подробно детализировать все нюансы. Более того, в этом нет необходимости, излишние подробности только усложняют восприятие. Для этого существует текстовое описание.
Например, в графической модели мы указали «Создать заявку». В самой диаграмме этого достаточно. Но в текстовом описании мы указываем, что необходимо для создания заявки. Это может быть перечень полей (Клиент, Сумма заявки, Комментарий и пр.).
Аналогично при создании Сделки на основе заявки, в тексте описываются поля «Сумма сделки», «Перечень товаров», «Клиент», «Этап» и т.д.
Требования к текстовому описанию:
Текстовое описание должно полностью описывать тот процесс, который есть в графическом описании.
Дополнительно в текстовом описании должно быть все, что необходимо для разработки решения и передачи его в работу программистам.
Если идея нужна для руководства, в основном, BPMN-диаграмма — для руководства и сотрудников высшего звена, т.е. тех, кто будет принимать решения и в общем контролировать ситуацию, то текстовое описание нужно для программистов. С помощью диаграммы и текстового описания они уже смогут реализовать решение.
План
У нас уже есть понимание, что из необходимых и полезных инструментов уже имеется в наличии. Есть знание, к чему мы должны прийти. План отражает последовательность действий, которая нужна для достижения поставленной цели.
Например, у нас в процессе должен создаваться звонок и подключаться автоматически запись разговора. Значит, нам нужно:
Подключить IP-телефонию, если она еще не используется.
Интегрировать телефонию с системой.
Настроить запись звонков и выбрать для этих записей хранилище.
Еще один распространенный пример — на данный момент сайт заполняется вручную. Необходимо настроить автоматическую выгрузку на сайт. В плане мы так и ставим задачу: «Автоматическая выгрузка данных на сайт. Разработка скриптов переноса данных из учетной системы на сайт информации».
Таким образом, в план мы собираем задачи по автоматизации, а также указываем исполнителя и сроки. При этом нет необходимости указывать фамилии исполнителей. В плане важно указать просто: «программист», «консультант».
Я лично так понимаю:
Программист — это тот человек, который будет писать программный код.
Консультант — человек, который будет контролировать работу программиста.
Старший консультант — это человек, который будет осуществлять общее руководство проектом.
Иногда, если в этом есть необходимость, я указываю, что определенную задачу будет выполнять не просто программист, а, например, 1С-программист.
Требования к плану:
В плане должны быть отражены все задачи, которые нужно выполнить, чтобы получить из того, что есть, то, что должно быть.
В плане должны указываться четкие сроки выполнения задач, и кто исполнитель.
Подробнее эти этапы работ вы также можете изучить из моей статьи «Использование GAP-анализа для выявления и согласования задач по проекту».
Пример плана
Счет и/или калькуляция
В калькуляции мы берем те задачи, которые в плане оценены в часах и днях, и рассчитываем их стоимость. Если расчеты внутренние, калькуляции достаточно. Если ваш заказчик — другая компания, понадобится счет.
Здесь также все просто. Берем задачу, пересчитываем ее на рабочие часы, умножаем на стоимость часа и получаем расчет стоимости задачи. Саму методику вы можете изучить подробно в статье «Как рассчитать стоимость внедрения программного продукта»
