Обычно я пишу про ИТ – на разные, более или менее, узкоспециализированные темы вроде SAN/СХД или FreeBSD, но сейчас я попытаюсь выступить на чужом поле, поэтому многим читателям мои дальнейшие рассуждения, покажутся в достаточной мере спорными или даже наивными. Впрочем, так оно и есть, и потому я не в обиде. Однако, как непосредственный потребитель знаний и образовательных услуг, пардон за этот жуткий канцеляризм, а также как восторженный дилетант жаждущий поделиться urbi et orbi своими сомнительными «находками и открытиями», промолчать я вряд ли тоже смогу.
Поэтому, вы или проскакивайте этот текст дальше пока не поздно, либо смиритесь и терпите, потому, что, вольно цитируя известную песню, всё что я хочу, это гнать свой велосипед.
Итак, чтобы разложить все по полочкам, начнем издалека – со школы, которая по идее должна учить базовым вещам о науках и окружающем мире. В основе своей этот багаж преподносится с помощью традиционных приёмов схоластики, вроде зубрежки тщательно выхолощенной школьной программы, содержащей ограниченный набор препарируемых учителями выводов и формул, а также многократных повторений одних и тех же заданий и упражнений. Из-за этого подхода в изучаемых темах часто теряется ясность физического или практического смыслов, что, на мой взгляд, наносит критический ущерб систематизации знаний.
В общем, с одной стороны, школьные методы хороши для массового вдалбливания минимально-обязательного набора информации в головы тех, кто не очень-то хочет учиться. С другой, они могут тормозить развитие тех, кто способен добиться бОльшего, чем просто натренировать рефлекс.
Допускаю, что за те 30 лет, как я покинул школу, положение изменилось к лучшему, но подозреваю, что это всё равно не слишком далеко ушло от средневековья, тем более, что религия опять вернулась в школу и там вполне хорошо себя чувствует.
Я никогда не посещал колледж, или другое профессиональное учебное заведение, поэтому ничего не могу сказать про них по существу, однако велик риск, что изучение профессии там может свестись исключительно к тренингу конкретных прикладных навыков, упуская при этом из вида теоретическую базу.
Идем дальше. На школьном фоне образовательный институт, или университет, с точки зрения приобретения знаний выглядит настоящей отдушиной. Возможность, и даже в некоторых случаях обязанность изучения материала самостоятельно, бОльшая свобода выбора способов познания и источников информации открывает широкие возможности для тех, кто может и хочет учиться. Тут все зависит от зрелости студента и его стремлений и целей. Поэтому, несмотря на то, что высшее образование в какой-то мере заслужило репутацию косного, отстающего от развития современных ИТ, все-таки многие студенты успевают отработать методы познания, а также приобрести шанс возместить ущербность школьного образования и заново овладеть наукой учиться автономно и самостоятельно приобретать знания.
Что касается всевозможных курсов, которые организовывают поставщики ИТ оборудования и программного обеспечения, то надо понимать, что их основная цель – научить потребителей пользоваться их программами и оборудованием, поэтому часто алгоритмы и теоретические основы, а также важнейшие детали того, что скрыто «под капотом», рассматриваются на занятиях лишь в той мере, в какой производитель вынужден это сделать, чтобы дать общие сведения о технологии, не раскрыв при этом коммерческой тайны и не забыв подчеркнуть свои преимущества по сравнению с конкурентами.
По тем же причинам, процедура сертификации ИТ специалистов, особенно на начальных уровнях, часто грешит проверками малосущественных знаний, а тесты задают очевидные вопросы, или хуже того: проверяет у соискателей рефлекторное владение материалом. Как, например, почему бы на сертификационном экзамене не спросить у инженера «с какими аргументами: -ef, или -ax следует запускать команду ps», имея в виду данный конкретный вариант UNIX или дистрибутив Linux. Подобный подход потребует от тестируемого заранее вызубрить наизусть эту, а также многие другие команды, даже несмотря на то, что эти параметры всегда можно уточнить в man, если в какой-то момент администратор их забудет.
К счастью, прогресс не стоит на месте, и через несколько лет одни аргументы изменятся, другие устареют, а новые появятся и займут места прежних. Как это случилось в некоторых операционных системах, где со временем начали использовать версию утилиты ps, которая предпочитает синтаксис без «минусов»: ps ax.
И что же тогда? Правильно, необходимо пересертифицировать специалистов, а лучше взять за правило, раз в N-лет, или с выходом новых версий ПО и оборудования, отзывать «устаревшие дипломы», тем самым, побуждая инженеров проходить сертификацию по обновленной версии. И, разумеется, необходимо сделать сертификацию платной. И это при том, что сертификат одного вендора ощутимо потеряет локальную ценность в том случае, если наниматель специалиста поменяет вендора – начнет закупать аналогичное оборудование у другого поставщика. И ладно, если бы это происходило только с «закрытыми» коммерческими продуктами, доступ к которым ограничен, и потому, сертификация по ним имеет некоторую ценность из-за своей относительной редкости, однако часть компаний вполне успешно навязывает сертификацию и по «открытым» продуктам, например, как это случается с некоторыми дистрибутивами Linux. Более того, инженеры сами стараются «подсесть» и на сертификацию по Linux тоже, тратят на нее время и деньги, в надежде, что это достижение прибавит им вес на рынке труда.
Сертификация позволяет стандартизировать знания специалистов, давая им единый некий средний уровень знаний и оттачивает до автоматизма навыки, что, конечно, очень удобно для такого стиля менеджмента, который оперирует понятиями вроде: человеко-часы, людские ресурсы и нормы выработки. Корни такого формального подхода ведут в золотой век индустриальной эпохи, на крупные фабрики и промышленные предприятия, построенные вокруг конвейера, где требуется, чтобы каждый работник выполнял конкретные действия точно и в очень ограниченный срок, а на то, чтобы думать у него просто нет времени. Впрочем, чтобы думать и принимать решения, на заводе всегда есть другие люди. Очевидно, что человек в такой схеме превращается в «винтик системы» – легко-заменяемый элемент с известными характеристиками производительности.
Но и на не промышленном предприятии, а в ИТ, такое удивительное качество как лень, заставляет людей стремиться к упрощению. В системе Skills, Rules, Knowledge (SRK) многие из нас добровольно предпочитают пользоваться отработанными до автоматизма навыками и следовать правилам, которые разработали умные люди, а не прилагать усилия, исследовать проблемы вглубь и преобретать знания самостоятельно, ведь это так похоже на изобретение очередного бессмысленного велосипеда. И, в основном, вся система образования начиная со школы и заканчивая курсами/сертификацией ИТ-специалистов потворствует этому, приучая людей к зубрежке, вместо исследований; тренировке навыков пригодных для конкретных экземпляров приложений или оборудования, вместо понимания корневых причин, знания алгоритмов и технологий.
Другими словами, во время обучения львиная доля сил и времени отводится на то, чтобы отрабатывать подход «Как использовать тот или иной инструмент», а не на поиск ответа на вопрос «Почему это работает так, а не иначе?» По этим же причинам, в сфере ИТ зачастую применяется метод «best practices», описывающий рекомендации по «наилучшей» настройке и использованию тех или иных компонентов или систем. Нет, я не отвергаю идею best-practices, она весьма хороша в качестве cheat sheet или check list, но зачастую подобные рекомендации используются как «золотой молоток», они становятся нерушимыми аксиомами, которым инженеры и менеджмент следуют неукоснительно и бездумно, не удосуживаясь выяснить ответ на вопрос «почему» дана та или другая рекомендация. И это странно, ведь если инженер изучил и знает материал, ему не нужно слепо полагаться на авторитетное мнение, которое пригодно в большинстве ситуаций, но вполне вероятно, неприменимо к конкретному случаю.
Иногда в связи с best-practices доходит до абсурда: даже в моей практике был случай, когда вендоры, поставляющие один и тот же продукт под разными торговыми марками, имели слегка различавшиеся взгляды на предмет, поэтому когда они по просьбе заказчика проводили ежегодный assessment, один из отчетов всегда содержал предупреждение о нарушении best-practices, в то время как другой, наоборот, хвалил за полное соответствие.
И пусть это звучит слишком академично и на первый взгляд неприменимо в таких сферах как поддержка ИТ-систем, где требуется применение навыков, а не изучение предмета, но если есть желание вырваться из заколдованного круга, несмотря на скудность по-настоящему важной информации и знаний, всегда найдутся способы и методы во всем разобраться. Мне, по крайней мере, кажется, что помогают:
- Критическое мышление, научный подход и здравый смысл;
- Поиск причин и изучение первичных источников информации, исходных текстов, стандартов и формальных описаний технологий;
- Исследование в противовес зубрёжке. Отсутствие страха перед «велосипедами», постройка которых дает возможность, как минимум, разобраться, почему другие разработчики, инженеры и архитекторы выбрали тот или иной путь решения сходных проблем, а как максимум, сделать велосипед ещё лучше, чем прежде.
UPD: В качестве продолжения написал небольшой текст о принципиальных различиях между навыками и знаниями.
