Техзадание – руководство к действию или «мина» под проектом?

Хорошее техническое задание – залог успеха проекта. Но проблема в том, что «хорошесть» линейкой не измеришь. Педантичное следование методикам не гарантирует, что у вас получится хорошее ТЗ. Часто вместо четкого руководства к действию ТЗ становится «миной» под проектом. И вот почему.

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

А если подобный «роман» написал разработчик, то заказчик, даже осилив его до конца, не в силах понять, насколько точно оно отвечает его требованиям. Подавленный обилием деталей, он в итоге его утверждает. Потом, когда все будет сделано в точности, как написано, может оказаться, что он хотел вовсе не этого. Формально исполнитель вправе сказать: «Ну, вы же сами ТЗ подписали». Но поможет ли это ему получить следующий контракт? Едва ли.

К большой форме читателя надо подготовить, познакомить с героями, с обстановкой. И тогда он с удовольствием прочтет ваш роман. Прежде, чем взяться за «Улисса», Джойс написал серию рассказов «Дублинцы», персонажи которых потом перекочевали в его роман – и читать их надо в таком же порядке, легче будет. Поэтому не стоит «путать жанры» и превращать техзадание в техпроект.

ГОСТ нам в помощь?

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

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

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

Нужно ли ТЗ в эпоху «аджайл»?

 В том виде, в каком ТЗ привыкли составлять «водопадники», совершенно точно нет. Сейчас на старте проекта никто не заморачивается полным описанием будущего продукта, а просто делают что-то работающее и полезное – MVP.

Стив Бланк, один из авторов концепции MVP, говорил: «Вы продаёте видение и предоставляете минимальный набор функций для фантазёров». Это значит, что вместо повести в стиле реализма составитель ТЗ сочиняет фантастический рассказ.

Поскольку новое поколение не любит лонгриды, ТЗ в аджайле рассыпается на набор user stories – как если бы Пушкин публиковал свои повести Белкина в Твиттере. (У него бы получилось!)

Только надо остерегаться странного зверя «аджайл по ГОСТу», который появляется из-за того, что практика контрактования отстает от методологий разработки. В наших реалиях едва ли возможно провести конкурс по 44-ФЗ или 223-ФЗ, чтобы выполнять проект по аджайл, но понятно, что работать по водопаду будет неэффективно. Вот и приходится сочинять сказочное ТЗ, а потом как-то выкручиваться.

Знать (и любить) своего читателя

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