Сегодня в своем блоге Сергей Назарук опубликовал выдержки из стандарта, согласно которому должны разрабатываться веб-сайты государственных структур. Интересный документ.
Тут же на Хабре поднялась волна обсуждений, где среди прочего звучат заявления о возрождении совка, “не мешайте нам делать свою работу… ну и прочие отрицательные мнения. Мне же документ видится очень нужным и полезным.
Зачем вообще нужны стандраты? Чтобы по-меньше думать при принятии каких-то решений. При этом за счет накопленных и собранных в стандарт знаний повысить качество этих решений. Приведу пример. В 80х годах военное ведомство США озадачилось процедурой выбора вендоров на разработку и поставку ПО. Как выбирать подрядчиков? Надо было ввести какие-то показатели-уровни компаний, чтобы отделить тех, кто работает надежно, от тех кто работает как попало. В иделе этот показатель всего одно число: 1,2,3,4,5… Компания уровня 5ть лучше, чем компания уровня 3, поэтому работаем с компанией уровня 5ть. Так появился стандарт CMMI (Capability Maturity Model Integration). У компании EPAM – 4й уровень (из 5ти), значит на рынке она выглядит привлекательнее тех у кого 2й или 3й.
Как-то мне приходилось сталкиваться с разработкой интернет-проектов для государственных органов. Занятие это непростое и сопряжено с массой рисков. Результат часто зависел только от качества налаженных отношений с конкретным чиновником. Но если его меняли – можно было выкидывать написанный продукт в мусор – его заместитель снова требовал странного. Единственный выход – четкая фиксация требований и каждого движения в проекте. Уже тогда я писал ТЗ по ГОСТам, что приводило в восторг чиновников.
Так зачем же нужен такой стандарт?
В настоящее время качество многих интернет-проектов государственных структур и агенств ниже плинтуса. Не секрет, что эти сайты разрабатывались как придется, процедуры их обновления не сущетсвует, о защите информации и говорить не стоит. Порой работа сваливается на нищего системного администратора.
Документ апплеирует к стандартам W3C, что должно сильно радовать веб-стандартистов, а также к ряду положений юзабилити-стандартов.
Позитивно то, что ряд требований уже сформировано на уровне стандарта. Это на прямую означает, что при составлении Технического задания можно ссылаться на положения данного стандарта. Когда я занимался аналитикой для белорусских проектов мне такого стандарта очень не хватало.
Не секрет, что приемка работ при работе на государственных заказчиков – это всегда проблема. Причин тут две:
Дело в том, что если четко не прописать в ТЗ нефункциональные требования, то заказчик может аппелировать к стандартам отрасли. Если бы мы жили в ЕС, то аппеляция была бы к стандартам ISO. И тут бы мало не показалось.
Вообще если коротко, то подобный стандарт снимает целый ряд вопросов и задает базис для принятия решений чиновниками. А если стандарт получится на выходе достаточно качественным, то имеет смысл ссылаться на него и при разработке коммерческих сайтов.
Мне смешно слышать, что с вводом подобного стандарта веб-разработчикам придется туго. :) Во-первых, можно заделать целый лейбл, что мы дескать делаем по стандарту – айда к нам! Во-вторых, отстроить под этом дело стройный процесс разработки – со стандартом-то оно проще.
При этом я не хочу сказать, что документ прекрасный, отличный и его надо принимать в неизменном виде. Я не читал весь документ, только то, что выложил Сергей. Из того, что прочитал – масса вещей очень по делу. Имеет право на жизнь.
Что плохо:
Если нормальные методологи дойдут до документа они поправят эти нюансы. В целом направление позитивное.
Тут же на Хабре поднялась волна обсуждений, где среди прочего звучат заявления о возрождении совка, “не мешайте нам делать свою работу… ну и прочие отрицательные мнения. Мне же документ видится очень нужным и полезным.
Зачем вообще нужны стандраты? Чтобы по-меньше думать при принятии каких-то решений. При этом за счет накопленных и собранных в стандарт знаний повысить качество этих решений. Приведу пример. В 80х годах военное ведомство США озадачилось процедурой выбора вендоров на разработку и поставку ПО. Как выбирать подрядчиков? Надо было ввести какие-то показатели-уровни компаний, чтобы отделить тех, кто работает надежно, от тех кто работает как попало. В иделе этот показатель всего одно число: 1,2,3,4,5… Компания уровня 5ть лучше, чем компания уровня 3, поэтому работаем с компанией уровня 5ть. Так появился стандарт CMMI (Capability Maturity Model Integration). У компании EPAM – 4й уровень (из 5ти), значит на рынке она выглядит привлекательнее тех у кого 2й или 3й.
Как-то мне приходилось сталкиваться с разработкой интернет-проектов для государственных органов. Занятие это непростое и сопряжено с массой рисков. Результат часто зависел только от качества налаженных отношений с конкретным чиновником. Но если его меняли – можно было выкидывать написанный продукт в мусор – его заместитель снова требовал странного. Единственный выход – четкая фиксация требований и каждого движения в проекте. Уже тогда я писал ТЗ по ГОСТам, что приводило в восторг чиновников.
Так зачем же нужен такой стандарт?
Планка качества
В настоящее время качество многих интернет-проектов государственных структур и агенств ниже плинтуса. Не секрет, что эти сайты разрабатывались как придется, процедуры их обновления не сущетсвует, о защите информации и говорить не стоит. Порой работа сваливается на нищего системного администратора.
Документ апплеирует к стандартам W3C, что должно сильно радовать веб-стандартистов, а также к ряду положений юзабилити-стандартов.
Формулировка требований
Позитивно то, что ряд требований уже сформировано на уровне стандарта. Это на прямую означает, что при составлении Технического задания можно ссылаться на положения данного стандарта. Когда я занимался аналитикой для белорусских проектов мне такого стандарта очень не хватало.
Приемка работ
Не секрет, что приемка работ при работе на государственных заказчиков – это всегда проблема. Причин тут две:
- Часто не хватает квалифицированных специалистов, чтобы провести приемку работ. Доказать, что ты прав – очень сложно. В результате приходится прописывать в ТЗ очень подробные требования к качеству.
- Разрастание требований. Понимая, что после приемки договор закрывается заказчик пытается протолкнуть новые и новые требования.
Дело в том, что если четко не прописать в ТЗ нефункциональные требования, то заказчик может аппелировать к стандартам отрасли. Если бы мы жили в ЕС, то аппеляция была бы к стандартам ISO. И тут бы мало не показалось.
Вообще если коротко, то подобный стандарт снимает целый ряд вопросов и задает базис для принятия решений чиновниками. А если стандарт получится на выходе достаточно качественным, то имеет смысл ссылаться на него и при разработке коммерческих сайтов.
Мне смешно слышать, что с вводом подобного стандарта веб-разработчикам придется туго. :) Во-первых, можно заделать целый лейбл, что мы дескать делаем по стандарту – айда к нам! Во-вторых, отстроить под этом дело стройный процесс разработки – со стандартом-то оно проще.
При этом я не хочу сказать, что документ прекрасный, отличный и его надо принимать в неизменном виде. Я не читал весь документ, только то, что выложил Сергей. Из того, что прочитал – масса вещей очень по делу. Имеет право на жизнь.
Что плохо:
- Использование качественных определений. “Элементы страницы должны легко идентифицироваться” – неясно, что значит легко? Следует избегать подобных формулировок в стандартах и требованиях.
- Нечеткая структура. Например, про безопасность в разделе Дизайн. :)
Если нормальные методологи дойдут до документа они поправят эти нюансы. В целом направление позитивное.
