10 заметок с тегом

Xendz-айтишник

Разбор HR-полетов, или Летайте самолетами «Аэрофлота»

19 апреля 2010, 12:49
На сайте «Студии Артемия Лебедева» открылся раздел вакансий, в котором могут публиковать свои объявления о найме другие компании. Заглянул в раздел, увидел там объявление компании «S7 Airlines», полюбопытствовал...

Чудовищно.

Сначала приведу это объявление во всей его первозданной красе — для остроты ощущений и чистоты впечатлений:

Менеджер по управлению проектами

Компания: S7 Airlines

Данная позиция играет одну из ключевых ролей в успешной команде электронной коммерции. Сотрудник будет отвечать за внедрение новых решений и улучшение существующей платформы.

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

Основные задачи:

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

Требования:

Образование:
— Высшее образование. Предпочтительная специализация: Информационные технологии.
— Иностранные языки: Английский (свободное владение).

Навыки:
— Опыт от 3 лет в области электронной коммерции, цифровых медиа, проектах по созданию Web приложений.
— Опыт от 3 лет в области управления IT проектами.
— Навыки работы с MS Project.
— Ориентированность на результат, способность демонстрировать и применять технологические и технические знания для выбора оптимальных решений.
— Способность креативно решать проблемы, работать как самостоятельно, так и как часть команды, способность воплощать как свои так и чужие идеи.
— Способность организовывать, выставлять приоритет, планировать и управлять несколькими проектами с высокой нагрузкой одновременно.
— Способность уделять внимание деталям, высокая организованность и способность координировать несколько задач, для того чтобы соответствовать бюджету и временным рамкам.
— Опыт в разработке приложений для электронной коммерции очень желателен.
— Глубокие навыки в разработке всеобъемлющих прожект планов, контроля рисков и коммуникациях на уровне команды и с подрядчиками.

Условия:
— Возможность роста и самореализации в динамично растущей компании.
— Компенсационный пакет обсуждается с кандидатами прошедшими собеседование индивидуально.

Уважаемые соискатели!

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

Соискатели с шаблонными сопроводительными письмами рассматриваться не будут.

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

Менеджер по управлению проектами

Компания: S7 Airlines

Данная позиция играет одну из ключевых ролей в успешной команде электронной коммерции. Сотрудник будет отвечать за внедрение новых решений и улучшение существующей платформы.

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

Основные задачи:

Анализ и установка проектных задач на основании бизнес[-]задач.
Создание проектных планов, отслеживание проектных задач и рисков.
Подготовка проектной документации[, в]ключая документы[,] описывающие функционал, технические спецификации, планы тестирования, разработки и развертывания приложений.
Подготовка и презентация отчетов о статусе проекта.
Управление проектами, чтобы они были реализованы в срок и в соответствии с бюджетом.
Поиск и внедрение технологических решений для решения бизнес[-]задач.

Требования:

Образование:
— Высшее образование. Предпочтительная специализация: [и]нформационные технологии.
— Иностранные языки: [а]нглийский (свободное владение).

Навыки:
— Опыт от 3 лет в области электронной коммерции, цифровых медиа, проектах по созданию Web[-]приложений.
— Опыт от 3 лет в области управления IT[-]проектами.
— Навыки работы с MS Project.
— Ориентированность на результат, способность демонстрировать и применять технологические и технические знания для выбора оптимальных решений.
— Способность креативно решать проблемы, работать как самостоятельно, так и как часть команды, способность воплощать как свои[,] так и чужие идеи.
— Способность организовывать, выставлять приоритет, планировать и управлять несколькими проектами с высокой нагрузкой одновременно.
— Способность уделять внимание деталям, высокая организованность и способность координировать несколько задач, для того чтобы соответствовать бюджету и временным рамкам.
— Опыт в разработке приложений для электронной коммерции очень желателен.
— Глубокие навыки в разработке всеобъемлющих прожект[-]планов, контроля рисков и коммуникациях на уровне команды и с подрядчиками.

