Как написать техническое задание на разработку — личный опыт

Автор: Роман Чернышов Опубликовано: 27 февраля 2019

Доброго времени друзья! Сегодня я хочу поговорить о том, как написать техническое задание на разработку сайта, программного обеспечения или любого другого веб-проекта, и обратить ваше внимание на несколько основных моментов, которые следуют при этом учесть. Более того, так как в большинстве случаев, принципы написания технического задания, одинаковы, как для IT сферы, так и для любой другой — я думаю описанные мною правила, буду полезны также специалистом из других областей. Я решил поделиться ими, потому что ко мне часто обращаются люди с просьбами оценить стоимость работы или с предложением о сотрудничестве, ограничиваясь при этом, кратким описанием сути проекта или вовсе ссылкой на какой либо сайт, со словами: — «хотим такой же». Разумеется с такими исходными данными, произвести оценку, а уж тем более осуществить проект, не представляется возможным. Для этого нужно техническое задание(сокращенно — ТЗ), хотя бы его первичный, черновой набросок. Как его написать, читайте далее.

Что стоит учесть

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

1. Укажите цель проекта

Вначале документа, опишите цель проекта, это то, чего вы хотите достичь, а также для кого создается проект и кто им будет пользоваться. Расскажите о проекте, но не вдавайтесь в его технические детали, их вы сможете перечислить потом. Описание цели проекта служит для того, что бы любой человек, который впервые знакомиться с техническим заданием, смог сразу понять его суть и суть проекта. Описание цели проекта, должно отвечать на следующие вопросы: Какую проблему решать проект? Какой результат должен быть достигнут?

2. Разбейте на этапы и пункты

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

3. Сначала важное, потом все остальное

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

4. Дополнительные материалы разместите отдельно

Если техническое задание требует наличие дополнительных, поясняющих материалов(изображения, видео, прочие документы), то лучше их вынести в отдельную папку. Не стоит включать в тело документа технического задания множество изображений, они будут лишь отвлекать от основной сути, лучше просто сослаться на них, указав названия их файлов. Гораздо удобнее если дополнительные материалы, находятся в отдельной папке и имеют название файлов, кратко описывающих их содержимое.

5. Укажите срок и бюджет

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

6. Прочие характеристики проекта

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

Чего стоит избегать

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

1. Не пишите много и не по делу

Краткость сестра таланта. Часто в ТЗ можно встретить описание каких-то процессов не относящихся к задаче, например размышления о будущих перспективах проекта или упоминание о каком-то прежнем опыте заказчика, что не имеет прямого отношения к задаче. Более того, зачастую исполнителю многое знать и не нужно, достаточно лишь четкого описания задачи, без лишней философии. Большой текст сложно читать, из него сложно выделить основную суть. А если задача не простая, возможно текст придется перечитывать несколько раз, то его размер и наличие «воды», могут стать большой проблемой, вплоть до срыва всей работы.

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

2. Не ограничивайтесь ссылками и картинками

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

Ссылки со словами «нужно также», недостаточно.

3. Не переделывайте 100 раз

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

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

4. Не работайте над ТЗ всем коллективом

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

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

5. Не используете абстракции

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

Абстрактные критерии не позволяют оценить работу объективно.

Заключение

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

Если же с написанием ТЗ возникнут сложности, то буду рад помочь вам составить его. Обращайтесь!

Заказать работу >>