вторник, 19 мая 2009 г.

Мысли о роли ТЗ в программном проекте

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

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

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

Другими словами ТЗ - это "рыба" проекта, которую можно делать сразу, просто и очень дешево менять. А письменный он должен быть потому, что иначе мозг может и не включиться. П%;:ть, как грится, не мешки ворочать.


PS термин "техническое задание" спорный, но выбран как самый простой, для обобщения

PPS да, agile конечно штука, но не каждый заказчик готов по нему работать

UPD: мысль оказалась далеко не новой - Джоэль о том же пишет.