Редакторские будни: стиль - намного ли лучше, когда так "живенько"?

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

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

Впрочем, речь не об этом. Речь у нас сегодня о стиле. Интересное наблюдение сделал, когда получал отзывы от ближнего круга коллег и друзей о еще неопубликованной статье:

• ИТ-шники реагируют на нее сдержанно, но снисходительно;
• специалисты в других областях называют "дельной", "гениальной", "визжат от восторга" (это все цитаты).

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

• 50% читателей сочли ее слишком вольной. В этой группе оказались, в частности, ученые-рецензенты и редакторы. В этом нет ничего удивительного.
• 50% читателей, напротив (и это было полной неожиданностью), заявили, что язык статьи "слишком формальный", что "нужно попытаться перейти на более доступный для широкой аудитории язык". В эту группу попали специалисты по ИТ и не ИТ.

Обращаю внимание: речь-то идет об одной и той же статье. В результате я даже не знаю в чем каяться: в излишней вольности изложения или излишней его сухости. Не хочу себя хвалить, но ведь в какой-то степени это есть показатель уникальности стиля, не правда ли?

Я задумывался над тем, почему я так пишу (с эмоциями и разговорной лексикой), даже пытался обвинить себя в том, что блоггерство испортило мой стиль, но потом вспомнил, что первой моей крупной статьей (до этого были мелкие) были "Студенческие игры", и уже эта статья была написана довольно-таки вольно и эмоционально. Так что не время и род занятий меня испортили - я с самого начала был такой.

Многие коллеги мне пишут: «Ты вот еще это забыл отметить и это...», но не понимают, что так оно и было задумано – общая канва нарисована, система преподнесена, определенные выводы сделаны, а там уж у каждого возникают свои мысли. Так что я очень рад, когда получаю такие отзывы. Я давно понял, что если пытаться формализовать тему, то уходишь в нее одну и не выходишь уже - будут формулы, будет исключительно научная лексика, но эффективность работы в качестве стимула для размышлений читателя заметно снижается. Буду писать докторскую - там будет сухо, полновесно и исчерпывающе.

Я почему так усердно защищаюсь - нравится мне самому сей последний труд - один из наиболее удачных (а таких я могу вспомнить штук 5, наверное). Бывают статьи номинальные - результат необходимости доложиться об итогах исследования или озвучить тему какую популярную, или репортаж сделать, или обзор. А бывают настоящие – вот такие, как эта. Горжусь – не стыдно! А нашлепать из нее статей формальных и сугубо-научных можно сколько угодно. Вот сходу предлагаю идею для кандидатской: берем некую репрезентативную совокупность разношерстных материалов в Интернете, разбиваем их по типам (блоги, форумы, большие статьи и т.д.) или по темам (SEO, анатомия сусликов, влияние солнечной активности на потенцию и др.) и датам появления; выясняем, насколько активно множится ("ретвиттится", "репостится", тупо воруется, цитируется) один и тот же материал, и насколько активно в новом материале появляются ссылки на старый - это самая трудная, но в определенном объеме выполнимая задача. Затем берем модель Леонтьева "затраты-выпуск", и ву-аля: можем вычислить, какой объем материала оказался полезен и был потреблен в чистом виде (в терминах экономики - "в непроизводственной сфере"), а какой пошел исключительно на нужды других "производителей". Сыроватая идея, конечно, но, по-моему, вполне жизнеспособная.

Со стилем же работ вот еще какая проблема: у нас ведь ученой степени "канд.комп.наук" не существует, к сожалению. Ученые с другими степенями судят о научности-ненаучности на основании принятых в их областях канонов (математических, экономических и т.д.). Так вот это - неправильно! Потому что computer science давно созрела и выделилась в совершенно специфическую науку. Одной из особенностей этой науки является то, что юмор - это ее неотъемлемая часть, как применение латинских букв в математике. Вспомните/почитайте С.Макконнелла, Дж.Х.Рейнвотера, Р.Гласса, Д.Платта, ныне забытого, но все так же любимого мною Т.Свана (я до сих пор считаю, что его книга по Turbo Assembler - лучшая) - это все уважаемые специалисты и авторы (некоторые со степенями), их произведения в некоторых местах без улыбки (а кое-где и без гомерического хохота) читать невозможно, но никто не вменяет им это в вину, и они не становятся от этого менее уважаемыми. Такова специфика НАШЕЙ науки. Поэтому, когда мне говорят, что мои работы "не строго научны", всегда хочется сначала поинтересоваться, с точки зрения КАКОЙ науки они ненаучны, а потом вежливо, но убежденно заметить: "Господа, может быть, вы просто не в теме?"

