Хорошая привычка — перед написанием любого документа или текста хотя бы раз задуматься, задать себе вопрос: «А для чего мы его пишем?». А также, для кого — кто его будет читать и что нам хочется ему сказать своими словами (ибо в тот прекрасный момент никого более рядом с читателем может и не оказаться).
Техническое задание — это документ и текст, который пишет менеджер проекта, пишет его для себя, своего заказчика, своей проектной команды. И способов употребления у хорошего технического задания много.
Записывание мыслей есть лучший способ их продумывания
В первую очередь менеджер пишет техническое задание для себя. Важнейшим предназначением технического задания является сам процесс его написания. Хорошо известная истина о том, что выкладывание мысли словами способствует более чёткому осознанию самоёй мысли, лежит в основе этого предназначения.
Менеджер проекта должен хорошо, очень хорошо и очень чётко представлять себе будущий проект — чем должен стать сайт. Что такое «сайт с точки зрения менеджера проекта» — вообще тема отдельного разговора, здесь же скажу о том, что для полного представления о сайте, которое должен иметь менеджер, ему придётся взглянуть на проект с нескольких сторон.
Написание технического задания должно помочь менеджеру разрешить все мелкие несостыковки между идеями, которые хочет заложить в сайт он, его заказчик, гениальный дизайнер его проектной команды, парадигма реализации, которой пользуется студия.
Как вывод, формат технического задания должен хорошо подходить для укладывания и взаимной состыковки всех этих идей и, во многом, формат технического задания будет зависить от «парадигмы реализации» (того, как разработчики представляют себе «правильную» функционально-техническую реализацию всей заложенной в задании функциональности же).
Описание сайта для нашего заказчика
Второе очень важное предназначение технического задания — быть описанием сайта для нашего заказчика. Заказчик видит сайт как нечто, в большинстве случаев очень плоское и состоящее из «карты сайта» и «заглавной страницы». Сайт же, к его вящему удивлению, оказывается чем-то большим и сложным, — техническое задание должно помочь заказчику выжить в этом внезапном диссонансе.
Описание сайта должно быть, в конечном счёте, понятно для заказчика. Кроме того, все «нижние» уровни этого описания должны быть обусловлены верхними — это поможет заказчику двигаться «сверху-вниз» в процессе понимания задания. Хорошая, прозрачная структура также улучшает понимаемость технического задания.
Чеклист для приёмки сайта
Кстати, говоря о понимании, стоит говорить сразу и о взаимопонимании. Наиболее опасное для разработчиков место — приёмка готового продукта. Если заказчик и команда разработчиков хорошо друг друга понимают, то разногласий в приёмке не возникнет. Техническое задание служит для того, чтобы менеджер мог показать «нечто» заказчику и заявить «это соответствует такой-то части ТЗ», а заказчик радостно покивал головой или же, напротив, заглянул в ТЗ и указал на что-то, что заданию не соответствует.
Воспринимая техническое задание как своеобразный «чеклист» для приёмки сайта, легко оказаться в заблуждении и начать доводить детальность задания до умопомрачительного уровня. Работая над техническим заданием, менеджер должен детализировать каждый его блок до того уровня, когда следующие детали станут уже непринципиальны для заказчика. Хороший же заказчик должен считать принципиальными те детали, которые необходимы для его понимания замысла разработчика — но это сейчас частное отвлечение о ролях «заказчика» и «проектировщика».
Как вывод, техническое задание как чеклист должно содержать некоторое описание структуры, оформления, функциональности сайта, разбитое на какие-то блоки, которые можно согласовывать и принимать по отдельности; уровень детальности описания каждого блока будет зависеть от того, насколько этот блок сам по себе принципиален для заказчика (который в большинстве случаев видит «карту сайта» и «заглавную страницу», увы).
\"Жёсткая память\" менеджера
Хорошо, что я сначала сделал заголовки, а потом начал наполнять статью содержимым. Иначе я обязательно бы забыл про этот пункт, ибо по ходу написания уже три раза отвлекался. Между тем, пункт как раз и касается «забывчивости».
Я уже говорил, что любой проект оказывается тем успешнее, чем лучше его ведущий (в нашем случае — менеджер) представляет себе этот проект — чем более он сфокусирован на воплощении какого-то определённого представления (я намеренно опускаю вопрос о том, кто именно генерирует это представление). Практически в любой студии каждый менеджер одновременно «ведёт» несколько проектов, перебрасываясь с одного на другой. Эта необходимость переключения чрезвычайно затрудняет «фокусированность» — часто проекты начинают смешиваться в голове у менеджера — и, если для реализатора это всё же допустимо, то для проектировщика может означать полный провал.
Техническое задание в нашем случае выполняет роль «жёсткой памяти», постоянного хранилища, которое содержит в себе основные идеи и концепции, а также намеченный путь их реализации. Менеджер может, перелистав техническое задание, восстановить целостную картину проекта, как он его видел — пусть и после двухмесячного перерыва. «Я, очевидец», но не «я, робот».
Творчество и самореализация менеджера
И в последнюю очередь менеджер пишет техническое задание для себя же. Одна, не единственная, но всё же ценная радость менеджера проекта — хороший, наглядный и ладно состроенный текст технического задания.
«Я, очевидец», но не «я, робот». Менеджер проекта не может себе позволить стать роботом, бездушным компоновщиком блоков своих же собственных технических заданий, будь они сто раз как успешны и проверены. Почему? Оставляю это на самостоятельную проработку, если ответ вам не очевиден.
Вместе с тем, отдельные блоки технического задания обязательны, и формат, и содержимое их в большинстве случаев одинаково. Это, к примеру, описание технических требований системы и поддерживаемых стандартов. Менеджеру не стоит тратить своё время на многократное художественное выписывание этих разделов, когда он объясняет себе и заказчику, каков будет сайт.
Вместо заключения
Я попробовал рассказать, зачем и кому нужно техническое задание, и получил, что нужно оно главным образом менеджеру, вернее, всем тем окружающим его условиям, от которых он не может отмахнуться: заказчик, проектная команда, другие проекты, ожидающие своего часа. В следующий раз я буду стараться успеть рассказать и о том, какова структура ТЗ, и на каком объёме документа стоит остановиться.
Иной менеджер отмахнётся от моих околофилософских размышлений, сказав, что и без того хорошо представляет себе сайт. Что сказать мне в ответ? Пожалуй, ничего кроме того, что я, начиная писать эту статью, «хорошо представлял себе», что я там напишу. Однако, в процессе написания я таки пару раз крепко задумался и перечеркнул несколько абзацев.
Список статей
