От автора: даже если вы сотню раз разрабатывали сайты и приложения, это не повод отказываться от составления технического задания. Видение исполнителя и заказчика может быть разным, несмотря на внешнее сходство выраженных мыслей. Каждый пункт должен быть оговорен, каждая деталь учтена.
Сегодня расскажем, как сделать не просто ТЗ на разработку web приложения, а настоящее оружие, которое можно использовать только на благо сторон. Это основная позиция, которая позволит защитить свои интересы и создать по-настоящему хороший проект. Вы узнаете, почему недооценка или игнорирование ТЗ может привести к краху всей проделанной работы.
Что такое правильное ТЗ
Термин «техническое задание» стал по-настоящему популярным в эпоху интернета. ТЗ составляется для дизайнеров, программистов, копирайтеров и других специалистов, которые будут что-то создавать. Но, на самом деле, такая практика была характерна для всех креативных профессий. Художник-профессионал не надеется на то, что его картина понравится заказчику: он просит составить четкое задание и следует ему в процессе выполнения. Таким образом он сможет защитить свой труд в случае, если будут предъявлены претензии.
Техническое задание — это документ, в котором перечислены не только основные характеристики будущего объекта (предназначение, внешний вид, качество прочее), но и другие, не менее важные, моменты: способ, срок выполнения, способ и порядок оплаты. Кстати, на слове «документ» не зря сделан акцент: он, как и договор между заказчиком и исполнителем, имеет юридическую силу.
Если одна из сторон нарушит принципы выполнения, зафиксированные в техническом задании, у заявителя будут основания для удовлетворения его требований. ТЗ нельзя дополнять, упрощать, вносить любые правки без согласия сторон, если оно уже принято к исполнению. Как только договор заключен, техническое задание становится основной «картой» веб-разработки.
Многих наверняка отпугнули слова о заключении договора — мол, в среде Интернет-заказов, а особенно во фрилансе, такая практика, как подписание документов не распространена. Это неудобно, долго и требует дополнительных расходов материальных ресурсов. Но правда в том, что заключить договор можно не только на бумаге: принимая акцепт на фриланс-бирже, вы тоже заключаете договор, с юридической точки зрения.
В сфере веб-разработки принято рассматривать техническое задание с точки зрения формулы «вопрос-ответ». Это значит, что ТЗ всегда идет в первую очередь, перед тем как будет выполнена любая другая работа. Новички, приняв на веру концепцию о том, что клиент всегда прав, начинают рисовать скетчи, предлагать варианты, выполнять прочую работу, которая должна следовать за техническим заданием.
Но правда в том, что большинство клиентов обращаются к дизайнерам и программистам, не понимая полной картины. Более того, сначала у них может быть одно видение, потом кто-то посоветует «небольшие» улучшения, и вот — специалист работает сверхурочно и бесплатно, ведь клиент всегда прав. Потому нужно сначала составить задание, а уже после предлагать определенные решения, рисовать макеты и прочие примеры работы.
С другой стороны, техническое задание — это рычаг давления на исполнителя. В случае, если для отказа от оплаты труда будут объективные причины (разработка не соответствует требованиям эксплуатации, масштабируемости, адаптивности и т.д.), заказчик сможет требовать исправлений и дополнений. И при этом он сможет получить результат в пределах той суммы, которая оговорена в техническом задании.
С командой или в одиночку
Большинство начинающих разработчиков, узнав о том, что работать без технического задания нельзя, требуют его от заказчика. И что самое интересное, получают его. Но, как мы и говорили выше, заказчик не всегда прав потому, что зачастую некомпетентен. Он не знает, как создается веб-приложение. Прочитав несколько статей в интернете, он принимается за составление формального ТЗ, которое не отражает ни реальных требований к проекту, ни фактического рабочего процесса. Результат может быть еще более плачевным, чем при полном отсутствии технического задания.
Вы, как заказчик, можете создать техническое задание самостоятельно. Это актуально в таких случаях:
относительно простой проект. Если нужно создавать не динамическое веб-приложение, а обычный лендинг с основной информацией о продукте/услуге, можно обойтись самостоятельным составлением технического задания на основе аналогичного ТЗ, которое можно найти в Интернете;
вы сами опытный разработчик. Здесь комментарии излишни. Если вы настоящий full-stack, то составить задание для другого разработчика не составит труда. Вы можете разграничить обязанности, установить разумные сроки и прочие моменты;
вы готовы согласиться на все условия исполнителя. Конечно, если прописать строку, что любой не обусловленный момент решается на усмотрение разработчика, тогда и задание лучше составить одному.
Во всех остальных случаях нет лучшего решения, чем создать техническое задание вместе с командой других разработчиков. Причем, нужно учитывать специализацию каждого из них и опыт работы. Например, бэк-энд разработчик может внести эффективные правки в создание серверной стороны веб-приложения, значительно ускорив его работу впоследствии. А опытный дизайнер сможет уточнить оформление, чтобы дать исполнителю четкое понимание принципов, согласно которым внешний вид приложения будет сконструирован.
Да, собирать целую команду лишь для составления технического задания довольно затратно. Сумма, которую вы заплатите за такое задание, мало чем будет отличаться от создания целого приложения такой большой командой. Потому некоторые IT-компании зарабатывают на создании заданий. Они имеют постоянный доступ к реальным решениям, а потому технические задания они разрабатывают быстро и легко. Такое решение однозначно хорошо для кейса, когда вы сами не очень хорошо разбираетесь в веб-разработке и выбираете не высокооплачиваемого специалиста для своего проекта.
Но оптимальным вариантом для обеих сторон будет составление технического задания сообща. Исполнитель и разработчик быстрее начнут продуктивные действия, если вместе начертят план работ и основные эскизы. Таким образом, вы будете знать, какие технологические возможности доступны данному разработчику. Техническое задание будет адаптировано к специалисту и удовлетворит требования заказчика.
Этапы и ресурсы
Для того чтобы создать качественное техническое задание, нужно придерживаться определённых принципов и требований. Одним из них является следование этапам разработки ТЗ, которые приняты для работы над веб-приложением. О них ниже!
Идеология
Перед тем как размещать заказ на бирже, человек должен понять, с какой целью он создает продукт. Этот этап называют идеологическим, и он полностью лежит на плечах заказчика. Исполнитель не знает, сможет ли проект принести прибыль, заинтересует ли он общество. Он может создать все инструменты для этой цели. Лишь один момент: исполнитель должен четко понимать цель.
Не менее важным элементом идеологического этапа является и определение целевой аудитории. К примеру, если проект нацелен на молодую аудиторию (школьники, студенты), то дизайн и интерактивное взаимодействие с веб-приложением должно быть соответствующим. Не менее важно определение девайсов целевой аудитории. Если приложение рассчитано на отображение с мобильного устройства, возможно, стоит задуматься о создании «натива» или «прогрессива».
Прежде всего, разработчику необходимо понимать, какие общественные проблемы решает данное приложение. Имея в распоряжении подобную информацию, программист сможет применять технические инструменты, которые справятся с задачей лучше всего. К примеру, если оно рассчитано на предоставление информации о погоде в каждом уголке планеты, нужно будет придумать высокопроизводительную программу, которая будет собирать и анализировать большие массивы информации.
Приложение выполняет функции
Очень тесно переплетенный с предыдущим пунктом, но более детализированный этап. Возьмем то же приложение о погоде: пока не знаем, как именно хотим отображать информацию. Но теперь в техническом задании можно указать, что данное приложение будет демонстрировать погодные условия при определении геолокации, как и большинство современных виджетов. Это значит, что под программу нужно подвязать определение местоположения и анализ информации с нескольких метео-источников.
На этом этапе технического задания также нужно обусловить курс развития программы. Без постоянного обновления функционала, веб-приложение начинает терять аудиторию. Определить первые несколько апдейтов — обязательный пункт для динамического сайта. В противном случае, у заказчика появится проблема уже через несколько недель после полноценного запуска.
Все придумано до вас
Забавной тенденцией среди заказчиков является то, что они склонны скрывать источники своей идеи. Как правило, продукт, подобный тому, который предстоит разработать, уже существует. И точно нет смысла скрывать это. В мире веб-разработок плагиат (в разумных пределах) — не порок. А вот выдумка велосипеда — порок. Это доказал опыт успешной деятельности сайта ВКонтакте (идея была скопирована с американского Facebook).
На этапе определения аналогии важно найти продукт, который выполняет похожую функцию. Желательно, чтобы он был достаточно успешным. Ведь копировать то, что не получилось — скверная идея.
Нужное и ненужное
Наконец, пришли к тому, как должно выглядеть техническое задание. Но, к сожалению, представить универсальный шаблон не получится. Тенденции развития мира веб-разработки не позволяют сказать, какой формат ТЗ будет наиболее адекватным. Вместо этого можно оформить некоторые принципы, которые значительно ускорят создание приложения.
Во-первых, в техническом задании не должно быть двойных истин. Если есть требование «фон сайта белый, ближе к бежевому», значит, будьте готовы переделывать несколько раз. Вместо этого, в техническом задании должны быть четкие слова и цифры. К примеру, «фон сайта #FFFFF3». Вообще, чем более детализировано техническое задание, тем лучше для обеих сторон. Особенно это касается сложных проектов.
Но одной только детализации мало для качественного технического задания. Большую роль играет и разделение труда. К примеру, над приложением трудятся программист и дизайнер. Это значит, что их роли не должны накладываться друг на друга. Кодер не должен думать о том, насколько хорошо выделен или подсвечен объект. Он разместит его на сайте в указанных пропорциях и задаст функциональность, если это необходимо. Эстетический вид — это к дизайнеру. Только он должен выполнять подобную работу.
Задание не должно содержать оценочных понятий. Сюда относятся «красиво», «оригинально», «приятно для глаза», «нравится посетителям приложения». Как только разработчик соглашается с таким техническим заданием, он обрекает себя на бесплатный рабский труд. Конечно, возможно везение. Но, как правило, оно не приходит к тем, кто на него надеется.
Теперь лайфхак для разработчика: в конце технического задания должна стоять фраза о том, что все моменты, которые не оговорены в документе, должны выполняться на усмотрение разработчика. Да, звучит немного императивно, но в этом вся суть создания приложения на заказ. Если заказчик не доверяет вашему профессионализму, так пусть просто укажет необходимый элемент задания или найдет другого исполнителя.
«А может, без ТЗ»: ад без обратного пути
Это самое нелепое решение, которое может принять профессионал. Потому опытные веб-разработчики никогда не согласятся создавать даже самое простое приложение без детального технического задания. Таким образом, у каждой стороны правоотношений полностью развязаны руки. Но платит заказчик, и потому в проигрыше останется разработчик.
Плачевная ситуация ожидает и заказчика. Он требует изменения не потому что плохой, а потому, что приложение не отвечает его требованиям. Он чувствует себя обманутым, ведь оплатил работу и ждет продукт.
Самое негативное в подобном порядке вещей то, что, если вы приступили к работе в формате без ТЗ, то очень трудно начать все сначала. Единственное решение — составить новый договор и техническое задание. Однако потраченное время и средства уже никто не вернет. Потому выделите день или два на составление детального технического задания, и ваши шансы достичь успеха значительно возрастут.
На этом у нас все о ТЗ для веб-приложений. Составляйте их детально и не ленитесь, ведь от этого зависит ваше процветание в индустрии веба!
