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

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

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

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

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

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

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

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

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

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

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

Составить грамотную инструкцию — это большое и очень ценное в нашей компании умение. Мы разделяем процесс разработки на составные части:

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

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

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

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

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

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

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

Примеры

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

Идеального шаблона для технического задания не существует!
Но повод ли расстраиваться? 🤔

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

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

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

2. Все роли распределены

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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