среда, 2 ноября 2011 г.

Уровни экспертизы

Когда-то давно услышал чьё-то мнение о том, что японцы - самая художественная нация. Возник законный вопрос - почему? Ведь на вскидку почти любой образованный гражданин России, США и Европы не сможет припомнить ни одного знаменитого японского художника, хотя легко назовёт несколько великих российских и европейских художников. Выяснил, что критерий тут другой - лингвистический. Дело в том, что в японском языке присутствует самое большое количество самостоятельных слов, выражающих различные оттенки цветов. Можно долго строить предположения, с чем это связано, но пока можно заключить лишь, что на каком-то этапе развития японской культуры для них было очень важно различать большое количество оттенков цветов и для их отражения в их языке появились эти слова.

Я - тренер, так что предмет моей работы - это знание. И я думаю, что уже назрела необходимость расщеплять это понятие и разобраться с тем, что мы называем "знаю", а что - нет. Т.е. разобраться с тем, что знание по сути собой представляет и каким оно в силу этого бывает, так как отсутствие возможности объясниться по существу не даёт развиваться, более глубоко разбираться в теме. Не могу сказать, что долго копался в работах по гносеологизму, которые должны были бы, видимо, в этом вопросе активно копаться, так что сильно рискую изобрести велосипед, но всё-таки напишу как я вижу вопрос, не претендуя на особую оригинальность. Надеюсь, это окажется полезным и кому-то другому.

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

Перво-наперво определим предмет обсуждения. Я бы хотел разобраться в том, что можно называть "глубиной знания" какой-то темы. Глубина бывает разной. Что бы мерить глубину, нужны какие-то объективные критерии в виде того, что позволяет знание той или иной глубины, имеющееся у человека в отношении какой-либо темы. Т.е. в качестве критериев удобнее всего взять возможности, которые открывает знание определённой глубины. Такие критерии и становятся уровнями, вносящими разметку в глубину знания.

Итак, что значит - знать какой либо инструмент? По своему опыту я склонен делить знание на 3 уровня:
1. Знакомство или игровое знание. Знание, полученное в ходе игры с технологией. Знания на этом уровне достаточно для того, что бы делать интересные и в общем-то, как правило, никому, кроме автора, ненужные штуки на ней. Программисты так обычно и говорят - "поиграться" с какой-то технологией (например - "Я поигрался со Spring`ом"). Это означает, что на ней просто сделано что-то, что в принципе получилось и даже работает, но ничего полезного никому не приносит - не для этого делалось, а просто так. Кстати, знание именно на этом уровне обычно формируется в результате прохождения того или иного тренинга. В программировании людей, до конца прошедших этот уровень, обычно называют Junior Developer`ами или просто Junior`ами.

2. Навык или рабочее знание. Знание, полученное в ходе активного применения технологии в работе над каким-либо боевым проектом. Знания на этом уровне достаточно уже для того, что бы не просто делать ЧТО-ТО с помощью этой технологии, но и для того, что бы выполнять РЕАЛЬНЫЕ ЗАДАЧИ БИЗНЕСА, более или менее укладываясь в заявленные сроки. Т.е. необходим опыт применения этой технологии, достаточный для оценки рисков по срокам работ при получении задачи работником от своего менеджера проекта. Если такого опыта нет - просто ставить задачу бесполезно - человек не может оценить всех рисков и его согласие - это лишь согласие заняться этой задачей, а не принятие на себя ответственности за её решение в заявленные сроки. По-этому обычная обязанность Team-Lead`а (руководителя группы разработчиков) - брать на себя управление рисками при постановке задач Junior`ам. Обычно разработчиков, имеющих знание на этом уровне, называют либо просто разработчиками, либо Старшими разработчиками (Developer или Senior Developer).

