Жесткое ТЗ

Наверное каждый программист сталкивался в своей работе с неприятностями, вызванными нечеткими договоренностями. Заказчик (или начальник) ставит задачу устно и довольно неподробно. Программист, тем не менее, вполне понимает, о чем идет речь, соглашается сделать за определенные деньги или время, а потом оказывается, что заказчик имел в виду другое (читай: гораздо больше), и вроде как договоренность уже есть, и надо делать, и получается, что программист работает гораздо больше, чем рассчитывал.

После одного-другого таких случаев программист обычно решает, что отныне и навсегда все отношения с заказчиком/начальником обязательно должны регулироваться жестким техническим заданием.

Обратная сторона жесткости

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

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

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

Пример. Как читатели моего блога, несомненно, в курсе, недавно я был погружен в разработку Некого Музыкального Сервиса™, в котором люди обмениваются музыкой в виде альбомов. Так я и спроектировал, что в системе у нас будут Пользователи, а у каждого — список Альбомов. И в системе можно будет искать альбомы по, скажем, названию и получать их список с указанием, какому пользователю они принадлежат. Затем, когда эта простая модель стала разрабатываться в подробностях, у меня возник вопрос, который до этого ни разу не возникал: а что если у разных пользователей будут одинаковые альбомы? Надо решить, будет ли система считать все эти альбомы одним и тем же или же таки разными. Немного подумав, я решил, что пусть будут разные, потому что у разных людей эти альбомы могут быть в разном качестве и разной полноты (есть не все треки, например). Да и сами владельцы альбомов могут, например, быть в отпуске, и тогда будет иметь смысл попросить тот же альбом у другого человека. Логично, да?

Когда мы начали активные тесты, мгновенно стало очевидным, что такой вариант не работает. Представьте себе результаты поиска музыки, скажем, Beatles: это есть почти у каждого меломана, и часто практически все альбомы. В итоге на странице результатов поиска мы имеем 200 одинаковых альбомов "A Hard Day's Night", тянущихся несколько страниц, 200 одинаковых альбомов "Revolver" и т.д. Дальше — больше. А в какой из этих альбомов надо ткнуться, чтобы оставить комментарий? А надо ли раздельно хранить 200 почти одинаковых картинок обложек?

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

Причем, все эти проблемы выглядят очень очевидными, когда с ними сталкиваешься, но факт в том, что ни заказчик, ни программист не подумали о них в самом начале. Хотя думали, и думали напряженно (за себя, по крайней мере, могу ручаться :-) ).

Итак, если в двух словах:

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

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

Изменяющаяся спецификация

Ответ на вопрос, что с этой проблемой делать, дает agile-методология.

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

Чтобы такое гибкое ТЗ действительно было полезным инструментом, нужно выполнение нескольких условий:

Больше функций = больше ресурсов

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

Спецификацией надо заниматься

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

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

Спецификацию должны читать

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