Условия:
— Возможность роста и самореализации в динамично растущей компании.
— Компенсационный пакет обсуждается с кандидатами[,] прошедшими собеседование[,] индивидуально.

Уважаемые соискатели!

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

Соискатели с шаблонными сопроводительными письмами рассматриваться не будут.

Итоги: в объявлении из жалких 300 слов автор умудрился с поразительным упорством не поставить ни одного из полагающихся по закону 8 дефисов, пропустил 7 запятых и вкрячил 4 лишних. Двоечник несчастный. Содержание и стилистика объявления катастрофически, неисправимо беспомощны и находятся где-то между сочинением второклассника о мире во всем мире («Управление проектами, чтобы они были реализованы в срок и в соответствии с бюджетом») и первым выступлением доярки с трибуны Съезда (деепричастный оборот как самостоятельное предложение: «Включая документы описывающие функционал, технические спецификации, планы тестирования, разработки и развертывания приложений»). Особенно трогательно выглядит глубочайший пиетет автора перед интернетом, маркетологами и особенно их небесной комбинацией — Его Святейшеством Интернет-Маркетологом:).

Теперь — вариант с моими комментариями по содержанию.

Менеджер по управлению проектами

Компания: S7 Airlines
[Давайте вспомним, что заимствованное слово «менеджер» означает всего-навсего «управляющий». А значит, должность называется... «управляющий по управлению проектами», угу. Заметьте, что аналогичная вакансия в студии Лебедева имеет гораздо более лаконичное название «менеджер проектов» — понятно, почему?]

Данная позиция играет одну из ключевых ролей в успешной команде электронной коммерции. [О чем это? Правильно: ни о чем. Просто кто-то когда-то вбил автору объявления в голову, что использование ключевых слов вне зависимости от их порядка и связей друг с другом вызывает неотвратимое слюноотделение по Павлову.] Сотрудник будет отвечать за внедрение новых решений и улучшение существующей платформы. [«И швец, и жнец, и вообще п....ц». Не многовато ответственности на одного сотрудника? К слову, улучшение существующей платформы — скорее процессная, а не проектная деятельность.]

В этой роли сотрудник будет взаимодействовать с Интернет Маркетологом, руководителем группы разработчиков, директором проекта, и всей проектной командой, [Интересная картинка вырисовывается: есть «директор проекта» — видимо, самый главный; есть небожитель — «Интернет Маркетолог»; есть «вся проектная команда», которая, по-видимому, состоит из «Интернета Маркетолога» и разработчиков, поскольку никаких других промежуточных руководителей команд, кроме «руководителя группы разработчиков», не упомянуто. Напрашивается вывод: либо наш «менеджер по управлению проектами» непосредственно управляет всеми неразработчиками в команде («Интернетом Маркетологом», наверное?..), и тогда он скорее «руководитель группы неразработчиков», либо он — просто «прокладка» между директором проекта и руководителем группы разработчиков.] для анализа бизнес требований и технологических требований, с целью управления разработкой решений, планирования, сбора требований [Новое слово в науке управления IT-проектами: требования теперь делятся на бизнес-требования, технологические требования и просто требования. При этом мы сначала «анализируем» первые и вторые, а затем «собираем» третьи. Что именно мы «планируем», после этого даже не так уж важно...] и реализации проектов в поставленный срок и в соответствии с бизнес задачей. [Из проектной триады «качество — бюджет — сроки» остались сроки и полкачества (ибо соответствие бизнес-задаче затаскивается в эту категорию с некоторой натяжкой). Бюджет, видимо, не важен: S7 — компания богатая... Констатируем: попытка дать самопальное определение проектной деятельности с треском провалилась. Правда, непонятно, зачем она вообще была нужна: хороший менеджер проектов и сам знает, что это такое, а плохому краткий курс управления проектами в объеме одного объявления поможет как мертвому припарки.]

Основные задачи:

