Круги ада
на пути к идеальному ТЗ


Техническое задание (ТЗ) – главный и первый этап разработки продукта. Алексей Бородкин, директор по продукту компании Notamedia, расскажет о том, что такое ТЗ и почему важно его составлять, что такое ад для разработчика и какое ТЗ можно считать хорошим.

Вспомните культовую игру 1990-ых – Doom. По сюжету несколько ученых в ходе научных экспериментов случайно открыли портал в ад. Из ада полезли демоны и стали все крушить, а потом появился главный герой и накостылял всем демонам…

Все закончилось хорошо. Но есть еще один действенный способ открыть портал в ад. Достаточно произнести фразу: «Давайте работать без ТЗ».
«Давайте работать без ТЗ».
С этой фразы началась моя карьера аналитика-проектировщика.
В ту пору я работал на стороне клиента и занимал должность, которую даже и назвать нельзя правильно. Я занимался всем, что связано с интернетом.

Я отвечал за тексты, за сайт и вскоре мне дали задачу переделать сайт. Сайт был простым и стандартным, как многие корпоративные сайты: разделы «Продукты», «Решения», «О компании», «Контакты». И на этом все. Я подумал, что все просто, надо брать исполнителя.

Ребята, которые делали сайт, предложили обойтись без формальностей и работать без ТЗ. Сразу же начались проблемы. Разработчики приняли задачу, сделали, вернулись и принесли не то... Я велел переделать.

Второй вариант был подходящим, и я понес его коллегам, но там меня ждало другое открытие: коллеги представляли корпоративный сайт совершенно иначе. Пришлось снова переделывать, ведь у каждого – свое видение.
Начался мой персональный ад
Сначала я много нервничал и даже кричал матом на коллег. Проект надо было сдать в августе, а был уже конец июля.

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

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

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

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

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

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

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

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

Вигерс пишет: «Многие люди ошибочно считают, что время, которое тратится на обсуждение требований, просто отсрочивает выпуск продукта. Они полагают, что работа с требованиями не повышает рентабельность проекта, но на самом деле затраты на получение хороших требований всегда возвращаются с излишком».
Но если вы хотите понять на конкретном примере, за каким ТЗ не жаль спуститься в ад, то вот образец. Это пример идеального ТЗ:
Концепция сайта GO-ФЕРМА

Составлена отделом аналитики и проектирования агентства Notamedia

Дата актуализации: 13.11.2015

Назначение документа: дать предварительное описание разрабатываемого продукта — сайта GO-ФЕРМА. Указанная в документе информация может быть пересмотрена в ходе этапов аналитики, проектирования и дизайна по обоюдному согласию заказчика и исполнителя.

О продукте

Сайт GO-ФЕРМА – промосайт сети ферм «GO-ФЕРМА», позволяющий пользователям ознакомиться с деятельностью компании и отправить заявку на ее услуги - катание на различных видах животных.


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

1. Продвижение информации о компании и ее услугах

2. Сбор заявок от целевой аудитории и их хранение

3. Предоставление аудитории контактных данных ферм.


Можно выделить следующие целевые группы пользователей продукта:

● Потенциальные клиенты;

● Представители СМИ.


Целевые группы пользователей сайта GO-ФЕРМА, их задачи, решаемые ресурсом, задействованный функционал и страницы сайта описаны в следующей таблице.


Предполагаемая структура сайта:

● Главная страница

○ Страницы ферм

● Страница ошибки 404

● Административная часть


Предполагаемый функционал сайта:

● Отправка сообщений через форму обратной связи

● Интеграция кнопок для публикации информации (шэринга) в соцсетях

● Хранение заявок и предоставление доступа к ним

● Управление контентом на сайте


Дополнительные указания

● Хостинг осуществляется на ресурсах клиента;

● В качестве CMS должна использоваться система 1С-Битрикс;

● Сайт должен корректно отображаться и функционировать на мобильных устройствах (но не адаптироваться под них);

● Планы на дальнейшее развитие:

○ Ввод системы бронирования;

○ Размещение веб-камер на сайте;

○ Создание блога;

○ Создание адаптивной версии под мобильные устройства.


Продукт – сайт в международной системе интернет.

Версия продукта – стационарная и мобильная.

Доступ – осуществляется через Dial-up соединение, ADSL модем, FTTx, GPRS (мобильный) и WiMAX.

Назначение – многоцелевое.


Объекты

● Сайт рассчитан на 2 типа пользователей: статичные и движимые .

● Сайт должен содержать первичную базу статичных объектов с возможностью добавления.

● Движимые и недвижимые объекты имеют свои аккаунты на сайте разного типа.

● Количество аккаунтов для движимых объектов ограниченно 3-мя.

● Недвижимые объекты имеют только один аккаунт на сайте.

● Движимые объекты имеют несколько статусов одновременно, соответственно подвижные пользователи имеют возможность идентифицировать себя в нескольких местах одновременно.

● Движимые объекты имеют возможность пополнения списка недвижимых объектов на ограниченное время (это относится только к временным объектам), постоянные создаются только админом. Далее управление неподвижными аккаунтами может быть передано третьим лицам.

● База обоих типов пользователей многочисленна (от 100 до нескольких сотен миллионов).


Техническая информация

1. Хранение информации о пользователях осуществляется на отдельном удаленном сервере с возможностью архивации.

2. Пользовательские версии должны быть адаптированы под все виды мобильных телефонов (где предусмотрен доступ в интернет), планшетных устройств, стационарных компьютеров.

3. По будет использоваться в том числе в качестве приложения в таких системах, как PLAY MARKET, APPLE STORE И Т.Д.

4. Сайт мультиязычный.

5. Дизайн лаконичный.

А вот тут расположен пример того, как не стоит делать, даже если вас начали пытать. Пример плохого ТЗ:
Продукт – сайт в международной системе интернет.

Версия продукта – стационарная и мобильная.

Доступ – осуществляется через Dial-up соединение, ADSL модем, FTTx, GPRS (мобильный) и WiMAX.

Назначение – многоцелевое.


Объекты

● Сайт рассчитан на 2 типа пользователей: статичные и движимые .

● Сайт должен содержать первичную базу статичных объектов с возможностью добавления.

● Движимые и недвижимые объекты имеют свои аккаунты на сайте разного типа.

● Количество аккаунтов для движимых объектов ограниченно 3-мя.

● Недвижимые объекты имеют только один аккаунт на сайте.

● Движимые объекты имеют несколько статусов одновременно, соответственно подвижные пользователи имеют возможность идентифицировать себя в нескольких местах одновременно.

● Движимые объекты имеют возможность пополнения списка недвижимых объектов на ограниченное время (это относится только к временным объектам), постоянные создаются только админом. Далее управление неподвижными аккаунтами может быть передано третьим лицам.

● База обоих типов пользователей многочисленна (от 100 до нескольких сотен миллионов).


Техническая информация

1. Хранение информации о пользователях осуществляется на отдельном удаленном сервере с возможностью архивации.

2. Пользовательские версии должны быть адаптированы под все виды мобильных телефонов (где предусмотрен доступ в интернет), планшетных устройств, стационарных компьютеров.

3. По будет использоваться в том числе в качестве приложения в таких системах, как PLAY MARKET, APPLE STORE И Т.Д.

4. Сайт мультиязычный.

5. Дизайн лаконичный.

© Rusbase
Алексей Бородкин