Archive for the ‘Образование’ Category

И еще раз о амнезии (часть вторая). Буква закона vs. Дух закона.

Воскресенье, Май 11th, 2008

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

В этой статье не буду писать никаких решений, а только буду бить по больным местам… э… пожалуй, только по больным местам этой темы.

Итак, начнем с человека который генерирует знания (кстати, я вообще говорю о любых знаниях – технических, менеджерских, бизнес процессах и т.п.). Вот те вещи, которые отбивают охоту записывать знания:

а) Тот человек, которые создает знания и так их знает, поэтому для него запись знаний чаще всего бесполезная трата времени.

б) Запись знаний, чаще всего низкий приоритет в системе ценностей человека. И поэтому, когда встает выбор – разгребать текущие проблемы или создавать «нетленку» 🙂, то чаще всего начинают разгребать именно текущее дела.

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

в) Нужно ли заставлять подчиненного писать свои знания или делать остальную часть работы. Опять же возникает конфликт приоритетов.

Потребитель знаний:

г) Почему собственно нужно читать чьи-то ошибки, сделанные непонятно когда и кем и пытаться понять какие-то решения, принятые людьми, которые уже не работают в фирме?

д) Как справляться с тем потоком информации, которые могут быть сгенерированными многими людьми. Как отбирать только нужное и важное и не тратить время на все остальное?

Ну, и с точки зрения компания, проблемы следующие

е) Что делать с людьми, которые не хотят сохранять знания, особенно если они ими обладают. Должно ли стать это требованиям к работе. Что делать с теми, кто не хочет изучать знания?

ж) Какова приоритетность записи и изучения знаний? Это нужно для того, чтобы менеджеры могли выставлять приоритеты рабочим

В) Выделение специальных людей для сбора, организации знаний и контроля за этими процессами. Кстати, это требует финансов.

Д) Самое главное, как сделать весь этот проект прибыльным?

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

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

Как я уже писал, это затея очень неплохо «ест» деньги. И любой человек который работал или владел маленькой компанией знает, как для них критичен каждый доллар. И чаще всего вкладывается только в проекты первой приоритетности, которые могут вернуть деньги.

Даже, если деньги выделены, обычно в этот отдел нанимают юношей бледных со взором горящим. Я имею в виду, молодежь без опыта, знаний и только с амбициями и желанием менять мир (они наиболее дешевы при найме).

И именно это убивает эту идею на корню. Проблема состоит в том, что скажем тренер по футболу может натренировать команду с игроками, которые играют лучше него. Но вот человек не игравший в футбол никогда не может натренировать команду.

И вот те самые юноши (или девушки), которые были наняты контролировать, оказываются во главе процессов которые они не понимают, не знают и не пробовали. И получается, то самое, что я писал в названии статьи – они начинают пользоваться буквой закона, вместо духа закона.

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

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

Таким образом этот отдел, которые изначально был призван поддержать идею, вместо поддержки начинает ее активно и бездумно насаждать, что вызывает полное отторжение.

Как я и говорил, я не хочу писать никаких решений проблем, а только их формулирую. И проблема того, что отдел контроля становится своеобразным КГБ внутри организации очень типичная и большая проблема.

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

Опытный значит ошибавшийся.

Понедельник, Апрель 14th, 2008

По стопам прошлой статьи.

С Alexey мы углубились в дебри обсуждения и вышли на интересную тему – ошибок как двигателя обучения.

Чуть ли ключевым пунктом школьного и институтского образования проходит идея – «НЕ ОШИБАЙТЕСЬ». Вы ошиблись, вас наказали. Причем не просто нельзя ошибаться, а нельзя ошибаться даже первый раз. Но, ладно, тема пинания образования тут не ключевая.

Идея состоит в том, что я считаю, что обучиться можно ТОЛЬКО ошибаясь. Естественно, не имеет смысла делать ошибки специально, но только благодаря тому, что делается что-то много раз, каждый раз делаются ошибки и анализируются и есть движение вперед.

Многие скажут – только дураки учатся на своих ошибках. Опять же я не согласен.

Я бы сказал, что человек обучается не равномерно, а скачкообразно. То есть человек накапливает количественные знания, накапливает, до тех пор пока они скачком не переходят из количественных в качественные и человек переходит на новый уровень

Так вот, учиться на чужих ошибках можно только тогда, кода ошибки которые вы разбираете находятся на том же уровне, что и вы.

Как вы считаете, может человек только что начавший играть в шахматы учиться на ошибках чемпиона мира? Гроссмейстера? Перворазрядника?

А наоборот, может ли гроссмейстер обучаться на ошибках человека, который только научился играть?

То есть, да действительно можно учиться на чужих ошибках, но среди моря чужих ошибок вам подойдут, только ошибки вашего уровня. Мы же сами является постоянными генераторами ошибок именно нашего уровня, так что учиться легче всего на своих ошибках (и ничего в этом жуткого нет).

В какой-то момент, когда я нанимал студентов (еще не в свою компанию), то основное, что я хотел узнать у них – выписались ли они. То есть написали ли они уже скажем 10000 строк. Если человек их написал, то он уже совершил все ошибки на уровне непонимания языка программирования и его уже можно было брать (не беспокоясь об этом уровне понимания).

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

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

