Noveo

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

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

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

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

image

Поясним на примере реальной заявки, полученной нами от заказчика: «Хотим создать приложение о нашем поселке, то есть создать историю. Материалы все есть».

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

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

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

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

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

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

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

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

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

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

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

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

image

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

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

image

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

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

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

— Список всех действующих лиц, которые будут взаимодействовать с системой.

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

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

image

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

Оригинал: https://blog.noveogroup.com/ru/2015/09/how-to-write-specifications/

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

НазадПредыдущий пост ВпередСледующий пост

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: