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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии: 16 (feed)

  1. Corwin

    Я бы сказал что программист вообще не должен ничего с заказчиком решать. Для этого существует руководитель проекта, у которого есть достаточно опыта и знаний для того чтобы правильно выстроить взаимоотношения с заказчиком, и понять что тот хочет на самом деле и корректировать работы по ходу. А програмист вобщем то должен делать то что ему скажут, а надо это или нет, его касаться не должно :)

  2. Макс Лапшин

    а надо это или нет, его касаться не должно :)

    — это типичный путь для RUP-а. Отношение к программистам, как к быдлокодерам. Человек не может писать код, если не знает, что и для чего.

  3. Иван Сагалаев

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

  4. Portnov

    Кому интересно - вот неплохой краткий обзор гибких методологий:
    http://www.maxkir.com/sd/newmethRUS.html

  5. Константин

    Очень полезная статья, спасибо. Совершенно очевидно что Иван много шишек набил на подобных проблемах :).

  6. Max Ischenko

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

    не обязательно. Часто эффективнее выбросить/отложить на следующий milestone что-то старое.

  7. Ro

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

    • О стоимости проекта и о времени разработки говорить рано
    • ТЗ нужно составить
    • ТЗ может составлять заказчик или исполнитель
    • Если исполнитель составляет ТЗ, то составление ТЗ должно оплачиваться (желательно перед тем, как приступать к работе над ТЗ). Сумма, затраченная на ТЗ входит в стоимость проекта.
    • При составлении ТЗ необходимо активное участие второй стороны

    Свершился тот день, когда ТЗ готово (для проектов от 8 до 30 недель время на ТЗ обычно 1-2 недели). Что дальше? Надеюсь, что ТЗ уже оплачено. Дальше разработка прототипа. Программисты приступают к разработке прототипа и это тоже оплачивается отдельно. После того, как работа над прототипом будет завершена, заказчик решает, продолжать работу дальше или нет.

    Таким образом разработка любого проекта (на мой взгляд) должна быть разделена на 3 этапа:

    1. Составление ТЗ (меньше всего по времени)
    2. Подготовка прототипа
    3. Создание полнофункциональной версии (бОльшая часть времени)

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

  8. Андрей Хаврюченко

    Работаем так. При полной неспособности (нежелании?) Заказчика сформулировать требования и перманентных "срочных" изменениях "на вчера", процесс живёт достаточно успешно.

    Однако, как показывает опыт, это всё равно не спасает от периодический претензий класса "I need proactive developers!"..

    Так что разработчику приходится время от времени переквалифицироваться в business process engineer. :)

  9. necro

    Пример с альбомами неудачен имхо. Можно просто показыват одну строку с названием альбома, в скобках у нее у скольких пользователей он есть. Далее можно либо выбрать одним щелчком произвольно один из них, либо открыть список и выбрать альбом у конкретного пользователя. в общем, смотрим p2p, в частности emule.

  10. Begemot

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

  11. Доктор Тюнинг

    хм... Если разработчик одно лицо, то тогда все верно. Но возьмем корпоративную схему (ключевые фигуры):
    1. Руководитель проекта - ведет перговоры со строной заказчика, утрясает нюансы, выступает редактором технического задания.
    2. Начпрог - начальник отдела программирования, руководит девелоперами, разработчиками, проектировщиками, и БДшниками :) утрясает вопросы по проекту с руководителем.
    3. Проектировщики - делают объектный проект Интернет-ресурса в зависимости от поставленных задач.
    4. БД'ники, делают проект БД в зависимости от поставленных задач
    5. Программеры, на основе реализованных объектов (назовем их DAO) и реализованной БД программят, колдуют над ядром системы (под ядром понимается движок, возможно с ЦМС, движок реализует всю логику сайта)

    Все на этом работа программеров заканчивается, программеры выдали логику и набор переменных (не знаю как правильно назвать) для Аппликаторов (от слов application :) ), аппликатор привязывает подготовленную для него версту с логикой.

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

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

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

    P.S.: Есть такое понятие как уровень детализации технического задания. Некоторые технические задания описывают все вплоть до интерфейса продукта и включают проект БД с объектной моделью.

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

    фуух...

  12. [...] Жесткое ТЗ. Статья известного программиста и веб-разработчика Ивана Сагалаева, в которой он дает советы начинающим коллегам по составлению правильного технического задания. Соглашусь со словами одного из комментаров этой статьи — действительно чувствуется, что Иван на этом много шишек набил и советы дает дельные.

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

    [...]

  13. Дмитрий Сергеев

    О, хорошая статья. Я за последние пару дней прочитал штук двадцать версий того, как же писать ТЗ на сайт. Всё водица-водица :)

    А здесь разумное зерно — нормальное отношение к постоянному изменению требований.

  14. [...] статьи Жесткое ТЗ (Иван Сагалаев) Жизнь без технического задания (Олег [...]

  15. Любопытные статьи Жесткое ТЗ (Иван Сагалаев) Жизнь без технического задания (Олег Бунин)

  16. Вадим

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

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

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

    Поэтому вариантов собственно несколько:

    1) Если проект большой, о заказчик оплачивает составление специалистами ТЗ.

    2) Если проект не позволяет тратить на это средства, то программист должен помогать заказчику составить ТЗ, ( вот, например, некоторые моменты составления ТЗ на дизайн и особенности взаимодействия с заказчиком http://www.prof-raskrutka.ru/articles/dizain-saita ) а заказчик должен понимать, что при изменении требований будет меняться и цена.

Добавить комментарий

Format with markdown