Некоторый опыт работы над рубрикой «Поучительный пример».

Вот уже более двух лет мы публикуем статьи в рубрике «Поучительный пример». По правде говоря, она существует гораздо дольше, но для себя началом публикаций мы считаем выход в свет первого материала, написанного отечественным автором, так как первые год-полтора существования журнала в рубрике печатались исключительно переводные материалы. Среди них встречались весьма интересные, как, например, проект для Зала славы рок-н-ролла, но подавляющая часть рассказов о реально действующих проектах, как представлялось, была не вполне актуальна для наших читателей, поскольку американская действительность во многом отличается от российской. Поэтому в конце 1996 года редакцией было принято решение целиком и полностью перейти исключительно на местные материалы, т. е. рассказывать только о проектах, реализованных на территории России и СНГ — области распространения нашего журнала, — с целью анализа того, какие современные технологии реально находят применение на нашем рынке и почему. Думается, что рассказ о впечатлениях от двухлетнего опыта работы над рубрикой будет нелишним для наших читателей, тем более что этот опыт подвел нас ко вполне конкретным выводам.

ПИСЬМО ПОЗВАЛО В ДОРОГУ

Начать рассказ, наверное, стоит с того, как мы находим материал для рубрики. Сразу же отметим, что материал нам никто никогда не заказывает. Разумеется, публикации в рубрике положительно сказываются на отношениях с компаниями, упомянутыми среди поставщиков и исполнителей проекта, но для нас это является выгодным, главным образом, в долгосрочном плане. Мы не получаем никакой оплаты за публикации, равно как и не ставим условий размещения в этом же (или другом) номере рекламы за то, что материал пойдет в печать. Однако если кто-то считает, что у дверей редакции толпится очередь из интеграторов, приносящих на суд публики свои проекты, а мы отбираем среди них наиболее интересные, то он глубоко заблуждается. На самом деле, за материалом приходится в буквальном смысле охотиться: если мы знаем, о чем будем писать в текущем номере и в следующем, то это для нас большая удача, а определенность с материалами на три номера вперед расценивается как редкостный успех.

Все дело в том, что для печати в рубрике информация о проекте должна быть полностью открытой. Иными словами, мы должны иметь право опубликовать информацию не только об исполнителе или решении, но и самом заказчике — что это за организация, какие она ставит задачи перед информационной системой и как последняя используется в повседневной деятельности. На практике же многие уважаемые интеграторы так ни разу и не были упомянуты в рубрике в силу того, что они скрывают своих заказчиков и детали сотрудничества с ними из-за нежелания «давать наводку» своим конкурентам. К тому же, нередко сами заказчики не желают «светиться» либо из-за того, что не хотят рассказывать о специфике своей работы, либо (что характерно для представительств западных компаний) просто считают, что чем меньше информации выходит за пределы компании, тем меньше смогут узнать их конкуренты или налоговая инспекция. Поэтому совсем не случайно значительная часть проектов, описанных нами в 1997 году, была выполнена силами отделов ИС предприятий при минимальном участии интеграторов. Впрочем, регулярность публикаций и их актуальность заставляют отделы маркетинга многих игроков сетевого рынка изыскивать возможности по предоставлению нам материала, особенно если отношения с заказчиком носят тесный доверительный характер. Некоторый перекос в пользу одних и тех же имен (ряд компаний упоминается в рубрике не один раз) объясняется не какой-то нашей материальной заинтересованностью, а стремлением (и успешным!) этих компаний к сотрудничеству и пониманием сути рубрики.

Руководство же компаний-заказчиков проектов нам удается привлечь тем, что упоминание на страницах нашего журнала способствует укреплению имиджа компаний. Сегодня, когда информационные ресурсы не менее важны, чем финансовые, признание того, что корпоративная система предприятия достойна анализа в ведущем сетевом журнале, является не менее важным свидетельством надежности компании, чем годовой отчет или справка из банка. Различные же федеральные структуры (самые закрытые и непростые в работе заказчики) получают в свои руки дополнительный аргумент в пользу дальнейшего финансирования проекта. Несомненную выгоду имеем и мы, так как получаем материал для публикации и ближе знакомимся с вертикальными рынками, настроениями среди заказчиков и тенденциями отрасли в целом. Как мы надеемся, пользу для себя из этих материалов извлекает и наша читательская аудитория.

ВЗГЛЯД ИЗНУТРИ

Поначалу мы не очень четко представляли, как именно добиться того, чтобы рубрика приносила пользу. Точнее, не обладая достаточным опытом, мы еще не имели отработанной методики работы над рубрикой. Если вы обратитесь к архивам журнала, то заметите, что вначале мы полагались на сторонних авторов, и даже самый первый отечественный материал рубрики был написан не сотрудником редакции. Мы полагали, что лучше самих сотрудников организаций-героев рубрики никто не напишет о том, как они живут-здравствуют (от материалов, написанных исполнителями, мы отказались в принципе, так как «поучительный пример» и «success story» — несколько разные по форме и целям жанры). На практике оказалось, что технические специалисты знают много, но донести это знание до читателей им оказывается непросто. Это вызвано как отсутствием необходимого литературного опыта, так и нехваткой времени, поскольку у сторонних авторов хватает дел и помимо написания статей.

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

