В недалеком прошлом на этом замечательном ресурсе была опубликована статья Разработка технического задания (ТЗ) на программный продукт с точки зрения заказчика. Статья — сама по себе неплохая — содержит, к сожалению, ряд неточностей, о которых следует упомянуть. Сделаем это в «один проход» по абзацам. По второму абзацу:

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

Уточнения:

1. Технические задания не пишут (составляют, подготавливают, оформляют и пр.), а разрабатывают, см. хотя бы п. 1.2 ГОСТ 34.602-89;
2. Если заказчик и исполнитель руководствуются требованиями ГОСТов, то совершенно противоположных мнений у них в принципе быть не может и не должно. Если же взаимодействие осуществляется «по понятиям» — как сейчас принято — то без «плюрализЬма мнений» тут, конечно, никак не обойтись.

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

Палка о трех концах:

1. Чрезмерно детализированное техзадание становится техническим проектом, что, в общем-то, и неплохо, но кто даст исполнителю столько времени и денег на разработку излишне подробного ТЗ?
2. Вменяемый исполнитель всегда стремится сократить объем технического задания, поскольку «меньше слов — меньше вопросов». И меньше работы. Более того, на стадии технического задания очень трудно предугадать технический облик изделия, программы или автоматизированной системы в целом, поэтому существует типовая отмазка «то-то и то-то должно уточняться на стадии технического проекта»;
3. Исполнитель не должен забывать, что он несет обязательства не только в части реализации функциональных требований, но и общих требований — требований к надежности, безопасности и т.д. Нет смысла перечислять, поскольку их довольно много и все они подробно изложены в том же ГОСТ 34.602-89.

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

А вот тут уже все зависит от опыта исполнителя. Толковый исполнитель обязательно пропишет в договоре или ТЗ условие, при котором все дополнительные «хотелки» заказчика должны будут финансироваться отдельно с соответствующим увеличением срока разработки (дополнениями к ТЗ, допсоглашениями и т.п.). При этом очень важно — крайне важно! — не доверять всецело подготовку договора юристам, обязательно выверять все вплоть до каждой запятой, безжалостно уничтожать в документах любую юридическую казуистику, приводить документы к виду стройному, строгому и прозрачному. По третьему абзацу:

Как уже говорилось выше, в момент начала работы над ТЗ вы можете слабо себе представлять… В качестве исходных данных у вас могут быть разрозненные, часто противоречащие друг другу запросы… Хорошо, если вашей ИТ-службе удалось… Если же нет, то лучший вариант – это сначала разработать очень общее ТЗ, крупными мазками описывающее видение системы, перечислить необходимые модули (подсистемы), не углубляясь в подробности их функционирования, и далее совместно с исполнителем работать над детализацией требований к ним.

По сути правильно, только это будет не ТЗ, а нечто вроде оперативно-технической записки, ТТЗ, заявки, письма с хотелками — общими функциональными требованиями. Теперь о неточностях: нельзя смешивать понятия модулей и подсистем, поскольку подсистема — это та же система, только маленькая. Подсистема, как и система, включает в себя все виды обеспечения, все те же общие требования, а модуль есть всего лишь «Программа или функционально завершенный фрагмент программы, предназначенный для хранения, трансляции, объединения с другими программными модулями и загрузки в оперативную память [из п. 15 Таблицы 1 ГОСТ 19781-90]»

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

Что касается «основных понятий», то существует громадное количество ГОСТов, содержащих в своих названиях строчку «… Термины и определения». Их и следует применять в работе, чтобы быстрее освоить новую предметную область, но ни в коем случае не ссылаться на всяческие «… педии», поскольку это не только несолидно, но еще и «чревато боком» в части последствий. По четвертому абзацу:

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

За долгосрочное сотрудничество исполнитель будет цепляться всеми конечностями, если, конечно, заказчик вменяем… Спиральную модель заменим п. 1.7 ГОСТ 34.602-89 и уточним п. 11 Приложения 1 того же стандарта. По седьмому абзацу:

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

Смешаны понятия этапов и очередей. Применительно к автоматизированным системам: Этап — Часть стадии создания АС, выделенная по соображениям единства характера работ и (или) завершающего результата или специализации исполнителей [из п. 4.4 ГОСТ 34.003-90] Очередь — Часть АС, для которой в техническом задании на создание АС в целом установлены отдельные сроки ввода и набор реализуемых функций [из п. 4.5 ГОСТ 34.003-90] По девятому абзацу:

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

Зачем вся эта самодеятельность с составлением страниц с содержанием ТЗ? Есть ГОСТ 19.201, есть ГОСТ 34.602 и другие стандарты, в которых структура и содержание технических заданий расписана четко и строго, узаконена государством, не содержит практически ничего лишнего, при этом допускается вводить дополнительные разделы, подразделы, пункты и подпункты на усмотрение заказчика и исполнителя? По десятому абзацу:

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

Вот тут совсем непонятно: ведь заказывает музыку тот, кто платит, а платит заказчик. Как исполнитель может хоть что-то ему навязывать? Тут возможно лишь взаимное «согласие как продукт при полном непротивлении сторон»… По одиннадцатому абзацу:

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

Слезы потекли ручьем:

1. Плохо или неплохо — судить не нам, поскольку все существующие зарубежные стандарты, включая MIL, даже близко к ГОСТ 34-й системы не стояли в части детализации и полноты охвата;
2. ГОСТ 34.602 к программным продуктам вообще никакого отношения не имеет, ибо «Настоящий стандарт распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы» (далее — ТЗ на АС)».

Правда, отдельные требования ГОСТ 34.602 целесообразно присовокуплять к ТЗ, разработанным по ГОСТ 19.201, чтобы компенсировать некоторые его огрехи, что не возбраняется самим ГОСТ 19.201 — «В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них [из п. 1.4 ГОСТ 19.201-78]». По четырнадцатому большому абзацу:

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

Все это не предусмотрено как ГОСТ 19.201, так и ГОСТ 34.602, но имеется подраздел «Требования к численности и квалификации персонала системы и режиму его работы», который разумно добавить в ТЗ на ПО и детально расписать в нем категории персонала. И даже роли… А еще в ГОСТ 34.602 предусмотрены требования к организационному обеспечению — в них можно отлично развернуться и дать волю фантазии.Все, что перечислено ниже, детально расписано в РД 50-34.698-90. Если интересны подробности — задавайте вопросы в комментариях. По заключению:

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

И, наконец:

1. «Законодательно» ТЗ разрабатывается самим заказчиком только в том случае, если он представляет Министерство обороны или иное силовое ведомство;
2. Тендерную документацию разрабатывает именно тот подрядчик, который заведомо должен выиграть конкурс. Простите, но это жизненные реалии…

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

Автор: sudo-su

Источник