Мне, вообще, нравится работать с людьми, при взгляде на которых сразу понятно, что они были детьми и ими остались, в каком-то смысле. А вот смотреть на человека и не верить, что он когда-то был ребенком - совершенно не нравится (профессор медиалаборатории при MIT и известный графический дизайнер Джон Маэда описывает нечто подобное в своей книге Маэда Дж. Законы простоты: Дизайн. Технологии. Бизнес. Жизнь. - М.: Альпина Бизнес-Букс, 2009. - слава Богу, а то я думал, что один такой). Так вот большинство настоящих ИТ-шников - вечные дети, и это круто!

Треснувший рупор-4: защищая честь "Веселого Роджера" и право применять абордажные крючья 2

Я перешел к многоуровневой нумерации: то ли это тяга к систематизации, то ли просто очень глупый ход.

В этом посте на пиратство хотелось бы взглянуть с другой стороны: со стороны освещения в СМИ эффекта от него. Взглянуть и отвернуться.

Офис по вопросам подотчетности (Конгрессу) Правительства США (U.S. Government Accountability Office) опубликовал интереснейший доклад – Observations on Efforts to Quantify the Economic Effects of Counterfeit and Pirated Goods. Название можно перевести примерно, как «Обзор попыток измерить экономический эффект от подделки товаров и (интеллектуального) пиратства».

Полагаю, все мы (за себя говорю точно) видели публикации и репортажи с текстом вроде: "По оценкам аналитиков в прошлом году из-за пиратства киноиндустрия потеряла n млн.долларов", "Незаконное копирование и распространение программного обеспечения A нанесло его компании-производителю (по оценкам ее специалистов) урон в m млн.долларов". Содержание доклада – это один большой пинок всем авторам и исполнителям подобных песен. Конечно, как и во всех остальных случаях, "какая-то оценка" лучше никакой, но нужно различать значение оценки и ширину разинутого рта.

Правительство США, как и любое другое, каким-то образом борется с пиратством, выделяя, в частности, деньги на исследования в этой области. Так вот, выводы, представленные в указанном документе (которые, благо, обнаружились на 2-ой странице из 41-ой), заключаются в том, что:

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

Есть что-то романтичное в признании крупными ответственными организациями очевидных вещей. Чувствуешь, что ставится некая точка или, хотя бы, точка с запятой в вопросе. Жаль, что эти заграничные и международные организации высказываются крайне редко. Я не говорю про российские - они заняты тем, что придумывают, к словам какой бы еще части речи присовокупить приставку "нано-" (скоро, видимо, начнут присоединять к предлогам и союзам) или в качестве какого бы еще члена предложения всунуть слово "суперкомпьютеры", что, конечно, сложнее, поскольку в последнем значительно больше букв, да и на слух - не очень.

Что бы по поводу всего этого сделал я (иногда мне кажется, что я только рассуждаю - конструктива маловато)? Думаю, для начала я бы составил список интересующих меня отраслей. Потом я бы выбрал профильные отраслевые НИИ (выражаясь отечественным языком) или компании, в которых имеются мощные исследовательские центры, и отдал бы им в той или иной форме на откуп решение вопроса с мат.моделями потерь от пиратства. И уже затем я бы свел полученные результаты для вычисления потерь в масштабах страны, если это необходимо. У нас в стране сейчас такой период, когда половина гос.служащих решает, кому бы еще дать много денег, а вторая половина - на что бы их еще попросить. Так вот бесплатно предлагаю тему, авось, и полезное что выйдет. Мое личное мнение: засилье китайских "товаров" для нас куда вреднее, чем любое (другое) пиратство.

Письма: "Какой язык преподавать?"

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

Письмо, с которого началось обсуждение, было таким:

