Разработка технического задания (ТЗ) на программный продукт с точки зрения заказчика. Работаем над ошибками

В недалеком прошлом на этом замечательном ресурсе была опубликована статья Разработка технического задания (ТЗ) на программный продукт с точки зрения заказчика. Статья — сама по себе неплохая — содержит, к сожалению, ряд неточностей, о которых следует упомянуть. Сделаем это в «один проход» по абзацам. По второму абзацу:
Надо сказать, что у каждой из этих заинтересованных сторон свои требования и свое видение того, каким должно быть «хорошо написанное ТЗ». Например, у заказчика и исполнителя могут быть совершенно противоположные мнения на этот счет.
Уточнения:
  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. Тендерную документацию разрабатывает именно тот подрядчик, который заведомо должен выиграть конкурс. Простите, но это жизненные реалии...
Как-то так. В заключении можно рекомендовать старенькую статью Страшная правда о техническом задании, в которой довольно детально расписаны процессы взаимодействия заказчика и исполнителя в ходе разработки технического задания, а также всевозможные «тайные подлости» этого замечательного документа. Автору исходной статьи: как и упоминалось в начале, этот пост создавался в «один проход», т.е. отдельные наши уточнения оказались «опережающими» — кое-что было учтено самим автором исходника ниже по тексту. Ничего личного...
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 21
    0
    Вы исходите из того, что ГОСТ (и вообще подзаконная нормативка) — это такая библия, которую все должны знать и на которую все должны опираться. И если даже для госухи это так (хотя даже там это не совсем так), то в других областях разработки это может быть совсем не так.
      –3
      Отнюдь не обожествляю ГОСТы, особенно ГОСТ Р, но опыт доказывает, что соответствие чего-либо требованиям ГОСТов есть хотя бы минимальный показатель качества этого чего-либо. Все прочее — отсебятина, и останется ей до тех пор, пока не не станет стандартизованной отсебятиной :)
      И, поверьте, никому ничего не навязываю. Пусть каждый учится на своих ошибках, если не умеет на чужих :)
        0
        соответствие чего-либо требованиям ГОСТов есть хотя бы минимальный показатель качества этого чего-либо

        Вот этого я как раз и не люблю. За последние несколько лет я видел сильно больше одного ТЗ, которые соответствовали ГОСТам, но были совершенно неприменимы как ТЗ. Очень расстраивает.

        «Минимальный» — не значит «достаточный».
      0
      Уважаемый, если есть желание подискутировать — пишите конкретику, поскольку эмоциональных и безосновательных высказываний в рунете и без того выше крыши. Все это мало кому интересно. Как и то, что Вы любите или нет, что Вас расстраивает или нет.

      Опубликуйте хотя бы одно из «сильно больше» такого ТЗ — обсудим, проверим на соответствие требованиям ГОСТов, найдем «неприменимости», в которых «виноваты» ГОСТы. А еще лучше — изложите свои понятия в части «достаточности» технических заданий, разработанных вне рамок ГОСТов, отдельной статьей. Тогда и пообщаемся, а флуд интереса не представляет.
          –1
          «добейСЯ» = «добей СЕБЯ». Ап стену.
            +1
            Возможно Вы не в курсе, но «добейся» — это повелительное наклонение слова «добиваться».
              0
              По моему, это повелительное наклонение слова «добиться», которое, в свою очередь, произошло от слова «бить».
                0
                При этом «до-бить-ся» — возвратный глагол. Значение возвратного глагола: «собственно возвратное — действие производится субъектом, к-рый является одновременно и объектом действия: умываться, одеваться, купаться». Или, иными словами, «ся» == «себя», в случае с возвратным глаголом.

                Вы были правы, указав на то, что исходное слово производное от другого слова, но ничего не доказали и не опровергли по сути.
                  0
                  Вы не в курсе того, что, хотя "-ся" в возвратных глаголах и происходит от «себя», оно далеко не всегда это обозначает? И между возвратным и невозвратным глаголами вообще может не быть семантической связи?
                    0
                    В курсе. Поэтому написал, что это в случае с «добиться». Вы, вообще, не о том говорите.
                      0
                      В случае с добиться как раз значение не «собственно возвратное», объект действия — то, чего добиваются (он даже переходный).
                        –1
                        Или косвенно-возвратный. Что это меняет? Постфикс «ся» перестал означать «себя»?
                          +1
                          Да, перестал. Человек добивается чего-то другого.
                            –1
                            «Чего-то другого» себе (или для себя)! Вы пропустили ключевое слово.
                              0
                              Не обязательно. Если я завтра добьюсь удвоения числа кабинок в женских туалетах в макдональдсе, то лично в моей жизни ничего не изменится.
                                0
                                Вы выполните, поставленную перед собой задачу.

                                По-моему, пора прекращать эту демагогию.
                    0
                    В таком случае предлагаю Вам самому «добиться».
                    Можете быть вольны вложить в это слово наиболее приемлемый для Вас смысл.
          –5
          Возможно, Вы не в курсе, но «СЯ» в старославянском всегда обозначало «СЕБЯ».
            0
            Если рассматривать идеальный случай: адекватный Заказчик и адекватный Исполнитель, заинтересованные в реализации проекта, то формула (читай последовательность) может быть такой:
            1. Документ «Технические требования» — пишутся Заказчиком. Отвечает на вопрос: «чего хотим и ждем?»
            2. Документ «Техническое задание» — пишется Исполнителем. Отвечает на вопрос: «чего будем делать, чтобы реализовать требования?»
            3. Документ «Техпроект» (пояснительная записка к Техпроекту) — пишется Исполнителем. Отвечает на вопрос: «Что мы в итоге сделали?»

            К сожалению, эта формула работает только в идеальном мире. Ведь шаги 2 и 3 идут, обычно, уже после заключения договора. Часто, не имея возможности заранее оценить Исполнителя, Заказчик пытается максимально обезопасить себя. Т.е. берет разработку ТЗ в свои руки, чтобы ТЗ шло приложением к договору. Дальше уже начинает изворачиваться Исполнитель. В результате получаем кашу, монструозные ТЗ, затягивание проектов и прочие радости.

              0
              Спасибо, Артем — это совсем другое дело, а то все флуд да эмоции, а потом еще и в «минуса» меня. Дурная манера пытаться пройти по чужим головам.

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

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

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

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

              Вот фрагменты из Минобрнаучного ТЗ :)

              «… обоснование характеристик сторонних программных средств...» — ласкает слух! Берем какую-нибудь стороннюю софтинку типа ворда и обосновываем ее характеристики — В темных очках;
              «… унификация функциональных задач...» — см., уважаемые, определения функций и задач, хотя бы применительно к автоматизированным системам;
              «… графических элементов интерфейсов...» — вероятно, имеются в виду элементы графического интерфейса пользователя;
              «… графического интерфейса модулей...» — это уже придирка, конечно, но далеко не все программные модули оснащены графическим интерфейсом;
              «… сторонних систем...» — очевидно, речь идет о внешних системах;
              «… Технический акт...» — тут впору задумчиво почесать в затылке… Наверное, это что-то вроде загадочного зоологического термина «свинская собака» по Ярославу Гашеку;
              «… Документ «Обоснование необходимости закупки технических средств, программного обеспечения и лицензий на него»...» — косноязычие и полное непонимание сути проблемы… Обосновывать следует закупку технических средств с конкретными характеристиками, обеспечивающими конкретный вычислительный ресурс, требуемый для нормального (штатного) функционирования комплекса программ. Программное же обеспечение, если не приобретать пиратское, всегда продается совместно с лицензией. Но дорого, однако — Круглые глаза;
              «… контролем входной и выходной информации, основанной на методике кодирования объектов...» — входная информация (или данные), вводимая пользователем вручную в диалоговом (или интерактивном) режиме с помощью элементов графического интерфейса в поля ввода данных, подвергается форматно-логическому контролю, проверке неких граничных условий. Чтобы сильно не грузить читателя, приведем простой пример: форматно-логический контроль не позволит ввести, допустим, дату смерти более раннюю, чем дату рождения индивида;
              «… Критерием предельного состояния Комплекса XYZ является превышение времени выполнения функций...» — уважаемые господа, посмотрите, пожалуйста, в ГОСТ 27.002, что есть предельное состояние...;
              «… с возможностью «горячего резервирования» и перехода на резервное оборудование...» — налицо нарушение п. 4.2.3 ГОСТ 2.105 и явное невладение терминологией. Горячего резервирования не существует в природе, есть постоянное резервирование, которое, как известно (немногим), не требует никаких переходов (переключений). Слово «оборудование» в рамках стандартов по информационным технологиям и системам обработки информации не применяется, есть понятие «технические средства», «техническое обеспечение» и т.д.;
              и, наконец, самое забавное — «… должна соответствовать требованиям эргономики и профессиональной медицины...»… Есть подозрение, что под профессиональной медициной подразумеваются СанПиНы — санитарные правила и нормы — Ржу! (смайл)

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

            Самое читаемое