При написании требований к информационной системе (ИС), если она предназначена для госсектора или отдельных крупных предприятий, от подрядчика ожидают соблюдения ГОСТ 34 или 19.
Даже частные компании могут требовать документацию по ГОСТу, считая, что следование стандартам гарантирует качество ПО. Однако, хотя такой подход обоснован в производстве мороженого и многих других продуктов, в IT-индустрии у него есть определенные минусы — и в статье мы рассмотрим их подробнее.
Попробуем разобраться, почему вокруг ГОСТов сложилась такая ситуация и как можно выстроить работу с ними без ущерба для эффективности процессов.
Кому будет полезна статья:
Если у вас есть опыт в этом вопросе, мы рекомендуем перейти к части второй, где мы расскажем, “откуда растут ноги” у ГОСТа и так ли он неизбежен при работе с госзакупками.
Отдельные вопросы очевидны для заказчика потому, что он живёт и работает в определённой парадигме, свойственной именно его роду занятий. При этом картина мира разработчиков будет кардинально отличаться от представлений заказчика, а значит, они могут иначе понять требования к продукту.
Если требования не проработаны совместно, возможна ситуация, когда продукт будет соответствовать восприятию разработчика, а не заказчика. В этом случае заказчик будет настаивать на изменениях в рамках оговоренного бюджета, а разработчик окажется недоволен тем, что должен за свой счет вносить изменения в продукт, который отвечает всем формально заявленным требованиям.
Однако, квалифицированный разработчик, скорее всего, не возьмется за выполнение слишком абстрактной задачи или, как минимум, разъяснит все минусы и риски такого подхода.
Для того, чтобы избежать недопонимания, одной из сторон следует задать уточняющие вопросы, а ответы зафиксировать в виде тезисов (как правило, эту роль берет на себя разработчик с необходимой экспертизой). Таким образом, он создает документ, детально описывающий требования к будущей системе, комплексно и с учётом всех “да, но” и “что, если”. Этот документ сочетает две парадигмы, заказчика и разработчика, помогая им говорить на одном языке и правильно понимать друг друга.
Тем не менее документация НУЖНА, даже если это просто описание user stories. Иногда команде достаточно иметь определенные паттерны, чтобы понимать, что определенная user story предполагает наличие функции, которая должна быть реализована тем или иным способом.
Таким образом, требования необходимы практически на любой стадии производства продукта и в конечном счете напрямую влияют на его качество.
Помимо этого, требования должны быть подробными и исчерпывающими. В ином случае на стадии разработки будет больше простора для "творчества", и как следствие, есть большой риск получить продукт, не соответствующий поставленной задаче.
Для того, чтобы требования были максимально понятны всем участникам и детализированы в достаточной степени, требуются правила (стандарты). Исторически сложилось так, что при производстве информационных систем, по большей части в государственном секторе, для описания требований, используется ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы".
В СССР система ГОСТов была призвана сформулировать требования государства к производству продуктов, которые имеют важное межотраслевое значение. ГОСТы описывали требования к качеству и правилам производства таких продуктов. На сегодняшний день применение ГОСТов преимущественно добровольное, за некоторым исключением в части оборонзаказа.
Так как же получилось, что ГОСТ 34.602-89 стал практически обязательным для государственного заказчика?
Если говорить о ТЗ как о юридическом документе для договора между сторонами, то соблюдать ГОСТ целесообразно, но с некоторыми оговорками. А вот на стадии производства такой документ будет практически бесполезен, так как большинство методологий разработки требуют других подходов и к взаимодействию в команде, и к основному фокусу. Как правило, в центре продукта — пользователь, его инсайты, его реакция на приложение в целом и каждый отдельный элемент.
Посмотрим внимательно на состав ТЗ по ГОСТ 34, а именно:
С другой стороны, в нашей практике были случаи, когда заказчик, чтобы снизить возможные риски, стремился создать ТЗ даже более подробное, чем предполагалось по ГОСТу.
В разработке, в отличие от конкурсной документации, ТЗ обычно используют в более развернутом виде (как частное техническое задание). Такой подход нацелен на более быстрое согласование формальностей, например, при проведении государственных торгов. Причина в том, что для госзаказчиков зачастую очень важны сроки, а торги занимают достаточно много времени.
В составе же техпроекта может быть больше документации, описывающей информационную систему такой, какой она должна быть (или такой, какая она есть на текущий момент).
Примеры: руководство пользователя, администратора, описание технических решений, пояснительная записка к проекту, программа и методика испытаний и так далее.
Также бывают случаи, когда на старте полная проработка системы не нужна. Например, для MVP не всегда возможно детально и точно описать всю систему, если нет детальной информации о тех модулях, которые будут добавлены в дальнейшем.
В частности, разработчики могут сформировать для заказчика отдельный документ (например, на один из модулей системы) по ГОСТ 34, как ЧТЗ. В некоторых случаях подобный документ называют “описанием постановки задачи” (ОПЗ), и он содержит в своем составе описание бизнесовой части, схемы бизнес-логики на основании требований законодательства (НПА). В таком виде документация презентуется заказчику.
Если документация согласована, для команды разработки зачастую пишут новый документ, который имеет в своем составе больше технических деталей, описания алгоритмов, логики автоматизации, схемы логических моделей, интеграцию. Иначе говоря, это вопросы, которые могут не интересовать заказчика, но будут необходимы разработчикам.
Этот документ может быть оформлен не по ГОСТ 34 (так называемая "дельта" для разработки), в нем нет общих формулировок и "воды". Естественно основной документ в базе знаний постоянно актуализируется, после мержа туда таких вот "дельт".
Такой подход тоже не всегда эффективен, как правило, он применим после того, как общая архитектура приложения согласована и уже определены подходы, выбраны методы разработки, стек технологий. (Кстати, подозреваем, что, скорее всего, отсюда и пошло деление на бизнес-анализ и системный анализ).
На такие стандарты опираются международные сертификационные организации, например, IREB (International Requirements Engineering Board). В нашей команде аналитики по желанию проходят сертификацию IREB, и по нашим наблюдениям, многие заказчики обращают на это внимание (хотя если у специалиста нет сертификации, он все равно может иметь глубокие знания).
habr.com
Даже частные компании могут требовать документацию по ГОСТу, считая, что следование стандартам гарантирует качество ПО. Однако, хотя такой подход обоснован в производстве мороженого и многих других продуктов, в IT-индустрии у него есть определенные минусы — и в статье мы рассмотрим их подробнее.
Попробуем разобраться, почему вокруг ГОСТов сложилась такая ситуация и как можно выстроить работу с ними без ущерба для эффективности процессов.
Кому будет полезна статья:
- представителям заказчиков (в первую очередь государственных), заинтересованным в получении результата, а не кипы бумаг;
- тендерным специалистам со стороны как заказчика (специалистам по закупкам), так и исполнителя;
- заинтересованным лицам команды разработки (аккаунтам, ПМ, аналитикам).
Если у вас есть опыт в этом вопросе, мы рекомендуем перейти к части второй, где мы расскажем, “откуда растут ноги” у ГОСТа и так ли он неизбежен при работе с госзакупками.
Часть 1. Общие понятия
Что такое техническое задание (ТЗ) и зачем оно нужно?
Представим себе абстрактную ситуацию: заказчику нужно произвести некий продукт. Для того, чтобы донести свою потребность исполнителю, заказчик фиксирует требования в следующем виде: “Система должна автоматизировать процесс получения услуги Х”. Заказчик считает необходимым указать лишь эти детали, возможно, считая всё остальное очевидным — но здесь есть риск ошибиться.Отдельные вопросы очевидны для заказчика потому, что он живёт и работает в определённой парадигме, свойственной именно его роду занятий. При этом картина мира разработчиков будет кардинально отличаться от представлений заказчика, а значит, они могут иначе понять требования к продукту.
Если требования не проработаны совместно, возможна ситуация, когда продукт будет соответствовать восприятию разработчика, а не заказчика. В этом случае заказчик будет настаивать на изменениях в рамках оговоренного бюджета, а разработчик окажется недоволен тем, что должен за свой счет вносить изменения в продукт, который отвечает всем формально заявленным требованиям.
Однако, квалифицированный разработчик, скорее всего, не возьмется за выполнение слишком абстрактной задачи или, как минимум, разъяснит все минусы и риски такого подхода.
Для того, чтобы избежать недопонимания, одной из сторон следует задать уточняющие вопросы, а ответы зафиксировать в виде тезисов (как правило, эту роль берет на себя разработчик с необходимой экспертизой). Таким образом, он создает документ, детально описывающий требования к будущей системе, комплексно и с учётом всех “да, но” и “что, если”. Этот документ сочетает две парадигмы, заказчика и разработчика, помогая им говорить на одном языке и правильно понимать друг друга.
Проекты без технического задания
Существуют задачи, которые не требуют полноценного ТЗ – например, когда проект сравнительно невелик или нужно лишь доработать часть готовой системы. В этом случае детализация требований может зависеть от методологии разработки, времени, погруженности каждого участника в проект и прочих сопутствующих факторов.Тем не менее документация НУЖНА, даже если это просто описание user stories. Иногда команде достаточно иметь определенные паттерны, чтобы понимать, что определенная user story предполагает наличие функции, которая должна быть реализована тем или иным способом.
Таким образом, требования необходимы практически на любой стадии производства продукта и в конечном счете напрямую влияют на его качество.
Часть 2. ГОСТ: необходимость или неизбежность?
История вопроса
Начнём с того, что, исходя из здравого смысла, ТЗ всегда должно иметь структуру. Это непреложное правило: иначе невозможно ни управлять требованиями, ни качественно их реализовывать.Помимо этого, требования должны быть подробными и исчерпывающими. В ином случае на стадии разработки будет больше простора для "творчества", и как следствие, есть большой риск получить продукт, не соответствующий поставленной задаче.
Для того, чтобы требования были максимально понятны всем участникам и детализированы в достаточной степени, требуются правила (стандарты). Исторически сложилось так, что при производстве информационных систем, по большей части в государственном секторе, для описания требований, используется ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы".
В СССР система ГОСТов была призвана сформулировать требования государства к производству продуктов, которые имеют важное межотраслевое значение. ГОСТы описывали требования к качеству и правилам производства таких продуктов. На сегодняшний день применение ГОСТов преимущественно добровольное, за некоторым исключением в части оборонзаказа.
Так как же получилось, что ГОСТ 34.602-89 стал практически обязательным для государственного заказчика?
- Серия ГОСТ 34 рассматривает не только производство ТЗ. Она была создана как единый комплекс стандартов и регламентирует все стадии производства ИС, а также артефакты, которые в результате появляются.
- Серия ГОСТ 34 описывает правила проведения испытаний при приемке работ. Исходным документом для программы и методики испытаний является ТЗ. При этом для госзаказчика проведение испытаний – очень важная часть контракта.
- Стандарт используют по инерции, потому что долгое время не было других альтернатив. Стандарт имел государственное значение, разрабатывался на основе бесценного опыта при участии целых НИИ, а отрасль создания АИС являлась одной из важнейших для государства.
Недостатки ГОСТ
Наряду с бесспорными плюсами, ГОСТы серии 34 имеют ряд недостатков:- ГОСТы устарели морально. За время, прошедшее с их выпуска, изменились технологии и подход к процессу разработки, и появились новые более гибкие методологии.
- ГОСТы избыточны. Современные гибкие подходы к разработке требуют того, чтобы с документацией можно было работать быстро и с удобством, а требования были понятны каждому члену команды.
- В ГОСТ отсутствуют отдельные понятия IT-отрасли, связанные с управлением проектами и рисками.
- ГОСТы серии 34 долгое время не актуализировали, они имеют незавершенный вид и зачастую недостаточно подробно рассматривают процессы сопровождения и обслуживания.
Так нужно ли писать ТЗ именно по ГОСТ 34.602-89?
В нашей практике мы придерживаемся мнения, что писать ТЗ исключительно по ГОСТ — как правило, нецелесообразно и даже вредно. Например, если у вас продуктовая разработка, в первую очередь ориентированная на клиента и его текущие потребности, стоит найти более гибкий подход к документации — для того, чтобы быстро реагировать на изменения рынка, в том числе конкурентной среды и потребительского спроса.Если говорить о ТЗ как о юридическом документе для договора между сторонами, то соблюдать ГОСТ целесообразно, но с некоторыми оговорками. А вот на стадии производства такой документ будет практически бесполезен, так как большинство методологий разработки требуют других подходов и к взаимодействию в команде, и к основному фокусу. Как правило, в центре продукта — пользователь, его инсайты, его реакция на приложение в целом и каждый отдельный элемент.
Что же с госсектором?
ТЗ по ГОСТ 34 для госзаказчиков — это преимущественно юридический документ. Однако, в составе конкурсной документации нет понятия "Техническое задание" — этот документ правильнее называть “техническими требованиями”.Посмотрим внимательно на состав ТЗ по ГОСТ 34, а именно:
- РД 50-34.698-90 "Автоматизированные системы. Требования к содержанию документов" (см.Приложение 1)
- ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания"
В ином случае будет сложно и бесполезно писать ТЗ к тому, что еще пока неизвестно. В составе конкурсной документации, как правило, такой документ будет содержать очень много “воды” и подобных формулировок: "Требования будут уточнены на стадии проектирования и зафиксированы в частном техническом задании (ЧТЗ)".
С другой стороны, в нашей практике были случаи, когда заказчик, чтобы снизить возможные риски, стремился создать ТЗ даже более подробное, чем предполагалось по ГОСТу.
В разработке, в отличие от конкурсной документации, ТЗ обычно используют в более развернутом виде (как частное техническое задание). Такой подход нацелен на более быстрое согласование формальностей, например, при проведении государственных торгов. Причина в том, что для госзаказчиков зачастую очень важны сроки, а торги занимают достаточно много времени.
В составе же техпроекта может быть больше документации, описывающей информационную систему такой, какой она должна быть (или такой, какая она есть на текущий момент).
Примеры: руководство пользователя, администратора, описание технических решений, пояснительная записка к проекту, программа и методика испытаний и так далее.
Также бывают случаи, когда на старте полная проработка системы не нужна. Например, для MVP не всегда возможно детально и точно описать всю систему, если нет детальной информации о тех модулях, которые будут добавлены в дальнейшем.
Что же делать?
Многие команды разработки стремятся найти гибкие решения для проектирования, подстраиваясь под пожелания крупного бизнеса и госсектора писать ТЗ по ГОСТ 34.В частности, разработчики могут сформировать для заказчика отдельный документ (например, на один из модулей системы) по ГОСТ 34, как ЧТЗ. В некоторых случаях подобный документ называют “описанием постановки задачи” (ОПЗ), и он содержит в своем составе описание бизнесовой части, схемы бизнес-логики на основании требований законодательства (НПА). В таком виде документация презентуется заказчику.
Если документация согласована, для команды разработки зачастую пишут новый документ, который имеет в своем составе больше технических деталей, описания алгоритмов, логики автоматизации, схемы логических моделей, интеграцию. Иначе говоря, это вопросы, которые могут не интересовать заказчика, но будут необходимы разработчикам.
Этот документ может быть оформлен не по ГОСТ 34 (так называемая "дельта" для разработки), в нем нет общих формулировок и "воды". Естественно основной документ в базе знаний постоянно актуализируется, после мержа туда таких вот "дельт".
Такой подход тоже не всегда эффективен, как правило, он применим после того, как общая архитектура приложения согласована и уже определены подходы, выбраны методы разработки, стек технологий. (Кстати, подозреваем, что, скорее всего, отсюда и пошло деление на бизнес-анализ и системный анализ).
Другие стандарты
Помимо ГОСТ, существуют международные стандарты по проектированию требований, зачастую более современные:- ISO/IEC/IEEE 29148:2018 "Программная и системная инженерия. Процессы жизненного цикла. Разработка требований"
- ISO/IEC 25010:2011 "Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программного обеспечения"
На такие стандарты опираются международные сертификационные организации, например, IREB (International Requirements Engineering Board). В нашей команде аналитики по желанию проходят сертификацию IREB, и по нашим наблюдениям, многие заказчики обращают на это внимание (хотя если у специалиста нет сертификации, он все равно может иметь глубокие знания).
Выводы
По нашему мнению, стандарты – вещь, безусловно, полезная. На них можно и нужно опираться. Но делать ГОСТ “священной коровой” и считать его единственно верным стандартом составления технической документации – ошибочно, поскольку стандарты постепенно устаревают морально, технически и лексически.Следуете ли вы ГОСТу или свободны в составлении документации, важно придерживаться нескольких принципов, направленных на качество требований. В их числе:
- полнота;
- однозначность;
- осуществимость;
- трассируемость (прослеживаемость);
- атомарность (независимость от других требований);
- абстрактность (независимость от способов реализации);
- непротиворечивость;
- проверяемость;
- лаконичность.
Всегда ли нужен ГОСТ при разработке крупных проектов?
При написании требований к информационной системе (ИС), если она предназначена для госсектора или отдельных крупных предприятий, от подрядчика ожидают соблюдения ГОСТ 34 или 19. Даже частные...
habr.com