Меня критикует второй преподаватель по программированию у нас на кафедре, что я на "Языках программирования" даю С++ и С# в среде MS Visual. А потом он на 4 курсе дает методы программирования и прикладное программирование под Delphi, и получается не очень.

У меня здесь своя логика. Я провела небольшое исследование по поводу первоначальных навыков студентов первого курса. Так вот чаще всего в школе изучают Basic в 6 случаях из 10 и Pascal - в 3 из 10, потом Delphi 1 из 10. Есть редкие случаи, когда студент изучал С++ или С# - один из 100. Так вот, представляете приходит группа 30 человек на занятие, как выбрать язык, чтобы всем это было новым? Второй момент, это то, что в газетах в объявлениях редко бывает требуются специалисты в Delphi. Плюс второй язык изучать проще, чем первый, а третий - еще проще. Вот и решила с С++ начинать. Как Вы думаете нужно ли что-то поменять подходе?

Ответ был таким:

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

Вопрос в том, из чего состоит специальность, связанная с разработкой ПО? Она состоит не из научения 8-ми языкам. Она даже не исчерпывается программированием как таковым, далеко не исчерпывается. Есть анализ, проектирование, реализация, тестирование, сопровождение, документирование. Каждая из этих составляющих может быть организована по-разному и иметь свои разные стандарты и приемы, знания, необходимые для такой деятельности, а сами эти фазы/этапы/виды деятельности могут быть по-разному организованы, какие-то могут не присутствовать в конкретном случае, какие-то могут быть уникальны. Слишком сильный акцент на языке приводит к воспитанию специалистов, которые могут писать ПО в гараже или на коленке, но не в команде и не в промышленных условиях. В самом программировании опять же есть много уровней с очень большой вариативностью: прикладное/системное, ОС, язык, парадигма (ООП, структурная, функциональная и т.д.), технология (WinAPI, Windows Forms, Presentation Foundation, например, все позволяют делать оконные программы) и т.д.

Принципиальных проблем с ПО сегодня три, на мой взгляд:

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

