«Есть такой известный эксперимент Стива Бокмана», — эта фраза немного подвесила меня, так как ничего ни про эксперимент, ни про самого Стива я ни разу не слышал… Начал искать, кто такой Стив. С трудом отфильтровал его от актера, нашел на FB, и только после этого наткнулся на его описание проведения того самого эксперимента. Чем и делюсь.
«Избегаем узких мест передачи знаний.
В разработке программного обеспечения есть много способов передать знания о том, как создать продукт, людям, которые выполняют фактическое здание. Однако производство может быть серьезно затруднено, если эти знания генерятся быстрее, чем они потребляются. Это узкое место передачи знаний.
Недавно я провел семинар, который позволяет участникам испытать три различных способа передачи знаний в рабочей среде. Изделие в данном случае представляло собой бумажный самолетик необычной конструкции. Идея заключалась в том, чтобы попробовать различные способы передачи знаний о том, как построить самолет, от «главного конструктора» (меня) к производственным работникам, и сравнить относительную производительность различных методов:
- Документация – рабочим были даны письменные инструкции (22 шага) по постройке самолета.
- Обратный инжиниринг – рабочие получили готовый самолет, который они могли изучить, чтобы воспроизвести шаги, необходимые для его создания.
- Наставничество — «главный конструктор» строил самолет шаг за шагом, и рабочие повторяли каждый шаг по мере его выполнения.
Эксперимент проводился в два этапа. На первом этапе все 8 участников использовали метод документирования. На втором этапе одна команда из 4 человек попробовала реверс-инжиниринг, а другая команда из 4 человек — наставничество.
Результаты оказались интересными. Используя метод документации, только один человек из в общей сложности 8 приблизился к тому, чтобы вообще построить самолет за отведенный 5-минутный период.
Используя метод обратного проектирования, 1 человек из в общей сложности 4 произвел готовый самолет за 5 минут.
Используя метод наставничества, каждый из 4 членов команды сделал готовый самолет менее чем за 5 минут.
Узкое место передачи знаний в программном обеспечении
В процессе разработки программного обеспечения передача знаний происходит постоянно, и легко представить себе разработчика программного обеспечения в роли “главного конструктора”, описанной в упражнении выше.
Предположим, я разработчик, который обнаружил и написал код для реализации метода привязки некоторых данных к элементам управления пользовательского интерфейса, и что этот метод формирует шаблон, о котором хотят знать мои коллеги-разработчики. Если бы вы были одним из моих коллег-разработчиков, вы бы предпочли, чтобы я (а) дал вам документ, в котором я описал технику, (б) рассказал вам, где находится код, и предложил вам разобраться в нем самостоятельно себя или (в) в паре с вами реализовал шаблон для нового набора данных?
Конечно, в реальной жизни работа в паре с тобой занимает больше моего времени и может показаться менее эффективной с моей точки зрения. В конце концов, я мог бы заняться проектированием следующего рисунка, и еще одного после этого. Но производительность команды в целом, а не моя личная производительность, вот что важно. А наставничество помогает повысить производительность команды, избегая узких мест в передаче знаний.»
Великолепный пример, который содержит в себе много интересного. Во-первых, то, что передача документированных знаний (базы знаний, инструкции, регламенты и прочее), — не всегда оптимальный способ научить чему-то. Особенно, если учатся новички.
Во-вторых, и это ценнее на несколько порядков, — «надо чаще встречаться»! Именно за счет коммуникации людей многие непонятные вопросы снимаются, приходят новые идеи, а задачи – решаются.
Свою профессиональную деятельность я начинал с роли системного аналитика. И мне повезло, — у меня был отличный учитель, который на сегодняшний день «спроектировал», наверное, под сотню систем самой разной сложности. И уже тогда, читая книги по системному анализу, я впитал, что «ошибки, выявленные на этапе проектирования, стоят на порядок дешевле, чем…» Ну, и так далее. Каково же было мое удивление, что реальный бизнес на миллионных, миллиардных контрактах, и не всегда в рублях, готов совершать эти самые ошибки, экономя на семечках, и терять потом колоссальные суммы!
А ведь казалось бы… Только сегодня обсудили с коллегой, что практически в любой организации можно довольно быстро собрать информацию о том, в какой предметной области сотрудники компании обладают экспертизой, и в короткие сроки выйти на создание системы поиска экспертов. Так почему иногда мы так долго и сложно ищем нужных специалистов на проект или на выполнение задания? Почему мы легко готовы расстаться с человеком, и только через месяц-другой узнаем, что в его голове были знания, которые уже никто не сможет восполнить за разумные сроки?
Возвращаясь к идеям Стива Бокмана, — каждая организация должна не просто знать своих экспертов, но и создавать условия для их общения друг с другом или с теми, кто только готовится стать экспертом или специалистом. При реализации новых проектов. При уходе ветеранов или просто опытных людей из компании. При вхождении в профессию новичков. При… да при решении любой задачи, которую, на ваш взгляд, можно выполнить чуть лучше. Конкретные форматы можем разобрать вместе.
Фото, к слову, с тренинга по управлению знаниями, который проводила компания Shell. )))
Владимир Баронов