Хабрахабр

Управление знаниями: какие документы нужны и что в них фиксировать

Процесс документирования эволюционно прорастает из скупых комментариев в коде по мере роста компании. Где-то в середине пути обычно появляются люди, которые говорят, что знают, как правильно, и что «в этой книжке написано, как надо делать документацию», и приносят в компанию какой-нибудь тяжелый процесс. Дальше идут обсуждения, споры, ссылки на разные источники с противоречивыми подходами и так далее. На самом деле всё это не случайно. Каждый раз, когда мы сталкиваемся с такими моментами, это значит, что есть культурные различия. Тренды меняются, и каждая эпоха дает свои учебники.

Да и вообще, зачем нужна это вся документация. Под катом вместе с Максимом Цепковым будем разбираться, какие уроки можно вынести из разных подходов, как проектировать документы проекта, что занести в wiki, для чего подойдет Google Docs, а что обязательно должно все время находиться перед глазами. Заодно и тему управления знаниями затронем.

Культуры программных проектов

История IT-отрасли делится на этапы-эпохи, для каждой из которых характерен свой подход к ведению проектов: свои представления об успехе, критерии качества, организации работ. Энтони Лаудер в 2008 году написал книгу «Культуры программных проектов» (ссылки на оригинал, перевод и рецензию Стаса Фомина), в которой выделил четыре периода:

  • научная;
  • заводская;
  • дизайнерская;
  • сервисная культура.

Каждая из них оказала влияние на подходы к ведению программных проектов. А о согласованности друг с другом никто не думал.

О спикере: Максим Цепков IT-архитектор и бизнес-аналитик, навигатор и эксперт по миру Agile, бирюзовых организаций и Спиральной динамике.

В схеме, которую я предлагаю, главное, что менялось, — рамки проекта. Я пользуюсь чуть-чуть другой периодизацией, продленной до настоящего времени. В эпоху НИОКР было важно, что IT-система работает, в эпоху RUP — что она сделана вовремя, в эпоху Agile — что она делает то, что надо заказчику, а не просто работает, потому что выяснилось, что часто делали не то.

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

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

А дальше были частные форматы: user story, use cases, частные практики, story mapping и т.д., которые отражались в документах. Agile в самом начале своего развития сильно качнул маятник в противоположную сторону, объявив, что работающий софт гораздо важнее, чем документы. Но всеобъемлющих учебников по этому поводу не написали, потому что поняли — учебники не работают.

Но при этом не надо изобретать с нуля, надо использовать шаблоны и образцы примерно так же, как это происходит, например, в проектировании интерфейсов. Сейчас мы поняли, что проекты разные и универсальных рецептов точно нет — надо делать то, что уместно. Но есть style guide, который обеспечивает интуитивное освоение, шаблоны и практики. Интерфейсы разные, особенно на мобильных устройствах с маленьким экраном надо размещать то, что сейчас важно для задачи, никаких универсальных вещей не существует.

В документации то же самое — на Doc style guide проекта. Разрабатывая style guide, ориентируются на UX.

Я надеюсь, что доклад даст принципы и концепты, опираясь на которые, вы сможете улучшать ситуацию и решать проблемы с документами в своем проекте.

Документы — для коммуникации

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

Форма документов, также как интерфейсов, вырабатывается из целей коммуникации.

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

С его помощью мы ведем коммуникацию с конкретными людьми, а не рассылаем на весь мир. А если документ нужен для коммуникации, то он должен быть адресным. Следовательно, делим документы по назначению и адресату:

  • для принятия решений;
  • текущей коммуникации;
  • сохранения знаний во времени («мне через полгода»);
  • передачи знаний другим людям;
  • помощи в текущей работе и пр.

Каждому назначению соответствует свой вид описания, — viewpoint — свой метод описания.

Критерий качества документа

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

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

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

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

Use case описывает, что надо сделать в системе, а в user story есть часть «зачем»: «Как <роль> я хочу <сделать что-то>, для того чтобы <достичь целей>». Следующий важный момент, о котором нужно помнить, проектируя систему документации: «зачем» и «почему» важнее, чем «что». все части обязательно должны быть. Причем этот форматuser story можно рассматривать как шаблон, т.е. Цель user story, цель любых требований — это распределенная во времени коммуникация заказчика (пользователя) с разработчиком и аналитиком в качестве посредника. Они появилась из опыта не сразу, но теперь мы знаем, что «зачем» очень важно.