Еще одна, как я люблю говорить, "вообще, проблема современного мира": масса людей, либо не понимает, что поступает неправильно, хотя для всех остальных это очевидно, либо понимает, но тщательно делает вид, что не понимает. В данном частном случае, например, это выражается в абсолютном незнании выпускниками ИТ-шниками основ бизнеса, особенностей работы в команде, вообще всего, что выходит за рамки кодирования (конечно, в редких вузах есть редкие исключения). В результате у нас бизнес в этой сфере развивается, но либо ненадолго и неправильно, либо очень медленно. Откуда студенты будут это знать, если большая часть их преподавателей на практике никогда не работала? А ведь начать бизнес, хотя бы малый, в этой сфере - дело очень дешевое, на самом-то деле. Ведь программисты работают не с дорогостоящими станками и материалами, а с "чистой мыслью" (по выражению С. Макконнелла).Такая вот интересная картина. В связи со всем этим первое, что нужно сделать, когда составляется план обучения на пятилетку (или если по направлениям, то уж как решили: 3, 3.5 или 4 года + магистратура), нужно определиться с тем, что будет в этом плане. Не какие ЯЗЫКИ, а какое наполнение, включая кодирование, но включая и очень многое другое. И вот для этих целей и нужен декан (или директор института). Именно его видение специальности, его понимание готового к работе специалиста, по согласованию (или "с приправами", или корректировками) с заведующими кафедрами и преподавателями и является тем, что записывается в план и реализуется. Определиться с этим сами кафедры или преподаватели не могут по определению, поскольку не видят всей картины - её видно только тому, кто видит специальность в целом, а кафедры делятся в зависимости от специализации, научной школы, отрасли, но не специальности. При этом неважно, подчинены ли они факультету или нет: когда я там работал, кафедры в МЭСИ были подчиненными факультетам, а в МФПА (в период моей работы там) - общеакадемическими, то есть деканы не имели формальной власти над ними. У нас практически не было лишнего дублирования в дисциплинах, все текло гладко и логично, потому что я вычитывал каждую программу, работал с каждой кафедрой или преподавателем, разумеется, "неся свою веру" и видение и размахивая планом. И большое им спасибо за совместную работу. Это очень кропотливый труд, не скрою.Как определить содержание плана? Разные есть подходы: можно на основе того, что является востребованным отраслью ИТ или другими, можно на основе стандартов и рекомендаций наших (АПКИТ работает в этом направлении) или международных. Я брал за основу рекомендации по подготовке ИТ специалистов ACM Computer Curricula 2001 + в последние годы Swebok (так называемое "ядро знаний в области ИТ"). На 4-ом, 5-ом годах обучения в рамках дисциплин специализации уделял большее внимание тому, что актуально в отрасли на данный момент (5-10 лет назад это был Веб, потом Unix, потом Мобильные устройства, потом опять Unix и т.д.), тогда как на первых курсах больше давал того, что в большей степени неизменно. Таким образом сглаживалась эта истерическая изменчивость ИТ - если начинать ориентироваться на современные потребности рынка сразу, то через 5 лет окажется, что учили "не тому", а если кто из ребят пойдет работать прямо сейчас с младших курсов, то и сам поднаберется опыта.После того, как определено и согласовано "видение"/план вместе со списком, наполнением и порядком дисциплин - только после этого для каждой дисциплины в зависимости от того, что за чем идет, и, что для чего уместнее, выбирается среда или язык, в которых будет происходить обучение. Понимаете, что я хочу сказать - это не вопрос для неаргументированного спора двух преподавателей (и даже для аргументированного), на чем лучше учить, не вопрос двух дисциплин. Это очень серьезная вещь на уровне целой специальности в вузе (за которую я обычно беру деньги, но тут уж меня "приперло" поговорить). Ведь от того, насколько правильно, логично выстроена вся цепь дисциплин: и профильных, и "непрофильных", зависит в конечном итоге судьба людей. Лично мое мнение (резюме): С++ откровенно плох для первого курса, потому что на первом курсе обычно проходятся по базовым конструкциям и алгоритмам структурного программирования, и Pascal 7.0 - старый, добрый, или VB мне кажется куда уместнее, чем С++ со своими строками, массивами, указателями и ссылками - ни к чему он там с этими лишними сложностями. Мне очень понравилось высказывание в книге Кернигана, Ритчи и Денниса: "С - это язык не слишком высокого уровня". То есть обычно языки делят на "высокого" и "низкого уровня", а тут - ни 2, ни 1.5.С другой стороны, Delphi для четвертого курса, при условии, что это новая для большинства среда - тоже откровенно неправильный вариант. К этому моменту большинство уже попробовало визуальное программирование в той или иной среде, зачем делать акцент на изучении еще одной? Не понимаю. Но опять же, как я уже сказал, это нужно видеть программы (1), и это нужно видеть последовательность дисциплин (2), потому что раз возникают такие споры и такие решения, значит там явно не все гладко. Извините, что я так прям с плеча, но зато я предельно откровенен.Мы делали так (это один из вариантов - они менялись с годами): на первом курсе VB или Pascal (вот кстати, где можно использовать Delphi - все-таки внутри-то у нее Object Pascal, поэтому и попроще, чем С++ - с одной стороны, и введение в визуальное программирование - с другой, только если без заострения внимания на внутренних механизмах). Второй год - С (не С++), работаем с указателями и прочим. В параллель с изучением С идет полгода Ассемблера обязательно. Сколько бы ни говорили о его устаревании, нет ничего лучше для разбирательства с разными типами адресации, хорошее понимание которой, как воздух, нужно для С и С++ и ООП в целом (и специалисты отрасли мне лично говорили об этом и даже благодарили отдельно за это). Потом С++ с ООП... и понеслась. Дальше уже как Бог на душу положит в смысле языков: дело в содержании дисциплин - в парадигмах, технологиях, ОС, а язык подбирается под это содержание. Можно, например, дать все на одном языке или диверсифицировать - дать все на разных; тут уже все зависит от вкуса и контингента: насколько хорошо студенты воспринимают новое.В целом, я считаю так: хороший план - это как хорошая песня: должна быть зажигательная музыка (общая концепция), актуальные слова (набор и содержание дисциплин), четкий ритм (последовательность и объем дисциплин), голосистое исполнение (преподаватели) и аудитория, которая способна это все благодарно воспринять (студенты). :)

Отделение стандартных зерен от стандартных плевел

