Всем привет
Ниже пойдет речь о том, что такое техническое задание, когда применяется техническое задание, и какие требования предъявляются к написанию технического задания.
Итак. Техническое задание – текстово-графический документ, описывающий содержание разработки, требования, предъявляемые к конечному продукту разработки, критерии приемки готового продукта, сроки разработки, и ответственности сторон.
Техническое задание в обычной жизни – приложение к согласованной форме договора. При этом договор – юридически верный документ, описывающий процессы взаимоотношения сторон при осуществлении коммерческой сделки, тогда как техническое задание определяет требования к продукту разработки. Договор может быть «шаблонным», и применяться в многих типах сделок между сторонами, а техническое задание должно быть уникальным для каждого случая.
Рассмотрим ситуацию, приближенную к жизни Саппорта. К примеру, «А» пришел на сайт фрилансеров, и обратился к сообществу за разработкой программы, которая должна считать, сколько денег он тратит на продукты. За 3т.р. создать программу вызвался разработчик «Б». Объем задач обсудили по ICQ, и разработчик представил интересное решение – программа считает затраты, представляя сводные данные по каждому месяцу. Прошла оплата, а через 3 недели «А» обращается с претензией к «Б», требуя доработку программы:
– программа работает под Winodws XP, но не работает под Windows -7;
– отсутствует пароль на доступ к отчетам;
– нельзя сводить данные с разных источников (у жены «А» есть ноутбук, где она так же сводит затраты на продукты, которые покупает сама, но объединить данные по затратам с супругом не получается);
– «А» очень хочется получить цветные графические отчеты по расходам, а данных функций у программы нет;
– хочется вводить затраты еще на смартфоне, а потом экспортировать на стационарный ПК, но и этого нет в программе;
и т.д.
Наверное, с подобными проблемами сталкивался каждый. Как со стороны «А», так и со стороны «Б». В чем основная причина проблем и претензий?
Причина претензий – завышенные ожидания заказчика «А» по объему разработки исполнителя «Б». Исполнитель разработал «ровно столько», сколько ему было сказано (на момент передачи информации от «А» к «Б»). Формат диалога – ознакомление Исполнителя с Техническим Заданием, созданным Заказчиком. Обычно у разработчика заказ не один; хотите, чтобы ваш запрос не забылся и был выполнен в соответствии с пожеланиями – ПИШИТЕ Техническое Задание, учитывая стандартный путь при установлении взаимоотношения сторон:
1. Предоставление технического задания (ТЗ) Заказчиком;
2. Оценка ТЗ Исполнителем;
3. Заключение договора (фиксируются объем разработки, стоимость, сроки, требования к качеству и приемке, гарантийный период). Взаиморасчеты (предоплата);
4. Выполнение работ Исполнителем;
5. Передача готового продукта Исполнителем Заказчику (взаиморасчеты);
6. Проверка готового продукта, приемка Заказчиком (взаиморасчеты).
* Как только появляются запросы Заказчика (содержание разработки, сроки, качество, и т.д.) Исполнитель оценивает влияние на возможность разработки, сроки разработки и стоимость разработки – возврат на пункт №2.
Причины проблем «А» с функционалом – отсутствие четкого Технического Задания, о составе которого речь пойдет ниже.
Итак, давайте набросаем структуру Технического Задания:
1. Общий объем разработки – не заставляйте Исполнителя читать десятки страниц текста, чтобы понять, может ли он взяться за заказ. Сформулируйте все, что вы хотите в 1-3 предложениях, и представьте это в самом начале. К примеру «Разработка многопользовательской программы для линейки Windows для учета затрат пользователя, с возможностью формирования и печати отчетов, и поддержкой мобильных устройств»;
2. Исходная информация – напишите то, что вы уже можете сообщить Исполнителю о данных, которые уже известны, системах, которые уже используются – это даст отправную точку в разработке. Укажите известные вам примеры, охарактеризуйте/прокомментируйте их плюсы и минусы;
3. Состав разработки – это 90% от ТЗ. Укажите все, что вы можете сообщить о конечном продукте (то, как вы это понимаете), о его функционале. Предоставьте графические данные/чертежи, помогающие Исполнителю понять, как «это» должно выглядеть.
4. Требования, предъявляемые к конечному продукту разработки – укажите функционал, совместимость, требования к безопасности;
5. Критерии приемки готового продукта – предложите процесс приемки (к примеру – после тестирования в течение 1 дня на реальном форуме с 100 пользователями «онлайн»);
6. Сроки разработки – напишите ваши требования по срокам разработки, от вашей предоплаты за разработку;
7. Ответственности сторон – максимально пропишите, что вы ожидаете от Исполнителя, а что будете делать только сами (кто будет ставить тестовый продукт на форум, кто будет решать проблемы в случае возникновения проблем с продуктом, будут ли предоставлены Исполнителю доступы в админку/ftp, и т.д.);
8. Гарантия. Согласуйте с Исполнителем период времени ОТ ПРИЕМКИ выполненных работ, в течение которого Исполнитель будет осуществлять поддержку Заказчика при возникновении проблем с продуктом ЗА СЧЕТ Исполнителя. По истечению этого срока все проблемы Заказчика будут решаться за счет Заказчика.
Как-то так. Можно будет дополнить/подправить в диалоге. Приглашаю к обсуждению.