Главная > техническое задание > Вводная статья о техническом задании

Вводная статья о техническом задании

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


     ТЗ – это документ, который регулирует процесс разработки, дает четкое представление о конечном результате, когда можно сказать это все, мы выполнили свою задачу. Главная задача проектировщика не написать документ, а спроектировать сайт.

     Хочу отметить, что документы составляются разные при каскадной (или водопадной) методике разработки и при экстремальном программировании, также следует обратить внимание на некоторый отличия, которые будут при написании ТЗ в компании разрабатывающей интернет ресурс и отдельно заказанным ТЗ.

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

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

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

     ТЗ можно заказать у компании исполнителя, технические писатели помогут разработчикам в ходе проекта, эти сотрудники являются ресурсом компании и соответственно хорошо контролируемы, исполнители будут говорить на одном языке, в таком случае мы избегаем несоответствия представлений составителя с возможностями и представлениями реализаторов проекта, но есть и минусы технические писатели могут быть очень загружены, могут иметь однобокое представление о проекте, и рекомендовать только те технологии, которые использует данная компания.
     Можно обратиться в компанию-разработчика и заказать только ТЗ. Здесь плюсом играет то, что составитель изначально знает, что проект реализовывать будет не его компания, соответственно, меньше вероятность “раздувания” бюджета, доскольнально точно учитываются все тенденции и технологии, нет привязанности именно к своим правилам разработки, будет более полная деталицация т.к. разработчики не будут иметь возможности обратиться к техническому писателю (человеку написавшему ТЗ).

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

admin техническое задание

blog comments powered by Disqus