Анализ и установка проектных задач [устанавливают готовый программный продукт, а проектные задачи — ставят; зачем их при этом анализировать, совершенно непонятно (полагаю, исходно анализировать предполагалось бизнес-задачи, но в тесной голове все склеилось...)] на основании бизнес задач.
Создание проектных планов, отслеживание проектных задач и рисков.
Подготовка проектной документации. [Кажется, слово «проектный» для автора объявления — это что-то вроде вудуистского заклинания, иначе зачем бы повторять его через слово?] Включая документы описывающие функционал, технические спецификации, планы тестирования, разработки и развертывания приложений. [Я ж говорил: «И швец, и жнец...» — и далее по тексту. В нормальных местах план тестирования готовит руководитель группы тестирования, а спецификацию пишет аналитик требований, причем спецификация и есть документ, наиболее полно описывающий функционал (с точки зрения разработчика; а с точки зрения пользователя функционал описывается в руководстве пользователя, которое создает технический писатель).]
Подготовка и презентация отчетов о статусе проекта. [Это, я так понимаю, самый важный пункт?.. Тогда вам стоит рассмотреть вопрос о найме журналиста. Я не к тому, что руководитель проекта вообще не должен уметь докладывать руководству о статусе проекта, — но это просто составная часть навыка общения, который для руководителя проекта является базовым, ибо ключевая задача руководителя проекта — «договорить всех со всеми».]
Управление проектами, чтобы они были реализованы в срок и в соответствии с бюджетом. [Появился бюджет — исчезло качество. «Стоило взяться за яйца — пропало молоко», — как говаривал незабвенный А. Г. Лукашенко. Про бессмысленную всеохватность формулировки даже говорить ничего не буду...]
Поиск и внедрение технологических решений для решения бизнес задач. [Снова «общность, граничащая с пустотой» ((c) И. Пригожин).]

Требования:

Образование:
— Высшее образование. Предпочтительная специализация: Информационные технологии.
— Иностранные языки: Английский (свободное владение).

Навыки:
— Опыт от 3 лет в области электронной коммерции, цифровых медиа [объясните мне, айтишнику: что такое «опыт в области цифровых медиа»?!], проектах по созданию Web приложений [«опыт в области проектах» или «опыт в проектах»? и то и другое не по-русски... видимо, имелся в виду опыт участия в проектах — ибо об опыте управления проектами говорится дальше]
— Опыт от 3 лет в области управления IT проектами.
— Навыки работы с MS Project. 
— Ориентированность на результат, способность демонстрировать и применять технологические и технические знания для выбора оптимальных решений.
— Способность креативно решать проблемы [во-первых, решают задачи — а проблемы устраняют; во-вторых, «креативно» — это, по-русски говоря, «творчески», так что либо «творчески решать задачи», либо «креативно солвить проблемы» — вы уж определитесь... в-третьих, может быть, лучше способность просто решать задачи? если у задачи есть хорошее нетворческое решение, творчество чаще вредит, чем помогает], работать как самостоятельно, так и как часть команды [«нам нужен командующий армии для действий на поле боя — как самостоятельных, так и в составе регулярных войск»... умение махать шашкой — это, безусловно, ценный навык для руководителя проекта], способность воплощать как свои так и чужие идеи [не знаю, все ли со мной согласятся, но, по-моему, руководитель проекта, занятый воплощением своих идей, — это катастрофа].
— Способность организовывать, выставлять приоритет [один?], планировать и управлять несколькими проектами с высокой нагрузкой одновременно [ох, чую беду... мой опыт показывает, что руководитель проекта может нормально управлять одним интенсивным IT-проектом, в крайнем случае — одним интенсивным и одним на стадии инициации; в противном случае проекты переходят на самоуправление со всеми вытекающими отсюда последствиями].
— Способность уделять внимание деталям, высокая организованность и способность координировать несколько задач [если вы требуете от человека управления несколькими проектами, упоминание про «несколько задач» выглядит детским лепетом], для того чтобы соответствовать бюджету и временным рамкам [и снова о русском языке: кто должен соответствовать бюджету и временным рамкам — руководитель проекта или все же сам проект? про качество я уж молчу...].
— Опыт в разработке приложений для электронной коммерции очень желателен. [Простите, а о чем тогда вещалось несколькими абзацами выше? Там же уже были и «цифровые медиа», и «электронная коммерция», и «IT-проекты», причем в качестве требований, а не пожеланий... Или там было по отдельности, а здесь все вместе?..]
— Глубокие навыки в разработке всеобъемлющих прожект планов [если «проджект-планы» — то тогда уж «глубокие скиллы»... а «всеобъемлющие планы» — это просто изумительно! теряю дар речи...], контроля рисков [вообще-то control переводится с английского как «управление» — так что речь, говоря по-человечески, об управлении рисками] и коммуникациях [«навыки в коммуникациях»... о боги, яду, яду мне. Это просто умение общаться!] на уровне [интеллектуальном? физическом? психологическом?..] команды и с подрядчиками[ну, у этих, видимо, вообще никакого уровня нет...].

