Yuri Shilyaev. Blog.

Пару лет назад я написал бойкую и объемную статью про то, как должно быть написано технического задание (ТЗ) на сайты. Эта статься явилась результатом апогея моей работы в качестве бизнес-аналитика в одной известной белорусской компании. В присутствии вдохновения я мог выдавать на-гора по 10 печатных страниц технического текста в день, строго помечая каждый абзац отдельным пунктом. Особенно удавались те куски ТЗ, где описывались конкретные продукты, которые мы планировали внедрить без лишнего спроса у заказчика. Помню, как я бойко описывал модуль форума, в качестве которого использовали phpBB. Точно также можно творчески переписать чужую книжку о войне и выдать это за свои собственные мемуары.
Я раза 4 переделывал формат ТЗ, вносил туда информационные схемы страниц, иногда описывал процесс разработки. И даже создал не просто шаблон самого документа, где надо было прописать компанию и названия проекта, но также создал шаблоны описания отдельных модулей. Я умудрялся проектировать и собирать ТЗ на 40 страниц за 2-3 дня.

После написания той статьи я не написал ни одного ТЗ.

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

ТЗ в общем-то нужно

Давайте разберемся в таком важном вопросе: что вам понадобиться если вы решили скосить траву на дачной лужайке? Думаю, вам будут необходимы инструменты и план. Т.е. неплохо бы обзавестись газонокосилкой или деревенской косой и решить для себя: с какой стороны начинать косить с подветренной или от забора.

Но если вы на том же дачном участке решили построить, простите, сортир, то кроме всего прочего вам также понадобиться чертеж и смета
работ. (Почему я привожу в пример сортир? На мой взгляд, это самая простая и в то же время самая первая постройка на дачном участке).

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

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

ТЗ дает возможность сравнить то, что планировалось с тем, что выполнено, но не говорит о том, что реально хотел заказчик.

Ага. Перечитайте еще раз.

Более того, когда на середине проекта кто-то вдруг решает, что скромная дачная постройка должна иметь возможность интеграции в строящийся рядом дом, а также быть использована по назначению в зимний период с подогревом… приходится перечеркивать прежний план и смету и занудно говорить заказчику: “Ну вы же понимаете…”

В чем же цель ТЗ?

Целей для чего человечество придумало составлять документы миллион. Для чего чаще всего составляют ТЗ?

• Без бумажки — ты букашка. Есть ряд случаев, когда ТЗ просто необходимо как бумажка, которую согласуют, подпишут, пропечают те люди, которые не видели этот документ дальше 2й страницы. Вру, первой. Но при этом все равно необходимо нормально написанное ТЗ, потому что эти же люди в последствии могут туда заглянуть и достать вас, как розовая кофточка.
• Иногда цель ТЗ в том, чтобы согласовать работы нескольких сторон разработки. Например, когда интегрируется несколько приложений, которые должны обмениваться данными в определенном формате, по заранее определенному алгоритму. Тут никак не обойтись.
• По ТЗ легче делать оценку проекта, нежели слушать фантастический очерк стратега-заказчика о каких-то там рыночных перспективах. Нам часто присылают ТЗ на оценку, и когда оно написано хорошо, то проблем никогда не бывает.
• Соответственно, по ТЗ проще бюджетировать проект. Точно также, как ТЗ является защитой для разработчика от желаний заказчика, ТЗ является и защитой руководителя проекта заказчика от его же финансовой службы, которая хочет знать на что запланирован бюджет проекта.

Представим, что на руках у нас этот самый толстый документ с кучей пунктов. (Мне они попадают в руки регулярно). Что делать если у нас возникают следующие ситуации?

Пришла мысль. Черт ее знает, где она ходила раньше, но пришла она когда проект перевалил за вторую очередь предоплаты. Назад дороги нет, проект разобран и соберется по плану как раз к сдаче. Принимаем решение, что мысли будем реализовывать после сдачи. Что будет с бюджетом проекта после сдачи? Его зарежут.

До завершения проекта далеко, а его уже надо переделывать. Мир на месте не стоит в отличие от бездушной бумаги, которая все стерпит. Случается, что изменения настигают проект в самом разгаре. Надо включать change management process, а это долго, муторно и надо все останавливать. Плюс и бюджетные деньги уже потрачены и на переделку никто не рассчитывал.

Пользователи просят, а в ТЗ говорит “нет”. Тестовые версии проекта опробованы представителями заказчика и нарастает понимание, что хочется чего-то еще и совсем другого. Чего-то красного, но синего. Документ ТЗ утвержден, пропечатан и согласован, а мольбы пользователей также останутся “на потом”.

Сделаем то чего не надо. Когда планируется большой проект, и креатив настигает всех его участников , формулируется ряд идей и фич, которые иначе, как барохлом не назовешь. Это фичи, которые также бесполезны, как балконный хлам. В нашем формате функционального листа они проходят под приоритетом — If have time. На запуск и работу проекта они не влияют, но согласно ТЗ должны быть выполнены даже в обмен на банкротство разработчика.

К чему я это веду.

Я хочу прояснить одну мысль относительно ТЗ:

Техническое задание является формой фиксации требований в проекте.
Повторяю: ФОРМОЙ.
А не догмой.

Для фиксации требований существуют и другие форматы и способы: use cases, user stories, прототипы, вайфреймы, функциональные листы, системы управления требованиями (fe: Rational Requisite) и т.д. Формат и метод фиксации требований зависит от процесса управления и разработки проекта.

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

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

Основным рабочим документом для нашей команды разработчиков является “Функциональный лист” (Feature List или Backlog) всего проекта, из которого формируются листы отдельных итераций. Требования при этом могут быть зафиксированы в ТЗ – тогда мы делаем ссылки на соответствующие пункты, а могут фиксироваться в виде дизайн-макетов, вайфреймов или писем. В конечно счете это уже не так важно. Мы работаем короткими итерациями и постоянно поддерживаем контакт с заказчиком, уточняя эти требования. Работы сдаются раз в месяц или раз в две недели, а потому что-то серьезно не угадать у нас просто не хватит времени.

Хотя здесь стоит тоже о кое-чем задуматься… Как-то в книжке Сирила Паркинсона я прочитал такую мысль, что писать мемуары о кругосветном путешествии надо еще до самого путешествия. Вдруг оно будет слишком скучным, и совесть не позволит вам написать о поверженных племенах Зулусов или пересечении Ганга вплавь. Составление ТЗ это в какой-то степени также составление описания не пройденного пути заранее. Если же вы ступаете на путь без ТЗ, то надо запастись “блокнотом”, чтобы фиксировать все события по ходу. Не забывайте об этом.

Спустя 2 года после того, как я рассказал про “хорошее ТЗ на сайт” я хочу сказать: не ставьте телегу впереди лошади и не накладывайте гипс на еще не сломанную руку. Определите свой формат работы, найдите организационную и юридическую форму работы с заказчиком, чтобы понять формат фиксирования требований. А вот после этого пишите такое ТЗ, которое вам будет необходимо.