Я опасаюсь, когда такая вещь, как стандарты, и следование им становятся "модными". Модные тенденции затмевают рациональное мышление.

Алексей Корольков в блоге "Websoft"-а опубликовал историю, которая наводит на определенные мысли. Цитирую:

В компании делали серию из нескольких курсов. Почти все курсы из них делали "как положено" - сначала писали и согласовывали сценарий, оформляли в PowerPoint, импортировали в авторское средство (Courselab) и затем доделывали (добавляли кое-где интерактивности, вставляли упражнения и вопросы и т.п.). Один из курсов преподаватель делал без всякого сценария и подготовки в PowerPoint прямо сразу в Courselab - придумывал и материал и способы его оформления и представления.

Так вот, по отзывам обучаемых, именно этот курс понравился им больше всего.

В чем причина? Ничто не сдерживало фантазии или сначала "набили руку" на сценариях и научились делать?

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

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

- За свою жизнь я сам написал пару дюжин тысяч служебных инструкций, а такого рода опыт не способствует готовности их выполнять. - М.Фрай. Простые волшебные вещи.

Ранее я уже делился соображениями, но там речь шла, в основном, о стандартах на интерфейсы, а тут размышления коснулись стандартов на процессы.

Для примера возьмем знаменитый стандарт ISO 9001 "Quality Management Systems - Requirements" ("Системы управления качеством - Требования", текущая его версия ISO 9001:2008, российский аналог - ГОСТ Р ИСО 9001-2008). Этот стандарт единственный из группы ISO 9000, применяемых при организации системы управления качеством, по которому допустима сертификация организаций. В последние годы организации ну очень любят по нему сертифицироваться, о чем с удовольствием пишут на своих сайтах и в своих проспектах. Это хорошо, даже очень, но хотелось бы сделать ряд замечаний:

• Соответствие данному стандарту, установленное в ходе сертификации, никоим образом не гарантирует качество продукции этой организации, поскольку в самом стандарте сказано, что (русский перевод):
  
  

  Требования к системе управления качеством, указанные в этом Международном Стандарте, являются дополнением к требованиям к продуктам.

  
  
• Опять-таки в самом стандарте сказано, что помимо применения с целью увеличения удовлетворенности потребителей, он может применяться, когда
  
  

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

  
  Обращаю внимание на тот факт, что "СПОСОБНОСТЬ постоянно ВЫПУСКАТЬ качественный продукт" и "ВЫПУСК ИСКЛЮЧИТЕЛЬНО качественного продукта" - формулировки по смыслу очень разные.
• Стандарт слишком общий. Весь его смысл заключается в рекомендации следующей поведенческой цепочки:
  1. Подумай, прежде чем что-то делать. ->
  2. Когда делаешь, документируй. ->
  3. После того, как сделал, проверь, насколько оно работает. ->
  4. После того, как проверил, сделай выводы. ->
  5. Перейди к шагу 1.
  Это не мои фантазии - в самом стандарте имеется указание на методологию PDCA:
  1. Plan. ->
  2. Do. ->
  3. Check. ->
  4. Act.

Я не нападаю на стандарт, но нужно же хорошо понимать его область действия и делать правильные выводы по факту наличия у компании/организации соответствующего сертификата. То, что компания сертифицирована по стандарту ISO 9001:2008,

• НЕ гарантирует качество ее продукции ни в какой степени;
• в определенной степени свидетельствует о том, что организация МОЖЕТ работать эффективно и производить качественную продукцию, но ни в коей мере НЕ гарантирует, что ее сотрудники будут прилагать все или хоть какие-нибудь усилия для этого;
• говорит о том, что для организации важна ее репутация;
• свидетельствует в пользу того, что в организации работают сотрудники, обладающие разумом.

Что касается последнего: и без сертификата довольно затруднительно найти какого-нибудь сотрудника какой-нибудь компании, который разумом не обладает.

Человек разумный - это не всегда разумный человек... хомо сапиенс - это возможность думать, но не всегда способность... - А. и Б. Стругацкие "Отягощенные злом, или сорок лет спустя".

ISO 9001 - это, как ни странно, стандарт на процессы, хотя в названии и значатся "требования" к системе управления качеством (что намекает на требования к интерфейсу). У меня к стандартам на процессы специфическое отношение. Я считаю, что они уместны там, где:

("Велика вероятность ошибки при выполнении какой-либо операции в составе процесса"
ИЛИ
"Имеет значение последовательность операций в ходе процесса")
И
"Ошибка при выполнении операции или в последовательности операций имеет значительные последствия".

В остальных случаях стандарты бессмысленны, а иногда вредны. Определение того, что для конкретной организационной единицы является "значительными последствиями", а что не является - это сложная задача. Проблема в том, что организации часто идут по пути "лучше перебдеть, чем недобдеть", пытаясь стандартизировать все, или даже так - ВСЁ! Стандарт или инструкция позволяют превратить любое "дело" в последовательность четких "операций", но в тех случаях, когда первоначальное "дело" было в значительной степени связано с творчеством, переход к операциям (особенно, если их много) часто заставляет человека забыть вообще о том, чего ради он все это начал (забыть об "идее"). Я называю это "Эффектом шелухи".

Представьте себе, что повар в столовой готовит яичницу из двух яиц. Через некоторое время он решает добавить в нее лук, затем фасоль, затем еще что-нибудь невообразимое. Его яичница становится популярным блюдом в меню, и директор столовой решает, что ее должны готовить и другие повара. Тут на арене появляется "рецепт", то есть - "стандарт на процесс приготовления яичницы". Другие повара готовят, следуя этому рецепту. Если они неопытные или не сильно увлечены своим делом, они так и будут ему следовать. Если они хотят творить новое, то могут втихую опробовать на посетителях другой набор ингредиентов либо обратиться к руководству. Если все пойдет удачно, новая яичница может быть опробована на нем, затем на посетителях (уже не втихую), а затем станет новым рецептом/стандартом. Цикл замкнулся. Все бы ничего, но обратите внимание:

• Первый повар изготовил свой шедевр в отсутствие стандарта.
• Другие повара-энтузиасты имеют два варианта действий: либо нарушить стандарт, либо предложить изменения/дополнения в него.

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

Таким образом, наличие, сам факт существования стандарта на тот или иной процесс в определенной степени идет вразрез с потребностями творческих натур, которым хочется попробовать добавить в блюдо перец хабанера вместо халапеньо и посмотреть, что будет, вместо того, чтобы тупо разбивать скорлупу. Я уж не говорю о том, что стандарт на процесс, где задействованы люди, или даже так ЛЮДИ, - эти непредсказуемые существа с чувствами, эмоциями и никому неизвестными болезнями и тараканами в голове - по определению не будет всегда точно выполняться.

Интересно, что определение того, что нужно стандартизировать, а что - нет; выделение чего-то общего, что можно записать в стандарт, с определенной точки зрения похоже на задачу проектировщика/программиста, который должен решить, насколько универсальным будет тот или иной модуль/метод/класс. И, зная, насколько сложна ЭТА задача, я могу предположить, насколько сложна первая. Кстати, что касается "сильно творческих" проектов в области разработки программного обеспечения, то "просветленные" авторитеты практически рекламируют уход от корпоративных стандартов и правил (Э.Йордон. Путь камикадзе. Второе издание. - М.: "Лори", 2008. ISBN 5-85582-227-3). Это, действительно, большая проблема - грамотно выбрать жертвенный процесс для стандарта, и над ней, на мой взгляд, маловато задумываются. Что до стандартов на интерфейсы, то тут, как ни крути, проще - исчезни они, и батарейки просто перестанут влезать в пульты.

Как бы то ни было, иногда, чтобы создать что-то по настоящему новое и качественное, имеет смысл ободрать всю шелуху и просто сделать ХОРОШО!

Редакторские будни: особенности научно-художественной визуализации

Тема рисунков и схем в научных, научно-популярных и практических статьях вскользь мною уже поднималась, однако упорство, напряженное самосовершенствование и изобретательность российских (в основном сужу по их произведениям) ученых в части иллюстрирования своих трудов заставляет заняться ею вплотную.

В свое время мой пожизненный научный руководитель докт.экон.наук, профессор Александр Анатольевич Емельянов передал мне завет своего руководителя: "Не можешь писать - рисуй"! Очень правильный совет, своим дипломникам я его тоже давал. Если размышления по теме зашли в тупик, то изображение схемы... чего бы то ни было, связанного с этой темой, - хороший способ выхода из этого тупика. Только нужно помнить две вещи:

