ТЗ: разбираем сущность и важность технического задания

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

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

Качество контента этого документа напрямую влияет на эффективность разработки. Чем детальнее и понятнее описаны все аспекты проекта, тем быстрее и с меньшими затратами его можно реализовать.

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

Роль технического задания на разработку сайта или приложения

Бизнесмены хвастаются умением объяснять работу на пальцах, но с техническим заданием так нельзя. В процесс вовлечены специалисты: дизайнеры, программисты, копирайтеры. Все они должны понимать свою задачу, читая документ. Он на всех один, для каждого писать затратно.

Если учесть, что читать будут клиент и команда, техническое задание - настольное руководство для обеих сторон. Просто каждая видит в нем необходимое для себя. Мы начинаем писать техническое задание сразу после знакомства. Чем раньше вы увидите, какой должна быть работа, тем быстрее и эффективнее ее удастся выполнить.

Дружеское напоминание!

Не надейтесь, что поняли друг друга 🙃 

В большинстве случаев это не так. Разработчики могут сколько угодно рассказывать бизнесмену о важности фреймворка, интуитивности интерфейса и лаконичности кода, но он поймет не более 30%. На слух такая информация воспринимается очень сложно. Поэтому мы в доступной форме расписываем этот документ.

Типы ТЗ для разработчиков и кто их пишет?

ТЗ бывают разными:

1. Формальное ТЗ. Детальное, со схемами, диаграммами и спецификациями. Подходит для серьезных проектов, где все должно быть четко прописано.
2. Неофициальное ТЗ. В стиле «Ну ты же понимаешь, что я хочу», что часто приводит к катастрофическим последствиям.
3. Агильное ТЗ. Краткие описания задач, которые уточняются в процессе разработки.

Кто занимается разработкой технического задания? Зависит от команды. Часто это менеджеры, аналитики или даже сам заказчик (если очень хочет).

Нам несложно уделить этому пару рабочих дней, но в результате мы получим не просто перечень пунктов задачи, но и путеводитель. В нем указаны ключевые исполнители – люди, которые занимаются вашим проектом. Вы можете поддерживать связь, просить держать в курсе проекта. Мы не против такой коммуникации между клиентом и нашими ребятами.

Как правильно писать технические задания? Не рекомендуем подробно расписывать все умения коллег. Клиент скрыто понимает, что если на его уважаемый проект поставили человека, он профессионал по умолчанию. Не заставляйте его в этом усомниться.

Расписываем, сколько часов у нас уйдет на написание вашей программы. Деловой человек должен контролировать свое время на всех уровнях занятости. Мы помогаем ему в этом и указываем ориентировочные сроки.

Важно! Приложение отнимает немало времени до тех пор, пока его доведут до состояния совершенства. Иногда тестирование может потребовать дополнительного времени, вам не стоит переживать об этом. Мы не заставим переплачивать за эти часы, ведь всегда учитываем форс-мажорные обстоятельства, когда речь идет о составлении плана.

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

Обсудить цели проекта

Чтобы разработка не превратилась в хаос, нужно четко определить цели:

1. Что мы создаем (интернет-магазин, приложение, CRM-систему, или только прототип?);
2. Кто этим будет пользоваться (клиенты, менеджеры, администраторы?);
3. Какую проблему это решает (упрощает покупки, автоматизирует процессы?).

Без четких целей разработка будет напоминать игру «Собери пазл без картинки».

Описание функционала

Описание функционала – это перечень возможностей, которые должна реализовать команда. Например:

1. Регистрация пользователей. Через email, соцсети или магию.
2. Корзина. Пользователи добавляют товары, не забывают об их расположении через минуту.
3. Фильтры. Потому что никто не хочет листать 1000 страниц товаров.

Главное - конкретика. Фраза «Сделать удобно» – не вариант. Лучше «Кнопка должна быть красной и выводить оповещение при нажатии».

Технологические требования к ТЗ

В техническом задании для программиста важно определить:

• совместимость с устройствами (будет ли это работать на тостере?);
• безопасность (насколько легко взломать систему?);
• производительность и скорость загрузки страниц (чтобы не висло при 1000 пользователях одновременно).

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

Требования к дизайну

Здесь важно:

• цвета, шрифты, кнопки – чтобы выглядело красиво и удобно для каждой страницы;
• логика навигации – чтобы не надо было гуглить «Как пользоваться вашим сайтом»;
• адаптивность – чтобы не выглядело ужасно на мобильных.

