Правильное ТЗ — залог успеха
В одном из недавних постов мы рассказывали о том, с какими интересными и порой забавными заявками пользователей нам приходилось сталкиваться. Юмор - это, конечно, хорошо, вот только он не всегда помогает в оценке и разработке приложения. Поэтому сегодня мы хотим рассказать о том, что поможет наверняка, - а именно о том, из чего складывается оценка приложения и как правильно составить техническое задание на разработку.
У человека, далёкого от мира программирования и IT, нередко складывается впечатление, что для примерной оценки будет достаточно описания, состоящего из пары фраз, или даже общей идеи в духе “диспетчер такси” или “новостное приложение под Android”. На самом деле это не так, и существует очень много вопросов и нюансов, которые надо прояснить, прежде чем можно будет назвать хотя бы приблизительную стоимостью
Поясним на примере реальной заявки, полученной нами от заказчика:
Хотим создать приложение о нашем поселке, то есть создать историю. Материалы все есть.
Что же это может быть и какова примерная стоимость? Рассмотрим подробнее... Программа-минимум займёт 9 человеко-дней, причём сюда уже включены менеджмент и уточнение требований, багфиксинг, приёмка и гарантия. Это будет приложение под Android со статической вёрсткой, контент - текст, картинки и видео.
“Как, и это всё?” - разочарованно тянет заказчик. - “А как же социальные сети? И чтобы комментарии можно было оставлять… Нет, так совсем простенько, на “создать историю” не тянет, уж извините.”
Не вопрос, давайте добавим немного наворотов! Скажем:
- авторизация в системе;
- возможность добавлять и просматривать комментарии к новостям;
- возможность добавить собственную новость: пользователь вводит текст и добавляет картинки, видео и аудио;
- интеграция с социальными сетями Вконтакте, Одноклассники и Facebook. Можно поделиться новостью или достопримечательностью.
Итого уже 40-45 дней.
“Вооот, так уже заметно лучше!” - радуется заказчик. - “Вот только это у всех есть, а я-то хочу особенное приложение. Ну знаете, что-нибудь такое крутое, технологичное!”
Крутое и технологичное? Это мы умеем! Вот например:
- Виртуальные экскурсии: дополненная реальность. По GPS и компасу определяется положение устройства в пространстве. На изображение с камеры добавляются метки “достопримечательностей”, нажимая на которые пользователь может посмотреть информацию о достопримечательности.
- Описание достопримечательности с текстом, картинками, видео и аудио. Можно добавлять и просматривать комментарии.
Итого 60-65 дней.
Приложение явно становится интересным! Кстати, а что это мы только под андроид разрабатываем? Давайте добавим iOS! (Итого 120-130 дней...) Кстати, если нужна поддержка iPad, стоимость iOS-версии будет в 1,5 раза больше, а если нет API, надо заложить ещё 2-4 недели на его разработку.
Вместе с разработкой растут затраты на тестирование и менеджмент, увеличивается срок приёмки...
Итого вместо 9 человеко-дней мы имеем уже пару сотен. Согласитесь, это совсем другое дело!
Прояснение требований и составление спецификации – отдельный этап жизни проекта, который может занимать не меньше, а иногда и больше времени, чем сама разработка. Хорошо, если у вас есть на это время. А если времени нет, релиз приложения планируется через два месяца, а оценка нужна буквально вчера? В таком случае выход один: попробовать составить ТЗ.
На самом деле, в этом нет ничего страшного: главное – взять листок бумаги и ручку (или открыть свой ноутбук) и изложить своими словами всё, что вы знаете о проекте. (Подсказка: результат обязательно должен быть больше одной страницы, другие случаи говорят о том, что вы забыли что-то важное!) Даже это сэкономит вам уйму времени. Вопреки распространённому заблуждению, вовсе не обязательно быть крутым техническим специалистом, чтобы написать хорошее ТЗ. На эту тему существует множество книг и статей, которые при желании несложно найти. Здесь же мы хотим напомнить несколько основных моментов.
Итак, если вы пишете ТЗ, обязательно осветите:
- Цели проекта. В этой части желательно донести до исполнителя, за счет чего вы собираетесь извлекать прибыль или что конкретно заставит заказчика почувствовать удовлетворение от результатов проекта.
- Список всех действующих лиц, которые будут взаимодействовать с системой.
- Все функциональные требования: кто и как может использовать систему. Этот пункт идеально оформить в форме «вариантов использования» или «use-cases», отражающих, какие действия может совершать пользователь и каким должен быть их результат.
- Все нефункциональные требования, например, нагрузка на систему, требования по безопасности или отказоустойчивости. Если речь идет о веб-приложении, то стоит перечислить браузеры, под которыми необходимо проводить тестирование, для мобильных приложений – список версий, на которых приложение должно работать.
Чем подробнее вы опишете всё перечисленное, тем меньше вероятность, что впоследствии возникнут “сюрпризы” или неучтённые пожелания, которые могут привести к серьёзным переделкам и задержкам релиза.
Разумеется, то, о чём мы сейчас рассказали, - только верхушка айсберга. Составлению технического задания посвящено множество книг, и перечислить (даже кратко) всё, что было бы нужно знать, в рамках одной статьи просто невозможно. И тем не менее, мы надеемся, что наши советы и рекомендации пригодятся вам в будущем, и, возможно, станут вашим первым шагом к составлению собственного ТЗ!
Оригинал: https://blog.noveogroup.com/ru/2015/09/how-to-writ...