Условия:
— Возможность роста и самореализации в динамично растущей компании.[Более существенного и конкретного ничего? Это, извините, пустое место. Если бы менеджеры проектов так формулировали цели и критерии качества, мы бы до сих пор махали каменными топорами и выделывали шкуры.] 
— Компенсационный пакет обсуждается с кандидатами прошедшими собеседование индивидуально. [«Обсуждается индивидуально» или с «прошедшими индивидуально»? «Кто на ком стоял? Потрудитесь выражаться яснее!» (c) проф. Ф. Ф. Преображенский. Ну, или хотя бы запятые ставьте...]

Уважаемые соискатели!

В сопроводительном письме пожалуйста указывайте почему Вы считаете, себя подходящим кандидатом на данную вакансию [«Мы, уважаемые соискатели, считаем себя подходящим кандидатом на данную вакансию, потому что нас мало... нас адски мало!»], ваши сильные стороны [«Усы, лапы и хвост — вот мои сильные стороны!» Сойдет за указание?], Ваши достижения в этой области, опыт.

Соискатели с шаблонными сопроводительными письмами рассматриваться не будут. [«Не надо меня рассматривать! Займитесь лучше моим резюме...»]


И напоследок — то, что следовало написать на самом деле:

Менеджер проектов

Компания: S7 Airlines

В компанию «S7 Airlines» требуется руководитель проектов по созданию web-приложений. Требования: высшее образование, свободный английский язык, опыт руководства IT-проектами не менее 3 лет. Желателен опыт управления аналогичными проектами. Зарплата по итогам собеседования.


С чего я так взъелся? Уж всяко не из-за запятых... Профессионализм, как и его отсутствие, лучше всего виден в мелочах. От этого объявления за 30000 футов несет непрофессионализмом. (В книге Демарко, Листера и их соавторов «Балдеющие от адреналина и зомбированные шаблонами» упоминается — хотя, к сожалению, не описан — организационный паттерн «Астрофизиков у нас нанимает отдел кадров». Видимо, этот тот самый случай.) Хорошо, что я не работаю менеджером проектов в компании «S7 Airlines»: представляю, какую команду способен нанять мне такой рекрутер...

А я ведь вполне мог бы оказаться кандидатом на эту должность — опыт и навыки позволяют. Все, что я изложил выше письменно, неизбежно придет в голову профессиональному менеджеру проектов, занятому поиском работы и прочитавшему это объявление. Текст объявления создает вполне рельефное и яркое впечатление о компании, позволяя сделать множество (пусть и предварительных) нелестных выводов. Неужели непонятно, что человек, публикующий тексты вакансий, в существенной степени отвечает за имидж компании?

Мне хочется верить, что все остальное в «S7 Airlines» хорошо и профессионально, но я не могу отделаться от «послевкусия»...

Летайте, что ли, самолетами «Аэрофлота»...

