Круги ада
на пути к идеальному ТЗ
Техническое задание (ТЗ) – главный и первый этап разработки продукта. Алексей Бородкин, директор по продукту компании Notamedia, расскажет о том, что такое ТЗ и почему важно его составлять, что такое ад для разработчика и какое ТЗ можно считать хорошим.
Вспомните культовую игру 1990-ых – Doom. По сюжету несколько ученых в ходе научных экспериментов случайно открыли портал в ад. Из ада полезли демоны и стали все крушить, а потом появился главный герой и накостылял всем демонам…
Все закончилось хорошо. Но есть еще один действенный способ открыть портал в ад. Достаточно произнести фразу: «Давайте работать без ТЗ».
Все закончилось хорошо. Но есть еще один действенный способ открыть портал в ад. Достаточно произнести фразу: «Давайте работать без ТЗ».
«Давайте работать без ТЗ».
С этой фразы началась моя карьера аналитика-проектировщика.
С этой фразы началась моя карьера аналитика-проектировщика.
В ту пору я работал на стороне клиента и занимал должность, которую даже и назвать нельзя правильно. Я занимался всем, что связано с интернетом.
Я отвечал за тексты, за сайт и вскоре мне дали задачу переделать сайт. Сайт был простым и стандартным, как многие корпоративные сайты: разделы «Продукты», «Решения», «О компании», «Контакты». И на этом все. Я подумал, что все просто, надо брать исполнителя.
Ребята, которые делали сайт, предложили обойтись без формальностей и работать без ТЗ. Сразу же начались проблемы. Разработчики приняли задачу, сделали, вернулись и принесли не то... Я велел переделать.
Второй вариант был подходящим, и я понес его коллегам, но там меня ждало другое открытие: коллеги представляли корпоративный сайт совершенно иначе. Пришлось снова переделывать, ведь у каждого – свое видение.
Я отвечал за тексты, за сайт и вскоре мне дали задачу переделать сайт. Сайт был простым и стандартным, как многие корпоративные сайты: разделы «Продукты», «Решения», «О компании», «Контакты». И на этом все. Я подумал, что все просто, надо брать исполнителя.
Ребята, которые делали сайт, предложили обойтись без формальностей и работать без ТЗ. Сразу же начались проблемы. Разработчики приняли задачу, сделали, вернулись и принесли не то... Я велел переделать.
Второй вариант был подходящим, и я понес его коллегам, но там меня ждало другое открытие: коллеги представляли корпоративный сайт совершенно иначе. Пришлось снова переделывать, ведь у каждого – свое видение.
Начался мой персональный ад
Сначала я много нервничал и даже кричал матом на коллег. Проект надо было сдать в августе, а был уже конец июля.
Следующими стали нервничать топ-менеджеры, все это было похоже на гражданскую войну: с одной стороны – разработчики, с другой – я, с третьей – коллеги, а с четвертой – топ-менеджмент. Мы потратили много нервов и денег: разработка трехкопеечного сайта стоила около 250 тысяч, но к концу разработки бюджет поднялся до 340.
Сайт, который должен быть готов с мая по август, в итоге разрабатывали до конца года. В начале следующего года я устал и уволился из компании, потом стал аналитиком-проектировщиком. Так начался мой карьерный путь.
А история была про то, что на любых проектах нельзя работать без ТЗ. Это прямой путь в ад, там теряются время, нервы, деньги, жизни, вселенные, города...
Следующими стали нервничать топ-менеджеры, все это было похоже на гражданскую войну: с одной стороны – разработчики, с другой – я, с третьей – коллеги, а с четвертой – топ-менеджмент. Мы потратили много нервов и денег: разработка трехкопеечного сайта стоила около 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. Дизайн лаконичный.
Составлена отделом аналитики и проектирования агентства 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. Дизайн лаконичный.
Версия продукта – стационарная и мобильная.
Доступ – осуществляется через Dial-up соединение, ADSL модем, FTTx, GPRS (мобильный) и WiMAX.
Назначение – многоцелевое.
Объекты
● Сайт рассчитан на 2 типа пользователей: статичные и движимые .
● Сайт должен содержать первичную базу статичных объектов с возможностью добавления.
● Движимые и недвижимые объекты имеют свои аккаунты на сайте разного типа.
● Количество аккаунтов для движимых объектов ограниченно 3-мя.
● Недвижимые объекты имеют только один аккаунт на сайте.
● Движимые объекты имеют несколько статусов одновременно, соответственно подвижные пользователи имеют возможность идентифицировать себя в нескольких местах одновременно.
● Движимые объекты имеют возможность пополнения списка недвижимых объектов на ограниченное время (это относится только к временным объектам), постоянные создаются только админом. Далее управление неподвижными аккаунтами может быть передано третьим лицам.
● База обоих типов пользователей многочисленна (от 100 до нескольких сотен миллионов).
Техническая информация
1. Хранение информации о пользователях осуществляется на отдельном удаленном сервере с возможностью архивации.
2. Пользовательские версии должны быть адаптированы под все виды мобильных телефонов (где предусмотрен доступ в интернет), планшетных устройств, стационарных компьютеров.
3. По будет использоваться в том числе в качестве приложения в таких системах, как PLAY MARKET, APPLE STORE И Т.Д.
4. Сайт мультиязычный.
5. Дизайн лаконичный.
© Rusbase
Алексей Бородкин