Два года работы над рубрикой позволяют нам теперь делать выводы об определенных тенденциях рынка и о том, в какой степени он восприимчив или, наоборот, толерантен к новым веяниям. Обнаружилось, например, что, несмотря на то что волна публикаций о технологиях Intranet постепенно схлынула, и, как выяснилось, Главной Идеей корпоративных систем им вряд ли суждено стать, они вовсе не умерли. Практически любая организация, о которой мы пишем, сегодня в той или иной форме использует Intranet. Где-то, хоть и в редких случаях, эти технологии распространяются на всю систему или большую ее часть. Как правило же, Intranet реализуется как одна из составляющих корпоративной системы, обеспечивающая удобный доступ к ресурсам общего пользования.

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

Иногда (в последнее время все чаще) наблюдается и отрадное для нас совпадение ключевых моментов материалов рубрики с наиболее актуальной, с точки зрения нашего журнала, тематикой. Иначе говоря, содержание рубрики перекликается с обзорными материалами из того же самого или предыдущего номера. Ввиду ограниченности выбора материала для рубрики мы никогда не пытаемся специально подобрать тематику (разве что стараемся «разводить» материалы об одинаковых вертикальных рынках или схожего фокуса), и такие совпадения происходят сами собой. Впрочем, подобные совпадения не случайны, а свидетельствуют о правильном выборе направления. Вообще, попытка соотнести опубликованное в различных выпусках рубрики, на наш взгляд, будет нелишней для читателей, так как поможет обобщить излагаемый в ней опыт отрасли в целом.

ЛОЖКА ДЕГТЯ

Опыт бывает как положительный, так и негативный. И то, и другое приносит пользу, только учиться, как известно, лучше на чужих ошибках (или неприятностях), чем на своих. Исходя из этого, мы стараемся рассказать и о проблемах, возникающих при реализации описываемых нами проектов, особенно если они не являются сугубо специфическими и могут повториться в аналогичной ситуации.

Однако далеко не весь негативный опыт попадает на страницы нашего журнала. Дело в том, что доступ к информации о проектах мы получаем, как вы поняли, в результате трехстороннего негласного джентльменского соглашения о сотрудничестве, выгоду от которого получают и журнал, и заказчик, и исполнитель. В отличие от газеты вроде «МК», мы не можем добывать материал любыми доступными путями и писать потом «согласно информированному источнику из отдела ИС компании X, основной платформой в ней является...», поэтому нам приходится согласовывать материал со всеми заинтересованными сторонами. Свойство же человеческой натуры таково, что о своих ошибках люди говорят неохотно, да и кому захочется признаваться в своих профессиональных упущениях на страницах специализированного журнала, тем более что его может читать и начальство? Естественно, мы не заинтересованы в том, чтобы создавать неприятности тем, с кем сотрудничаем, так как при такой репутации мы лишились бы источников материала для рубрики, поэтому далеко не все проблемы, о которых идет разговор в наших беседах со специалистами заказчика, потом находят отражение в напечатанном материале.

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

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

Заметим, что нередко в наш адрес приходят письма приблизительно следующего содержания — «что же вы не сказали, что такие-то и такие-то части решения — далеко не самый лучший выбор при всей аргументации заказчика» или «зачем же вы о них пишете, ведь у них такой-то и такой-то недочет». Про комментарии мы уже сказали, а про неидеальность выбора тех или иных решений заметим, что наша аудитория — не только корпоративные заказчики, но и компании, работающие на рынке информационных технологий. Рубрика предназначена и для них тоже, и тот факт, что какие-то актуальные технические решения (то же иерархическое хранение данных) не находят должного отклика у определенного рода заказчиков, должен послужить им пищей для размышления. Мы, конечно, стремимся пропагандировать все полезные и нужные технологии и решения, но убеждать заказчика в их необходимости приходится самому продавцу. Вообще, в частной беседе или переписке мы всегда готовы подробнее рассказать о том или ином проекте и пояснить реальные мотивы заказчиков при выборе того или иного решения; кроме того, желающие могут поинтересоваться подробностями у самих заказчиков — их адреса и телефоны мы даем именно для этого.

ЗАКЛЮЧЕНИЕ

Несмотря на то что с точки зрения объема рубрика «Поучительный пример» является далеко не самой значительной в нашем журнале, нередко работа над ней отнимает столько же времени и сил, сколько самый объемный и подробный обзор. По правде говоря, само по себе написание материала требует совсем немного времени, но подготовительный этап и согласование отдельных деталей подчас оказываются весьма длительной процедурой. Соответственно, нам очень хотелось бы, чтобы содержание рубрики, ведение которой сопряжено с известными трудностями, адекватно воспринималось читателями, и ее чтение действительно давало пищу для размышлений, ради чего и был написан этот «постскриптум».

Мы надеемся, что в какой-то степени достигли своей цели, свидетельством чему служат письма наших читателей, в которых они обращаются к автору рубрики с такими вопросами, как будто он своими руками реализовывал весь проект «от и до». Такая реакция нашей аудитории привела к тому, что в конце материала мы стали специально указывать, что автор — сотрудник LAN. Впрочем, рубрику несомненно ожидают и другие перемены, так как ее концепция будет развиваться и в дальнейшем по мере накопления нашего личного опыта и возникновения перемен в тенденциях рынка и менталитете заказчиков и исполнителей проектов.

ОБ АВТОРЕ

Александр Авдуевский — редактор журнала LAN. С ним можно связаться по адресу: shura@lanmag.ru.

Поделитесь материалом с коллегами и друзьями