У меня ушло очень много времени для того, что бы понять, в чём конкретно заключается разница между Senior`ом и простым Developer`ом. По сути во многих IT-организациях эти различия очень условны и на практике обычно отражают простую "выслугу лет" - например, 5 лет работал Developer`ом - после этого тебя нарекают Senior Developer`ом. Это, конечно, плохая практика с точки зрения удовлетворения карьерных амбиций - когда молодой сотрудник стремится построить свою карьеру, все его усилия сосредотачиваются на эффективном, быстром достижении каких-то целей, но когда он понимает, что цель "стать Senior`ом", фактически, является пассивно-достижимой (сама придёт к нему через 5 лет, и никак этот процесс ускорить нельзя) - это способно погрузить его в уныние.

Иногда говорят, что старшие разработчики должны дополнительно тянуть лямку обучения младших, однако на практике это требует уже следующего уровня (об этом - чуть ниже) и по-этому по факту выражается в пассивном обучении: такой старший разработчик говорит младшему примерно следующее - "Смотри на меня и делай, как я!" - и пишет при нём код, слегка проясняя какие-то моменты. Наиболее чёткий критерий я услышал от одного из крупных менеджеров Ланит`а. Он выразил мысль, что Senior - это тот, кому можно поставить задачу и не контролировать её выполнение, будучи полностью уверенным, что он уложится в срок или сам вовремя подаст сигнал о том, что не успевает или у него возникли какие-то иные трудности. А простому Developer`у нужен некоторый контроль, хотя, конечно, и не такой сильный, как за Junior`ом.

Кстати, именно по-этому Junior`ом так сложно устроиться - степень необходимого контроля за ним, выражающаяся во времени, которое тратит на него руководитель и консультирующие его по техническим вопросам коллеги, фактически часто перевешивает эффект от его работы, так что, вытягивая его на уровень Developer`а, организация часто больше тратит, чем приобретает и фактически такой сотрудник начинает приносить прибыль только после этого. Так что наём Junior`а - это лишь перспективное вложение денежных средств для компании.

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

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

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

Действительно, многим из нас часто кажется, что если, как утверждают философы, "практика - критерий истины", то способность использовать знание - есть критерий его наличия. И, соответственно, если ты знаешь - то "чего такой жадный?", ведь, "От тебя не убудет?" - обучи другого, "Жалко, что ли?".

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

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

Действительно, проведите над собой эксперимент. Найдите сейчас в своём поле зрения, например, дерево и задайте себе вопрос - какое оно? Скажите, что первым придёт в голову. Потом ещё раз - какое оно кроме того, что Вы уже сказали? И так раз 5-7, запоминая порядок, в котором Вы назвали эти признаки. Что получилось? У меня вот - Круглое в обхвате, большое, высокое, раскидистое, старое, унылое, шершавое, коричневое, красивое. Каких из этих признаков вы не назвали и что назвали такого, чего нет у меня? Попытайтесь проанализировать тот порядок, в котором вы назвали эти признаки. Это - не случайная последовательность признаков - нет! Это - картина ваших приоритетов, т.е. тех качеств, которые Вы видите в деревьях в первую очередь, поскольку именно в такой последовательности они для Вас важны. То, что вы назвали в числе последних - для вас практически не важно, а вот то, что называли первым - бросилось в глаза, значит, действительно важно. Если вы через несколько дней будете вспоминать, какое это было дерево, то вспомните, вероятно, только те его качества, которые назвали первыми. Этот порядок - это и есть проявление Вашей особенности восприятия мира вокруг на примере такого объекта, как дерево.

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

Но если дать ему группу желающих научиться работать с этой технологией и попросить её обучить - получится, что то, как привык действовать он, не подходит другим людям, т.к. они мыслят по-другому. У них другие приоритеты и они, применяя принцип Парето, из общего объёма знаний отсеяли бы ДРУГИЕ 20%, нежели те, которые отсеял он, восприняв то, что знает он, как "воду", "информационный шум".

Поэтому существует 2 подхода к решению данного вопроса.

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

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

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

Комментариев нет: