Компьютерра PDA 13.02.2010-19.02.2010

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

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

А критерий не изменился со времен первых инженеров, строивших пирамиды.

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

Ламер же воспринимает систему как некий условный алтарь, перед которым он "камлает". Он знает некие наборы действий, которые должны приводить к определенным результатам. Почему именно такие наборы и именно такие результаты - обычно ламер знает плохо или не знает вовсе. При этом человек может быть крутосертифицированным специалистом, успешно устанавливать и настраивать достаточно сложные системы, и всё равно оставаться лишь хорошо натасканным ламером.

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

Вопрос первый - почему так происходит?

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

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

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

Собственно, вопрос второй - как?

Как убить в себе ламера в отдельно взятой области и стать в ней специалистом?

Ответ уже был дан - строить модели и оперировать ими.

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

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

1. Первейшая задача траблшутинга - точная локализация проблемы. В зависимости от области и компетенции, успешная локализация означает от 50 до 95 процентов успешного разрешения проблемы.

2. Вы столкнулись с проблемой. Данная проблема имеет определенные проявления - нечто не работает или нечто работает не так как должно. Отлично - отметьте все проявления проблемы, которые можете. Т.е. то-то и то-то - не работает, это - работает вот так, а должно было этак. Ничего не меняйте.

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

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