Комментарии 20
Спасибо, как раз искал
реальность
Автору статьи — большое спасибо! Понимание рекомендаций ГОСТ и следование этим рекомендациям — как минимум треть (а то и половина) успеха внедрения системы (в т.ч. и на готовых продуктах, без разработки). Разными словами для разных собеседников я часто рассказываю об этом, а вот подготовить систематизированный материал как-то не собрался. Еще раз спасибо — эта статься является инструментом прямого действия при рассказе исполнителям и заказчикам о том, как нужно согласовывать и документировать требования.
ГОСТ 34 устарел именно из-за того, что это стандарт для разработки автоматизированных систем. А большинство разрабатываемых сейчас систем выходит за рамки определения АС. К сожалению, на это определение внимательно никто не смотрит, и сплошь и рядом считают, что любой программный продукт можно подвести под это определение.
В первую очередь, он устарел как раз из-за того, что в АС люди считаются «персоналом» — винтиками системы. Это отношение к людям как к персоналу выводит на первый план потребности организации и реализацию необходимых только ей функций. Это было так, когда вычислительные машины были большими и дорогими, это перестало быть так с появленим персональных компьютеров, и стало совсем не так с массовым распространением интернета.
При попытке применить ГОСТовский подход к системам, предоставляющим какой-то сервис для людей, получается как в анекдоте про детскую коляску и автомат Калашникова. Это было очень хорошо видно по первой версии портала госуслуг, например. И по-прежнему видно по сайтам, разрабатываемым по заказам госорганизаций, где ГОСТ очень любят.
Устарела и сама концепция видов обеспечения. Люди упорно пишут в раздел требований к лингвистическому обеспечению что-то вроде "интерфейс пользователя должен быть на русском языке". И правильно делают, потому что проблема лингвистического обеспечения давно решена и опустилась с уровня бизнес-требований в самый низ, на уровень реализации.
Опасность ГОСТа в том, что он кажется со стороны полноценной и законченной методикой разработки требований. Но, во-первых, он ей не является. Стандарт описывает результаты работ по выявлению и описанию требований, но не говорит практически ничего об их содержании. А во-вторых, он токсичен. Начав работать по ГОСТу, вы всё больше погружаетесь в болото его концепций. Эти концепции очень трудно изжить. Если вы после этого перейдёте в проект разработки продукта, который не подходит под определение АС, то ГОСТовский образ мышления будет отравлять ваш продукт. Вы будете думать в первую очередь о функциях, и в последнюю о людях (лично я это постоянно вокруг себя наблюдаю).
Если вам всё же не повезло в этой жизни, и вы вынуждены работать по ГОСТу, то, кроме искреннего сочувствия, могу вам посоветовать изучить его предшественника: серию стандартов ГОСТ 24. Тогда речь шла даже не об АС, а об АСУ — автоматизированных системах управления. Сама концепция АСУ вам вряд ли пригодится, но вы, по крайней мере, лучше поймёте значение многих терминов, которые используются в ГОСТ 34. Разработчики ГОСТ 34 использовали эти термины в предположении, что их и так уже все знают, поэтому ГОСТ 34 очень (даже слишком) лаконичен.
В первую очередь, он устарел как раз из-за того, что в АС люди считаются «персоналом» — винтиками системы. Это отношение к людям как к персоналу выводит на первый план потребности организации и реализацию необходимых только ей функций. Это было так, когда вычислительные машины были большими и дорогими, это перестало быть так с появленим персональных компьютеров, и стало совсем не так с массовым распространением интернета.
При попытке применить ГОСТовский подход к системам, предоставляющим какой-то сервис для людей, получается как в анекдоте про детскую коляску и автомат Калашникова. Это было очень хорошо видно по первой версии портала госуслуг, например. И по-прежнему видно по сайтам, разрабатываемым по заказам госорганизаций, где ГОСТ очень любят.
Устарела и сама концепция видов обеспечения. Люди упорно пишут в раздел требований к лингвистическому обеспечению что-то вроде "интерфейс пользователя должен быть на русском языке". И правильно делают, потому что проблема лингвистического обеспечения давно решена и опустилась с уровня бизнес-требований в самый низ, на уровень реализации.
Опасность ГОСТа в том, что он кажется со стороны полноценной и законченной методикой разработки требований. Но, во-первых, он ей не является. Стандарт описывает результаты работ по выявлению и описанию требований, но не говорит практически ничего об их содержании. А во-вторых, он токсичен. Начав работать по ГОСТу, вы всё больше погружаетесь в болото его концепций. Эти концепции очень трудно изжить. Если вы после этого перейдёте в проект разработки продукта, который не подходит под определение АС, то ГОСТовский образ мышления будет отравлять ваш продукт. Вы будете думать в первую очередь о функциях, и в последнюю о людях (лично я это постоянно вокруг себя наблюдаю).
Если вам всё же не повезло в этой жизни, и вы вынуждены работать по ГОСТу, то, кроме искреннего сочувствия, могу вам посоветовать изучить его предшественника: серию стандартов ГОСТ 24. Тогда речь шла даже не об АС, а об АСУ — автоматизированных системах управления. Сама концепция АСУ вам вряд ли пригодится, но вы, по крайней мере, лучше поймёте значение многих терминов, которые используются в ГОСТ 34. Разработчики ГОСТ 34 использовали эти термины в предположении, что их и так уже все знают, поэтому ГОСТ 34 очень (даже слишком) лаконичен.
Мне кажется, что вам просто «повезло» встретиться с людьми, использующими ГОСТ для галочки, а не для реальной работы. С Госуслугами, скорее всего, тоже так. Работаю много с госконтрактами: да, там всюду ГОСТ, и почти всюду в какой-то извращенной форме. К сожалению, в большинстве контор разработка и составление документов — абсолютно непересекающиеся процессы. Это не работа по ГОСТ, а мазохизм.
И ГОСТ 34 очень гибкий: добавляй, удаляй что хочешь, это прямо прописано. Голову-то никто не отменял. Смотришь один стандарт, смотришь другой, берешь оттуда нужное тебе, и вперед.
Ну и про то, что люди считаются персоналом, винтиками, в этом я с вами не согласен. Точенее, согласен, что так и есть, но не по ГОСТу, а в наших реалиях. Не вижу ничего плохого в том, чтобы определить количество необходимых нам людей, их квалификацию, продумать план их обучения. Или вечный бардак сделай то не знаю что лучше?
В общем, мне кажется, что кто-то вас сильно достал с ГОСТом, но этот кто-то, скорее всего, неправильно его применяет.
И ГОСТ 34 очень гибкий: добавляй, удаляй что хочешь, это прямо прописано. Голову-то никто не отменял. Смотришь один стандарт, смотришь другой, берешь оттуда нужное тебе, и вперед.
Ну и про то, что люди считаются персоналом, винтиками, в этом я с вами не согласен. Точенее, согласен, что так и есть, но не по ГОСТу, а в наших реалиях. Не вижу ничего плохого в том, чтобы определить количество необходимых нам людей, их квалификацию, продумать план их обучения. Или вечный бардак сделай то не знаю что лучше?
В общем, мне кажется, что кто-то вас сильно достал с ГОСТом, но этот кто-то, скорее всего, неправильно его применяет.
Вы сильно не правы.
1. любая ИС/АС создаётся во исполнения какой либо функции/задачи, результатом этой функции/задачи пользуются люди. В чём сложность описать это в ТЗ по ГОСТ. В чём сложность описать пользователей ИС как совокупность персонала с определённой квалификацией и внешних пользователей. Более того когда вы создаёте любую ИС то расчитываете на определённые знания человека, который увидит интерфейс.
2. Описанная Вами ситуация ( «интерфейс пользователя должен быть на русском языке») говорит о галочном подходе, не понимание своих хотелок, неумении проектировать.
3. Задача любого стандарта формализовать подход, создать принцип. Я неоднократно сталкивались с людьми заявляющими «ГОСТ устарел», «ТЗ пережитки», «проект — лишняя трата денег». Как показывает практика эти люди не понимают что такое жизненный цикл, почему он выглядит именно так, почему попытка обойти его заканчивается крахом.
1. любая ИС/АС создаётся во исполнения какой либо функции/задачи, результатом этой функции/задачи пользуются люди. В чём сложность описать это в ТЗ по ГОСТ. В чём сложность описать пользователей ИС как совокупность персонала с определённой квалификацией и внешних пользователей. Более того когда вы создаёте любую ИС то расчитываете на определённые знания человека, который увидит интерфейс.
2. Описанная Вами ситуация ( «интерфейс пользователя должен быть на русском языке») говорит о галочном подходе, не понимание своих хотелок, неумении проектировать.
3. Задача любого стандарта формализовать подход, создать принцип. Я неоднократно сталкивались с людьми заявляющими «ГОСТ устарел», «ТЗ пережитки», «проект — лишняя трата денег». Как показывает практика эти люди не понимают что такое жизненный цикл, почему он выглядит именно так, почему попытка обойти его заканчивается крахом.
Между тем в стране по прежнему разрабатывается множество АС, не ориентированных на персонал, а не на потребителей. И именно для их реализации зачастую ГОСТ 34 и применяется.
"ГОСТ 34 устарел именно из-за того, что это стандарт для разработки автоматизированных систем."
Я тут подумал, и кажется кое-что понял.
Дело не в том, что "устарел", а в том, что "это другое".
ГОСТ 34 и то что он регламентирует (создание АС) - это создание инструмента.
А современная разработка (сайты, веб-приложения) - это создание продукта!
Инструмент - это то, что решает задачи бизнеса, предприятия.
Продукт - это то, что "продают" широкому кругу пользователей. Продают также в широком смысле. Яндекс-карты не просят денег у пользователя, но им необходимо понравиться пользователю и выиграть у конкурентов, чтобы монетизировать свой продукт.
Конечно же это требует очень разных подходов ко всему. В случае АС можно вписать в ТЗ обучение персонала и компенсировать этим сложность интерфейса, с продуктом - так не получится - пользователи просто уйдут к конкуренту.
По факту получается следующее: на стратегическом уровне, уровне разработки базы и ключевых расчетных механизмов - обычная проектная технология а-ля ГОСТ34. А когда переходишь на стадию внедрения, то начинается куча мелких и не очень доработок уже по факту поступления запросов от пользователей или от членов команды, которые видят, что получается не то, что хотели.
Поверьте, за Яндекс.Карты - это очень сложный Инструмент: создать карты по спутниковым снимкам, склеить квадратики, начертить граф дорог, создать изображения для разных масштабов (генерализация), создать базу объектов и нанести их на карту. Это огромная работа. То есть Продукт - это только внешняя и очень малая часть Инструмента. Продукт без Инструмента работать не будет, даже Youtube.
А какие есть альтернативы?
За статью спасибо — для тех, кому приходиться работать с ГОСТами Вашу статью можно использовать в качестве чек-листа.
Но вот с Вашим утверждением «легко и просто» согласиться не могу.
По моему опыту все действительно легко и просто на внутреннем проекте, когда одни и те же специалисты одна команда и создает документ и впоследствии работает по нему же. В этом случае качество проработки документа именно такое, которое необходимо для дальнейшей работы над системой.
Но как только ТЗ по ГОСТу используется в отношениях Заказчик — Исполнитель на внешних проектах, то значительная часть документа превращается в «воду».
У госпредприятия (а ведь именно они живут по ГОСТам) нет денег ни на предпроектное обследование, ни на аналитика. А в закупку нужно предоставить именно ТЗ и именно по ГОСТу. И часто документ пишется бизнесом напополам со специалистом техподдержки. И они 15 страниц ГОСТа трактуют как бог на душу положит.
И то, что некоторые разделы ТЗ можно использовать в качестве защиты исполнителя я сомневаюсь. Вы действительно полагаете, что заказчик в протоколе испытаний так и напишет что система не работает потому что не хватает персонала?
По моему мнению ГОСТы действительно устарели, т.к. выражаясь Вашими же словами написаны общими словами «за все хорошее, против всего плохого». Шаблонов внутри себя не содержат, требуют составления таблиц «чтобы не запутаться». Без опыта, при чем без правильного опыта, их крайне сложно применять.
Но вот с Вашим утверждением «легко и просто» согласиться не могу.
По моему опыту все действительно легко и просто на внутреннем проекте, когда одни и те же специалисты одна команда и создает документ и впоследствии работает по нему же. В этом случае качество проработки документа именно такое, которое необходимо для дальнейшей работы над системой.
Но как только ТЗ по ГОСТу используется в отношениях Заказчик — Исполнитель на внешних проектах, то значительная часть документа превращается в «воду».
У госпредприятия (а ведь именно они живут по ГОСТам) нет денег ни на предпроектное обследование, ни на аналитика. А в закупку нужно предоставить именно ТЗ и именно по ГОСТу. И часто документ пишется бизнесом напополам со специалистом техподдержки. И они 15 страниц ГОСТа трактуют как бог на душу положит.
И то, что некоторые разделы ТЗ можно использовать в качестве защиты исполнителя я сомневаюсь. Вы действительно полагаете, что заказчик в протоколе испытаний так и напишет что система не работает потому что не хватает персонала?
По моему мнению ГОСТы действительно устарели, т.к. выражаясь Вашими же словами написаны общими словами «за все хорошее, против всего плохого». Шаблонов внутри себя не содержат, требуют составления таблиц «чтобы не запутаться». Без опыта, при чем без правильного опыта, их крайне сложно применять.
Полностью с вами согласен, кроме двух вещей: 1) Того, что ГОСТы устарели. Может, в чем-то и устарели, но ничего нового сопоставимого ни у нас, ни за рубежом не знаю. ИСО и IEEE со всех сторон так проект автоматизации не охватывают. 2) Того, что в ГОСТе нет шаблонов. Вот как раз этого там хватает. Приводится содержание около 60-и документов для разных стадий: выбирай не хочу. И фраза про общие слова «за все хорошее против всего плохого» относится не к ГОСТу, а к тем, кто пишет всякую ерунду, лишь бы разделы заполнить. Я как раз за то, чтобы воду исключать. ГОСТ позволяет делать с документами что хочешь, он очень гибкий. Это просто шаблон, а мы можем его использовать как хотим.
Ну а про госзаказчиков (да и других) отдельная тема. Если нет понимания проекта автоматизации, того, что нужно попотеть самим, то никакие стандарты и самое лучшее ТЗ не помогут. Плохому танцору известно что мешает.
Ну а про госзаказчиков (да и других) отдельная тема. Если нет понимания проекта автоматизации, того, что нужно попотеть самим, то никакие стандарты и самое лучшее ТЗ не помогут. Плохому танцору известно что мешает.
Насчет «легко и просто» — это можно сказать маркетинговый ход, чтобы заголовок привлекал. Конечно, составление ТЗ — тяжкий труд. Да и вообще разобраться в ГОСТ 34 сложно: не потому, что ГОСТ плохой, а потому, что проект автоматизации — крайне сложная штука.
Спасибо за замечательную статью! Единственное, на что хотел обратить внимание: «Например, если вы точно знаете, что в ваших разработках не может быть ничего патентованного, то зачем приводить требования к патентной чистоте? ». Вопрос проведения патентных исследований при выполнении проектов весьма обширный и ВАЖНЫЙ!!! И они должны проводиться не только ради возможности патентования технических решений, и патентная чистота обеспечит отсутсвие возможного нарушения прав третьих лиц. Поэтому с указанием требований в ТЗ на создание АС соответвующих требований (да и вообще в рамках проектов) — отдельная тема.
Андрей, привет!
7.1.6. Пункт 4.1.6. «Требования к эргономике и технической эстетике» /п. 2.6.1.6 ГОСТ 34.602-89/
Тут давно уже не надо писать ничего про красивость и число кликов, есть стандарты на человеко-машинное взаимодействие, можно предъявлять конкретные измеримые требования как минимум к:
* Результативности
* Эффективности
ГОСТ Р ИСО 9241-210-2012. Эргономика взаимодействия человек-система. Часть 210. Человеко-ориентированное проектирование интерактивных систем
standard.gost.ru/wps/wcm/connect/d661e080413f5db8a4e9fe7ab9890bef/GOST_R_ISO_9241-210-2012.pdf?MOD=AJPERES
Число кликов не гарантирует высокую пригодность использования (usability), можно вывалить на главной странице интернет-магазина весь каталог, кликай один раз для выбора товара — не хочу!
Важны когнитивные и временные усилия, которые как раз в плане результата меряются Результативностью и Эффективностью.
7.1.6. Пункт 4.1.6. «Требования к эргономике и технической эстетике» /п. 2.6.1.6 ГОСТ 34.602-89/
Тут давно уже не надо писать ничего про красивость и число кликов, есть стандарты на человеко-машинное взаимодействие, можно предъявлять конкретные измеримые требования как минимум к:
* Результативности
* Эффективности
ГОСТ Р ИСО 9241-210-2012. Эргономика взаимодействия человек-система. Часть 210. Человеко-ориентированное проектирование интерактивных систем
standard.gost.ru/wps/wcm/connect/d661e080413f5db8a4e9fe7ab9890bef/GOST_R_ISO_9241-210-2012.pdf?MOD=AJPERES
Число кликов не гарантирует высокую пригодность использования (usability), можно вывалить на главной странице интернет-магазина весь каталог, кликай один раз для выбора товара — не хочу!
Важны когнитивные и временные усилия, которые как раз в плане результата меряются Результативностью и Эффективностью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка Технического задания по ГОСТ 34 легко и просто