Привет! Спасибо за комментарий.
Неожиданный и удивительный для меня эффект с разочарованием.
Нет, я вовсе на задумывал статью в духе «вот завязка, а продолжение за деньги». :) Единственное и естественное ограничение обусловлено тем, что в одной статье всего не расскажешь.
Рано или поздно я постараюсь осветить все, что задумано — и в публикациях и на своем сайте, и в рамках петербургского отделения международного института проектного менеджмента (PMI) (организации, к слову, некоммерческой), и, возможно, в других статьях на хабре.
S_A: Про то, как управление проектом приживается в разных типах организаций — отдельная и интересная для меня тема. В том числе и ей, я и задумал уделить внимание на конференции. Соглашусь, что PMBoK с темы «съезжает». В двух словах: кончено, механистическая бюрократия тяготеет к более формальным, «водопадным» методам, адхократия — к «гибким», в простых и «профессиональных бюрократиях» приживаются разные подходы. Но такое распределение не строгое. Постараюсь подробнее рассказать на следующей неделе.
PS: про карьерные вопросы в Стратоплан могу ответить «за себя». Мне интересно все, что связано с «эффективностью» и «конкурентоспособностью» руководителей проектов. Карьера — одна из граней этой самой эффективности, а также фактор, который здорово влияет на самооценку (в конце концов работе, как к ней не относись, мы посвящаем значительную часть жизни).
Так что вопрос карьеры менеджера проекта лично мне довольно интересен и спрашивают часто. Часть моих изысканий обязательно будет с этим связана. А с коллегами из Стратоплан мы случайно совпали хотя и предсказуемо (большинство тем «софт скиллз» я, в целом, не считаю своими — я не про лидерство, переговоры и коммуникации, но про методологии, системы, конкретные инструменты).
Спасибо за теплый отзыв.
По вопросу — выскажусь субъективно. Я никогда не работал через биржи и, к сожалению, не знаю, как выглядят заявки поступающие через них и на сколько они подробны; но занимался и заказной и продуктовой разработкой для разных отраслей (сфера ИТ в целом — не только софтверная разработка, но и, скажем, построение ИТ-инфарстркутуры, внедрение программно-аппаратных комплексов и т.п.).
В отраслях где работал я — первичный запрос, обычно, кране неконкретный. Непонятно, что именно и как точно нужно сделать, есть некая общая идея (возможно, формализованная в двух-трех абзацах) и требуется быстро и приблизительно сориентировать «что из этого мы можем, какими людьми и в какие сроки это достижимо». Источником такого запроса может быть как внутреннее руководство, так и внешний заказчик (в том числе — объявленный тендер).
Обычно, формирование ответа на такой запрос всегда укладывается в интервал от 0,5 дня (короткие и понятные проекты) до 7 дней (большие, непонятные проекты и/или проекты с большим количеством участников / субподрядчиков которых к оценкам приходится привлекать).
В исключительных случаях оценка производится быстрее (например, сталкивался у некоторых внедренцев 1С – проекты стандартизованы, оценки выдаются в течение нескольких часов если поступившие требования достаточны). Медленнее – почти всегда неприемлемо с точки зрения того, кто эту оценку ждет (а иначе можно было бы пойти «долгим путем»)
Речь о предварительном «грубом» плане (rough estimate), который может и будет потом уточняться, наполняться конкретикой.
С чем сталкивались мы: эта цель простая, пока занимаешься ей для себя (и речь идет о собственных знаниях или о знаниях очень небольшой группы, например проектной команды 5-6 человек). Тогда достаточно, по сути, набора конспектов в любой привычной форме (на небольших проектах использовали google sites — сайт проекта прекрасно с задачей справлялся).
У нас возникли сложности, когда стали применять базу знаний в масштабах компании (нескольких департаментов), чтобы не терялись полезные знания сотрудников, чтобы они не делали двойную работу, чтобы вообще носители знания как-то проявляли себя и когда кому-то другому нужно быстро вникнуть в вопрос — он бы не метался по компании, а знал «куда смотреть» и / или к кому идти.
Суть проблем, которые мы решали в том числе инструментально:
— люди не осознают себя носителями знаний
— люди не хотят или не любят формализовать знания
— люди не доверяют «базе знаний» (не считают ее актуальной, полной) и игнорируют
— после начала эксплуатации любая база (особенно вики-подобная) очень быстро захламляется, искать в ней становится тяжело.
В итоге стали выделять несколько ролей:
— все сотрудники, пополняющие базу «информацией» (в качестве инструмента — простое файловое хранилище, самый простой вариант Dropbox)
— «создатели знаний», трансформирующие информацию в знания (в качестве инструмента — либо вики, либо заметки в стиле Evernote)
— «хранитель знаний», который смотрит, чтобы все работало (подобие «идеолога-администратора»).
Опять же, без дополнительной стимуляции процесс быстро затухал (люди «наигравшись» переставали знания публиковать — ведь это отдельная работа). Соответственно инструмент должен был помогать оценивать качество работы «создателей знаний», выделять лучших (в том числе и материально). Под эту задачу, подходящего механизма так и не нашлось, пользуемся «костылями».
Вообще, идеологически подход к организационной базе знаний я почерпнул у Ikujiro Nonaka «Компания — создатель знания...». Там много воды, но базовый посыл (отличие организационного знания от индивидуального) лег в основу всех наших экспериментов. :)
Не тривиальный вопрос. По моему опыту — важно удержаться от сваливания в выбор именно инструментов, без оглядки на цель.
Технически, в моей практике это всегда было сочетание, как минимум:
— структурированные избранные знания (в вики-подобном формате)
— неструктурированная информация (файлохранилка + минимально категоризированные тексты)
— «новости»
— инструменты «заказа знаний» и оценки материалов.
Во что это выливается программно — вопрос второй (зависит от того, к чему привыкли в компании).
Например: evrenote + dropbox, или highrise + SVN + корпоративная вики. Варианты, в общем-то бесконечны, пригодность к использованию для данных конкретных команд — основной критерий.
Действительно, понимание различий важно. Я предполагал его. Например, оно упоминается в открытом курсе по управлению проектами, которые некоторое время назад записал для «ликвидации пробелов у коллег по работе»: pmlead.ru/?page_id=1724 (занятие 1, часть 2).
Приветствую!
Из платного – я бы рекомендовал обратить внимание на библиотеку PMI (при оплате годовой подписки у них библиотека бесплатна – можно скачать самые актуальные версии, в том числе PMBOK и других руководств). Первоисточники, так сказать.
Чтобы наверняка — лучше следить за сайтом. Будут ли анонсы на хабре — я, пока, не уверен :)
Неожиданный и удивительный для меня эффект с разочарованием.
Нет, я вовсе на задумывал статью в духе «вот завязка, а продолжение за деньги». :) Единственное и естественное ограничение обусловлено тем, что в одной статье всего не расскажешь.
Рано или поздно я постараюсь осветить все, что задумано — и в публикациях и на своем сайте, и в рамках петербургского отделения международного института проектного менеджмента (PMI) (организации, к слову, некоммерческой), и, возможно, в других статьях на хабре.
Спасибо за позитивные отзывы.
S_A: Про то, как управление проектом приживается в разных типах организаций — отдельная и интересная для меня тема. В том числе и ей, я и задумал уделить внимание на конференции. Соглашусь, что PMBoK с темы «съезжает». В двух словах: кончено, механистическая бюрократия тяготеет к более формальным, «водопадным» методам, адхократия — к «гибким», в простых и «профессиональных бюрократиях» приживаются разные подходы. Но такое распределение не строгое. Постараюсь подробнее рассказать на следующей неделе.
PS: про карьерные вопросы в Стратоплан могу ответить «за себя». Мне интересно все, что связано с «эффективностью» и «конкурентоспособностью» руководителей проектов. Карьера — одна из граней этой самой эффективности, а также фактор, который здорово влияет на самооценку (в конце концов работе, как к ней не относись, мы посвящаем значительную часть жизни).
Так что вопрос карьеры менеджера проекта лично мне довольно интересен и спрашивают часто. Часть моих изысканий обязательно будет с этим связана. А с коллегами из Стратоплан мы случайно совпали хотя и предсказуемо (большинство тем «софт скиллз» я, в целом, не считаю своими — я не про лидерство, переговоры и коммуникации, но про методологии, системы, конкретные инструменты).
По вопросу — выскажусь субъективно. Я никогда не работал через биржи и, к сожалению, не знаю, как выглядят заявки поступающие через них и на сколько они подробны; но занимался и заказной и продуктовой разработкой для разных отраслей (сфера ИТ в целом — не только софтверная разработка, но и, скажем, построение ИТ-инфарстркутуры, внедрение программно-аппаратных комплексов и т.п.).
В отраслях где работал я — первичный запрос, обычно, кране неконкретный. Непонятно, что именно и как точно нужно сделать, есть некая общая идея (возможно, формализованная в двух-трех абзацах) и требуется быстро и приблизительно сориентировать «что из этого мы можем, какими людьми и в какие сроки это достижимо». Источником такого запроса может быть как внутреннее руководство, так и внешний заказчик (в том числе — объявленный тендер).
Обычно, формирование ответа на такой запрос всегда укладывается в интервал от 0,5 дня (короткие и понятные проекты) до 7 дней (большие, непонятные проекты и/или проекты с большим количеством участников / субподрядчиков которых к оценкам приходится привлекать).
В исключительных случаях оценка производится быстрее (например, сталкивался у некоторых внедренцев 1С – проекты стандартизованы, оценки выдаются в течение нескольких часов если поступившие требования достаточны). Медленнее – почти всегда неприемлемо с точки зрения того, кто эту оценку ждет (а иначе можно было бы пойти «долгим путем»)
Речь о предварительном «грубом» плане (rough estimate), который может и будет потом уточняться, наполняться конкретикой.
У нас возникли сложности, когда стали применять базу знаний в масштабах компании (нескольких департаментов), чтобы не терялись полезные знания сотрудников, чтобы они не делали двойную работу, чтобы вообще носители знания как-то проявляли себя и когда кому-то другому нужно быстро вникнуть в вопрос — он бы не метался по компании, а знал «куда смотреть» и / или к кому идти.
Суть проблем, которые мы решали в том числе инструментально:
— люди не осознают себя носителями знаний
— люди не хотят или не любят формализовать знания
— люди не доверяют «базе знаний» (не считают ее актуальной, полной) и игнорируют
— после начала эксплуатации любая база (особенно вики-подобная) очень быстро захламляется, искать в ней становится тяжело.
В итоге стали выделять несколько ролей:
— все сотрудники, пополняющие базу «информацией» (в качестве инструмента — простое файловое хранилище, самый простой вариант Dropbox)
— «создатели знаний», трансформирующие информацию в знания (в качестве инструмента — либо вики, либо заметки в стиле Evernote)
— «хранитель знаний», который смотрит, чтобы все работало (подобие «идеолога-администратора»).
Опять же, без дополнительной стимуляции процесс быстро затухал (люди «наигравшись» переставали знания публиковать — ведь это отдельная работа). Соответственно инструмент должен был помогать оценивать качество работы «создателей знаний», выделять лучших (в том числе и материально). Под эту задачу, подходящего механизма так и не нашлось, пользуемся «костылями».
Вообще, идеологически подход к организационной базе знаний я почерпнул у Ikujiro Nonaka «Компания — создатель знания...». Там много воды, но базовый посыл (отличие организационного знания от индивидуального) лег в основу всех наших экспериментов. :)
Не тривиальный вопрос. По моему опыту — важно удержаться от сваливания в выбор именно инструментов, без оглядки на цель.
Технически, в моей практике это всегда было сочетание, как минимум:
— структурированные избранные знания (в вики-подобном формате)
— неструктурированная информация (файлохранилка + минимально категоризированные тексты)
— «новости»
— инструменты «заказа знаний» и оценки материалов.
Во что это выливается программно — вопрос второй (зависит от того, к чему привыкли в компании).
Например: evrenote + dropbox, или highrise + SVN + корпоративная вики. Варианты, в общем-то бесконечны, пригодность к использованию для данных конкретных команд — основной критерий.
Действительно, понимание различий важно. Я предполагал его. Например, оно упоминается в открытом курсе по управлению проектами, которые некоторое время назад записал для «ликвидации пробелов у коллег по работе»: pmlead.ru/?page_id=1724 (занятие 1, часть 2).
Пожалуй, акцент заслуживает быть более явным.
Из платного – я бы рекомендовал обратить внимание на библиотеку PMI (при оплате годовой подписки у них библиотека бесплатна – можно скачать самые актуальные версии, в том числе PMBOK и других руководств). Первоисточники, так сказать.
Из бесплатного – может быть окажется полезным открытый курс по управлению проектами, о паспорте и концепции речь идет в занятии 2 и занятии 3.