IT-проекты в картинках (продолжение темы)

23 февраля 2010, 16:51
Когда-то я уже «цитировал» три популярных комикса на тему управления IT-проектами. Сегодня наткнулся на продолжение темы на сайте http://www.projectcartoon.com/. Здесь можно даже выстроить свою последовательность — especially for your Boss. Как и большинство сиквелов, по определению вторично, но некоторые фрагменты-наблюдения довольно забавны, точны и язвительны.

Deadline is deadline!

29 сентября 2008, 11:41
Когда-то меня эта картинка привела в восхищение, и я потом долго пытался ее найти, но это все никак не удавалось... Однако, видимо, многие вещи во Вселенной неслучайны и происходят неспроста: именно теперь, после нескольких недель, прошедших «под знаком дедлайна», эта картинка вдруг нашлась сама собой (не в очень хорошем качестве, правда, но это уже мелочи):

Deadline is deadline!


Повесил у себя над столом...

Особенности национального программирования

23 сентября 2008, 6:14
Текст этот — довольно старый и распространен в Сети в такой степени, что ссылка на какой-либо конкретный источник попросту не имеет смысла.
Приведенные портреты — изумительно точны и даже, я бы сказал, архетипичны!:)
Я, как обычно, слегка поправил запятые. — Xendz
Любой русский программист после пары минут чтения кода обязательно вскочит и произнесет, обращаясь к себе: «Переписать это все нафиг!» Потом в нем шевельнется сомнение в том, сколько времени это займет, и остаток дня русский программист потратит на то, что будет доказывать самому себе, что это только кажется, что переписать — это много работы!.. А если взяться и посидеть немного, то все получится. Зато код будет красивый и правильный!

Hа следующее утро русский программист свеж, доволен собой и без единой запинки докладывает начальству, что переписать этот кусок займет один день, не больше. Да, не больше. Hу, в крайнем случае два, если учесть все риски. В итоге начальство даст ему неделю — и через полгода процесс будет успешно завершен... До той поры, пока этот код не увидит другой русский программист.

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

Эта четверка давно не пишет ничего нового, а только поддерживает код, написанный в свое время индусом и дважды переписанный двумя разными русскими. В этом коде не просто живут баги. Здесь их гнездо. Это гнездо постоянно воспроизводит себя при помощи любимой китайской технологии реиспользования кода — copy/paste. Отсюда баги расползаются в разные стороны посредством статических переменных и переменных, переданных по ссылке (китайский программист не способен примириться с неудобствами, вызванными тем, что он не может изменить значение внешнего параметра). Вспоминая об этих переменных и ссылках, русский программист, как правило, на время теряет дар английской речи и переходит к какой-то помеси русского и китайского. Он давно мечтает переписать весь кусок, над которым работают китайцы, но у него нет времени: он уже переписывает два больших куска и только что доказал начальству необходимость переписать третий. Кроме того, русский программист боится обидеть китайцев. Они могут решить, что он пытается вытеснить их с работы. (К слову сказать, напрасно боится, поскольку китайцы уже так решили.)

Hа китайцах висят серьезные баги. Начальство об этих багах знает и постоянно торопит китайцев. Китайцы уважают начальство и потому перевешивают баги друг на друга очень торопливо. Они знают, что все попытки починить приведут к появлению новых багов, еще худших. (И в этом они правы.) Разобраться в том, в каком порядке меняются и как приобретают свои значения статические переменные, способен только один человек на фирме — индус. Hо он пребывает в медитации. Поэтому, когда всю четверку уволят во время сокращения... (А кого еще увольнять? Русский еще не переписал свой кусок, а индус — главная ценность фирмы, он редко обращает внимание на проект, но когда обращает — все понимают, что так, как он, архитектуру никто не знает.) Так вот, когда китайцев уволят, у их кода возможны две основные судьбы. Первая — он попадет к русским и его перепишут. Вторая — он попадет к местному, канадскому программисту.

