Колонки

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

Колонки
Дмитрий Соколов
Дмитрий Соколов

Сооснователь IT-студии Alef Development

Полина Константинова

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

Дмитрий Соколов, сооснователь IT-студии Alef Development, рассказывает, зачем тратить время на составление техзадания и как распознать качественное ТЗ. Примеры в статье будут связаны с разработкой мобильного приложения, но советы применимы к техническому заданию на любой программный продукт, будь то сайт или уникальная CRM, сделанная под ваши нужды.

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

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

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

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

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

Все, что прописано в ТЗ, считается истиной при любом возникшем споре. Проверьте техническое задание до мелочей, потому что в ответственный момент фраза «Мы ведь это обсудили! Ну и что, что в ТЗ забыли внести...» не сработает.


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

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

Фото: Unsplash

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

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

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

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

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

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

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

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

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

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

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

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

Скриншот программы

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

Скриншот программы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Материалы по теме:

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Актуальные материалы —
в Telegram-канале @Rusbase