правильное ТЗ — залог успеха

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

У человека, далёкого от мира программирования и IT, нередко складывается впечатление, что для примерной оценки будет достаточно описания, состоящего из пары фраз, или даже общей идеи в духе “диспетчер такси” или “новостное приложение под Android”. На самом деле это не так, и существует очень много вопросов и нюансов, которые надо прояснить, прежде чем можно будет назвать хотя бы приблизительную стоимость.

6cb6664332ab410c761aebf2aeb12579

Поясним на примере реальной заявки, полученной нами от заказчика:

Хотим создать приложение о нашем поселке, то есть создать историю. Материалы все есть.

Что же это может быть и какова примерная стоимость? Рассмотрим подробнее… Программа-минимум займёт 9 человеко-дней, причём сюда уже включены менеджмент и уточнение требований, багфиксинг, приёмка и гарантия. Это будет приложение под Android со статической вёрсткой, контент — текст, картинки и видео.

Как, и это всё?” — разочарованно тянет заказчик. — “А как же социальные сети? И чтобы комментарии можно было оставлять… Нет, так совсем простенько, на “создать историю” не тянет, уж извините.

Не вопрос, давайте добавим немного наворотов! Скажем:

  • авторизация в системе;
  • возможность добавлять и просматривать комментарии к новостям;
  • возможность добавить собственную новость: пользователь вводит текст и добавляет картинки, видео и аудио;
  • интеграция с социальными сетями Вконтакте, Одноклассники и Facebook. Можно поделиться новостью или достопримечательностью.

Итого уже 40-45 дней.

Вооот, так уже заметно лучше!” — радуется заказчик. — “Вот только это у всех есть, а я-то хочу особенное приложение. Ну знаете, что-нибудь такое крутое, технологичное!

Крутое и технологичное? Это мы умеем! Вот например:

  • Виртуальные экскурсии: дополненная реальность. По GPS и компасу определяется положение устройства в пространстве. На изображение с камеры добавляются метки “достопримечательностей”, нажимая на которые пользователь может посмотреть информацию о достопримечательности.
  • Описание достопримечательности с текстом, картинками, видео и аудио. Можно добавлять и просматривать комментарии.

Итого 60-65 дней.

Приложение явно становится интересным! Кстати, а что это мы только под андроид разрабатываем? Давайте добавим iOS! (Итого 120-130 дней…) Кстати, если нужна поддержка iPad, стоимость iOS-версии будет в 1,5 раза больше, а если нет API, надо заложить ещё 2-4 недели на его разработку.

Вместе с разработкой растут затраты на тестирование и менеджмент, увеличивается срок приёмки…

Итого вместо 9 человеко-дней мы имеем уже пару сотен. Согласитесь, это совсем другое дело!

C8kn2byc0vE

Прояснение требований и составление спецификации – отдельный этап жизни проекта, который может занимать не меньше, а иногда и больше времени, чем сама разработка. Хорошо, если у вас есть на это время. А если времени нет, релиз приложения планируется через два месяца, а оценка нужна буквально вчера? В таком случае выход один: попробовать составить ТЗ.

На самом деле, в этом нет ничего страшного: главное – взять листок бумаги и ручку (или открыть свой ноутбук) и изложить своими словами всё, что вы знаете о проекте. (Подсказка: результат обязательно должен быть больше одной страницы, другие случаи говорят о том, что вы забыли что-то важное!) Даже это сэкономит вам уйму времени. Вопреки распространённому заблуждению, вовсе не обязательно быть крутым техническим специалистом, чтобы написать хорошее ТЗ. На эту тему существует множество книг и статей, которые при желании несложно найти. Здесь же мы хотим напомнить несколько основных моментов.

atkritka_1354040443_363

 

Итак, если вы пишете ТЗ, обязательно осветите:

  • Цели проекта. В этой части желательно донести до исполнителя, за счет чего вы собираетесь извлекать прибыль или что конкретно заставит заказчика почувствовать удовлетворение от результатов проекта.
  • Список всех действующих лиц, которые будут взаимодействовать с системой.
  • Все функциональные требования: кто и как может использовать систему. Этот пункт идеально оформить в форме «вариантов использования» или «use-cases», отражающих, какие действия может совершать пользователь и каким должен быть их результат.
  • Все нефункциональные требования, например, нагрузка на систему, требования по безопасности или отказоустойчивости. Если речь идет о веб-приложении, то стоит перечислить браузеры, под которыми необходимо проводить тестирование, для мобильных приложений – список версий, на которых приложение должно работать.

Чем подробнее вы опишете всё перечисленное, тем меньше вероятность, что впоследствии возникнут “сюрпризы” или неучтённые пожелания, которые могут привести к серьёзным переделкам и задержкам релиза.

Как-правильно-составить-техническое-задание-на-создание-сайтов

Разумеется, то, о чём мы сейчас рассказали, — только верхушка айсберга. Составлению технического задания посвящено множество книг, и перечислить (даже кратко) всё, что было бы нужно знать, в рамках одной статьи просто невозможно. И тем не менее, мы надеемся, что наши советы и рекомендации пригодятся вам в будущем, и, возможно, станут вашим первым шагом к составлению собственного ТЗ!