Определение задачи
Техническое задание является описанием поведения продукта, необходимых изменений, входящих и исходящих параметров системы. Для того чтобы определенная задача была решена, она должны быть правильно определена и разобрана каждым из сотрудников, который будет ею заниматься, нужны конкретные примеры и процедура проверки входящих и исходящих данных. Поэтому техническое задание – это очень основательный документ, который регламентирует задачи и предоставляет предложения для его решения.
Правильное задание
Правильное техническое задание состоит из 4 шагов, 3 из которых являются обязательными, а последний шаг – вспомогательный и только рекомендован к исполнению:
- Предложение и его аргументация для изменения или создания новой функциональности. Это обязательный этап задания;
- Конкретный пример входящих данных, с указанием реальных ситуаций, практических действий и последовательности. К ним прилагаются соответственные действия, которые должны быть предприняты программным обеспечением. Это также обязательный этап задания;
- Указывается результат действия входящих данных в виде таблицы или документа. Здесь можно проверить трансформацию, которая произошла с входящими данными, и каким образом были получены результаты. При выполнении задания и завершении изменений проигрывается именно этот пример путем сопоставления шагов 2 и 3. Это также обязательный этап задания;
- Дополнительные разъяснения метода работы, аналоги в других системах, возможно похожие документы и другая вспомогательная информация. Этот шаг носит рекомендательный характер и необходим для формирования лучшего понимания процессов со стороны программистов и архитекторов компьютерной системы.
Правильное техническое задание содержит реальные примеры, реальные цифры и реальные результаты. Таким образом, можно проанализировать связи и сравнить полученный результат с предварительно заданными значениями, параметрами и действиями.
Неправильное задание
Неправильное задание по изменению продуктов можно охарактеризовать несколькими простыми предложениями. В нем, обычно, нет точных примеров последовательной работы и определенных задач:
- Задание из разряда «Сделайте этот отчет, как тот» может вызвать только один комментарий специалиста, например, «Тогда используйте тот отчет, а не этот!»;
- Предложение из разряда «Добавьте в этот документ такие-то данные» автоматично формирует необходимость в представлении соответствующей аргументации или формуле. Обычно, после этого от клиента следует тишина, т.к. он и сам не знает какая именно формула нужна или не обладает аргументацией;
- На стандартный запрос «Может ли этот продукт работать, как тот» всегда есть один ответ «Нет, каждый продукт обладает своей технологией работы, и они не могут перемешиваться между собой».
Вышеперечисленные примеры являются обобщенными, но отображают тенденцию большинства запросов — без предоставления аргументации и основы для анализа. Именно эти примеры показывают, как не должны быть предоставлены требования об изменениях в продукте и как отсутствие примеров, фактов и аргументов, в конечном счете, приводит к хаосу в работе с предложением.
Пример технического задания
Чтобы показать пример технического задания, предлагаем рассмотреть модификацию документа продажи с дополнительными параметрами, необходимыми для партнеров. Для этой цели составим техническое задание следующего вида:
- Необходимо модифицировать документ о продаже, а именно «Товарную накладную», т.е. в документ нужно добавить текущие задолженности клиента, только после чего сформируется этот документ. Данное изменение поможет в торговой деятельности, т.к. будет ясно определять задолженности клиента в каждой выданной копии;
- Пример изменения документа — добавление в следующих строках в конце документа, под таблицей с товарами:
- Текущая сумма документа перед оплатой;
- Предыдущая задолженность клиента;
- Оплата по документу;
- Задолженность после оплаты или неоплаченный остаток.
- Результат от изменения «Товарной накладной» — в верхней части документа должны появляться следующие данные:
- 1000 EUR – текущая сумма;
- 700 EUR – предыдущая задолженность;
- 900 EUR – оплата;
- 800 EUR – остаток по задолженности.
- Задолженность клиента формируется из предыдущей задолженности, суммированной с текущей суммой документа. После чего вычитается проведенная оплата и, в качестве остатка, появляется разница между задолженностью и оплатой.
Написанное таким образом техническое задание абсолютно понятно: есть пример, аргументация и описание действий. С помощью указанных примеров можно повторить ситуацию и проверить на практике все цифры. Таким образом, проверка технического задания становится легкой, и оно само может быть одобрено подрядчиком после проверки сделанных изменений.
Время, необходимое для технического задания
Очень часто встречается утверждение, что «нет времени» для написания технического задания. Практика показывает, что:
- Время на создание технического задания может быть от нескольких минут до 1-2 часов;
- Время выполнения технического задания может быть от нескольких дней до 1-2 месяцев.
Отсюда следует, что написание технического задания намного проще, чем реальное выполнение проекта. Поэтому оно должно быть хорошо сделано и передано в соответственном виде.
Соотношение времени на создание технического задания к времени на его выполнение: 1:50 / 1:200. Поэтому важно тщательно анализировать все желаемые возможности и только после этого описывать их в качестве изменений в продукте.
Устное техническое задание
Существуют партнеры, которые в устной форме объясняют желаемые изменения в программных продуктах. После чего эти же партнеры проверяют результат и делают новое задание. И этот процесс постоянно повторяется и неблагоприятно влияет на обе стороны. Очевидная проблема в том, что нет определенной формы задания, все изменения происходят произвольно, из-за чего желаемый вариант никогда не достигается. Одновременно с этим, программисты системы уделяют много времени и ресурсов на создание модулей, после чего их же перерабатывают согласно новым требованиям, и это превращается в замкнутый круг. Т.к. время на создание модуля в 50-200 раз дольше, чем время на его описание, то постоянные изменения загружают не только программистов, но и замедляют развитие самих программных продуктов.
Вывод очевиден — техническое задание должно быть подробно изложено и предоставлено в письменной форме. В противном случае достижение нужного результата становится невозможным.
Выводы
Правильные изменения в ПО, создание новых модулей, отчетов и документов требует подробного и аргументированного описания функций продуктов. Техническое задание – основной документ, благодаря которому достигается согласование изменений со стороны клиента, технического специалиста и программиста системы. С его помощью определяются задачи для каждого участника процесса, и этот документ становится основной базой для определения объема работы. В качестве финального штриха можно отметить, что техническое задание регламентирует, какие именно результаты должны достигаться программой, что позволяет сравнить получаемые программой данные с предварительным примером. Таким образом, проверяется его работоспособность и возможность выполнения всего проекта.
Информация взята с сайта http://wiki.microinvest.su
Дополнительную информацию о техническом задании можно посмотреть здесь: http://ru.wikipedia.org/wiki/Техническое_задание и здесь: http://www.prj-exp.ru/patterns/pattern_tech_task.php