 |
Пять ключей к обмену знаниями в проектах
01.07.07
В мире программного обеспечения неудачные проекты встречаются чаще, чем успешные. Один из способов добиться того, чтобы проекты были успешными, - воспользоваться уже накопленным опытом. Однако сказать это намного проще, чем сделать. Как реализовать возможность многократного использования знаний в программных проектах? Как выбрать средства для обмена знаниями между ними?
Обмен знаниями между проектами может гарантировать хороший результат. К примеру, менеджер программного проекта (назовем его Сэм) прекрасно осведомлен об этом, но сам по себе данный факт нисколько не помогает Сэму, сидящему за столом и мучительно размышляющему, что делать с проектом дальше. Ему уже приходилось руководить проектами, но сейчас он вынужден заниматься совершенно новой для себя работой — будущее компании и сотен ее сотрудников зависит от того, удастся ли Сэму успешно реализовать проект. Однако, по его ощущениям, он что-то упустил и не может эффективно руководить данным программным проектом. Сэму кажется, что проект выходит из-под контроля — затраты растут, а доля выполненных работ остается на прежнем уровне. Несмотря на огромный опыт, Сэм понимает, что ему необходимы дополнительные технические знания, чтобы досконально разобраться во всех проблемах, с которым сталкивается его команда. Тем более, что это первый проект, в работе над которым принимают участие сразу несколько бизнес-подразделений и два основных бизнес-партнера компании.
Сэму нужны новые, творческие идеи, позволяющие найти мотивацию для команды проекта и гарантирующие эффективную координацию работ внутри организации. Ему необходимо также понять, как сообщить плохие новости руководству. Сэм мог бы воспользоваться общими соображениями, приобретенными в предыдущих проектах, но, учитывая критическую важность новой работы, он хочет знать, что помогло, а что нет в тех проектах, при выполнении которых возникали аналогичные трудности. Так как ему получить эти сведения?
К сожалению, в мире программного обеспечения неудачные проекты, не выполненные в срок, вышедшие за рамки бюджета или такие, в которых не были реализованы ключевые функции, встречаются чаще, чем успешные [1]. Один из способов добиться того, чтобы проекты всегда были успешными, — воспользоваться накопленным опытом [2]. Однако сказать это намного проще, чем сделать. Возможность многократно использовать знания в программных проектах крайне важна, но обеспечить ее на практике весьма сложно.
Каждый программный проект по-своему уникален, однако между всеми ними есть определенное сходство, и определенными знаниями можно многократно пользоваться, передавая их из проекта в проект. Менеджеры проектов и организации в целом имеют в своем распоряжении немало средств, которые позволяют использовать знания от проекта к проекту. Менеджер может выбрать конкретный инструмент, потому что тот удобен, ему знаком или относительно дешев. К тому же часто возможность использовать полученные уроки в последующих проектах, даже с помощью самого совершенного инструментария, на практике воплощается не так, как предполагалось.
Пять вопросов
Компания Сэма использует различные инструменты поддержки передачи знаний между проектами. Он изучил отчет, подготовленный по итогам последнего проекта, но не нашел в нем ничего для себя полезного. Он поискал информацию в электронном репозитории знаний, но был лишь разочарован тем, что из множества найденных там документов ни один, по-видимому, не содержал нужной ему информации. Наконец, он нашел пару полезных технических руководств, которые помогли ему понять отдельные концепции, связанные с технологией, но интересующие его вопросы, касающиеся управления, так и остались без ответа. Компания потратила тысячи долларов на создание этих репозиториев. На формирование контента в виде отчетов по итогам проектов, проектной документации и образцов планов ушло огромное количество часов. Однако Сэм не смог найти ответы на свои вопросы. Безусловно, это не самый эффективный способ извлечь уроки из успехов и ошибок других.
Легко упустить из виду реальный бизнес-контекст и конкретные цели обмена знаниями. А потому, выбирая инструмент для обмена знаниями по принципу «самый удобный», можно лишь зря потратить ресурсы, а инструментом попросту не будут пользоваться, и он будет вызывать у сотрудников организации лишь разочарование.
Прежде всего, чтобы понять, какова цель обмена знаниями между проектами, необходимо спросить себя, зачем это может потребоваться? Нужно определить, будут ли эти знания использоваться для получения новых знаний, идей или представлений (то есть они будут нужны в качестве основы для исследований), или знания, полученные в прошлых проектах, можно будет применить напрямую (они потребуются для использования).
Определив, требуется ли в первую очередь создавать новые знания или использовать уже полученные ранее, необходимо спросить себя, какого рода знаниями предполагается обмениваться? Хотите ли вы «знать как»: получить вспомогательные знания о процедурах и практических решениях. Или вам интересно «знать почему» — для вас важны обоснования процедур и практических решений.
Затем, следует подумать о том, кто именно будет обмениваться знаниями. Это может быть группа, работающая над проектом. Если это так, значит, предполагается использовать опыт и знания в рамках проекта, и это зависит от людей, входящих в состав команды проекта. Другая возможность — коллеги в целом. В этом случае цель состоит в том, чтобы эффективно использовать знания коллег из разных проектных групп. Третий вариант предполагает обмен знаниями в масштабе всей организации.
Четвертый вопрос, на который необходимо ответить, заключается в том, как будут передаваться знания, и каким образом ими будут обмениваться. Обмен осуществляется, как правило, двумя основными способами, следующими из того, что знания бывают спонтанными или документированными. Спонтанными знаниями человек с человеком обменивается во время «мозговых штурмов» и во время «диалогов между людьми, а не объектами знаний в базе данных». Документированные знания, с другой стороны, «извлекаются из человека, который их создал, становятся независимыми от него и многократно используются для различных целей».
Последний вопрос, который вы должны себе задать, связан с тем, на какой период времени ориентирован обмен знаниями? Полученные в прошлом знания касаются предыдущих проектов и уже имеющегося опыта. Если вы ориентируетесь на текущий период времени, то будете использовать знания, полученные в прошлом, но адаптированные к контексту текущих событий. Ориентация на будущее — это использование знаний в попытке предсказать или оценить будущие события.
Десять типов инструментов
На вопрос «зачем» Сэм ответил: «для исследования». В связи с вопросом «что», его не интересуют детальные процедуры («знать как»), но важны обоснования, то есть ему необходимо «знать почему» его коллеги сделали тот или иной выбор в прошлом. На вопрос «кто», Сэм ответил, что он хочет получить информацию от тех менеджеров проектов, которые уже оказывались в подобных ситуациях, а не общий совет, сформулированный на основе множества проектов. О том, что касается вопроса «как», Сэм в идеале хотел бы лично побеседовать с несколькими опытными менеджерами проектов, чтобы перенять их опыт. Он уже искал доступные документы, но безрезультатно, поэтому спонтанный обмен знаниями в его ситуации подходит лучше. Наконец, относительно вопроса «когда», Сэм уверен, что знания, ориентированные на настоящее, в его ситуации более актуальны. Теперь, когда он понял, чего же он на самом деле хочет, он готов представить, какого рода инструмент для обмена знаниями лучше всего подходит к его ситуации.
Существует несколько видов инструментов для обмена знаниями, которыми могут пользоваться менеджеры программных проектов. В таблице описан каждый из них применительно к ответам на упомянутые основные вопросы.
Системы совместной работы позволяют людям организовать виртуальную встречу, обсуждение, «мозговой штурм» и обмен знаниями. Участники создают новые знания за счет исследования и постепенного понимания, позволяющего «узнать почему» в проекте следует принять то или иное решение. Несмотря на то, что системы совместной работы могут использоваться на уровне всей организации или сообщества коллег, они часто применяются в рамках проектной группы для контроля версий, распространения информации и для уведомления о тех вопросах, которые могут повлиять на выполнение проекта. С помощью систем совместной работы можно получить знания, касающиеся создания решений, которые соответствуют контексту текущего проекта.
Репозитории контента хранят документированные знания в централизованной базе данных и используются для накопления информации в масштабах всей организации. Они помогают применять имеющиеся знания в новых проектах и сохранять наилучшие практические решения и методы в виде документально оформленных знаний, полученных за время прошлых проектов, и, тем самым, сформировать базу знаний организации с информацией, позволяющей «знать как» было сделано то или другое.
Системы управления инвестициями и портфелями служат для определения, планирования и контроля инвестиций. Этот инструментарий полезен для выбора и планирования будущих проектов с учетом потребностей организации. Руководители проектов используют знания, полученные в уже осуществленных проектах, в среде для разработки и документирования обоснований (что позволяет «знать почему»), для того чтобы понять, стоит ли организации продолжать вкладывать средства или риски растут неадекватно быстро.
Карты знаний помогают находить людей, обладающих требуемым опытом, что важно, когда знания можно получить только в результате «мозговых штурмов» и бесед с экспертом, а также когда их нелегко документировать. Сложная природа управления программным проектом предполагает, что для решения некоторых проблем лучше прибегать к интерактивному подходу.
Социальные сети формируют отношения, способствующие обмену знаниями путем общения, обсуждения и использования общих практических методов. Менеджеры программных проектов и члены проектных групп могут, во многих случаях, за счет неформальных отношений обмениваться знаниями более эффективно, чем это позволяют обширные репозитории знаний. Люди получают новые знания и могут «узнать почему» следует сделать так, а не иначе, в личных беседах со специалистами (или наставниками) в определенных профессиональных областях.
Анализ по завершении проекта — это процесс, позволяющий выявить и документально зафиксировать успехи и неудачи проекта. Знания, полученные по время такого анализа, могут уберечь от повторения прежних ошибок, поскольку дают возможность узнать, что раньше было сделано неправильно и, как следствие, усовершенствовать процессы и повысить производительность будущих проектов. Такой анализ часто документируется менеджером проекта или членами проектной группы для того, чтобы поддержать обмен знаниями в организации.
Системы управления проектами могут помочь планировать, определять сроки выполнения и отслеживать прогресс в выполнении задач проекта. Эти системы создают структуру работ и расписание задач. Менеджеры проектов могут повторно использовать расписания и оценки предыдущих проектов для создания плана текущего проекта. Процедуры (то есть «знание как») требующиеся для реализации проекта, документируются как задачи. Знания, заложенные в план проекта, передаются проектной группе для взаимодействия ее участников и координации выполнения будущих задач.
Оценка риска дает возможность выявить, проследить и проконтролировать неопределенности в проекте, что позволяет эффективно использовать знания, полученные ранее, информацию из среды и другие факторы, связанные с проектом, для того, чтобы обнаружить потенциальные проблемы. Как только риски определены, процедуры, касающиеся этих рисков, оформляются документально. Проектная группа часто выявляет потенциальные риски и разрабатывает планы на случай возникновения непредвиденных ситуаций (решения в категории «знать как»).
SWOT-анализ применяется для оценки сильных и слабых сторон проекта, потенциальных возможностей и угроз. Эта классическая методика позволяет выявлять и оценивать основные характеристики программного проекта. Группа разрабатывает идеи и рекомендации, специфические для контекста проекта (знания категории «почему»).
Шаблоны — это документы (планы проекта, бюджеты или документация), взятые из выполненных ранее проектов. Эти материалы постоянно используются повторно для поддержки согласованности между проектами. Значительная часть времени обычно тратится на создание документации по проекту в виде планов разработки, контроля качества и тестирования, а также спецификаций требований и архитектуры. Обмен шаблонами с коллегами поможет менеджерам программных проектов использовать практические знания, накопленные при реализации прошлых проектов. Планы проектов или документы с описанием требований, принятые в качестве образца, могут часто повторно использоваться, их адаптируют к требованиям текущих проектов.
Сэм изучил список возможностей и выбрал социальную сеть в качестве инструмента обмена знаниями, который мог бы помочь ему, однако, учитывая, критическую важность проекта, Сэм опасается, что попытка обсудить проблемы с его коллегой, менеджером программного проекта, может быть воспринята как проявление некомпетентности. Поскольку Сэм не может обратиться за помощью к людям, составляющим его внутренний круг общения, он рассматривает другие возможности. Неуверенный в том, что знакомые действительно готовы ему помочь, Сэм позвонил Эмили, с которой он познакомился во время семинара в профессиональной организации по управлению проектами.
Улучшенный обмен знаниями
Встреча с Эмили прошла великолепно. У Сэма было множество свежих идей. Если бы Сэм не остановился и не попробовал бы ответить на пять вопросов и оценить каждый из десяти инструментов для обмена знаниями, он бы никогда не обратился к Эмили за помощью. Он осознал, что именно контекст должен диктовать, как нужно начинать путешествие за знаниями, и что не всегда следует использовать одни и те же инструменты, даже если они уже есть в его организации.
Ориентация на технологию, а не на сами знания и их контекст — стратегия, которая неизбежно приведет к неудаче в обмене знаниями [10].
Отвечая на пять вопросов применительно к программным проектам, необходимо учитывать, на каком уровне принимается решение об использовании инструментов. Инструмент может и должен быть утвержден на уровне организации и предоставлен для всех программных проектов. Многие инструменты обмена знаниями по своей природе таковы, что их применение утверждается на уровне организации, в том числе анализ по окончанию проектов, репозитории контента и системы управления инвестициями и портфелями. Однако имеется масса ситуаций, когда конкретный проект выходит за традиционные для организации рамки. В этом случае инструментарий может быть выбран для одного проекта. Вне зависимости от того, утвержден ли инструмент для одного проекта или для всей организации, сфера его применения, как правило, может увеличиваться или уменьшаться с учетом конкретных требований к обмену знаниями.
Инструменты также могут быть адаптированы к контексту обмена знаниями — большинство менеджеров придут к выводу, что одного инструмента для поддержки обмена знаниями не достаточно. Возможно, необходимо некое сочетание инструментов и весьма вероятно, что придется переопределить некоторые инструменты так, чтобы они предоставляли дополнительную функциональность или для того, чтобы ответить должным образом на пять вопросов. Например, wiki и репозитории контента быстро завоевывают популярность, и их можно легко развивать в соответствии с конкретными требованиями к обмену знаниями.
К сожалению, многим менеджерам программных проектов ситуация, в которой оказался Сэм, хорошо знакома.
Обмен знаниями между проектами может гарантировать хороший результат. К примеру, менеджер программного проекта (назовем его Сэм) прекрасно осведомлен об этом, но сам по себе данный факт нисколько не помогает Сэму, сидящему за столом и мучительно размышляющему, что делать с проектом дальше. Ему уже приходилось руководить проектами, но сейчас он вынужден заниматься совершенно новой для себя работой — будущее компании и сотен ее сотрудников зависит от того, удастся ли Сэму успешно реализовать проект. Однако, по его ощущениям, он что-то упустил и не может эффективно руководить данным программным проектом. Сэму кажется, что проект выходит из-под контроля — затраты растут, а доля выполненных работ остается на прежнем уровне. Несмотря на огромный опыт, Сэм понимает, что ему необходимы дополнительные технические знания, чтобы досконально разобраться во всех проблемах, с которым сталкивается его команда. Тем более, что это первый проект, в работе над которым принимают участие сразу несколько бизнес-подразделений и два основных бизнес-партнера компании.
Сэму нужны новые, творческие идеи, позволяющие найти мотивацию для команды проекта и гарантирующие эффективную координацию работ внутри организации. Ему необходимо также понять, как сообщить плохие новости руководству. Сэм мог бы воспользоваться общими соображениями, приобретенными в предыдущих проектах, но, учитывая критическую важность новой работы, он хочет знать, что помогло, а что нет в тех проектах, при выполнении которых возникали аналогичные трудности. Так как ему получить эти сведения?
К сожалению, в мире программного обеспечения неудачные проекты, не выполненные в срок, вышедшие за рамки бюджета или такие, в которых не были реализованы ключевые функции, встречаются чаще, чем успешные [1]. Один из способов добиться того, чтобы проекты всегда были успешными, — воспользоваться накопленным опытом [2]. Однако сказать это намного проще, чем сделать. Возможность многократно использовать знания в программных проектах крайне важна, но обеспечить ее на практике весьма сложно.
Каждый программный проект по-своему уникален, однако между всеми ними есть определенное сходство, и определенными знаниями можно многократно пользоваться, передавая их из проекта в проект. Менеджеры проектов и организации в целом имеют в своем распоряжении немало средств, которые позволяют использовать знания от проекта к проекту. Менеджер может выбрать конкретный инструмент, потому что тот удобен, ему знаком или относительно дешев. К тому же часто возможность использовать полученные уроки в последующих проектах, даже с помощью самого совершенного инструментария, на практике воплощается не так, как предполагалось.
Пять вопросов
Компания Сэма использует различные инструменты поддержки передачи знаний между проектами. Он изучил отчет, подготовленный по итогам последнего проекта, но не нашел в нем ничего для себя полезного. Он поискал информацию в электронном репозитории знаний, но был лишь разочарован тем, что из множества найденных там документов ни один, по-видимому, не содержал нужной ему информации. Наконец, он нашел пару полезных технических руководств, которые помогли ему понять отдельные концепции, связанные с технологией, но интересующие его вопросы, касающиеся управления, так и остались без ответа. Компания потратила тысячи долларов на создание этих репозиториев. На формирование контента в виде отчетов по итогам проектов, проектной документации и образцов планов ушло огромное количество часов. Однако Сэм не смог найти ответы на свои вопросы. Безусловно, это не самый эффективный способ извлечь уроки из успехов и ошибок других.
Легко упустить из виду реальный бизнес-контекст и конкретные цели обмена знаниями. А потому, выбирая инструмент для обмена знаниями по принципу «самый удобный», можно лишь зря потратить ресурсы, а инструментом попросту не будут пользоваться, и он будет вызывать у сотрудников организации лишь разочарование.
Прежде всего, чтобы понять, какова цель обмена знаниями между проектами, необходимо спросить себя, зачем это может потребоваться? Нужно определить, будут ли эти знания использоваться для получения новых знаний, идей или представлений (то есть они будут нужны в качестве основы для исследований), или знания, полученные в прошлых проектах, можно будет применить напрямую (они потребуются для использования).
Определив, требуется ли в первую очередь создавать новые знания или использовать уже полученные ранее, необходимо спросить себя, какого рода знаниями предполагается обмениваться? Хотите ли вы «знать как»: получить вспомогательные знания о процедурах и практических решениях. Или вам интересно «знать почему» — для вас важны обоснования процедур и практических решений.
Затем, следует подумать о том, кто именно будет обмениваться знаниями. Это может быть группа, работающая над проектом. Если это так, значит, предполагается использовать опыт и знания в рамках проекта, и это зависит от людей, входящих в состав команды проекта. Другая возможность — коллеги в целом. В этом случае цель состоит в том, чтобы эффективно использовать знания коллег из разных проектных групп. Третий вариант предполагает обмен знаниями в масштабе всей организации.
Четвертый вопрос, на который необходимо ответить, заключается в том, как будут передаваться знания, и каким образом ими будут обмениваться. Обмен осуществляется, как правило, двумя основными способами, следующими из того, что знания бывают спонтанными или документированными. Спонтанными знаниями человек с человеком обменивается во время «мозговых штурмов» и во время «диалогов между людьми, а не объектами знаний в базе данных». Документированные знания, с другой стороны, «извлекаются из человека, который их создал, становятся независимыми от него и многократно используются для различных целей».
Последний вопрос, который вы должны себе задать, связан с тем, на какой период времени ориентирован обмен знаниями? Полученные в прошлом знания касаются предыдущих проектов и уже имеющегося опыта. Если вы ориентируетесь на текущий период времени, то будете использовать знания, полученные в прошлом, но адаптированные к контексту текущих событий. Ориентация на будущее — это использование знаний в попытке предсказать или оценить будущие события.
Десять типов инструментов
На вопрос «зачем» Сэм ответил: «для исследования». В связи с вопросом «что», его не интересуют детальные процедуры («знать как»), но важны обоснования, то есть ему необходимо «знать почему» его коллеги сделали тот или иной выбор в прошлом. На вопрос «кто», Сэм ответил, что он хочет получить информацию от тех менеджеров проектов, которые уже оказывались в подобных ситуациях, а не общий совет, сформулированный на основе множества проектов. О том, что касается вопроса «как», Сэм в идеале хотел бы лично побеседовать с несколькими опытными менеджерами проектов, чтобы перенять их опыт. Он уже искал доступные документы, но безрезультатно, поэтому спонтанный обмен знаниями в его ситуации подходит лучше. Наконец, относительно вопроса «когда», Сэм уверен, что знания, ориентированные на настоящее, в его ситуации более актуальны. Теперь, когда он понял, чего же он на самом деле хочет, он готов представить, какого рода инструмент для обмена знаниями лучше всего подходит к его ситуации.
Существует несколько видов инструментов для обмена знаниями, которыми могут пользоваться менеджеры программных проектов. В таблице описан каждый из них применительно к ответам на упомянутые основные вопросы.
Системы совместной работы позволяют людям организовать виртуальную встречу, обсуждение, «мозговой штурм» и обмен знаниями. Участники создают новые знания за счет исследования и постепенного понимания, позволяющего «узнать почему» в проекте следует принять то или иное решение. Несмотря на то, что системы совместной работы могут использоваться на уровне всей организации или сообщества коллег, они часто применяются в рамках проектной группы для контроля версий, распространения информации и для уведомления о тех вопросах, которые могут повлиять на выполнение проекта. С помощью систем совместной работы можно получить знания, касающиеся создания решений, которые соответствуют контексту текущего проекта.
Репозитории контента хранят документированные знания в централизованной базе данных и используются для накопления информации в масштабах всей организации. Они помогают применять имеющиеся знания в новых проектах и сохранять наилучшие практические решения и методы в виде документально оформленных знаний, полученных за время прошлых проектов, и, тем самым, сформировать базу знаний организации с информацией, позволяющей «знать как» было сделано то или другое.
Системы управления инвестициями и портфелями служат для определения, планирования и контроля инвестиций. Этот инструментарий полезен для выбора и планирования будущих проектов с учетом потребностей организации. Руководители проектов используют знания, полученные в уже осуществленных проектах, в среде для разработки и документирования обоснований (что позволяет «знать почему»), для того чтобы понять, стоит ли организации продолжать вкладывать средства или риски растут неадекватно быстро.
Карты знаний помогают находить людей, обладающих требуемым опытом, что важно, когда знания можно получить только в результате «мозговых штурмов» и бесед с экспертом, а также когда их нелегко документировать. Сложная природа управления программным проектом предполагает, что для решения некоторых проблем лучше прибегать к интерактивному подходу.
Социальные сети формируют отношения, способствующие обмену знаниями путем общения, обсуждения и использования общих практических методов. Менеджеры программных проектов и члены проектных групп могут, во многих случаях, за счет неформальных отношений обмениваться знаниями более эффективно, чем это позволяют обширные репозитории знаний. Люди получают новые знания и могут «узнать почему» следует сделать так, а не иначе, в личных беседах со специалистами (или наставниками) в определенных профессиональных областях.
Анализ по завершении проекта — это процесс, позволяющий выявить и документально зафиксировать успехи и неудачи проекта. Знания, полученные по время такого анализа, могут уберечь от повторения прежних ошибок, поскольку дают возможность узнать, что раньше было сделано неправильно и, как следствие, усовершенствовать процессы и повысить производительность будущих проектов. Такой анализ часто документируется менеджером проекта или членами проектной группы для того, чтобы поддержать обмен знаниями в организации.
Системы управления проектами могут помочь планировать, определять сроки выполнения и отслеживать прогресс в выполнении задач проекта. Эти системы создают структуру работ и расписание задач. Менеджеры проектов могут повторно использовать расписания и оценки предыдущих проектов для создания плана текущего проекта. Процедуры (то есть «знание как») требующиеся для реализации проекта, документируются как задачи. Знания, заложенные в план проекта, передаются проектной группе для взаимодействия ее участников и координации выполнения будущих задач.
Оценка риска дает возможность выявить, проследить и проконтролировать неопределенности в проекте, что позволяет эффективно использовать знания, полученные ранее, информацию из среды и другие факторы, связанные с проектом, для того, чтобы обнаружить потенциальные проблемы. Как только риски определены, процедуры, касающиеся этих рисков, оформляются документально. Проектная группа часто выявляет потенциальные риски и разрабатывает планы на случай возникновения непредвиденных ситуаций (решения в категории «знать как»).
SWOT-анализ применяется для оценки сильных и слабых сторон проекта, потенциальных возможностей и угроз. Эта классическая методика позволяет выявлять и оценивать основные характеристики программного проекта. Группа разрабатывает идеи и рекомендации, специфические для контекста проекта (знания категории «почему»).
Шаблоны — это документы (планы проекта, бюджеты или документация), взятые из выполненных ранее проектов. Эти материалы постоянно используются повторно для поддержки согласованности между проектами. Значительная часть времени обычно тратится на создание документации по проекту в виде планов разработки, контроля качества и тестирования, а также спецификаций требований и архитектуры. Обмен шаблонами с коллегами поможет менеджерам программных проектов использовать практические знания, накопленные при реализации прошлых проектов. Планы проектов или документы с описанием требований, принятые в качестве образца, могут часто повторно использоваться, их адаптируют к требованиям текущих проектов.
Сэм изучил список возможностей и выбрал социальную сеть в качестве инструмента обмена знаниями, который мог бы помочь ему, однако, учитывая, критическую важность проекта, Сэм опасается, что попытка обсудить проблемы с его коллегой, менеджером программного проекта, может быть воспринята как проявление некомпетентности. Поскольку Сэм не может обратиться за помощью к людям, составляющим его внутренний круг общения, он рассматривает другие возможности. Неуверенный в том, что знакомые действительно готовы ему помочь, Сэм позвонил Эмили, с которой он познакомился во время семинара в профессиональной организации по управлению проектами.
Улучшенный обмен знаниями
Встреча с Эмили прошла великолепно. У Сэма было множество свежих идей. Если бы Сэм не остановился и не попробовал бы ответить на пять вопросов и оценить каждый из десяти инструментов для обмена знаниями, он бы никогда не обратился к Эмили за помощью. Он осознал, что именно контекст должен диктовать, как нужно начинать путешествие за знаниями, и что не всегда следует использовать одни и те же инструменты, даже если они уже есть в его организации.
Ориентация на технологию, а не на сами знания и их контекст — стратегия, которая неизбежно приведет к неудаче в обмене знаниями [10].
Отвечая на пять вопросов применительно к программным проектам, необходимо учитывать, на каком уровне принимается решение об использовании инструментов. Инструмент может и должен быть утвержден на уровне организации и предоставлен для всех программных проектов. Многие инструменты обмена знаниями по своей природе таковы, что их применение утверждается на уровне организации, в том числе анализ по окончанию проектов, репозитории контента и системы управления инвестициями и портфелями. Однако имеется масса ситуаций, когда конкретный проект выходит за традиционные для организации рамки. В этом случае инструментарий может быть выбран для одного проекта. Вне зависимости от того, утвержден ли инструмент для одного проекта или для всей организации, сфера его применения, как правило, может увеличиваться или уменьшаться с учетом конкретных требований к обмену знаниями.
Инструменты также могут быть адаптированы к контексту обмена знаниями — большинство менеджеров придут к выводу, что одного инструмента для поддержки обмена знаниями не достаточно. Возможно, необходимо некое сочетание инструментов и весьма вероятно, что придется переопределить некоторые инструменты так, чтобы они предоставляли дополнительную функциональность или для того, чтобы ответить должным образом на пять вопросов. Например, wiki и репозитории контента быстро завоевывают популярность, и их можно легко развивать в соответствии с конкретными требованиями к обмену знаниями.
К сожалению, многим менеджерам программных проектов ситуация, в которой оказался Сэм, хорошо знакома.
