Comments 14
В целом полезно, но где-то уже проскакивало, причем с бОльшими подробностями.
Мы в своё время быстренько поизучали УП по PMBOK. Один семестр.
А здесь что рекомендуете использовать? с точки зрения платформы/технологии?
Приветствую!
Не тривиальный вопрос. По моему опыту — важно удержаться от сваливания в выбор именно инструментов, без оглядки на цель.
Технически, в моей практике это всегда было сочетание, как минимум:
— структурированные избранные знания (в вики-подобном формате)
— неструктурированная информация (файлохранилка + минимально категоризированные тексты)
— «новости»
— инструменты «заказа знаний» и оценки материалов.
Во что это выливается программно — вопрос второй (зависит от того, к чему привыкли в компании).
Например: evrenote + dropbox, или highrise + SVN + корпоративная вики. Варианты, в общем-то бесконечны, пригодность к использованию для данных конкретных команд — основной критерий.
Не тривиальный вопрос. По моему опыту — важно удержаться от сваливания в выбор именно инструментов, без оглядки на цель.
Технически, в моей практике это всегда было сочетание, как минимум:
— структурированные избранные знания (в вики-подобном формате)
— неструктурированная информация (файлохранилка + минимально категоризированные тексты)
— «новости»
— инструменты «заказа знаний» и оценки материалов.
Во что это выливается программно — вопрос второй (зависит от того, к чему привыкли в компании).
Например: evrenote + dropbox, или highrise + SVN + корпоративная вики. Варианты, в общем-то бесконечны, пригодность к использованию для данных конкретных команд — основной критерий.
Цель простая: конспектировать знания не сильно отрываясь от работы, а потом с такой же лёгкостью их извлекать.
С чем сталкивались мы: эта цель простая, пока занимаешься ей для себя (и речь идет о собственных знаниях или о знаниях очень небольшой группы, например проектной команды 5-6 человек). Тогда достаточно, по сути, набора конспектов в любой привычной форме (на небольших проектах использовали google sites — сайт проекта прекрасно с задачей справлялся).
У нас возникли сложности, когда стали применять базу знаний в масштабах компании (нескольких департаментов), чтобы не терялись полезные знания сотрудников, чтобы они не делали двойную работу, чтобы вообще носители знания как-то проявляли себя и когда кому-то другому нужно быстро вникнуть в вопрос — он бы не метался по компании, а знал «куда смотреть» и / или к кому идти.
Суть проблем, которые мы решали в том числе инструментально:
— люди не осознают себя носителями знаний
— люди не хотят или не любят формализовать знания
— люди не доверяют «базе знаний» (не считают ее актуальной, полной) и игнорируют
— после начала эксплуатации любая база (особенно вики-подобная) очень быстро захламляется, искать в ней становится тяжело.
В итоге стали выделять несколько ролей:
— все сотрудники, пополняющие базу «информацией» (в качестве инструмента — простое файловое хранилище, самый простой вариант Dropbox)
— «создатели знаний», трансформирующие информацию в знания (в качестве инструмента — либо вики, либо заметки в стиле Evernote)
— «хранитель знаний», который смотрит, чтобы все работало (подобие «идеолога-администратора»).
Опять же, без дополнительной стимуляции процесс быстро затухал (люди «наигравшись» переставали знания публиковать — ведь это отдельная работа). Соответственно инструмент должен был помогать оценивать качество работы «создателей знаний», выделять лучших (в том числе и материально). Под эту задачу, подходящего механизма так и не нашлось, пользуемся «костылями».
Вообще, идеологически подход к организационной базе знаний я почерпнул у Ikujiro Nonaka «Компания — создатель знания...». Там много воды, но базовый посыл (отличие организационного знания от индивидуального) лег в основу всех наших экспериментов. :)
У нас возникли сложности, когда стали применять базу знаний в масштабах компании (нескольких департаментов), чтобы не терялись полезные знания сотрудников, чтобы они не делали двойную работу, чтобы вообще носители знания как-то проявляли себя и когда кому-то другому нужно быстро вникнуть в вопрос — он бы не метался по компании, а знал «куда смотреть» и / или к кому идти.
Суть проблем, которые мы решали в том числе инструментально:
— люди не осознают себя носителями знаний
— люди не хотят или не любят формализовать знания
— люди не доверяют «базе знаний» (не считают ее актуальной, полной) и игнорируют
— после начала эксплуатации любая база (особенно вики-подобная) очень быстро захламляется, искать в ней становится тяжело.
В итоге стали выделять несколько ролей:
— все сотрудники, пополняющие базу «информацией» (в качестве инструмента — простое файловое хранилище, самый простой вариант Dropbox)
— «создатели знаний», трансформирующие информацию в знания (в качестве инструмента — либо вики, либо заметки в стиле Evernote)
— «хранитель знаний», который смотрит, чтобы все работало (подобие «идеолога-администратора»).
Опять же, без дополнительной стимуляции процесс быстро затухал (люди «наигравшись» переставали знания публиковать — ведь это отдельная работа). Соответственно инструмент должен был помогать оценивать качество работы «создателей знаний», выделять лучших (в том числе и материально). Под эту задачу, подходящего механизма так и не нашлось, пользуемся «костылями».
Вообще, идеологически подход к организационной базе знаний я почерпнул у Ikujiro Nonaka «Компания — создатель знания...». Там много воды, но базовый посыл (отличие организационного знания от индивидуального) лег в основу всех наших экспериментов. :)
Хорошо бы сделать ветку отличие Проектного управления от операционного.
В одной из компаний даже был курс «Проектный менеджмент для операционных менеджеров».
На мой экспертный взгляд многие менеджеры занимаются управлением операциями проекта в рамках проекта, но не занимаются проектным управлением. Увидев такие отличия, они бы выяснили основные пробелы в своей деятельности и направления для совершенствования.
В одной из компаний даже был курс «Проектный менеджмент для операционных менеджеров».
На мой экспертный взгляд многие менеджеры занимаются управлением операциями проекта в рамках проекта, но не занимаются проектным управлением. Увидев такие отличия, они бы выяснили основные пробелы в своей деятельности и направления для совершенствования.
Пояснение: под операциями подразумеваются «таски»
Приветствую! Спасибо, согласен.
Действительно, понимание различий важно. Я предполагал его. Например, оно упоминается в открытом курсе по управлению проектами, которые некоторое время назад записал для «ликвидации пробелов у коллег по работе»: pmlead.ru/?page_id=1724 (занятие 1, часть 2).
Пожалуй, акцент заслуживает быть более явным.
Действительно, понимание различий важно. Я предполагал его. Например, оно упоминается в открытом курсе по управлению проектами, которые некоторое время назад записал для «ликвидации пробелов у коллег по работе»: pmlead.ru/?page_id=1724 (занятие 1, часть 2).
Пожалуй, акцент заслуживает быть более явным.
Интеллект-карта:
•.mind
•.mm
•.mmap
•.xmind
Ребят, а в каком-нибудь более распространенном формате у вас нет? В чем-то из MS офиса, например? (да хоть .png)
Интеллект-карта:
•.xmind
Кто-то еще может поделиться интелект-картой?
Ссылки в статье не рабочие.
Sign up to leave a comment.
[интеллект-карта] Спецификация хорошего ПМа