А результат гуманизма? Вот начальник отдела из КБ, и ныне ещё поставляющего на экспорт оружие на девятизначные суммы. Он получил молодых специалистов. Начальница сектора поручила одному из них по двум точкам определить, где прямая пересечется с другой прямой. Ответа через полчаса не было. "Почему?" "А это высшая математика, которую нормальный человек знать в принципе не может…" Начальнику отдела пришлось отпаивать подчиненную арманьяком. Вот тут мы наконец встречаемся с парой человек, которым разговоры о модернизации излишни – они и так вынуждены жить на фронтире технологий. И подготовкой молодого специалиста вообще-то не удивлены – "на кафедрах деды за семьдесят, зайдут за свои 15-20 тыр на часок, прочтут, чему учились в пятидесятые…". Но вот нужна ли модернизация упомянутым "дедам", которые получают прибавку к пенсии? И что можно наработать при таких молодых кадрах, искренне считающих себя нормальными?
А чуть дальше смахивающий на человека-пингвина местный политик-демагог массует работяг на митинг. Их старинный завод не платит зарплату. (Вышеупомянутое КБ наконец-то нашло более дешёвых подрядчиков, с аппетитами местных неминуем вылет, – но не боевой на цель, а с рынка.) Нет работы – нет и денег! Но понять это пролетариату трудно – "всегда-то платили…", обиженно бормочет он. Уверены, что ему, пролу с разваленной печенью и трясущимися лапками, нужна модернизация? Нет, увеличения получки хочется, но вот зарабатывать её, учиться чему-то, дисциплинированно и усердно работать, конкурируя в глобальной экономике с работягами из Азии… Зачем, когда есть возможность воспользоваться гражданскими правами – выйти на митинг и заставить директора завода взять кредит (вымороченные цеха в центре города банк пристроить сумеет…).
Сделаем грустный вывод – большинство избирателей в технологической и организационной модернизации, во вложении денег не в текущее потребление, а в обновление оборудования, в оптимизацию бизнес-процессов, не заинтересованы. И овладевать новыми знаниями и навыками им не хочется. Ведь демократические механизмы позволяют перераспределить попавшие в Россию в нулевые годы нефтедоллары на пополнение потребительской корзины – тем более, что весь механизм рынка твердит "Покупай! Потребляй!". Ничего удивительного. Пока есть, что перераспределять – будет выгодно перераспределять, а не производить. А когда перераспределять станет нечего, не на что будет и модернизироваться. Так было везде и всегда – не надо полагать, что у нас народ имеет какие-то специфические недостатки (или достоинства). Эдакий принцип наименьшего действия. Ещё в Элладе было принято демократическим путем раскулачивать зажиточных, о чём нам подробно рассказал Аристотель. И те надежды, которые в Перестройку возлагали на народоправство, да и возлагают посейчас, говорят не о том, что большевики скрывали Отца философии от масс, а о том, что его элементарно ленятся читать…
Но и говорить, как любят часто, что нам не повезло с народом, нельзя. В обрушении здания всегда виноват архитектор. Другое дело, что из самана строят по иным канонам, чем из портланд-бетона и нержавеющей стали. И претендующие на право строить общество обязаны это знать.
"Убить ламера" или системный подход к траблшутингу
Автор: Денис Теребий
Опубликовано 16 февраля 2010 года
Наш читатель Денис Теребий написал статью о различиях между ИТ-специалистами и ИТ-ламерами. А также о том, что вторые при желании вполне могут со временем стать первыми. Орфография и пунктуация автора сохранены.
Предисловие: Надеюсь, что для большинства читателей я данной статьёй ничего нового не открою. Но как показывает мой опыт ИТ-руководителя, для многих (практически всех) начинающих ИТ специалистов многие вещи очевидными не являются, что сильно снижает их эффективность. Для них и их руководителей эта статья.
Как отличить ИТ-специалиста от ИТ-ламера? Задумывались? Наверняка задумывались те, кому нужно было нанять сотрудника, и желательно - с мозгами. Как показывает практика, никакие сертификаты не покажут реальной способности сотрудника решать нетипичные задачи. Знания систем и способность эти знания успешно использовать в нештатных ситуациях - весьма не одно и тоже. Так где критерий?
А критерий не изменился со времен первых инженеров, строивших пирамиды.
Специалист воспринимает систему как комплекс связанных между собой элементов, знает механизмы и правила связей и в состоянии мысленно представить модель системы или отдельных её элементов. Пройтись мысленно же от базовых блоков до ожидаемых наблюдаемых эффектов и наоборот - по наблюдаемым эффектам вычислить нюансы работы базовых блоков.
Ламер же воспринимает систему как некий условный алтарь, перед которым он "камлает". Он знает некие наборы действий, которые должны приводить к определенным результатам. Почему именно такие наборы и именно такие результаты - обычно ламер знает плохо или не знает вовсе. При этом человек может быть крутосертифицированным специалистом, успешно устанавливать и настраивать достаточно сложные системы, и всё равно оставаться лишь хорошо натасканным ламером.
Специалист оперирует моделью. Ламер - набором шаблонов. Специалист в одной области может быстро разобраться в другой родственной, поняв основные принципы построения системы. Ламера нужно переучивать и долго натаскивать - тогда он кое как сможет выполнять те задачи, на которые его натаскали.
Вопрос первый - почему так происходит?
Чтобы ответить, придется обратить внимание на механизмы работы нашего мозга. Не углубляясь в детали обратим внимание лишь на базовые аспекты: когда мозг получает новую ситуацию, с которой ему нужно справиться, он в первую очередь обращается к воспоминаниям в поисках схожей ситуации. Если находит - то предлагает тот вариант решения, который сработал тогда. И этот алгоритм - основа мозговой деятельности любого земного организма с высшей нервной системой. В том числе и для высших приматов вплоть до нас с вами.
Иначе говоря, использование шаблонов при поиске решения - это штатный режим для человеческого сознания. Более того, в подавляющем большинстве вопросов, начиная с моторики, продолжая межполовыми вопросами и заканчивая управлением государством - чуть менее чем всюду используется именно эта схема. Потому как она - оптимальна с точки зрения затраты/эффективность в подавляющем большинстве случаев. К тому же ни один мозг не в состоянии моделировать в себе сколько либо значительную часть окружающей реальности.
Но в отдельных ограниченных областях мы можем выходить за пределы шаблонного восприятия, и именно в этих областях мы можем и должны быть специалистами. Такой выход не отменяет использование шаблонов, но значительно расширяет и дополняет их.
Собственно, вопрос второй - как?
Как убить в себе ламера в отдельно взятой области и стать в ней специалистом?
Ответ уже был дан - строить модели и оперировать ими.
Ниже будет дан простой сценарий по использованию моделей в траблшутинге. В текущем виде он относится к системному и сетевому администрированию, но, полагаю, при желании может быть расширен как на программирование, так и на далекие от ИТ области.
Уточняю - речь идет о проблеме, не являющейся хорошо известной столкнувшемуся с ней и к которой "стандартные драйвера не подошли"(с)
1. Первейшая задача траблшутинга - точная локализация проблемы. В зависимости от области и компетенции, успешная локализация означает от 50 до 95 процентов успешного разрешения проблемы.
2. Вы столкнулись с проблемой. Данная проблема имеет определенные проявления - нечто не работает или нечто работает не так как должно. Отлично - отметьте все проявления проблемы, которые можете. Т.е. то-то и то-то - не работает, это - работает вот так, а должно было этак. Ничего не меняйте.
3. Посмотрите на базовые показатели системы, постарайтесь отметить отклонения от нормальных или ожидаемых. Либо отметить полное соответствие - на данном этапе данная информация имеет совершенно идентичный уровень важности. Опять-же ничего не меняйте.
4. Остановитесь и подумайте. Теперь ваша задача - сформулировать предположение о том, некорректная работа в какой подсистеме (или подсистемах) могла привести к тому набору симптомов и показателей, которые вы зафиксировали. Данное предположение должно быть более-менее разумным и объяснять все наблюдаемые проявления. Данный пункт - самый важный.
5. Найдите способ проверить ложность вашего предположения. Это может быть счетчик или датчик, это может быть вариант пустить работу системы в обход подозреваемой подсистемы с редуцированием некого функционала, думайте. Главное, чтобы данный показатель мог гарантированно продемонстрировать ошибочность вашего предположения, если оно действительно ошибочно. Акцентирую - задача первичной проверки не доказать правильность предположения, а гарантированно отбросить предположение в случае его ошибочности.
