Как ускорить разработку проекта на несколько месяцев за счет качественного техзадания

Зачем тратить время на ТЗ

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

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

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

Почему разработка ТЗ стоит денег

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

За время написания ТЗ можно проверить, насколько комфортно работать с выбранной командой:

• внимательны ли они к деталям,
• быстро ли реагируют на сообщения,
• адекватно ли воспринимают критику.

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

Если же подрядчик сообщает вам, что разработка ТЗ бесплатна, не воспринимайте это буквально — стоимость ТЗ «размазана» по общей стоимости проекта. В таком случае будет достаточно сложно сменить исполнителя.

Кто должен составлять ТЗ — заказчик или исполнитель

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

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

Как согласовать ТЗ быстро и качественно

Один из самых распространенных подходов к утверждению и обсуждению ТЗ — пересылка друг другу документа с правками или совместная работа над документом в Google Docs.

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

Мы под эту задачу написали программу Voodoo.

Принцип ее работы такой: ТЗ разбивается на отдельные экраны, к каждому составляется схема и описание. Под экраном — лента обсуждения из комментариев заказчика и ответов исполнителя.

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

Как распознать качественное ТЗ

• С первых страниц понятно, какую функцию выполняет приложение

Попросите постороннего человека прочитать ТЗ и описать приложение в общих чертах. У него это должно легко получиться.

• Перечислены поддерживаемые устройства и операционные системы

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

• Детально описаны все экраны и кнопки

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

• К каждому экрану нарисована схема

Она поможет представить, как экран будет выглядеть в готовом продукте и станет основой для дальнейшей разработки дизайна.

• Не используются отсылки к сторонним продуктам при описании функций

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

• Прописано поведение приложения для нестандартных ситуаций

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

На что стоит обратить внимание в ТЗ

• Контрольная панель. Она нужна, чтобы управлять пользователями и контентом в приложении. Если не предусмотреть в ней все необходимые действия, то вам придется постоянно обращаться к разработчику за помощью.
• Система оплаты. Если вы используете систему оплаты, зафиксируйте в ТЗ, какой провайдер платежей используется, как происходит процесс оплаты, что произойдет в случае неуспешного платежа. Убедитесь, что провайдер работает в вашей стране и предоставляет необходимые тарифы.
• Загрузка фото. Стандартные системные функции подразумевают выбор фотографии или ее получение с камеры. Если вам нужно ручное кадрирование аватарки пользователя, фильтры или другие способы обработки — скажите об этом отдельно.
• Шеринг материалов. Если в приложении можно делиться товаром или статьей, убедитесь, что в ТЗ описана веб-страница, на которую будет вести ссылка шеринга.
• Геолокация. Если для работы приложения нужна геолокация, укажите в ТЗ, что произойдет, когда пользователь не даст разрешение на использование геоданных.
• Различные формы доступа. Убедитесь, что по ТЗ неавторизованный пользователь не может ошибочно попасть на экран для авторизованного.
• Жизненный цикл. Если в приложении предусмотрены разные статусы объектов, проверьте описание переходов между ними. Например, заказы в интернет-магазине отмечаются как «получен», «обрабатывается», «на доставке», «отменен», «доставлен». При ошибке в переходе между этими статусами возникнет проблема со своевременной доставкой, а следом — недовольные клиенты и потеря денег.
• Аналитика. Если вы хотите знать, сколько времени пользователи проводят в приложении, на какие экраны они попадают чаще и какие кнопки нажимают, это стоит отдельно прописать в техническом задании. По умолчанию такие данные нигде не учитываются.

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