О, канадский программист — это особый тип! Он, ни на минуту не задумываясь, как рыцарь без страха и упрека, бросится фиксить самый свирепый Баг китайского кода. Этот Баг живет там уже три года, и китайцы уже четырежды (каждый по разу) сообщали начальству, что он пофиксен. Hо Баг каждый раз возвращался, как Бэтмен в свой Готхем. Итак, канадский программист, воспитанный на героической патетике американского футбола — бросаться в бой головой вперед, — сделает то, что китайцы не рисковали делать в течение трех долгих лет: он при помощи дебагера отследит место, где статическая переменная приняла значение -1 вместо правильного 0, — и решительным движением заведет рядом вторую переменную с правильным значением. Баг погибнет в неравной схватке с героем.

Hо победа будет достигнута дорогой ценой: работать перестанет все, включая только что переписанный русским программистом код. Это повергнет русского программиста в задумчивость на целых два дня, после чего он сделает предсказуемый, в общем-то, вывод о том, что дизайн с самого начала был неправильным и все надо переписать. Hа это нам нужна неделя. Да, неделя, не больше. Канадский программист смело бросится налаживать все — и станет еще хуже, хотя, казалось бы...

Эта суета выведет из медитации индуса, который придумает и вовсе гениальное решение: отбранчить код. Согласно его плану, мы теперь будем поддерживать две версии одного и того же кода: одну работающую, но с Багом, другую — без Бага, но неработающую. Русский программист, услышав об этом плане, сломает линейку об стол и обзовет жену дурой, но на митинге возразить не решится.

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

Книга жалоб и предложений (КЖИП)

4 сентября 2008, 18:50
Вчера я очередной раз почистил комментарии от спама... При этом есть вот какое любопытное наблюдение: спам появляется далеко не во всех заметках. Сначала спамерские роботы «долбятся» в какую-то одну; проходит неделя-две — обнаруживают еще одну; и так далее. Такое чувство, что остальные статьи они до поры до времени не видят.

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

Итак, добро пожаловать в «Книгу жалоб и предложений»! :)

IT-проекты в картинках

19 февраля 2008, 12:55
Эти картинки в разное время прислали мне разные люди (третья, как подсказывает пометка на ней, взята с сайта Гоблина, но мои поиски не увенчались успехом). В чем-то картинки повторяют друг друга, в чем-то дополняют. Я затрудняюсь однозначно выбрать лучшую, поэтому публикую все три — в каждой есть изюминка, а все вместе замечательно отражают особенности того, как обычно происходят IT-проекты:).

IT-проект 1


IT-проект 2


IT-проект 3

Обработка ошибок и турникеты

16 февраля 2008, 19:10

Часть первая, проектировочная

Я начну с довольно пространной цитаты из книги Дж. Гарретта «Веб-дизайн, ориентированный на пользователя. Элементы опыта взаимодействия». Гарретт выделяет три уровня обработки ошибок — предотвращение (prevention), исправление (correction) и восстановление (recovery) — и описывает их следующим образом:
Что должна делать система, когда люди совершают ошибки, и, прежде всего, что она может предпринять для предотвращения этих ошибок?

Первая и самая лучшая защита от ошибок — это разработка такой системы, в которой ошибки пользователей просто невозможны. Хороший пример такого типа защиты мы видим в любом автомобиле с автоматической коробкой передач. Попытка запустить мотор при включенной трансмиссии может повредить чувствительный и сложный механизм; более того, машина никуда не поедет, а лишь резко дернется вперед. Это плохо для машины, для водителя и для невинного пешехода, случайно оказавшегося рядом с дернувшейся машиной.

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

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

