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

4

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

Не путать повесть и роман 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 


4573
Коментарии: 4

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Татьяна Орлова
    Рейтинг: 377
    ЗАО "ЕС-лизинг"
    Замдиректора по инновационной и экспериментальной деятельности, консультант по управленческим дисциплинам
    22.07.2020 17:47

    И все бы хорошо и правильно. Остается один вопрос: а как проводить официальные проверки, аудит по бюджетным расходам? Там без ГОСТа никак...

  • Станислав Макаров
    Рейтинг: 54
    Независимый эксперт
    Аналитик
    23.07.2020 12:30

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

  • Олег Баталов
    Рейтинг: 152
    AO Caspian Beverage Holding
    Начальник отдела информационных технологий
    09.08.2020 09:40

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

  • Андрей Зелинский
    Рейтинг: 43
    АО "КировТЭК", ГК "Кировский завод"
    Начальник АСУП
    10.08.2020 12:10

    Сейчас был как раз похожий опыт. Нужно было максимально быстро запустить ServiceDesk в работу (предшественники увязли в составлении максимально подробного ТЗ и завалили проект так ничего и не внедрив (ПО тоже не закупили)), срок 2 недели.
    Пришлось быстренько, формулируя по кусочкам задания, разрабатывать на коленке временную систему без единого ТЗ.
    В итоге запустились. До этого потратив почти полгода ничего работоспособного сделать не смогли, зато подготовили кучу промежуточных документов, провели много совещаний и т.п.

Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.