Что это за страшное слово ТЗ и как сделать оптимальное ТЗ?

Это страшное слово ТЗ

Это страшное слово ТЗ

Техническое задание – понятие сильно растяжимое. Кто-то им называет описание работы приложения на 1-2 страницы формата A4, кто-то обходится скринфлоу, а кто-то предпочитает писать полноценную документацию. Мы же, разработав более 80 проектов за 5 лет работы компании, пришли к следующей схеме написания ТЗ:

— концепция проекта;
— интерфейсы клиентской части;
— ТЗ по клиентской части;
— интерфейсы по серверной части (если проект предполагает наличие таковой);
— ТЗ по серверной части.

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

Концепция
Здесь мы говорим о назначении приложения, приложениях-аналогах, поддерживаемых платформах, доступном функционале админки и прочих вещах, которые, по сути, являются обобщением входных требований и пожеланий от заказчика. Занимает этот раздел в зависимости от объема проекта от 3 до 10 страниц и от 2 до 5 дней работы технического писателя-аналитика.

Интерфейсы клиентской части
Интерфейсы клиентской части — это схематичные прототипы будущих экранов приложения без вмешательства дизайнера. Если, конечно, не говорить о взаимодействии дизайнера и технического писателя в процессе отрисовки прототипов на тему соблюдения гайдов, каких-то креативных идей и т.д. В нашей компании мы приняли за правило проектировать и согласовывать с заказчиком сначала какие-то основные экраны, на которых держится вся логика, и только после этого уходить в детальную проработку. На проработку всех экранов клиент-серверного приложения средней сложности мы затрачиваем от 10 до 20 дней.
В том случае, когда заказчику сложно представить себе работу приложения, смотря только на статичные картинки, в ход идут интерактивные прототипы. Это кликабельные экраны формата html.

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

ТЗ на клиентскую и серверную части
А вот здесь начинается самое интересное. В самом тексте ТЗ мы описываем всю логику действий, которые могут быть совершены в приложении. Практика показывает, что необходимо учесть все возможные варианты реакции приложения на то или иное действие пользователя. Зачем, если многие вопросы можно решить по ходу разработки? Да, когда-то и мы так думали. Но, во-первых, стоимость человеко-часа тех. писателя/юзабилиста меньше, чем разработчика, которому придется переделывать и пересогласовывать элементы приложения, так сказать, «на ходу». Во-вторых, сроки разработки значительно затягиваются в случае, если картина работы приложения представлена не полно. В-третьих, дизайнеру проще и эффективнее сразу представлять себе все экраны приложения и предоставить все материалы по ним, чем в какой-то момент понять, что чего-то не хватает, и снова возвращаться к задаче.
Важно отметить, что представленная схема работы имеет смысл в двух случаях: фиксированной цены за разработку и/или первого релиза приложения, содержащего в себе довольной большой объем функционала. В случае, когда заказчик принимает и доверяет нам работу по T&M (оплаты по фактически отработанным часам за определенный промежуток времени), как правило, ТЗ либо сильно сокращается, либо представляется только в виде прототипов. Здесь у заказчика есть полная свобода вносить любые изменения по ходу разработки проекта. Обычно этот формат работы используется в креативных проектах, концепцию которых до начала работ сложно продумать полностью.
Нам известно, что многие компании-разработчики нашего сегмента заключают один договор, где написание ТЗ является одним из этапов разработки. Но обратите внимание: сумма по договору уже зафиксирована. И, соответственно, исполнитель будет писать ТЗ не на тот продукт, который реально нужен заказчику, а на тот, по которому он как исполнитель уложится в согласованный бюджет. Наш опыт показывает, что на этапе ТЗ из предполагаемого небольшого проекта с парой-тройкой экранов иногда вырастает огромный портал, на разработку которого требуется, естественно, гораздо больший бюджет и срок, чем предполагалось ранее. По этой причине мы всегда открыто говорим о том, что та сумма, которую мы называем заказчику до начала работ по ТЗ, является предварительной и может быть изменена после его написания.

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

Раздел «Расписание». Результатом его работы должно стать рассчитанное кол-во таблеток для приема. На основе него пользователь получает напоминания о необходимости приема того или иного лекарства.

Исходные данные для ввода:
— длительность курса
— дозировка приема препарата в граммах в день, назначаемая врачом
— количество приемов препарата в день в данной дозировке
— дозировка, указанная на упаковке или «часть» таблетки (половина, четверть), которую составляет эта дозировка
Получаемые данные: количество таблеток и частота их приема в день

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