Так, что спросите на следующем собеседование, не только о успешных, но и о заваленных проектах.

P.S. Загляните на этот блог 🙂

И если вы LJ пользователь, то можете меня зафрендить. Мой профайл: vronin.

 

Как быстро подтянуть разработчиков?

Среда, Апрель 9th, 2008

Что-то никак не хватает времени написать полноценную статью. Надеюсь, завтра этим займусь.

Так что, просто выкладываю совсем необработанные раздумия.

Я прошел через несколько мелких фирм, которые вырастали. Везде были одни и те же проблемы, как быстро сделать из группки молодых программистов, группу зубастых профов.

Как по мне, правильный ответ — никак. Быстро это сделать не удастся. Можно только, медленно и постепенно и то, не все станут профами.

Начнем с того, что вероятнее всего, в группе будут две подгруппы — те у кого нет опыта (то, что лечиться) и те у кого нет мозга (лечется только хирургическим путем).

Ладно, оставим вторых. Сконцентрируемся на первых.

Самый лучший метод, который я знаю на сейчас, просто сидеть с людьми (а-ля XP программирование) и вместе решать задачи/обсуждать, помогать править их код и объяснять, почему и что делается. Но, лучший не значит самый простой (честно говоря забирает кучу времени).

Второе, что приходит в голову — давать правильные книги. Занимает меньше времени, но гораздо менее эффективно.

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

Кстати, одна из самых важных вещей база. Все знания хорошо ложаться, только на хорошую базу. В нее должна входить логика/абстрактное мышление и достаточно долгий опыт просто писания кода (чтобы не возникали проблемы в простейших языковых конструкциях).

Редкие налеты в виде просмотра код раз в месяц, как по мне не дают фактически ничего. Это может помочь уже толковому программисту, который и так растет каждый день, чуть ускорить рост. Но, это явно не столкнет с места новичка.

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

P.S. Антон Наумов напомнил, один из достаточно эффективных, но жестоких методов. Новичка кидают на настоящий проект, с полной выкладкой и ответственностью. Собственно так я учился, когда после полтора года опыта оказался ведущим программистом, на достаточно крупном проекте (явно размером больше моих умений).

Как научиться учиться?

Пятница, Февраль 29th, 2008

Продолжая тематику образования и эффективности.

На заре своей карьеры, я очень неэффективно подходил к учебе. Мне давали задачу, которую я не знал как сделать, и я выискивал решение – быстро ее делал (за что был хвалим). Но обычно я не изучал ничего вокруг самой задачи, за что в результате был бит жизнью.

Достаточно часто получалось так, что мне приходилось раз за разом возвращаться к тому же документу, который я кусочно читал сначала для одной задачи, потом для другой задачи. Каждый раз я пытался «выкусить» только информацию необходимую для решения текущей задачи. Естественно в краткосрочной перспективе это давало выигрыш, но в долгосрочной я всегда проигрывал время, так как по ходу успевал забыть, другие части документа и их приходилось перечитывать второй раз.

Кстати, описанная проблема это классическое проблема целевика (детальнее о то, что такое целевик можно почитать в статье «Цель vs Путь»)

Таким образом, я по молодости не подготавливал «базу» для решения следующих задач.

Сейчас, я перешел кардинально на другой подход. Обучение я разбиваю на три фазы

А) Сбор информации.

Б) Первичный анализ информации.

В) Сбор вопросов и контроль понимания.

Во время сбора информации, я просто ищу, все, до чего могу добраться на интересующую тему. Например, сегодня я разбирался с Bluetooth на WinMobile и соответственно добрался до общего описания, описания security, описания как бороться с этим security, Widcomm SDK для BT WinCE, Microsoft примеры в Platform Builder’е, ну и еще некоторого количества документов. Все это я просто пробегаю взглядом, чтобы оценить, интересующая меня это информация или нет. Дальше, я аккуратно складываю все в папочку (не читая) и продолжаю поиск. В тот момент, когда я вижу, что документов достаточно  где-то на день чтения, то я перехожу к второй стадии.

В момент первичного анализа информации, я бегло читаю текст (относясь к нему скорее как к художественному произведению, чем как к научному), пытаясь понять, но в случае застревания или не понимания, просто помечая непонятное и выписывая возникшие вопросы. Собственно говоря, я не хочу застревать и разбираться в этот момент, так как вероятнее всего в найденных мной документах информация будет дублироваться и вполне вероятно она где-то будет написана лучше. Например, в моем сегодняшнем случае, в одной статье по security было очень сложно описано, что происходит с ключами в момент pairing устройств. Добравшись до статьи, как бороться с BT security, я обнаружил гораздо более толковое описание.

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

Ну и суммируя это. Как мне кажется, данный метод достаточно эффективен, так как не требует фактически никакого напряжения на каждом этапе.  Плюс он значительно уменьшает издержки переключения между этапами (относительны схемы — нашел, прочел,  составил список вопросов, нашел что-то новое, прочел, составил список вопросов и т.п.).