Проектирование сайта: Техническое задание или чего хочет заказчик

20 Тра
20.05.2013

Техническое задание

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

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

Так как же избежать извечного конфликта заказчика и исполнителя, чтобы при этом все остались довольны?

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

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

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

Техническое задание

Как показывает статистика, при работе с большими проектами исправление ошибки в требованиях на этапе проектирования обходится втрое дороже, чем исправление аналогичной ошибки на этапе требований. Аналогичная ошибка на этапе кодирования обходится в 5-10 раз дороже, а после выпуска программы — в 10-100 раз. На более мелких проектах,  где административные расходы значительно меньше, показатель ближе к 5-10, чем 100. Но как бы то ни было — лишние расходы вам абсолютно не нужны.

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

Поэтому четко сформулированные требования — залог для успешного завершения проекта. Многие предполагают, что это даже более важный аспект, чем использование эффективных методов проектирования и разработки. Старайтесь из заказчика выжать как можно больше информации о проекте. Если это проблематично — сделайте это за него и покажите эти требования заказчику.

Техническое задание

Теги: ,