Информативные сообщения об ошибках и хорошо продуманные интерфейсы во многих случаях помогут пользователям обнаружить совершенные ошибки. Однако некоторые действия пользователя могут вначале казаться корректными, а потом будет слишком поздно, чтобы система могла их обработать. В таких случаях система должна предоставить пользователю способ восстановления после ошибки. Самым известным примером такой функции является «отмена действия», однако восстановление после ошибки может принимать разные формы. Если восстановление невозможно, то единственным доступным системе способом удержать пользователя от ошибки является большое количество предупреждений. Разумеется, предупреждения эффективны, только если пользователи действительно обращают на них внимание, и поэтому последовательность диалоговых окон «Вы уверены?..» больше раздражает, чем помогает.
Что происходит на практике, когда программист работает над кодом? Предотвращение обычно отметается, поскольку является весьма затратным именно с точки зрения программиста. Допустим, некоторая операция в данный момент не может быть выполнена или не имеет смысла (например, копирование в буфер обмена, когда только что создан новый пустой документ — в котором нечего копировать по определению). Чтобы предотвратить ее выполнение, надо сделать ее недоступной во множестве мест: заблокировать в меню, заблокировать в контекстном меню, заблокировать на стандартной панели инструментов, заблокировать на пользовательских панелях инструментов (если она там есть), заблокировать соответствующие «горячие» клавиши, заблокировать стандартную «быструю» комбинацию клавиш (если она не переназначена), заблокировать пользовательские комбинации клавиш (если есть)... (К чести Microsoft Word, в ней работа в этом случае идет именно на уровне предотвращения.)

Проще, намного проще «помочь пользователю осознать ошибку и устранить ее». Однако и это в мышлении программиста трансформируется в банальное «выдать сообщение об ошибке». Он не видит в этом ничего дурного: сам он регулярно имеет дело с сообщениями об ошибках — в том числе в роли пользователя. Ему крайне трудно представить себе ощущения человека, не являющегося IT-специалистом, когда тот сталкивается с сообщением об ошибке...

Часть вторая, жизненная

Мой старший сын очень не любит метро. Причина этой неприязни весьма проста: однажды, когда ему было лет 5 или 6, турникет — тот самый советских времен турникет, который в ответ на попытку неоплаченного прохода грозно лязгает «челюстями», — сработал не так, как должен был. Сейчас в московском метро идет постепенная замена турникетов на «французские» (так их называет мой сын, которому в качестве утешения я рассказал тогда про то, что бывают более «дружелюбные» турникеты и что я видел такие в Париже). «Французский» турникет действует ровно наоборот: он открывает проход, если получена оплата.

Давайте посмотрим на ситуацию с точки зрения схемы взаимодействия пользователя с системой.

Происходят последовательно два действия пользователя: (А) оплата и (Б) проход. Если в ходе действия А случилась ошибка (проход рассматривается системой как неоплаченный — потому что он действительно не оплачен, или потому что билет просрочен, или потому что билет размагнитился, или потому что пользователь не достал обработанный билет из щели, или потому что просто сбойнула электроника, и т. п.), пользователь не должен совершить («ошибочное») действие Б.

«Французский» турникет работает по принципу предотвращения: он не открывает проход, просто не давая возможности совершить ошибочное действие. «Извините, проход закрыт».

«Советский» турникет блокирует действие Б в момент его совершения — по сути своей это соответствует крайней форме сообщения об ошибке. «КУДА ПРЕШЬ, КР-Р-РЕТИН?!»

(К слову, мне кажется, что это свидетельствует и о разнице в менталитете проектировщиков этих турникетов.)

Подавляющее большинство программистов живут в крупных городах и хотя бы однажды были «неправедно защелкнуты» турникетом старого образца. Полагаю, в тот момент это вызвало вполне определенную эмоциональную реакцию; теперь достаточно просто ее вспомнить, чтобы на своей шкуре почувствовать, как рядовой пользователь воспринимает сообщение об ошибке: «ЧТО ТЫ СДЕЛАЛ, НЕДОУМОК?!»

Ноги сапожника

7 февраля 2008, 12:29
Повелось у нас принимать как данность отсутствие сапог у сапожника. А между тем они, как правило, есть, и их качество может о многом сказать даже очень постороннему взгляду... (Хм... зощенковский какой-то зачин получается... ну да бог с ним.)

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

