Читать «Мобильное приложение как инструмент бизнеса» онлайн - страница 90

Вячеслав Семенчук

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

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

Есть заказчики, требующие создать вначале договор с прикрепленным к нему ТЗ, а затем говорящими: «Только тогда мы подумаем над тем, заказывать ли у вас». Дескать, иначе они не смогут понять уровень профессионализма разработчика или сразу хотят увидеть, что он способен предложить. Частично это правда, и по ТЗ действительно можно судить о разработчике, но ТЗ не создается на коленке за несколько часов. Это сложная работа, требующая участия многих специалистов и отнимающая много времени. Разработка ТЗ должна оплачиваться, иначе оно не будет качественным. При заказе и составления ТЗ, и разработки мобильного приложения стоимость составления ТЗ будет ниже, чем для тех, кто заказывает только одно ТЗ. Это связано с затратами времени специалистов: если они тратят его как на ТЗ, так и на производство приложения, то это окупается, в отличие от написания ТЗ без продолжения работы.

Государство позаботилось о правильности создания ТЗ, выпустив для этого соответствующие межгосударственные стандарты (ГОСТ, ОСТ). Вот только проблема в том, что они несколько устарели. Например, ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» был выпущен еще в 1989 г. Не советую использовать ГОСТ как основу для создания качественного ТЗ, хотя вы можете почерпнуть там что-то полезное.

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