Не читайте стандарты на ночь

Не читайте стандарты на ночь
Марина Аншина | 17.03.2014
Что приходит вам в голову при слове «стандарты»? Скорей всего — это что-то нужное, но скучное и унылое. Вряд ли кто-то станет читать стандарты для удовольствия, если только перед сном, чтобы быстрей уснуть. 

В 2002 году по закону «О техническом регулировании» большинство стандартов стали добровольными. И развитие стандартизации ИТ в России практически остановилось. То есть, конечно, стандарты иногда разрабатывают, чаще переводят, адаптируют, принимают, но поскольку отсутствует система их продвижения, то «новыми» стандартами никто не пользуется. Зачем читать документ, который необязателен? Зачем использовать то, что никто не требует использовать? А чтобы быстрее уснуть, есть много разных других способов... 

Однако во всем мире и в разных областях стандарты играют значительную роль. Хотя они не только в ИТ представляют собой не самые увлекательные документы. Потому что являются основой взаимоотношений, в том числе продавца и покупателя или исполнителя и заказчика. И при таком подходе отношение к ним становится совершенно иным. Ведь и договоры не самые увлекательные документы, хотя стороны обычно читают их очень внимательно. (Подчеркиваю слово «обычно», потому что недавно мне попался договор, в котором было сказано буквально следующее: «Стоимость работ составляет ХХХХХ чел./час., в том числе НДС 18%».) Но, кажется, большинство участников рынка уже научилось отводить договорам важное место.

Но договор, в частности в ИТ, не может вместить все тонкости взаимодействия заинтересованных сторон. В противном случае подготовка договора станет делом более трудоемким и долговременным, чем его выполнение. Например, если договор касается разработки ПО, то обстоятельный заказчик захочет удостовериться, что основные процессы организованы правильно, что они приведут к созданию качественного ПО, соответствующего его потребностям, что документация будет содержать все необходимое для использования и развития ПО и что передача продукта в эксплуатацию совершится к общему удовольствию. Если записать в договоре или в сопровождающей его документации, что ТЗ должно быть сделано по ГОСТ 34 (что чаще всего происходит) или по ИСО/МЭК 15289 (что больше соответствует современному уровню развития ПО), то обеим сторонам понятно, что имеется в виду (при условии, что они знают указанные стандарты). Но еще важнее то, что если в дальнейшем возникнут разногласия и исполнитель будет считать, что сделал ТЗ как надо, а заказчик с ним, мягко говоря, не согласится, и они обратятся в суд, — будет достаточно просто определить, кто из них прав.

Прошлые привычки

Возможно, наше отечественное, несколько пренебрежительное отношение к стандартам связано с тем, что в недавнем прошлом, то есть в СССР, стандарты были обязательны к исполнению, и нам частенько по молодости казалось, будто они только мешают и без них работа шла бы успешнее. И как только «вожжи» отпустили, мы все дружно вырвались на волю. И тут оказалось, что без стандартов трудно работать. Я далека от того, чтобы все беды отечественных ИТ приписать недостаточному использованию стандартов. Конечно, причины глубже, а отсутствие стандартов, кстати, один из признаков затянувшегося кризиса. Но вместе с тем полное игнорирование этих полезных инструментов организации деятельности несомненно влечет за собой серьезные проблемы для отрасли.

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

То же ТЗ, в конце концов, все представляют себе по-разному. Кто-то понимает под этим развернутый план вплоть до технического проекта, кто-то — только технические требования без детализации, что именно предстоит сделать. И лавиной идут взаимные обвинения в некомпетентности и недобросовестности. 

Объединяющая роль стандартов

Очевидно, что стандарты способны принести большую пользу и как объединяющее отрасль начало. Совместная работа над стандартами может послужить той осью, вокруг которой удастся собрать взаимодействующие стороны. Они часто осознают себя противоборствующими, хотя такой подход только вредит каждой из них. Ситуация «win-win», при которой каждая сторона выигрывает, для ИТ-проектов и ИТ-сервисов является, по-моему, необходимым условием успеха. Пока игроки рынка этого не осознали и всячески пытаются либо надуть, либо не доплатить противной стороне, положение не улучшится.
С удовольствием наблюдаю случаи, когда работа над стандартами ведется именно таким совместным образом. В частности, это относится к созданию некоторых профессиональных стандартов под эгидой АПКИТ (представитель исполнителя). Например, стандарт менеджера по ИТ разрабатывал СОДИТ (представитель заказчика), привлекая различные стороны, обладающие компетенциями и заинтересованные в создании и внедрении такого стандарта. Очень надеюсь, что подобный опыт будет только развиваться и привлечет наиболее знающих и неравнодушных профессионалов. Я искренне рекомендую участвовать в этом представителей обеих сторон. Разработчики стандартов всегда заинтересованы в том, чтобы их стандарт использовался. А для этого им надо добиться, чтобы в его разработке принимали участие компетентные и разносторонние специалисты, способные исследовать проблему с разных точек зрения:

1. Привлечь к разработке стандарта представителей всех заинтересованных в его использовании сторон.
2. Организовать максимально широкое обсуждение стандарта.
3. Учесть и обработать все поступившие замечания.
4. Разработать и осуществить распространение стандарта.
5. Обеспечить его полноценный жизненный цикл.

Не ищите универсальный рецепт

Не могу не отметить еще одну проблему внедрения современных стандартов. Не секрет, что большинство из них являются рамочными, то есть описывают границы, в которых должен находиться предмет стандарта. Современные стандарты всегда (кроме строгих норм безопасности) оставляют свободу тем, кто их использует. Однако, как я писала выше, в головах ИТ-специалистов и ИТ-менеджеров витает образ советского стандарта как однозначной инструкции о том, как и что делать. Хотя вот что интересно: тот же ГОСТ 34, точнее серию ГОСТов, если присмотреться повнимательнее, можно рассматривать так же как рамочные. К сожалению, имея достаточный опыт обучения ИТ-менеджеров, могу сказать, что они нередко просили: «А скажите, как нам делать то-то и то-то — например, внедрять АС или выбирать поставщика?» И все мои попытки объяснить, что не бывает готовых рецептов, что надо учитывать множество факторов, связанных как с «больным», так и с окружающей его реальностью, не встречали никакого понимания. Скажу больше: применение готовых ИТ-рецептов или ИТ-стандартов одной компании в другой ни к чему хорошему привести не может, просто потому, что она — ДРУГАЯ! Поэтому не ждите, что кто-то на блюдечке с голубой каемочкой принесет вам готовый стандарт, который осчастливит вашу организацию по крайней мере во всем, что касается ИТ. Только напряженная умственная, организационная и техническая работа позволит на основе стандартов построить ИТ так, как вам нужно. 

Почему я так назвала статью? Потому что читать на ночь столь серьезные и важные документы просто опасно: и не уснешь, и не поймешь. Так что прямо завтра с утра берите, что у вас там есть из гаджетов, и читайте, читайте, читайте стандарты. И думайте, как они вам могут помочь в вашей текущей и будущей работе. А они могут...

Теги: стандарты, практики, задачи, стратегии

Журнал IT-Manager    [ PDF ]    [ Подписка на журнал ]

Об авторе


Марина Аншина

Марина Аншина

Председатель Комитета по стандартам Российского Союза ИТ-директоров.
Руководила службой ИТ, подразделениями ПО и системного администрирования в ряде российских и иностранных предприятий, работала руководителем проектов, ведущим программистом и системным администратором в России и в США.
Автор книги «Технология создания распределенных систем» (совместно с А. Цимбалом), «Питер», 2003 г., переводчик книги «CORBA 3» «Малип», 2002 г., технический редактор книги «Основы CORBA» «Малип», 1999 г.
Автор и преподаватель курсов «Strategic Information Management» (Школа Бизнеса МГУ), «Корпоративная Архитектура» (программа МВА для CIO в Школе ИТ-менеджмента), «Реинжиниринг бизнес-процессов» (программа МВА в АНХ при Правительстве РФ), разработка стратегии ИТ (ТМКонсалт) и других.
Автор множества статей по тематикам стратегии ИТ и архитектуры предприятия, оценки эффективности ИТ и управления проектами ИТ, технологии CORBA.
В 2004 г. прошла стажировку по теме «Стандарты в области ИТ» по программе SABIT Министерства Торговли США.
Имеет диплом с отличием Российско – бельгийской программы EMBA (2008 г.), международный сертификат по управлению проектами GAPPS (2008), сертификаты MCSE и MCDBA.


ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Другие материалы рубрики

Быстро проникая в новые методики и технологии, именно ИТ-служба способна задать бизнесу новое направление развития.
Идея перехода на облачные технологии исходит от ИТ-службы, но описание бизнес-процессов, для которых подобные технологии будут использоваться, нам диктует бизнес.