посмотри на ноги сапожника.


Раскрутчики должны как-то сами раскручиваться... Остальное было минутным делом — найти в поисковике сайты, которые ссылаются на сайт маленькой группы умелых товарищей. Поисковик вывалил нам список, на 98% состоящий из порносайтов.

Вот так закончился спор. А принцип остался — рекомендую!:)
SEO   Xendz-айтишник   просто Xendz   простые мысли

Две лошадиных задницы

25 декабря 2007, 12:41
Американские космические челноки снабжены твердотопливными ускорителями (попросту говоря, двигателями) диаметром около 5 футов. Конструкторы хотели бы сделать эти двигатели больше, но не смогли. Почему?

Дело в том, что эти ускорители производятся на заводе компании Thiokol в штате Юта и доставляются на космодром по железной дороге, проходящей по узкому горному туннелю, ширина которого по сути определяется шириной железнодорожной колеи — 4 фута 8,5 дюйма. Возникает вопрос: откуда взялось это расстояние между рельсами — 4 фута 8,5 дюйма?

Оказывается, первые железные дороги в США строили английские инженеры — они и позаимствовали английский железнодорожный стандарт. На английские железные дороги этот стандарт был, в свою очередь, перенесен с английских трамваев, которые унаследовали это значение от конки. Однако почему длина оси конки составляла 4 фута 8,5 дюйма?

Вагоны конки изготавливались с помощью тех же лекал и инструментов, что и кареты, поэтому длина их оси совпадала с каретной. А почему кареты имели ось такой длины?

Дело в том, что при такой длине оси каретные колеса попадали в глубокие колеи на старых дорогах Англии. При другом значении кареты часто выходили бы из строя. Однако почему колеи на английских дорогах оказались выбиты именно на таком расстоянии — 4 фута 8,5 дюйма?

Первые дороги на длинные расстояния в Европе (и Англии) строились Римской империей. Ширина колеи делалась такой, чтобы по ней могли легко передвигаться римские боевые колесницы, длина оси которых была... совершенно верно — 4 фута 8,5 дюйма! Но чем определялась эта длина?

В боевую колесницу обычно запрягалась пара лошадей, и 4 фута 8,5 дюйма — это как раз удвоенная ширина лошадиного крупа. Делать ось короче неразумно, потому что колесница становится менее устойчивой, а при большей длине оси повышается риск поломки (например, при встречном разъезде).

Вот и ответ на самый первый вопрос: даже теперь, когда человечество вышло в космос, его наивысшие технические достижения напрямую ограничиваются размером лошадиной задницы две тысячи лет назад.
P.S. В поисках первоисточника этого замечательного текста я докопался до статьи на сайте отделения IEEE в Хантсвилле. Оказывается, всё всерьез.

SAPерские премудрости

9 ноября 2007, 3:11
«В среднем, из общего числа IT-систем, находящихся в разработке, более половины прекращают свое существование, а из второй половины приблизительно две трети идут в разработку. Половина этих систем так никогда и не реализуется, а реализация другой четверти не доводится до середины. В свою очередь, из оставшейся четверти половина систем не способна обеспечить необходимый набор функциональных возможностей, и, вследствие этого, отбрасывается за ненадобностью. И лишь остаточная половина систем используется после внесения значительного количества модификаций, что влечет дополнительные задержки и издержки практически бесконечного процесса.»

В. Кале. Внедрение SAP R/3. Руководство для менеджеров и инженеров. — М.: Компания АйТи, 2006. С. 32.
Ну ни дать ни взять — «занимательная арифметика для топ-менеджера»! Если господа SAPеры внедряют системы с той же степенью внятности, с которой пишут книги, меня не удивляет, что даже по опубликованным оценкам четверть внедрений SAP неуспешна.

К слову, орфография и пунктуация оригинала бережно сохранены...

SAP   Xendz-айтишник   Xendz-читатель   фи