Всегда есть непредусмотренные альтернативы: по расположению кнопок на форме, по коду, по гибкости, общности решения. В этой распределенной во времени коммуникации очень важно донести смыслы, чтобы разработчик принимал конкретные решения. Но лучше, чтобы он в этот момент мог сам поставить бизнес-задачу и принять решение — прерывание в процессе кодирования дорого. Если решение критично, разработчик, конечно, прервется и уточнит. Ответ на вопрос «зачем» в документации сильно помогает, поэтому и появился.

А то содержание целей проекта часто сводится к «бизнесу зачем-то надо». Урок про «зачем» и «почему» надо учитывать, даже если используешь другие форматы — фиксировать цели пользователей и бизнеса, начиная от целей проекта.

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

Проектируем документы проекта

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

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

Дальше в процессе использования оцениваем качество, и повышаем его так же, как Usability и UX.

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

У артефактов будут какие-то ответственные, backlog. Если в этой модели расставить классические артефакты взаимодействия между заказчиком и командой, то там будут: требования, задание на разработку, тест-кейсы, PMI, версии.

Особенно это относится как раз к требованиям и заданиям на разработку. Не факт, что вам нужны именно эти документы.

Модель отражает систему, и её ведут аналитики с одной стороны и разработчики с другой.
Есть, например, альтернативна — Domain-Driven Design, согласно которому вместо требований и заданий на разработку используется модель системы, как коллективный артефакт.

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

Вместо концепта возникли такие вещи как нужды пользователей и возможности для бизнеса. V-модель — это наследие эпох НИОКР и RUP. С тех пор культуры поменялись, и современный проект гораздо шире. Справа, вместо разового maintenance, появилось delivery очередного релиза и непрерывное во времени сопровождение.

Требования

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

Как правило в концепции нужно отразить: Насколько концепция или видение должно быть подробно проработано, определяется функционально: документ надо сделать как можно более коротким, потому что быстро, но так, чтобы стейкхолдеры приняли решение о старте проекта.

  • идею проекта — возможность для бизнеса: что, для кого и как сделать;
  • реализуемость и целесообразность идеи;
  • интересы и ожидания основных стейкхолдеров от результата проекта;
  • устройство продукта и его предполагаемое использование;
  • оценку необходимых для проекта ресурсов.

Дальше интересы и ожидания могут изменяться, и, если это произошло, важно это вовремя зафиксировать.

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

Эта граница тоже сдвигается. Если говорить про удовлетворенность пользователей, то там тоже возникла линейка специализаций: UI-дизайнер, который отвечает за удовлетворенность пользователей внешним видом, Usability — про использование и UX-специалист, который работает над интуитивной осваиваемостью интерфейсов. И совсем другое дело, например мобильная разработка. В вашем конкретном проекте она может быть разной, так как одно дело enterprise-разработка, для которой и система обучения есть, и пользователь никуда не денется, как 1С-бухгалтер, потому что это его рабочее место. Если в магазине текучка кадров такая, что продавец или кладовщик работает в среднем по 3-6 месяцев, то вопрос освоения мобильного приложения для работы за 2 дня, а не за 2 недели обучения актуален.

Если у вас классические требования Requirements and Architecture, то Test Driven Design возможен, а Behavior Driven Design вряд ли. Ведение требований должно соответствовать подходу к тестированию и наоборот. Если в требованиях нет сценария, то и взять его неоткуда. Потому что BDD по замыслу рассчитан на то, что вы сформулируете сценарий работы пользователей, то есть на более высокий уровень абстракции. Такие связи надо учитывать, а еще контролировать стоимость ведения и проверки тест-кейсов.

Артефакты для индивидуального фокуса

Отдельный класс артефактов предназначены для повседневного индивидуального фокуса. Это, например, те схемы, которые распечатаны и висят в комнате разработчиков перед глазами. Один из уроков Agile: доска с задачами и Burn down chart, физически висящие в комнате или настроенные на горячие клавиши в электронном формате, очень помогают. Отвлеченный в раздумьях взгляд, случайно цепляется, и информация все время освежается. Точно так же с архитектурными схемами, важными принципами.

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

