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

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

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

Расскажите друзьям
Полина Константинова

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

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

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

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

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

  1. вы даете исполнителю краткий перечень функций, экранов и других особенностей приложения;

  2. он делает предварительный расчет и называет примерные сроки и стоимость работ, опираясь на эту информацию;

  3. когда есть понимание вилки цены и сроков, происходит переход к этапу написания ТЗ;

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

  5. как только техническое задание будет написано и утверждено, вы, наконец, получите точную стоимость и сроки разработки приложения.


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


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

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

Фото: Unsplash

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

  • внимательны ли они к деталям,

  • быстро ли реагируют на сообщения,

  • адекватно ли воспринимают критику.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Шеринг материалов. Если в приложении можно делиться товаром или статьей, убедитесь, что в ТЗ описана веб-страница, на которую будет вести ссылка шеринга.

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

  • Различные формы доступа. Убедитесь, что по ТЗ неавторизованный пользователь не может ошибочно попасть на экран для авторизованного.

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

  • Аналитика. Если вы хотите знать, сколько времени пользователи проводят в приложении, на какие экраны они попадают чаще и какие кнопки нажимают, это стоит отдельно прописать в техническом задании. По умолчанию такие данные нигде не учитываются.

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


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

В нашем Instagram @rusbase сегодня есть на что посмотреть! Подписаться

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

‡агрузка...

Комментарии

  • Robert Vasilyev
    Robert Vasilyev 12:02, 2.04.2019
    1
    • Daria Bondarenko Daria Bondarenko
    Где найти ссылку на программу?
  • Dima Sokolov
    Robert Vasilyev Dima Sokolov 15:15, 2.04.2019
    1
    • Daria Bondarenko Daria Bondarenko
    Роберт, на данный момент это внутренний инструмент, который мы используем внутри компании. В этом году планируем выпустить новую публично доступную версию
  • Dmitriy Podluzny
    Dmitriy Podluzny 14:04, 4.04.2019
    0
    Читайте "Разработка требований к программному обеспечению" Карла Вигерса и будет вам счастье.
  • Aleksandr Bogachev
    Aleksandr Bogachev 00:22, 5.04.2019
    1
    • Dima Sokolov Dima Sokolov
    Любопытный подход, но неужели в процессе работы клиенту не хочется что-то поменять? Вот прям сели и запроектировали до каждой кнопки всё сразу же?
  • Dima Sokolov
    Aleksandr Bogachev Dima Sokolov 14:39, 8.04.2019
    0
    На 100% от желаний что-то поменять во время разработки это не спасает. Но это помогает предотвратить большинство серьезных изменений. После такого подробного обсуждения обычно возникают уже незначительные коррективы по положению элементов, шрифтам и прочим небольшим деталям. Если все же возникает желание сделать какие-то более серьезные изменения, то и у подрядчика, и у заказчика есть четкое понимание, что обсуждаемые изменения выходят за рамки и рассматриваются как доп. работы: влияют на общий срок и бюджет. Без столь подробно проработанного ТЗ такой вопрос не всегда решается очевидным образом.
Зарегистрируйтесь, чтобы оставлять комментарии и получить доступ к Pipeline — социальной сети, соединяющей стартапы и инвесторов.
Санкт-Петербургская интернет-конференция СПИК
30 мая 2019
Ещё события


Telegram канал @rusbase