• Рисунки, полученные в процессе таких вот тягостных раздумий, необходимо переделать, прежде чем включать в финальный вариант статьи или пояснительной записки. Незачем портить ауру работе, которую будут читать другие люди, если, конечно, вы не хотите, чтобы читатели ощутили всю тернистость вашего научного пути и тяготы вашего общения с карандашами или мышью. Научные работы, вообще-то, публикуются не для этого; по крайней мере, так думают "потребители". Детали воплощения статьи в жизнь могут быть уместны, но не являются уместными по определению.
• Рисунки для презентаций и для статей, которые будут печататься, должны быть разными - здесь я не открою Америки. Удивительно, но если авторы об этом задумываются, то, в целом, интуитивно чувствуют, что рисунки для презентаций могут быть крупнее и цветастее, а для печатной версии статьи - проще, меньше и черно-белые. Проблема в том, что раздумия очень часто просто не возникают.

Далее я привожу "топ-лист" неприятностей, связанных с рисунками, с которыми мне приходится регулярно сталкиваться при редактировании "Прикладной информатики":

• Цветность - много раз и во многих местах говорилось, что у нас "grayscale"-журнал (то есть в оттенках серого), тем не менее, авторы регулярно шлют цветные рисунки. Иногда в ответ на просьбу переделать рисунок, автор меняет в Word режим его отображения (на шкалу серого), совершенно не заботясь о последствиях, а именно о том, что разные цвета при преобразовании выглядят одинаково или почти одинаково.
  
  
  Уважаемые авторы, поверьте, если бы все было так просто, то мы - редакторы, скрепя сердце, спотыкаясь, но смогли бы-таки 6 раз щелкнуть мышкой (для рисунков в версиях Word до 2007; в 2007 - 4 раза), чтобы выполнить преобразование.
• Еще хуже, когда в тексте статьи имеются ссылки на "красные стрелки на схеме 1" или "зеленые прямоугольники на рисунке 2".
• Потеря подписи - для 10 стрелок есть подписи, а для 11-ой - нет.
• Сочетание размеров шрифтов и фигур - оно иногда наводит на мысли о просто-таки полном отсутствии вкуса, а не только о неверной расстановке акцентов.
  
  
  По моему опыту, в роли "Супер-штуки" чаще всего почему-то выступает здоровенная бочка из Visio с надписью "База данных". Причем размер букв зачастую таков, что будь они выдавлены шрифтом Брайля, их можно было бы читать не пальцами, а всей ладонью.
• "Стрелочный беспредел" - классика.
  
  

Мой коллега Александр Беляев когда-то очень давно употребил термин "Синдром домохозяйки" применительно к веб-страницам, на которых помещено все интерактивное, что можно себе представить: анимированные баннеры с психоделической гаммой красок, мигающие Java-аплеты, скачущие flash-окошки и так далее. Иногда кажется, что с авторами (при всем уважении к ним), происходит что-то подобное. Будучи вынужденными придерживаться строгого стиля в тексте, они испытывают столь сильные позитивные эмоции по отношению к новым горизонтам в "живописи", открываемым для них Corel-ом и Visio, что пытаются добавить к рисункам столько красок, сколько смогут. Я как-то в шутку предложил добавить в требования к оформлению статей для журнала "Прикладная информатика" следующее предложение:

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

Я пишу все это вот с какой сугубо практической целью: я далек от мысли, что авторы издеваются, или им наплевать на собственные творения, но я знаю, что часто имеет место ситуация, в которой имеются сомнения по поводу качества рисунков, и эти сомнения отгоняются. Я перечислил неприятные рисованные сюжеты, которые однозначно не проходят мимо меня, так что если вы - автор и видите у себя нечто подобное, лучше исправьте сразу. Я готов исправлять и даже перерисовывать заново сам, но а) по некоторым вопросам невозможно принять решение без вашего участия, а значит мы потеряем время, и б) присылайте векторные версии рисунков в форматах Corel-а или Visio, поскольку кривой и смазанный JPEG, вставленный в документ со статьей, - не лучший вариант для дальнейшего редактирования.