Но лежать в документации или висеть на стене постоянно — это большая разница. ER-диаграммы, слоевая схема приложения или основные компоненты — есть в документации. Если схема есть где-то там в документе, то о ней можно временно забыть, и быстренько написать код, нарушающий архитектуру. Когда разработчик думает: «А не проковырять ли дырочку в API поверх слоевой модели наискосок?», потому что это реально сократит время разработки конкретной фичи (но аукнется потом при сопровождении), а схема тем временем висит перед глазами, то скорее всего он увидит, что это будет именно дырка.

Знания о движении проекта

В Scrum-процессе предусмотрены специальные точки формирования знаний о движении проекта:

  • Демо — представление состояния проекта тем, кто пользуется результатами твоей работы, и другим интересующимся.
  • Ретро — оценка себя: правильно ли мы работаем и что можно улучшить.
  • Daily meeting — синхронизация представлений команды о движении проекта.
  • Планирование — синхронизация намерений.

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

Долговременные описания

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

  • Научить нового пользователя работать с системой.
  • Дать справочную информацию по редким функциям системы.
  • Представить концептуальное устройство системы новому разработчику.
  • Помочь вспомнить устройство фрагмента системы автору для доработок.
  • Описать устройство модуля системы для развития новым разработчиком.
  • Дать информацию об устройстве системы инженеру сопровождения.

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

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

Надо фиксировать назначение, оценивать соответствие, помнить: чем подробнее документ, тем дороже.

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

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

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

Как правило, нормативные документы обеспечивают коммуникацию заказчика с его проверяющими и должны быть написаны в том объеме, в котором нужно, и с учетом использования заказчиком. С нормативно необходимыми документами по ГОСТу, нужно понять, нужны они для сдачи проекта или еще для чего-то. У нас, например, есть заказчики, для которых отдельно изготавливается рабочая документация и документация для проверяющих. Иногда это write-only документы. В зависимости от этого процесс документирования отличается, но как только мы понимаем его назначение — всё хорошо. Но есть и те, кто хочет, чтобы идущие на проверку документы были рабочими, основными.

Коммуникация передает смыслы

Немного отвлечемся и обсудим, что коммуникация передаёт смыслы.

Если мы разложим мир на объекты и связи, то получим однозначно трактуемую картину мира.
Начинается всё с предположения эпохи RUP, которая породила Объектно-ориентированный подход (ООП).

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

Иерархические модели, таксономии пошли от научного освоения мира, в котором все приведено к строгой форме и «разложено по полочкам». Разный способ мышления — это норма. Такое мышление эффективно и операбельно. Сейчас же, с развитием интернета, популярно мышление мира как облако тэгов со связями, есть даже специальное слово — «фолксономия». А мир IT-инженеров, которые ближе к научной картине мира, всё больше и больше с этим сталкивается.
Маркетинг, масс-медиа построены на этом.

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

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

