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

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

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

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

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

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

Наиболее типичные проблемы, к которым приводит его отсутствие или плохое качество.

Техническое задание как документ отсутствует полностью, задача описана только устно и нигде не зафиксирована

Если нет ясного описания того, что нужно делать, то многое из того, что было вами сказано, довольно быстро забудется. Это особенность человеческого мозга, который запоминает лишь 10% того, что человек слышал, и 30% того, что видел. Насколько существенные моменты останутся в памяти программиста, угадать трудно – он может знать о большой синей кнопке, но не сможет вспомнить, для чего она предназначалась. Вы сами тоже многое забудете, и завтра кнопка уже окажется зеленой. А призвать к ответственности будет некого и не за что – мысли в голове пока не являются сильным аргументом, например, при судебном разбирательстве (хотя в случаях, когда подобный риск есть, обе стороны обычно понимают, что техническое задание необходимо).

Техническое задание неполно, двусмысленно или противоречиво

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

Ноябрь 15 2007