Если функционал -–это тело, тогда дизайн – это одежда и макияж.

Сроки и бюджет

Хорошее техническое задание на разработку сайта или приложения четко определяет:

• когда что должно быть готово;
• сколько это стоит;
• какие этапы контроля.

Это три вещи, которые всегда обсуждают, но редко придерживаются.

Мы разделяем процесс разработки на составляющие:

• идеологический;
• маркетинговый;
• механический;
• примеры.

Составить грамотную инструкцию – это большое и очень ценное в нашей компании умение.

Идеологическая часть

Команда должна с первого взгляда понять, какая работа их ждет. Если это редизайн сайта, воздержитесь от формулировок «Приведение сайта компании к новому уникальному оформлению». Сокращайте в местах, где лучше сохранить лаконичность. С другой стороны, объясняйте клиенту сложные моменты. Например, если речь о функциях фреймворка, объясните их простыми словами и добавьте, что их использование принесет клиенту. Проявляйте заботу и терпение.

Маркетинговая часть

Начинается с кабинетных исследований, продолжается в полевых условиях, а заканчивается снова в кабинете. Мы проверяем рынок, чтобы понять, в каких условиях будет работать ваше приложение. Нужно ли добавить продвинутые функции, которые есть у конкурентов? Правильный ли слоган мы выбрали для коммуникации? Готова ли к продукту целевая аудитория? Готова ли SEO-стратегия? Ответы на эти вопросы стоят очень дорого. От них зависит успешность разработки.

Механическая часть

Мы определились с целями и теперь хотим понять, как делать продукт. На собрании обсуждаем особенности, механизмы и технологии, которые подойдут лучше всего. Уже на этой стадии мы узнаем о структуре приложения, насколько информативным делать интерфейс и как масштабировать продукт в недалеком будущем. Последний пункт заслуживает особого внимания, поэтому описание роста лучше сопровождать диаграммой с наглядной статистикой.

Примеры

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

Идеального шаблона для технического задания нет!

Но есть ли повод из-за этого расстраиваться? 🤔

Каждое техническое задание для сайта или приложения уникально и должно освещать конкретные аспекты работы и бизнеса клиента. Необходимо объяснять, почему стоит делать именно так, а не иначе. Руководствуйтесь тремя принципами, создавая приложение.

1. Не избегайте конкретики

Клиенту и исполнителю стоит избегать расплывчатых формулировок вроде: «Красивый шрифт с вензелями». Скажите сразу Helvetica 18pt. Никаких вопросов не возникнет. При удаленной работе возникают трудности с выбором цвета. Описать цвет сложно, а в параметрах RGB клиент не разбирается. Лучше провести разговор через средства видеосвязи и поделиться своим экраном.

2. Все роли распределены между исполнителями

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

3. Говорите фактами, а не оцениванием

В словах «красиво», «полезно» и «эффективно» силы ровно столько, сколько в белом шуме телевизора. Клиент должен собственными глазами видеть все, о чем идет речь. Не поленитесь внести дополнительную инфографику. В этом формате удобно представлять цифры проекта: его бюджет, часы работ и т.д.

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

✅: Командная работа. Ответственные исполнители помогают распределить время и вносят в план детали, известные только им. Например, программист может заметить, что на тестирование в связи со сложностью предстоящих работ выделено недостаточно времени. Дизайнер увидит несовместимость шрифтов, выбранных клиентом, и маркетинговой задачи.

❌: Уверяем клиента, что работа будет технически совершенной. Кроме громких слов, доказательства не приводим.

✅: Показываем примеры работ и фото/видеодемонстрации любого описываемого технического параметра. Как иначе клиент поймет, что ему предлагают? Запомните, заказчики не имеют степени в компьютерных технологиях и программировании.

❌: Отказываемся от проведения исследования. Доверяем при разработке интуиции, ведь она никогда не подводила.

✅: Ставим на осведомленность. Незачем стрелять вслепую! Узнаем, что нужно рынку и будущим клиентам, а после вносим сведения в документ.

Любителей не сделать ТС много. Это не только коллеги в Украине, мы сталкивались с необязательностью также за рубежом.

Осуждаем такой подход!

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

Почему нет понимания?

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

Не будьте лентяями, амигос! 

Пишите техническое задание просто и понятно, не опуская деталей и заботясь о клиенте. Это отношение вернется к вам двойным бумерангом благодарности.

Ваши Brander.ua!