Обикновено пиша за ИТ – относно различни, повече или по-малко, сфери като 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, нещата достигат абсурд: дори в практиката ми е имало случай, когато доставчици, предлагащи един и същ продукт под различни търговски марки, имаха леко различаващи се погледи по въпроса, затова когато по молба на клиента провеждаха ежегодна оценка, един от докладите винаги съдържаше предупреждение за нарушаване на best-practices, докато друг, напротив, хвалеше за пълно съответствие.
И нека това звучи прекалено академично и на пръв поглед неприложимо в области като поддръжка ИТ системи, където се изисква прилагане на умения, а не изучаване на предмета, но ако има желание да избягаш от омагьосания кръг, независимо от оскъдността на наистина важната информация и знания, винаги ще се намерят начини и методи да разбереш всичко. Най-малкото на мен ми се струва, че помагат:
- Критично мислене, научен подход и здрав разум;
- Търсене на причини и изучаване на първични източници на информация, основни текстове, стандарти и формални описания на технологии;
- Изследване, а не зубрене. Липса на страх от "велосипедите", построяването на които дава възможност поне да разбереш защо други разработчици, инженери и архитекти са избрали един или друг начин за решаване на сходни проблеми, а максимално да направиш велосипеда още по-добър от преди.
Източник: habr.com