доклад «Коммуникация при различной структуре мышления — таксономия против фолксономии»). Ортогональный источник схем за пределами IT — СМД-методология (см.

Принципы ведения документов

   1. У документа нет автора.

Можно и Google Docs, но там отдельные документы, что не всегда удобно. Он живет дольше первого автора, поэтому работаем коллективно, а не пересылаем в письмах, используем wiki-системы. Для короткоживущих постановок Google Docs замечательно подходит.

Из того принципа, что у документа нет автора и опыта wiki-систем, следует важное следствие: увидел, что улучшить, — делай сразу, согласование нужно только по несогласию.

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

Документ создается постепенно.    2.

Достаточно кратких концептов, а детализация по необходимости. Большой документ устаревает раньше, чем будет написан. Делаем ту часть документа, которая касается текущей задачи.

Они ориентированы как раз на инкрементальное создание документов, инкрементальную проработку. Форматы, которые принес Agile: user story, use case, story mapping, в отличие от прежних монолитных постановок, появились не сразу. Как только мы пишем систему инкрементально, а не до конца всё отлаживаем, мы должны соответственно организовать код: компонентная архитектура, микросервисная архитектура — много вариантов, но не монолит. Они не везде есть, но как только мы решили, что документы сдаем и детализируем инкрементально, это накладывает такие же ограничения на структуру артефактов, как и на код.

Содержание важнее формы.    3.

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

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

Оставляем следы.    4.

То есть поговорили вживую, в чате и записываем в Task Tracker резюме на 1-2 предложения. Это другой важный принцип касается протоколов совещаний, резюме разговоров. Обычно мы думаем, что все запомним и так, но потом случаются форс-мажоры, а через неделю уже никто не помнит, о чем тогда договорились.

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

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

Типовые модели знаний

Есть типовые модели:

  • Модели для описания бизнеса в Archimate.
  • Модель мотивации стейкхолдеров в Archimate.
  • Подходы объектно-ориентированного программирования, перенесенные на разработку онтологий в Domain Driven Design.
  • Карта ведения проекта OMG Essence.
  • Схема множественных viewpoint’ов ISO 42010.

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

Только определив характер работы с документами, имеет смысл выбирать инструменты, а не наоборот. Так же, как фреймворки для разработки, имеет смысл выбирать, поняв, что за проект, какие там интерфейсы, взаимодействия с базой данных, сервером приложений, а не постулировать: это хороший фреймворк, будем писать на нём.

Я не буду за него агитировать, но чуть-чуть похвастаюсь. Как я уже говорил, Wiki — хороший вариант, потому что это общее пространство для всех документов, удобная коллективная работа, изменения, поиск, схемы и т.д. Мы ее сделали давно, ещё до Jira и Confluence, она выложена в OpenSource и доступна на http://4intra.net. У нас в компании CUSTIS есть собственная сборка движка MediaWiki. Я на ней, например, поднимал wiki-системы для студентов, когда преподавал.

Их удобно хранить рядом с задачами в Slack, Task Tracker или в Google Docs, как ссылки. Совершенно другое дело — кратковременные документы.

Там свои инструменты, не wiki. Долговременные же лучше держать в публикуемой документации вместе с кодом. Хотя можно в wiki публиковать git, который по коммиту что-то отрендерит в wiki-разметку и опубликует как страницу вместе с написанными вручную материалами, которые там же лежат.

Главное — не система документирования, а способ её использования.

Управляем профессиональными знаниями

Помимо управления проектной документацией есть управление профессиональными знаниями, которые относятся не к проектам, а к технологиям и процессам.

Она родилась, когда Запад задумался: «А чем нам выигрывать в конкурентной борьбе после того, как Китай сопрёт все патенты?» Решили, что будут конкурировать знаниями. Это отдельная отрасль, называется «управление знаниями». Она уже относительно несвежая, но из неё всё равно можно извлечь много уроков, также как из старых учебников по ООП, мы просто берем что нам надо.
Там есть много наработок, например, классическая книга «Учитесь летать» на эту тему, про опыт British Petroleum.

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

За это время в современном мире он необратимо устареет. К сожалению, по многим областям учебники никогда не будут написаны, потому что характерное время написание учебника 5–7 лет, а то и больше.

Например, способ программирования в миксованной парадигме, который появился, когда в C# втащили реляционную функциональную парадигму, до сих пор теоретики ООП не осмыслили. А программисты уже лет пять как используют.

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

Уроки управления знаниями

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

Урок от IBM: профессионал не понимает вопроса дилетанта — нужны переводчики.

Что важно, экспертов на это мотивировали. Идея IBM была такая: создать сообщество, в которое люди будут писать свои вопросы по такой-то теме, а эксперты будут их видеть и отвечать. Вроде везде условия были одинаковые, но оказалось, что в успешных сообществах, были специальные люди, которые мониторили весь поток вопросов, а потом маршрутизировали их к нужным экспертам, переводя по дороге и объясняя эксперту, что «это вопрос к тебе, он спрашивает про то, что ты знаешь». IBM большая компания и запустила сразу много сообществ, но взлетели только некоторые. Поэтому отдельная полезная компетенция в вопросе управления знаниями — понять по вопросу тему, а потом перевести вопрос эксперту по теме, чтобы тот принял его. То есть профессионал часто просто не опознает вопрос.

Подводим итоги

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

На сайте спикера Максима Цепкова mtsepkov.org (тоже, кстати, в формате wiki) много материалов по анализу и архитектуре, ведению проектов и agile, управлению знаниями.

Многие другие важные аспекты, такие как: вовлечение сотрудников, создание культуры непрерывного обмена знаниями, оценка эффективности управления знаниями, процессы и ПО, мы будем обсуждать на нашей профессиональной конференции по управлению знаниями Knowledge Conf. Документирование — лишь один из вопросов управления знаниями.

Приходите, заодно пополним список болей для нашей конференции.
Но сначала 25 февраля в рамках митапа на TeamLead Conf мы с Максимом Цепковым и Дмитрием Симоновым попробуем решить одну конкретную практическую проблему.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть