О ГОСТах на ГОСсайты

    Сегодня в своем блоге Сергей Назарук опубликовал выдержки из стандарта, согласно которому должны разрабатываться веб-сайты государственных структур. Интересный документ.

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

    Зачем вообще нужны стандраты? Чтобы по-меньше думать при принятии каких-то решений. При этом за счет накопленных и собранных в стандарт знаний повысить качество этих решений. Приведу пример. В 80х годах военное ведомство США озадачилось процедурой выбора вендоров на разработку и поставку ПО. Как выбирать подрядчиков? Надо было ввести какие-то показатели-уровни компаний, чтобы отделить тех, кто работает надежно, от тех кто работает как попало. В иделе этот показатель всего одно число: 1,2,3,4,5… Компания уровня 5ть лучше, чем компания уровня 3, поэтому работаем с компанией уровня 5ть. Так появился  стандарт CMMI (Capability Maturity Model Integration). У компании EPAM – 4й уровень (из 5ти), значит на рынке она выглядит привлекательнее тех у кого 2й или 3й.

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

    Так зачем же нужен такой стандарт?

    Планка качества


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

    Документ апплеирует к стандартам W3C, что должно сильно радовать веб-стандартистов, а также к ряду положений юзабилити-стандартов.

    Формулировка требований


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

    Приемка работ


    Не секрет, что приемка работ при работе на государственных заказчиков – это всегда проблема. Причин тут две:
    • Часто не хватает квалифицированных специалистов, чтобы провести приемку работ. Доказать, что ты прав – очень сложно. В результате приходится прописывать в ТЗ очень подробные требования к качеству.
    • Разрастание требований. Понимая, что после приемки договор закрывается заказчик пытается протолкнуть новые и новые требования.

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

    Вообще если коротко, то подобный стандарт снимает целый ряд вопросов и задает базис для принятия решений чиновниками. А если стандарт получится на выходе достаточно качественным, то имеет смысл ссылаться на него и при разработке коммерческих сайтов.

    Мне смешно слышать, что с вводом подобного стандарта веб-разработчикам придется туго. :) Во-первых, можно заделать целый лейбл, что мы дескать делаем по стандарту – айда к нам! Во-вторых, отстроить под этом дело стройный процесс разработки – со стандартом-то оно проще.

    При этом я не хочу сказать, что документ прекрасный, отличный и его надо принимать в неизменном виде. Я не читал весь документ, только то, что выложил Сергей. Из того, что прочитал – масса вещей очень по делу. Имеет право на жизнь.

    Что плохо:
    • Использование качественных определений. “Элементы страницы должны легко идентифицироваться” – неясно, что значит легко? Следует избегать подобных формулировок в стандартах и требованиях.
    • Нечеткая структура. Например, про безопасность в разделе Дизайн. :)


    Если нормальные методологи дойдут до документа они поправят эти нюансы. В целом направление позитивное.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 34

      0
      Я тоже крайне положительно отнесся к такой затее. Правда почему-то представляется такая картина: чиновник(без IT образования) приходит домой и говорит сыну кулхацкеру восьмилетнему: ты в компах разбираешься, напиши мне, какими должны быть хорошие сайты :)

      Интересно, насколько реально в такой стандарт для гос. сайтов встроить некие описания стандартов интерфейсов для взаимодействия между сайтами или с центральным гос. сайтом. Чтобы, ну просто к примеру, на центральном сайте абсолютно автоматически обновлялся список всех новых гос. сайтов (соответствующих стандарту), а так же выводились важные новости со всех гос. сайтов и тд и тп.
        +3
        PS в России почему же никто не задумывается о таком стандарте? Который бы еще описывал и задавал критерии для тендеров… А то от сумм на разработку убогих гос. сайтов у меня волосы дыбом встают…
          +1
          Ибо тогда распилить не получится. на конкретные требования — конкретный объем оплачиваемых работ, не получится выбить большой бюджет и отдать разработку Васе-админу, в счет премии к зарплате, а денюжку себе положить в карман.
        • UFO just landed and posted this here
            0
            RSS ленты можно организовать как угодно и разместить их где угодно. Я не о том, чтобы придумать новую технологию публикации, генерации или получения информации. Я о том, чтобы стандартизировать местоположения и форматы ключевых ссылок, указать какие технологии должны использоваться обязательно.
          0
          Обычно всякие большие компании с кучей подразделений могут заказать себе подобный документ и заказывают.

          Здесь более важный вопрос звучит так: Кто разрабатывал данный стандарт?
            +11
            Наличие такого ГОСТа полезно хотя бы тем, что в ТЗ на разработку сайтов для гос.органов теперь не нужно будет на 10 страницах расписывать базовые требования по соответствию стандартам, структурированности и юзабилити. Достаточно будет написать всего одну строчку «Сайт должен соответствовать ГОСТ12345-10», а отдельно в ТЗ расписывать только специфические требования.

            Т.е. ГОСТ задаёт единый шаблон основных требований, которые едины для всех гос.сайтов.
              +6
              Некоторые ГОСТ-ы — очень даже благое дело. Вот недавно вышел ГОСТ по управлению проектами. В америке уже давно был свой PMBok, в Великобритании — PRINCE, теперь и у нас свой есть. Я знаю людей, которые разрабатывали отечественный стандарт — они действительно спецы в этой области. Мне нравится тенденция по подобной стандартизации
                +1
                Сначала прочел пост, откомментил, а только потом понял что речь идет про Байнет, а не Рунет. Прошу прощения;)
                  0
                  ГОСТ вообще действует во всем СНГ, если не заменен местным стандартом.
                    +2
                    ГОсударственный СТандарт. Я слышал о каком-то мифическом союзном государстве, но не думал, что ГОСТЫ разработанные в Белоруссии после развала СССР без участия РФ становятся общими стандартами для всего СНГ. Предлагаю разработать такой стандарт, который поставит в очень невыгодное положение весь СНГ как в случае следования ГОСТ, так и в случае отказа от следования ему :)
                      0
                      Я имел ввиду ГОСТ по управлению проектами.
                      Белорусский ГОСТ в РФ, понятно, не действует. Хотя он вроде вполне вменяемый.
                +1
                Я считаю что для гос. сайтов стандарт просто обязателен. Ибо чиновники у нас…
                  +1
                  У EPAM 5??????? Извините, конечно, но контора пишет откровенный ужас.

                  Сталкивался много раз с приложениями (в том числе и веб, которые, я считаю, я достаточно адекватно могу оценить), в которых на странице прогружается несколько десятков ресурсов (css/js), половина из которых заканчивается в 404. Молчу уже про то, что сайт на www выглядел точно так же, как и без www, но при этом половина js-кода не работала (потому что не была подгружена или делала неправильные ajax-запросы)
                    0
                    Упс, у EPAM 4, пардоньте, но положения дел не меняет.
                      +1
                      EPAM большой. Есть проекты, которыми некоторые из посетителей данного сообщества пользуются каждый день. Но никто не знает, что это делает Епам. Есть и мелкие проекты с низким уровнем качества.
                      Связь между уровнем CMMI и качеством работы — это отдельный большой разговор. :)
                        0
                        Следует отметить в таком случае, что и связи «размер проекта — качество проекта» быть не должно. Иначе говоря, «мелкие проекты с низким уровнем качества» — это очень плохо :)
                          0
                          Согласен речь скорее о бюджете проекта и интереса к нему со стороны руководства. :)
                    +2
                    надо бы сделать банеры вроде «XHTML 1.0 valid», только «соответствует ГОСТ ХХХХ-ХХ», с учётом того, что сердцевиной ГОСТа является WAI и сразу есть упоминание про мобильные платформы, то всё очень здорово
                      +1
                      Оо
                      –1
                      CMMI говорите? не смешите мои тапочки
                      общеизвестно, что оценка стандартизирования контор по этой лавочке не имеет ничего общего с качеством продукта
                      особенно в россии
                      пост — заказуха, либо автор имеет отношение к этой самой стандартизации :)
                        0
                        Не обижайтесь, я просто много знаю об особенностях CMMI сертификации в России в частности, а по поводу стандартизации вообще — ничто не помешает делать с соблюдением всех стандартов, сроков, технологии процесса и его организации ПОЛНОЕ ГОВНО. Примеров масса, не только в IT
                          +1
                          Ну так во-первых речь не про Россию все-таки. А во-вторых никто и не утверждает, что ГОСТ на гос сайты сразу сделает их хорошими. К сожалению абсолютное ГОВНО можно сделать из всего, а вот качественный продукт…
                          Про CMMI в статье речь идет про США, а то как у нас вводят разного рода стандартизации и как получаются по ним хорошие оценки, я думаю все и так знают.

                          А с автором я соглашусь, что потенциал у таких начинаний большой, главное что бы не превратили в очередной распил.
                            0
                            Не очень представляю экономику, но где на составлении стандарта можно чего-то распилить?
                              –1
                              И много компаний с CMMI 5 мы знаем? =)

                              Лучше бы написали в ГОСТе CMMI 3 и спилили бы денег =)
                            0
                            А где я писал, что уровень CMMI как-то коррелирует с качеством работы? У меня написано про «привлекательность на рынке». То что у большинства это показуха — да. Я с этим согласен.
                            То, что можно по любой красивой методике сделать говно — тоже. Поэтому не понял в чем вы со мной не согласны. ;)
                              0
                              тогда — извините, пробежался по вершкам
                              –2
                              «пост — заказуха»
                              — заказуха от белоруских чиновников?
                              — от НЛО?
                              второе гораздо более вероятно, — вот тут уже «не смешите мои тапочки»
                                0
                                Ой, ну я вас умоляю!..
                              +1
                              ГОСТ может быть и устарел, но все равно благотворно влияет на качество проектов.
                              А то некоторые фирмы-«внедрители» вообще не утруждают себя составлением приличной документации.
                              Например, сетку провели — нет ни документации, ни плана, ни маркировки — ничего. А в ГОСТе ведь все требования прописаны.
                                +2
                                В принципе, так и есть. В ТЗ пишем: «ГОСТ ### + специфические требования». Во-первых, это уменьшает объём ТЗ. Во-вторых, чуть сложнее будет 90% присвоить, а на 10% нанять явных халтурщиков, которые, например, не проверяют HTML на корректность или бросают сайт после его сдачи. В общем, даже такой куцый стандарт — большой плюс.
                                  0
                                  В посте высказаны очень правильные мысли. Создание стандарта создаст фундамент для формирования грамотного рынка создания веб-сайтов. Т.е. в нем будут прописаны основные положения которым должен соответствовать создаваемый сайт. А если действительно появится хороший стандарт и его станут использовать коммерческие студии — вообще хорошо будет.

                                  У нас в Казахстане его очень не хватает. Все сайты разношерстные, непонятно какой сайт государственного учреждения какой-нет. В общем хаос. Нужны правила.
                                    0
                                    Жалко нищего системного администратора =( Аж грустно стало, хоть и упомянут был образно…
                                      0
                                      В веб-разработках регламентирующая техдока может, разве что определить количественную сторону проекта. Качественную сторону описывать устанете и никогда не опишите так чтобы какой-нибудь «олух» не сделал проект и не смог отбиться фразой «все как в ТЗ или стандарте». Отсыл к валидности, конечно на радость стандартофилов — но я могу показать тонны валидных и до нельзя убогих при этом сайтов. Чуть раньше мы у себя тоже весьма подробно делились мыслями на схожую тему — blog.artsofte.ru/blog/post/id/171

                                      Only users with full accounts can post comments. Log in, please.