:: urbansheep (urbansheep) wrote,
:: urbansheep
urbansheep

Управление потоками знаний // Первый кейс „протоколирования изменений“

Работать в сфере управления знаниями интересно потому, что материя и продукт твой эфемерны, но последствия от неуправления ими видны очень отчётливо. Как только компания становится „большой“, отсутствие собственной, прочувствованной и выстраданной политики по накоплению и хранению знаний связывает нам руки и ухудшает „обозримость“ предприятия в целом. Разбросанные знания там и тут, горы ресурсов — которые по отдельности никто эффективно использовать не сможет. И моя работа, как инфоарха, здесь лежит в куда менее привычной области, чем обычное структурирование данных. Вызов в том, что вместе со всеми людьми в компании построить систему управления знаниями. К чему мы постепенно и идём.

И эта история о том, что мне удалось вчера пообщаться с руководством и аккуратно его отчитать за то, что мы всё равно не фиксируем тот опыт, что накопили, даже в критических ситуациях. Отчитывание было больше похоже на конструктивный разговор с предложением „попробовать вести записи“ в тех случаях, когда ход проекта резко изменяется.

Дело было примерно так.

 Предыстория

Изучая и наблюдая со стороны за работой своей компании, я стараюсь отмечать, где и каким образом проходит информационная часть бизнес-процессов. Знания, коммуникации, диалоги. Так как на мне лежит сейчас и разработка стратегии внутренней системы управления проектами, то влезать приходится почти во всё — благо, компания внутри прозрачна и на мои вопросы, если мне удаётся их сформулировать, отвечают почти всегда.

И вот, после двух месяцев проектирования в „полуабстрактном“ режиме, началось самое нетривиальное — в коллективное сознание компании встраивается информационная дисциплина. Раньше это было лишь словами, никому не близкими, а теперь начинают появляться один за другим живые примеры — когда происходят события, которые нигде зафиксированы не были, а для компании в целом они важны.


 Кейс: дело о потерянном времени

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

Одно простое — „поправить“ выборку, и нацелить её так, чтобы в результате были гарантированно валидные данные. Для этого используется сегмент, в котором мы максимально уверены (например, потому что мы уже его проверяли или работали с ним).

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

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

Вынужденным волевым решением одного из руководителей, эта пополняющаяся и прочищаемая случайная выборка идёт под нож, и происходит откат к первому пути — взять для выборки только уже пришедшие и проверенные данные. Такой выходит „shaped random sequence“. И три дня потеряны.

Мне удалось зацепить эту ситуацию во время обеда с девушкой, которая является сейчас главным БД-специалистом и выполняет основную работу по проекту, а потому я сразу, пока ещё все участники проекта „в теме“, решила поговорить с руководителями о том, как они собираются записать это событие, и как мы будем о нём узнавать через полгода, и как будем передавать знание, когда в штат придёт кто-то новый.

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


 Разбор полётов — сложности при фиксировании изменений

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

  • С точки зрения добросовестного зайчика, шэйпинг данных — это неэтично. Писать об этом как-то неудобно. Пусть и для себя.
  • Потерянные три дня (или ошибка подрядчиков, или не туда отправленный курьер, или опечатка в смете, или скоропостижная командировка лиц, принимающих решения) — это, всё же, небольшой провал и ошибка. Признать ошибки непросто, но можно. Писать о том, почему ошибки были допущены, ещё сложнее.
  • Никто не может сформулировать толком, в словах, что произошло (а я говорила им „начинайте вести журналы“! А они не послушались! Они все заняты!), хотя рассказывают об этом легко
  • Никто не задумался, что с этими знаниями (в виде фразы „консолидация базы данных из разных источников требует запаса времени, рассчитываемого по формуле...“) может произойти дальше. Для людей „здесь и сейчас“ необходимость фиксировать знания неочевидна. Сожалеют всегда потом, уже забыв о чём-то, потеряв что-то.
  • Система управления проектами чудовищна, работать в ней невозможно.

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


 Чему надо научиться для эффективного сохранения знаний

 Совместное осознание событий

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

Иначе всё будет идти, как идёт — менеджер в обычном режиме проходит кризис за кризисом, об этом никто не узнаёт. Через какое-то время ситуация может легко повториться с другим менеджером, и он тоже пройдёт по тем же граблям, даже не подумав спросить об этом кого-то.

 Привычка к работе с поиском

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

Проблема тут всего одна — люди тщеславны. Они не любят терять лицо и признавать, что чего-то не знают. И надо ещё создать такую атмосферу, где спросить — это значит научиться, а не показать слабость. В принципе, в моей компании в этом смысле сейчас атмосфера очень позитивная, но направленность на обмен знаниями и коммуникацию всё равно надо постоянно акцентировать. Учиться, учиться, всё время учиться.

 Умение отличить итерацию от радикального изменения

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

О том, почему полезно ведение документации по всем аспектам — вплоть до списка обсуждённых, но не принятых решений, можно прочесть в моей старой записи urbansheep: Документация и сохранение истории процесса, или „Почему этого сделано не будет“.

Проанализировав навскидку наш ход работ, мы пришли к такому варианту: протоколируются важные, резкие, радикальные изменения.

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

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

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

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

 Разделение ошибок и знаний

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

Это хорошо работает, потому что человек, который может испытывать некоторое чувство вины за проваленный или „неидеально проведённый“ проект, часто сам не замечает того, чему он научился. Он избегает лишний раз лезть в проект мыслями, либо наоборот, зацикливается на том, что он сделал неправильно. Если вывести человека из этого состояния, если помочь ему пересмотреть ситуацию с отстранённых позиций, то как только точка зрения „что я из этого вынесла“ ему будет выдана в качестве основной, человек постепенно перейдёт к конструктивной, а не эмоциональной оценке произошедшего.

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

 Вовлечение всего коллектива, и работа с сомнениями коллег

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

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


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


Вывод, сделанный для себя из процесса: управление знаниями оказывается куда более увлекательной задачей, чем обычно кажется. Это не столько „библиотекарство“ и раскапывание архивов, сколько искусство научить людей работать с информацией и помочь им этой информацией эффективно воспользоваться.




Subscribe
  • Post a new comment

    Error

    Comments allowed for friends only

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 4 comments