tag:blogger.com,1999:blog-964820474912238672024-03-27T10:17:55.982+05:00ProjectProfy.ruБлог по методикам и инструментам импортозамещения для проектных организацийVladimir Ivanovhttp://www.blogger.com/profile/05223453757943695857noreply@blogger.comBlogger52125tag:blogger.com,1999:blog-96482047491223867.post-3419381088016088962023-12-27T04:14:00.001+05:002023-12-27T04:22:15.304+05:00Искусственный интеллект для управления строительными проектами<p><span style="background-color: white; color: #0d0d0d; font-family: Roboto, Noto, sans-serif; font-size: 15px; white-space-collapse: preserve;"><a href=" https://youtu.be/zuWFEA8hqLk" target="_blank">Данное видео </a>рассматривает использование Chat GPT на примере управления строительным проектом. Получение WBS по ТЗ. Оценка сроков, ресурсов и стоимостей и рисков искусственным интеллектом.
Научное исследование Университета NYUAD о планировании строительных проектов Искусственным Интеллектом Chat GPT.
Рецензировано MDPI, включено в мировую базу надежных научных исследований</span></p><p><br /></p>
<br /><div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen="" class="BLOG_video_class" height="293" src="https://www.youtube.com/embed/zuWFEA8hqLk" width="352" youtube-src-id="zuWFEA8hqLk"></iframe></div><br />Vladimir Ivanovhttp://www.blogger.com/profile/05223453757943695857noreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-2078710319768115982023-03-28T15:30:00.004+05:002023-12-28T00:25:11.010+05:00Импортозамещение ПО в управлении проектами. Часть I. Project Libre, Gantt Project, WINE и др.<p>Первая часть посвященная обзору импортозамещения ПО в управлении проектами.</p><p>Рассматриваются бесплатные продукты с открытым кодом как Project Libre и Gantt Project</p><div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen="" class="BLOG_video_class" height="266" src="https://www.youtube.com/embed/1k5w3eXCikk" width="405" youtube-src-id="1k5w3eXCikk"></iframe></div><br /><p></p>Vladimir Ivanovhttp://www.blogger.com/profile/05223453757943695857noreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-50207266383176232472023-03-28T15:27:00.002+05:002023-12-27T04:22:43.076+05:00Макроэкономические прогнозы и условия ведения проектов в режиме санкций<p>Данная подборка видео сделана сразу после начала санкционной войны и рассматривала макроэкономические прогнозы. Посмотрим насколько сбылись наши прогнозы.</p><p><a href="https://youtu.be/Wugxruv3QwQ " target="_blank">Видео по экспорту</a>. Прогноз практически сбылся. Коньюктура больше зависит от общей рыночной цены на ресурсы. Price Cap по факту не сработал также.</p><p><br /></p><p><br /></p><div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen="" class="BLOG_video_class" height="266" src="https://www.youtube.com/embed/Wugxruv3QwQ" width="320" youtube-src-id="Wugxruv3QwQ"></iframe></div><br /><p><a href="https://youtu.be/oASu6XgItDQ" target="_blank">Инвестиции и ЗВР</a>. Прогноз сбылся в плане того, что ситуация более-менее стабильная после обмена сторон действиями. Индикаторы их ВВП и курс рубля.</p><div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen="" class="BLOG_video_class" height="266" src="https://www.youtube.com/embed/oASu6XgItDQ" width="320" youtube-src-id="oASu6XgItDQ"></iframe></div><div class="separator" style="clear: both; text-align: center;"><div class="separator" style="clear: both; text-align: left;"><a href="https://youtu.be/bNEuZqm5fhI" target="_blank">Импорт</a>. Прогноз сбылся, переход на серый и паралельный импорт произошел быстро</div><div class="separator" style="clear: both;"><br /></div></div><div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen="" class="BLOG_video_class" height="266" src="https://www.youtube.com/embed/bNEuZqm5fhI" width="320" youtube-src-id="bNEuZqm5fhI"></iframe></div><div class="separator" style="clear: both; text-align: center;"><div class="separator" style="clear: both; text-align: left;"><a href="https://youtu.be/vbQLxAl4_MA">Прогноз </a>насчет перспектив сбылс, т.к. динамика измения ВВП G7 и E7 скорее показывает, что тренд правильно угадан.</div><div class="separator" style="clear: both; text-align: left;"><br /></div></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen="" class="BLOG_video_class" height="266" src="https://www.youtube.com/embed/vbQLxAl4_MA" width="320" youtube-src-id="vbQLxAl4_MA"></iframe></div><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><br />Vladimir Ivanovhttp://www.blogger.com/profile/05223453757943695857noreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-27572120895071024202023-03-28T15:20:00.008+05:002023-12-27T04:22:54.745+05:00Появились "импортозамещенные" решения на WINE и почему 1С отказался от такой "схемы"?<p>Часть приложений под Windows импортозамещают с помощью технологии WINE. Почему тогда 1С отказался от WINE? Как обеспечивается надежность приложений под WINE? <a href="https://youtu.be/hhZsJRxIL24" target="_blank">Видео</a> разбирает вопросы проблемы с кодом Microsoft, который оказался в составе "импортозамещенных" приложений под Linux</p><div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen="" class="BLOG_video_class" height="264" src="https://www.youtube.com/embed/hhZsJRxIL24" width="399" youtube-src-id="hhZsJRxIL24"></iframe></div><br /><p><br /></p>Vladimir Ivanovhttp://www.blogger.com/profile/05223453757943695857noreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-58442180575377834682023-03-01T19:19:00.002+05:002023-03-01T19:23:39.859+05:00Почему российская школа управления проектами самая сильная в управлении ресурсами<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">Это перепубликация довольно популярной статью об истории отечественных методик управления ресурсами, которые в данный момент реализованы в Turbo Planner и <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="179" data-yobjectid="0oCgtlbnc0MzIzMTMyNBgD89Qgpw" data-yobjectlength="14" id="c610759f5fef63486ba814874e103d211790oCgtlbnc0MzIzMTMyNBgD89Qgpw" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Spider Project</yobject>. Речь идет о довольно уникальной методологии управления проектами, которая не может быть реализована без специальной математики расчета ресурсов. Интересное видео 1976 года показывает как глубоко учили управлению проектов даже студентов советских ВУЗов, но для профессионалов в СССР методология управления была еще более продвинутой - <b style="font-style: italic;">российская школа управления проектами была и есть </b><b style="font-style: italic; text-decoration: underline;">ресурсная</b><i>. </i>C интересом почитаю Ваши отзывы под статьей, т.к. многие тезисы в статье будут "рвать шаблоны".</div>
<iframe width="486" height="365" src="https://www.youtube.com/embed/B1D1nl7jUBE" title="Управление проектами в СССР. ВУЗФИЛЬМ 1976" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
<br />
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
<em style="color: firebrick;">Учебный фильм СССР 1973 года по основам управления проектами для студентов 1го курса. Представьте себе уровень подготовки профессиональных планировщиков в СССР</em><br />
<em style="color: firebrick;"><br /></em>
<br />
<a name='more'></a>Давайте зададим себе вопрос, почему только в этих двух системах (Turbo Planner и Spider Project) в мире реализуется такая ресурсная методология, почему она лучшая. Проще говоря, давайте покажем и докажем, что советская школа управления проектами самая сильная в мире. Я не описался, именно - "<em>советская</em>", т.е. школа <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="648" data-yobjectid="0oCghydXc4MzI5MRgDKeRziA" data-yobjectlength="20" id="c610759f5fef63486ba814874e103d216480oCghydXc4MzI5MRgDKeRziA" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">управления проектами</yobject> рожденная во времена СССР и на которой во многом базировались успехи <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="738" data-yobjectid="0oCgpydXczODkxMTIzGAOtzFDM" data-yobjectlength="17" id="c610759f5fef63486ba814874e103d217380oCgpydXczODkxMTIzGAOtzFDM" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Советской Империи</yobject>. Давайте вернемся в прошлое и узнаем многое о наследстве наших дедов и то, что нам предстоит продолжать дальше.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Во времена развала страны стало очень модно идолопоклонничество перед менеджментом Запада и в особенности перед американской школой проектного менеджмента. Иногда можно только с улыбкой смотреть на некоторых коллег, зубрящих <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="1099" data-yobjectid="0oCgpydXcxMTE4MjYxGAMxaOup" data-yobjectlength="5" id="c610759f5fef63486ba814874e103d2110990oCgpydXcxMTE4MjYxGAMxaOup" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">PMBOK</yobject> едва ли не как "<yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="1121" data-yobjectid="0oCghydXc3NzcxNhgDZaNHjA" data-yobjectlength="8" id="c610759f5fef63486ba814874e103d2111210oCghydXc3NzcxNhgDZaNHjA" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Отче Наш</yobject>". Некоторые даже считают своей миссией, чтобы все остальные также вызубрили PMBOK и тем самым обрели просветление, этакие Свидетели Откровения Американского УП. Сам автор PMBOK г-н Дункан не согласен с тем, чтобы его классификатор процессов превращали в некоторое подобие нового Евангелия. Это причина <a href="http://www.microsoftproject.ru/articles.phtml?aid=68" style="color: #443333;">резкой критики Дункана</a> с известной его фразой, что менеджер работающий по вызубренному PMBOK "<a href="http://www.microsoftproject.ru/articles.phtml?aid=68" style="color: #443333;">полный идиот</a>". Тем не менее, Россия явно преуспела в поклонении американской школе менеджмента. Конечно велика заслуга <a href="http://en.wikipedia.org/wiki/Henry_Gantt" style="color: #443333;">Генри Гантта</a>, который в 1919 году опубликовал свою работу, однако она была во многом копией работы российского поляка <a href="http://en.wikipedia.org/wiki/Karol_Adamiecki" style="color: #443333;">Карола Адомески</a>, который опубликовал такие же методики на 5 лет раньше на русском и польском языках. Поэтому даже вопрос приоритета открытия методологии управления проектами вопрос дискуссионный. </div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Тем не менее в XX веке американская школа конечно преуспела в области систематизации бизнес-процессов управления проектами и Дункан яркий представитель этого поколения. Но что мы знаем о математике <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="2173" data-yobjectid="0oCglydXcxMDkwNTYYAzKZjag" data-yobjectlength="19" id="c610759f5fef63486ba814874e103d2121730oCglydXcxMDkwNTYYAzKZjag" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Леониде Канторовиче</yobject> из СССР получившим <a href="http://n-t.ru/nl/ek/kantorovich.htm" style="color: #443333;">Нобелевскую премию в 1975 году за работу «Экономический расчет наилучшего использования ресурсов»</a>? За адаптацию этой работы для экономики США математик <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="2367" data-yobjectid="0oCglydXcxMDg5NDIYAxj4rsg" data-yobjectlength="16" id="c610759f5fef63486ba814874e103d2123670oCglydXcxMDg5NDIYAxj4rsg" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Тьяллинг Купманс</yobject> также получил Нобелевскую премию (но как мы увидим дальше в США долгое время практически не применялись такие методы). </div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Давайте также зададим вопросы к тем, кто считает, что американская школа управления проектами лучшая во всем. Кто запустил первого космонавта? Кто построил крупнейший флот атомных подводных лодок в мире? Кто создал вторую после США железнодорожную и энергетическую систему в условиях <strong>крайне ограниченных ресурсов</strong>?</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Я не зря выделил "<strong>крайне ограниченных ресурсов". </strong>Достижения СССР с точки зрения менеджмента проектов намного более значимые чем в США, т.к. следует учесть, что СССР располагал примерно в <a href="http://www.slideshare.net/msproject/ss-13289708" style="color: #443333;">2-4 раза меньшими ресурсами</a> (разница в оценках связана с тем, что <a href="http://www.mfit.ru/defensive/vestnik/vestnik8_1.html" style="color: #443333;">расчет на деле велся от бюджетов обороны стран</a>). Поэтому даже сопоставимые результаты соревнований в Х<yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="3192" data-yobjectid="0oCghydXcyNTM1MxgDYGCDsw" data-yobjectlength="14" id="c610759f5fef63486ba814874e103d2131920oCghydXcyNTM1MxgDYGCDsw" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">олодной Войне</yobject> это исключительный успех отечественной школы управления проектами, а если что-то делалось лучше и быстрее, так это выглядит вообще невероятно. Давайте вернемся в прошлом и разберемся, что лучше делали в СССР, что лучше в США.<br />
<br />
<h2 style="text-align: left;">
Американская школа управления проектами - это управление проектом де-факто с неограниченными ресурсами</h2>
</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
На становление русской и американской школы управления проектами повлияли очень разные условия для выполнения проектов. В США условия были намного проще для ведения проектов, чем в СССР. Важнейшим отличием было то, что для США был доступен международный финансовый рынок и США могли привлекать займы под очень низкие проценты и транслировать их в экономику. Часто мне американские коллеги в критичных проектах говорили "<b><i>money is not problem</i></b>", т.е. фактически проект работает в условиях неограниченных финансовых ресурсов.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Поскольку проекты в США финансировались (обращаю внимание на прошедшее время) по принципу "сколько нужно, столько займем", то формировался огромный рынок заказов на реальные ресурсы от проектов. Денег от дешевых кредитов так много, что ресурсы фактически стали управляться процессными компаниями, которые предоставляют в аренду технику, людей и материалы по так называемой схеме "times & materials". Если вы еще не догадались раньше проектному менеджеру в США не требовалось вообще управлять ресурсами кроме разве что своих подчиненных, подрядчики аутсорсили практически готовые производственные процессы с ресурсами.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Расскажу на примере строительного проекта США как он выглядел до глобального финансового кризиса. Предположим вы хотите построить небоскреб в <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="4907" data-yobjectid="0oCghydXc3NjkxMxgDdl-irg" data-yobjectlength="6" id="c610759f5fef63486ba814874e103d2149070oCghydXc3NjkxMxgDdl-irg" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Сиэтле</yobject>. Вы понятия не имеете как это делается, у вас нет ни гроша в кармане и никакого опыта строительства, но <strong>идея хорошая</strong>. С этой идеей облеченной в бизнес-план вы идете в инвестиционный банк, который часто назывался... <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="5131" data-yobjectid="0oCglydXcyMjM1MjMYA7VGZJE" data-yobjectlength="15" id="c610759f5fef63486ba814874e103d2151310oCglydXcyMjM1MjMYA7VGZJE" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Lehman Brothers</yobject> :) Знакомое название? Не делая глубокую экспертизу себестоимости небоскреба Leman Brothers, если идея интересная, открывает кредитную линию. Конечно есть риски, но Leman Brothers это не пугает. Примерно 80% строительных компаний США банкротятся в течении года, но банк забирает оставшиеся активы себе и почти ничего не теряет, а что может потерять банк застрахует в... <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="5516" data-yobjectid="0oCglydXcxNTg0NzMYA-eEZpQ" data-yobjectlength="3" id="c610759f5fef63486ba814874e103d2155160oCglydXcxNTg0NzMYA-eEZpQ" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">AIG</yobject>. Еще одно знакомое название? :) Теперь банку нужно взять где-то самому деньги, для этого ваш небоскреб "смешают" с ценными бумагами каких-то ходовых торговых центров и так получится кредитная бумага, которую потом назовут "токсичным активом", но пока она считается надежной, поэтому потенциальным покупателям без оглядки дадут деньги ... <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="5858" data-yobjectid="0oCgpydXcxMzE2MjM4GAMwak1x" data-yobjectlength="11" id="c610759f5fef63486ba814874e103d2158580oCgpydXcxMzE2MjM4GAMwak1x" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Freddie Mac</yobject> и <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="5872" data-yobjectid="0oCglydXczNzc1OTAYA0kkeTI" data-yobjectlength="10" id="c610759f5fef63486ba814874e103d2158720oCglydXczNzc1OTAYA0kkeTI" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Fannie Mae</yobject>. Знакомые имена снова? :)</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Дальше будет нанята обычно компания по проектированию, которая и будет далее управлять строительством. Это удачная находка менеджеров США внедряется и у нас. Однако если вы разберете схему выше, важно понять, что это схема фактически неограниченных финансовых ресурсов. Огромный рынок закупок ресурсов для проектов порождается множество компаний где техника и люди собираются не под проект, а просто ждут заказов, которые конечно будут ... если <strong>финансовый Пузырь продолжит существовать</strong>. Интересно, что после падения железного занавеса, когда советские эксперты по планированию смогли изучить западные решения, они конечно отдали должное высокому уровню проектной коммуникации в США, но многие уже тогда предсказывали Глобальный Финансовый Кризис, т.к. экономика которая не умеет управлять ресурсами не контролирует свою себестоимость, а ведение проектов через займы и перезаймы это финансовая наркомания, которая неизбежно кончается хлопком Пузыря. На деле СССР развалился от <a href="http://www.mfit.ru/defensive/vestnik/vestnik8_1.html" style="color: #443333;">милитаризации экономики в годы холодной войны</a> и невозможности покрыть дефицит бюджета дешевыми кредитами, США в годы <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="7012" data-yobjectid="0oCghydXcyNTM1MxgDYGCDsw" data-yobjectlength="14" id="c610759f5fef63486ba814874e103d2170120oCghydXcyNTM1MxgDYGCDsw" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Холодной Войны</yobject>запустили финансовый Пузырь кредитования, который подорвался только недавно и если сейчас будет вторая волна, последствия мало предсказуемые. </div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Если вы проанализируете типичную схему ведения проектов в США до Глобального Финансового Кризиса, то вы легко можете понять, что ресурсами там управлять менеджерам проектов не нужно, они же в процессных компаниях-подрядчиках. Также вы можете заметить, что сами ресурсы никак не связаны с себестоимостью проектов и их реальными потребностями. Ресурсы создавались под проекты без учета реальных потребностей проектов в разное время, т.е. <strong>ресурсы создавались избыточные</strong>. </div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Меня всегда веселят некоторые специалисты которые чуть ли на коленях стоят перед <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="7735" data-yobjectid="0oCgpydXcxMTE4MjYxGAMxaOup" data-yobjectlength="5" id="c610759f5fef63486ba814874e103d2177350oCgpydXcxMTE4MjYxGAMxaOup" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">PMBOK</yobject> с <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="7743" data-yobjectid="0oCgpydXcyNDc3NTI1GAM9FSpB" data-yobjectlength="9" id="c610759f5fef63486ba814874e103d2177430oCgpydXcyNDc3NTI1GAM9FSpB" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Primavera</yobject> и <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="7755" data-yobjectid="0oCghydXc5NDMxMRgD9Abk6Q" data-yobjectlength="10" id="c610759f5fef63486ba814874e103d2177550oCghydXc5NDMxMRgD9Abk6Q" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">MS Project</yobject>. Я вам могу ответственно сказать, как участник разработки крупнейшей в мире проектной системы Microsoft Project и знающий сценарии бизнес-процессов множества корпораций в мире реализованных на MS Project, что поставить Primavera или MS Project себе в компанию как икону лучших практик, это внедрить в свою компанию автоматизированные процессы создания Глобального Кризиса в миниатюре. Надо трезво понять, что американская школа управления проектами где-то приносит лучшие практики, а где-то просто в каменном веке относительно даже методологии ведения проектов в СССР и потому может грозить катастрофой вашему проекту, если только у вас также вдруг не откроется неиссякаемый источник средств.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Так где же американская школа управления проектами сильнее советской? На деле - в коммуникации. Если вы приглядитесь к схеме выше и отбросите составляющую финансового безумия в управлении проектом, то видно, что даже рядовой американский проект имеет множество участников с помощью кооперации которых он выполняется. Это создает очень высокие требования к методологии и средствам проектной коммуникации. Сила PMBOK как раз в регламентации бизнес-процессов как "правил игры" для множества участников проекта. Лучшие американские системы управления проектами как <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="9026" data-yobjectid="0oCghydXc5NDMxMRgD9Abk6Q" data-yobjectlength="10" id="c610759f5fef63486ba814874e103d2190260oCghydXc5NDMxMRgD9Abk6Q" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">MS Project </yobject>или <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="9041" data-yobjectid="0oCgpydXcyNDc3NTI1GAM9FSpB" data-yobjectlength="9" id="c610759f5fef63486ba814874e103d2190410oCgpydXcyNDc3NTI1GAM9FSpB" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Primavera</yobject> - это продукты с богатейшими коммуникационными возможностями, которые легко обходят тот же <yobject data-hashcode="c610759f5fef63486ba814874e103d21" data-reqid="55325432-3545-4251-808D-7E54E4FB1B27/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="9140" data-yobjectid="0oCgtlbnc0MzIzMTMyNBgD89Qgpw" data-yobjectlength="14" id="c610759f5fef63486ba814874e103d2191400oCgtlbnc0MzIzMTMyNBgD89Qgpw" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Spider Project</yobject>, который не имеет до сих пор проектный сервер для коммуникации команды в реальном времени.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Теперь давайте заглянем в школу управления проектами в СССР и поймем где она сильнее, а также попробуем ответить является ли отсутствие сервера управления проектами у Spider Project просто "наследием Совка" или же коммуникационная модель в СССР отличалась от модели управления проектом в США?</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Руководство СССР даже если бы захотело не смогло бы управлять проектами как в США через финансовый Пузырь генерирующий неограниченные ресурсы. Доступ СССР на международный кредитный рынок был очень ограничен и ставки кредитов для СССР были высоки, чтобы легко начать "пузырить" проекты. В реальности у СССР не оставалось выбора как сосредоточиться на тщательном управлении ресурсами, которые СССР был в состоянии создать. Вы должны понимать неасколько эффективная советская ресурсная методология управления проектами. Десятилетиями СССР выдерживало годы Холодной Войны против США имея в разы меньше ресурсов, при этом население имело довольно высокий уровень жизни.<br />
<br />
<h2 style="text-align: left;">
Советская школа управления проектами - это управление проектом с ограниченными ресурсами</h2>
</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Советская школа управления проектами строилась от управления ресурсами в первую очередь, для этого <strong>ресурсы нормировались</strong>, т.е.определялось сколько часов нужно сотруднику или оборудованию, чтобы произвести единицу продукции. Сколько нужно материалов для производства единицы продукции. Нормирование ресурсов в СССР было тотальным и лежало в экономическом обосновании фактически всех проектов. Строительные нормативы, рожденные во времена СССР, хорошо знакомы любому строителю России и их продолжают развивать. В тоже время для строительного менеджера в США это просто космические технологии управления проектом. Нормирование ресурсов в СССР было настолько тотальным, что даже удалось придумать модели нормирования труда проектировщиков и программистов, т.е. определять длительность задач и их ресурсную потребность автоматически, исходя из нормативов, а не по экспертной оценке на "глазок" как делает менеджер в США. Не всегда нормирование хорошо работает для труда инженеров, но для производственных и строительных проектов это базовая методология для компании, которая не хочет обанкротиться. Отметим интересный признак системы, умеющей планировать график от норм ресурсов, всегда нормы расхода ресурсов формулируются на единицу продукции создаваемую задачей (процессом), сама продукция измеряется в <strong>физическом объеме</strong>. То что в MS Project и Primavera нет понятия физического объема доказывает, что наши американские партнеры ничего не понимают в управлении ресурсами в проектах, если сравнивать это с высокой планкой русского ресурсного менеджмента в проектах.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Отметим тут еще очень интересный момент. Долгое время Владимир Иосифович Либерзон (бывший глава PMI в России из Spider Project) ведет битву с PMBOKчниками доказывая, что софт совсем не вторичен относительно методологии. Действительно для последователя американской школы управления проектами главное - проектная коммуникация и некоторая программа Paint для рисования Гантов. С этой точки зрения действительно не велика так разница будет там Primavera или MS Project, т.к. программы примерно одинаковые в базовых сценариях бизнес-процессов. Для русской ресурсной школы проектного менеджмента нужны вычисления по нормативам, программы не одинаковые, нужны <strong>мозги для вычисления графиков на основании нормативов, т.е. специальная математика без которой методология не работает в принципе, </strong>сколько бы бумаг с регламентами вы не написали. Поэтому Владимир Иосифович совсем не Дон Кихот проектного менеджмента, отечественная методология управления проектами реализуема только при наличии ресурсной математики. Такая математика и реализуется в Spider Project или может быть реализована в Microsoft Project если его расширить нашим компонентом Turbo Project. Без такой "машинки для подсчета ресурсов" шансы реализовать методологию равны не нулю, они отрицательные, т.к. такой объем цифр вручную рассчитать невозможно в принципе. </div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
У русской школы управления проектами есть еще одно преимущество - <strong>русская методология может рассчитать <u>реальные сроки</u> проекта, которые на деле <u>зависят от возможностей ресурсов</u></strong>. В американской школе управления проектами сроки все директивные, т.е. выставляются "на глазок" экспертом по его опыту. Когда-то он угадает, когда-то нет. Помнится у меня была дискуссия с одним известным экспертом по УП в России о том, что если он хочет удержать в сроках свой стратегический проект, он должен опуститься до уровня ресурсов хотя бы с помощью укрупненных норм и проверить возможности подрядчиков. Мне ответили, что пусть подрядчики сами разбираются с ресурсами, а настоящий методолог будет работать со списком контрольных точек. Результат? Чтобы проект вернуть в сроки потребовался перерасход бюджета почти на <strong>миллиард долларов</strong>. Подрядчики поняв, что их не контролируют быстро растащили деньги и не выставили на площадку необходимое количество ресурсов где-то по умыслу, а где-то потому, что сами не знали сколько их нужно, чтобы попасть в сроки. Советский планировщик никогда бы не совершил такой банальной ошибки, он легко бы выяснил сколько ресурсов требуется для того чтобы попасть в директивный срок или же какой срок получится исходя из имеющихся ресурсов. Отметим, что описанный пример это не коррупционная особенность России. Первенство СССР в запуске человека в космос во многом заслуга отечественной школы управления проектами. США имея больше ресурсов проиграли гонку за космос, т.к. американцы не могли связать между собой ресурсы и сроки как в описанном выше примере. Для восстановления репутации державы пришлось лететь на Луну, создавая огромную нагрузку на бюджет страны.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Продолжим о финансовых аспектах. До глобального финансового кризиса проектных менеджеров в США вообще не интересовало управление ресурсами, деньги можно было подметать шваброй (money is not problem). Сейчас ситуация совсем другая и пока многие в России зажигают свечки перед иконой PMBOK, в США сейчас очень многие заняты тщательным реинжирингом опыта СССР и России в управлении ресурсами, чтобы забрать у нас эти лучшие практики, т.к. теперь финансовые условия в США требуют управлять ресурсами неспосредственно из проекта. Будет просто любопытно, если Россия имеющая историческое наследие СССР с преимуществом в ресурсных методиках управления проектами вдруг окажется позади США, которые еще только учатся такой методологии управления проектами.<br />
<br />
Так почему "отсталые" американцы из Microsoft легко побеждают продвинутую ресурсную математику Spider Project?<br />
<br />
<h2 style="text-align: left;">
Коммуникация в проектах - преимущество американской проектной школы</h2>
</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
К слову, могу пояснить Владимиру Иосифовичу Либерзону из Spider Project почему ему не удалось после изрядного маркетинга на строительных конференциях в США добиться успеха, хотя превосходство русской ресурсной школы в управлении проектами для экспертов из США совсем не секрет. Могу прямо сказать в этой статье, что очень многие эксперты Microsoft Project, тщательно изучают его продукт на предмет заложенных методик. У меня все-таки есть доступ к экспертам из 30 стран и к самим разработчикам/методологам из США через программы <yobject data-hashcode="538fdabeff1e69c1fcd430a954b958f8" data-reqid="5D9C031A-2621-409B-A254-2405065AE56D/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="6111" data-yobjectid="0oCghydXcxMTk4NxgDRFkIHA" data-yobjectlength="9" id="538fdabeff1e69c1fcd430a954b958f861110oCghydXcxMTk4NxgDRFkIHA" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Microsoft</yobject>.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Дело не в раскрутке и не в том, что эксперты из США не способны понять эффективные методологии, дело именно в том, что <b>американская школа сильнее в коммуникационной модели</b> и Spider Project лишь как калькулятор ресурсов по средствам коммуникации сильно отстает от де-факто стандартов в США. Также очень важный момент, что советская школа коммуникации в проектах отличается от американской. На деле американцы ее изучили и применяют, но это только один из вариантов, который только еще набирает популярность. Речь идет о методологии управления коммуникацией в проекте по советской модели планировщиков.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
На деле в США раньше редко использовались планировщики для управления проектами. Сами менеджеры этим занимались в большинстве случаев. Это оправдано когда основной акцент управления проектами в коммуникацию и особо сложных вычислений в проекте не делается, т.е. по-сути управлять проектом может любитель-менеджер, а не специально обученный профессионал. На фоне советских ресурсных методик с мощными математическими расчетами по нормативам, даже квалификация PMP выглядит бледно в сравнении с подготовкой планировщика в СССР. Как я уже отмечал, в СССР большой акцент в ресурсный менеджмент, кооперация между компаниями ограничена, поэтому проекты управлялись не менеджерами, а их помощниками в лице профессиональных планировщиков. Практически любая проектная организация в СССР имела подразделение профессионалов-планировщиков. За время Перестройки это огромное преимущество отечественного проектного менеджмента благополучно развалили и теперь восстанавливают.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Для управления ресурсной моделью нужен не любитель, а профессиональный планировщик. Поскольку это не любитель, а профессионал его производительность труда и надежность намного выше, чем у менеджера, который управляет проектом по-совместительству с работой по принятию проектных решений. <yobject data-hashcode="538fdabeff1e69c1fcd430a954b958f8" data-reqid="5D9C031A-2621-409B-A254-2405065AE56D/7392a86f3a8fc529259ce14651efca2b" data-yobjectbegin="7990" data-yobjectid="0oCglydXczOTgyNDAYA4x9dHw" data-yobjectlength="24" id="538fdabeff1e69c1fcd430a954b958f879900oCglydXczOTgyNDAYA4x9dHw" style="border-bottom: 1px dotted rgb(102, 102, 102); cursor: help; display: inline; margin: 0px; padding: 0px; position: relative;">Производительность труда</yobject> профессиональных планировщиков очень велика, фактически один профессиональный планировщик может без проблем обслуживать около 100 контрагентов, т.е. управлять около 100 подрядчиков или 100 сотрудниками. Он может это делать <strong>один</strong>. А поскольку он один, то ему не нужен сервер управления проектами, его проектная система сама по себе его персональный сервер. Фактически Spider Project как советский продукт и поддерживает модель планировщиков, поэтому ему сервер и не нужен, в большинстве клиентов у Spider Project стоит всего один экземпляр программы у самого планировщика, у остальных средства просмотра и внесения данных об исполнении (модуль "Учет").</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Как не сложно догадаться советские системы начинают испытывать проблемы при управлении портфелями из множества проектов, начинается подлинное безумие с обменом файлами, что конечно менее надежно и менее оперативно чем серверные технологии американских систем.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
<h2 style="text-align: left;">
Давайте подведем итог</h2>
</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Советская методология управления проектами сильнее американской в управлении ресурсами и также имеет более продуманную схему коммуникации для индивидуальных профессионалов-планировщиков.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Американская методология управления проектами сильнее советской школы в коммуникации и "дружественности" методик и интерфейсов программ с учетом того, что проектом управляют коллективно и многие непрофессионалы в проектном менеджменте.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Одинаково неверны утверждения, что отечественная школа управления проектами сильнее американской или наоборот. Каждый силен в своем.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Очевидно, что решения нового поколения должны совместить достижения лучших проектных школ в мире - американской и русской.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
От американцев надо взять их лучшие средства проектной коммуникации в методологии и инструментов. От отечественной школы нужно взять умение управлять проектом по нормативам и схему управления проектом через планировщика.</div>
<div style="background-color: white; font-family: Helvetica, Arial, sans-serif; font-size: 12px; margin-bottom: 14px; margin-top: 14px;">
Именно это мы и пытаемся сделать в Turbo Planner, в котором коммуникационный модуль поддерживает модель управления через планировщика, но с использованием передовых американских методик и технологий (включая ультра-современные облачные технологии коммуникации). С другой стороны Turbo Planner оборудован ресурсным движком, который базируется на лучших достижениях советской ресурсной школы, поэтому не удивительна совместимость со Spider Project даже на уровне справочников норм. Это одна методология управления проектами от ресурсов - русская школа управления проектами, которая запустила Гагарина в космос.</div>
</div>
Vladimir Ivanovhttp://www.blogger.com/profile/05223453757943695857noreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-8208389309822552992022-11-02T00:49:00.000+05:002023-03-01T19:43:20.957+05:00 ГОСТ Р 55348-2012 «Системы управления проектированием Словарь терминов, используемых при управлении проектированием»<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCcu7HJIHnT9Mi0ojPr1MtUOeWW0w-iRxC7uwlkHE_LceY6NvuXZsDDTzgRL9szH_vrOgI8oF-ZGIVT4nADHRm_SQVdm6b8qOGbQmbaD8HxQ5aJfIw6KKXPTSejifV67elkjaZu1Dmpik/s1600/e7c3918763d85a6ff86abc5ba04c1e34.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCcu7HJIHnT9Mi0ojPr1MtUOeWW0w-iRxC7uwlkHE_LceY6NvuXZsDDTzgRL9szH_vrOgI8oF-ZGIVT4nADHRm_SQVdm6b8qOGbQmbaD8HxQ5aJfIw6KKXPTSejifV67elkjaZu1Dmpik/s1600/e7c3918763d85a6ff86abc5ba04c1e34.png" height="320" width="228" /></a></div>
<span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.0" style="background-color: #f6f7f8; color: #141823; font-family: Helvetica, Arial, 'lucida grande', tahoma, verdana, arial, sans-serif; font-size: 12px; line-height: 15.3599996566772px;"><span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.0.$end:0:$0:0"><br /></span></span>
<span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.0" style="background-color: #f6f7f8; color: #141823; font-family: Helvetica, Arial, 'lucida grande', tahoma, verdana, arial, sans-serif; font-size: 12px; line-height: 15.3599996566772px;"><span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.0.$end:0:$0:0"><br /></span></span>
<span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.0" style="background-color: #f6f7f8; color: #141823; font-family: Helvetica, Arial, 'lucida grande', tahoma, verdana, arial, sans-serif; font-size: 12px; line-height: 15.3599996566772px;"><span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.0.$end:0:$0:0">Росстандарт выложил постраничные сканы ГОСТ Р 55348-2012 «Системы управления проектированием. Словарь терминов, используемых при управлении проектированием» объёмом 40 страниц, который введён в действие 01.01.2014. Как отмечается в аннотаци</span></span><span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.3" style="background-color: #f6f7f8; color: #141823; font-family: Helvetica, Arial, 'lucida grande', tahoma, verdana, arial, sans-serif; font-size: 12px; line-height: 15.3599996566772px;"><span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.3.0"><span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.3.0.$text0:0:$0:0">и, стандарт разработан АНО «Международная академия менеджмента и качества бизнеса», внесен Техническим комитетом по стандартизации ТК100 «Стратегический и инновационный менеджмент».</span></span></span><br />
<span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.3" style="background-color: #f6f7f8; color: #141823; font-family: Helvetica, Arial, 'lucida grande', tahoma, verdana, arial, sans-serif; font-size: 12px; line-height: 15.3599996566772px;"><span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.3.0"><br data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.3.0.$text0:0:$1:0" /><span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.3.0.$text0:0:$2:0">В стандарте использованы положения британского стандарта BS 7000-10:2008 «Системы управления проектированием. Часть 10. Словарь терминов, используемых при управлении проектированием» (BS 7000-10:2008 Design management systems - Part 10: Vocabulary of terms used in design management.</span></span></span><br />
<span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.3" style="background-color: #f6f7f8; color: #141823; font-family: Helvetica, Arial, 'lucida grande', tahoma, verdana, arial, sans-serif; font-size: 12px; line-height: 15.3599996566772px;"><span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.3.0"><span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.3.0.$text0:0:$2:0"><br /></span></span></span>
<span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.3" style="background-color: #f6f7f8; color: #141823; font-family: Helvetica, Arial, 'lucida grande', tahoma, verdana, arial, sans-serif; font-size: 12px; line-height: 15.3599996566772px;"><span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.3.0"><span data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.3.0.$text0:0:$2:0">Ссылка на ГОСТ </span><a class="" data-reactid=".8l.1:3:1:$comment918132724879783_948369361856119:0.0.$right.0.$left.0.0.1:$comment-body.0.3.0.$range0:0" dir="ltr" href="http://protect.gost.ru/v.aspx?control=8&baseC=6&page=10&month=8&year=2014&search&RegNum=1&DocOnPageCount=15&id=176044" rel="nofollow" style="color: #3b5998; cursor: pointer; text-decoration: none;" target="_blank">http://protect.gost.ru/v.aspx?control=8&baseC=6&page=10...</a></span></span></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-9411945687937538962022-06-18T00:54:00.000+05:002023-03-01T19:37:56.695+05:00<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/Nsmb0RsMtUQ/0.jpg" src="https://www.youtube.com/embed/Nsmb0RsMtUQ?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
<span style="background-color: white; color: #141823; font-family: helvetica, arial, sans-serif; font-size: 14px; line-height: 19.3199996948242px;">Очень интересное интервью практика как Сергей Луговцов о том как разработать и внедрить ресурсные нормативы. </span></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-65062285855023807432022-06-18T00:52:00.000+05:002023-03-01T19:38:16.367+05:00<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/sZgmliw0oBs/0.jpg" src="https://www.youtube.com/embed/sZgmliw0oBs?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
Интервь Владимира Малахова по теме российской практики применения EPC контрактов.</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-58971904790545205322022-06-18T00:50:00.000+05:002023-03-01T19:40:26.560+05:00<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/ZWKWrvCnIkI/0.jpg" src="https://www.youtube.com/embed/ZWKWrvCnIkI?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
Оригинальная методика отслеживания сетевой модели промышленных проектов от Максима Боруховского под названием "Клетчатый".<br />
<br />
Это интервью особенно будет интересна практикам-планировщикам для расширения своего арсенала инструментов календарного планирования.</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-47364207729041846662022-06-18T00:45:00.000+05:002023-03-01T19:40:46.146+05:00<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/oWsBzXQFc_8/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/oWsBzXQFc_8?feature=player_embedded" width="320"></iframe></div>
<br />
Если Вы хорошо разбираетесь в сметном деле и вам хочется острых ощущений, то рекомендуется к просмотру. Если же в сметном деле вы новичок, вы откроете для себя удивительные подходы к ценообразованию, о которых даже и не догадывались ранее.<br />
<br />
Интервью с Сергеем Мишиным по теме западного ценообразования. Сергей в ходе интервью постарался раскрыть ключевые отличия западного подхода к формированию смет от нашего отечественного.<br />
<a name='more'></a><br />
Практически во всех профильных группах по управлению промышленными проектами это интервью вызвало активное обсуждение.<br />
<br />
Примеры некоторых комментариев из обсуждений:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhV1pQqMjCKV6XuQlWehKPWaxik8U68CHVKW-LFQqNn6xt8niN5L6Vld0z5r3_1P_Q-zOqKYQ1GLHIcH4CF50AbjnRDwqYduTXGR0EnyHciHkUtEUJRctJ-b8kXoApT5A30DeAywXU65y8/s1600/001.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="210" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhV1pQqMjCKV6XuQlWehKPWaxik8U68CHVKW-LFQqNn6xt8niN5L6Vld0z5r3_1P_Q-zOqKYQ1GLHIcH4CF50AbjnRDwqYduTXGR0EnyHciHkUtEUJRctJ-b8kXoApT5A30DeAywXU65y8/s400/001.png" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi_-TGkIiVk8UIrUNM6qsjdFpxL7KC45HEODWTHFH63t2yd7TJkHGtC0hqsut35L634mdxpwxGtskIb16v9uZavCajyoUt6lX65ITEFmBNPTBLVtpl7JL0MClDERQPapoPxEbS4YzfD4oU/s1600/002.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="63" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi_-TGkIiVk8UIrUNM6qsjdFpxL7KC45HEODWTHFH63t2yd7TJkHGtC0hqsut35L634mdxpwxGtskIb16v9uZavCajyoUt6lX65ITEFmBNPTBLVtpl7JL0MClDERQPapoPxEbS4YzfD4oU/s400/002.png" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgXm2M2ae5lviGD2PQ4VYDHOhm91tNXfLzUuA9mPMyhh8CWzpvIs-IIaBAwgraaA9r6-3RJhm3hW09R0qTsqel-rfRPFSPrvPeLHnepaHfucfQEmAdZCLY16NwN4nbqnEO3z08_BismUfA/s1600/003.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="102" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgXm2M2ae5lviGD2PQ4VYDHOhm91tNXfLzUuA9mPMyhh8CWzpvIs-IIaBAwgraaA9r6-3RJhm3hW09R0qTsqel-rfRPFSPrvPeLHnepaHfucfQEmAdZCLY16NwN4nbqnEO3z08_BismUfA/s400/003.png" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-47384946699724442232022-04-12T16:32:00.000+05:002023-03-01T19:44:52.906+05:00Кейс «Решение проблемы последнего процента»<div dir="ltr" style="text-align: left;" trbidi="on">
Коллеги, каждый из Вас наверняка сталкивался с проблемой последнего наидлиннейшего процента. Ну, т.е. когда Вы ставите задачу исполнителю на 5 дней, а он отчитывается за выполнение ежедневно, то Вы получаете примерно следующую отчётность:<br />
<div class="separator" style="clear: both; text-align: center;"><br /></div>
<br />
<ul style="text-align: left;">
<li>1 день = 20%</li>
<li>2 день = 40%</li>
<li>3 день = … и тут исполнитель понимает, что он нихера ещё и половины работы не сделал, но пишет навскидку 55%</li>
<li>4 день = ы-ы-ы... 70% и в лучшем случае начинается торг за вменяемое увеличение сроков</li>
<li>5 день = 80%</li>
<li>6 день … </li>
</ul>
<br />
Оставшиеся 20% могут длиться ещё 5 дней. А самый последний 1% - может длиться ещё 5 дней… И получается, что за первые 5 дней исполнитель «выполняет» 80% работы, за вторые 5 дней – ещё 19%, а за последние 5 дней – ещё 1%.<br />
<br />
<b><span style="color: blue;">Знакомо?</span></b> <b>А какие могут быть решения данного кейса? </b>Я знаю два:<br />
<br />
<a name='more'></a><br />
<h1 style="text-align: left;">
1. Отчёт трудочасами (или трудоднями)</h1>
<i>Это решение мы использовали с <a href="https://plus.google.com/+VadimGerya">Вадимом Герей</a> при внедрении систем управления проектами.</i><br />
<br />
Задаче указывается не только длительность, но и количество человеко-часов, требуемых для выполнения задачи. После этого исполнитель отчитывается не процентовками, а количеством потраченных и оставшихся трудозатрат. Просто в конце рабочего дня вспоминает, сколько часов он сегодня потратил на задачу и вносит эту цифру в одну ячейку, и прикидывает, сколько ещё часов нужно на реализацию оставшейся части работ и вносит в другую ячейку.<br />
<br />
Проценты выполнения, в таком случае, высчитывает сама система (тот же Microsoft Project). А Вы, как проектный менеджер, уже с первых дней выполнения работы видите более-менее реальную картинку.<br />
<h1 style="text-align: left;">
2. Отчёт по заранее заданным показателям</h1>
<i>Это решение использует компания <a href="http://www.dragonoil.com/">Dragon Oil</a>. И в своё время у меня была задача адоптировать систему УП одной нашей компании под их требования.</i><br />
<br />
Для начала, просто привожу выкопировку DragonOil-овского Scope of Work, а разбор полёта – внизу:<br />
<h4 style="text-align: left;">
<span style="font-family: Georgia, Times New Roman, serif;">16.5 Шкалы продвижения РАБОТ (для измерения фактического продвижения РАБОТ)</span></h4>
<span style="font-family: Georgia, Times New Roman, serif;">Для каждого отдельного комплекса РАБОТ и единицы РАБОТЫ должен быть использован набор шкал для оценки фактического продвижения РАБОТ. Шкалы степени продвижения РАБОТ должны быть использованы для распределения весовых коэффициентов на всю временную протяженность РАБОТЫ. Фактическое продвижение РАБОТЫ должно всегда базироваться только на физическом приросте объема РАБОТЫ. Фактическое продвижение РАБОТЫ должно рассчитываться на нижнем уровне с использованием нескольких шкал продвижения РАБОТЫ, которые отличаются одна от другой в зависимости от типа РАБОТЫ.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;"><u>Рабочее проектирование</u>: Накопительные шкалы (по нарастанию) продвижения РАБОТ должны составляться с использованием контролируемых этапов физического прироста объема РАБОТЫ для каждого общего типа документов:</span><br />
<ul style="text-align: left;">
<li><span style="font-family: Georgia, Times New Roman, serif;">Начало документа/чертежа - <b>5%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Готовность/законченность к рассмотрению (в аспекте между направлениями) - <b>45%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Выдача ЗАКАЗЧИКУ для рассмотрения/комментирования - <b>50%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Утверждение для проекта/проектирования - <b>90%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Утверждение для строительно-монтажных РАБОТ - <b>100%</b></span></li>
</ul>
<u style="font-family: Georgia, "Times New Roman", serif;">Материально-техническое обеспечение</u><span style="font-family: Georgia, 'Times New Roman', serif;">: Накопительные шкалы (по нарастанию) продвижения РАБОТЫ должны быть установлены для отслеживания каждой позиции, начиная с этапа запроса и вплоть до доставки и приемки на месте производства РАБОТ:</span><br />
<ul style="text-align: left;">
<li><span style="font-family: Georgia, Times New Roman, serif;">Подготовка запроса - <b>5%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Выпущено для запроса - <b>10%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Выдача заказа на закупку - <b>20%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Утвержденные чертежи поставщиков - <b>25%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Поставка с завода-изготовителя - <b>75%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Доставка и таможенная очистка - <b>95%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Доставка и приемка на месте производства РАБОТ - <b>100%</b></span></li>
</ul>
<u style="font-family: Georgia, "Times New Roman", serif;">Строительно-монтажные РАБОТЫ</u><span style="font-family: Georgia, 'Times New Roman', serif;">: Накопительные шкалы (по нарастанию) продвижения РАБОТ должны быть установлены для отслеживания изготовления/монтажа до окончательного утверждения/приемки:</span><br />
<ul style="text-align: left;">
<li><span style="font-family: Georgia, Times New Roman, serif;">Законченные рабочие чертежи - <b>5%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Наличие поставленных материалов и изделий - <b>25%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Завершение изготовления компонентов предварительного изготовления - <b>45%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Монтаж - <b>90%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Испытание и сдача в эксплуатацию - <b>95%</b></span></li>
<li><span style="font-family: Georgia, Times New Roman, serif;">Передача - <b>100%</b></span></li>
</ul>
<span style="font-family: Georgia, 'Times New Roman', serif;">Фактическое продвижение в выполнении РАБОТ, ни при каких условиях не может оцениваться соотнесением с количеством затраченных человеко-часов. Приведенные выше цифры по оценке продвижения РАБОТ предназначены только для определения хода РАБОТ и не могут использоваться для целей оплаты.</span><br />
<h4 style="text-align: left;">
Разбор полётов:</h4>
Вы типизируете работы и проставляете критерии их оценки заранее, и лишаете исполнителя права и возможности самому придумывать проценты выполнения. Достигнув того или иного критерия, исполнитель просто указывает условленный процент выполнения.<br />
Так же, как и в прошлом решении, картинка по выполнению работ становится более-менее реальной.<br />
<br />
<h1>
3. Дробить задачи, сокращая их длительность</h1>
<i>Это решение в <a href="https://www.facebook.com/groups/msproject/permalink/764407966928066/" target="_blank">FB-дискуссии</a> предложил <a href="http://www.facebook.com/gandjustas" target="_blank">Стас Выщепан</a> и подтвердил <a href="http://www.facebook.com/konstantin.trunin" target="_blank">Константин Трунин</a>.</i><br />
<br />
Если речь об ИТ-проектах, то есть отличное решение кейса. Для каждой задачи единственный срок - сегодня (или даже "сделай сегодня и ниипет"), сделал или нет - неважно, в конце дня результат и следующая задача \ корректировка плана.<br />
<br />
А если проект длинною в год; да, ещё и пара-тройка десятков ежедневно работающих исполнителей, то чтоб ПМ не "зашился" с декомпозицией задач до одного дня, необходимо использовать делегирование. А делегатов вполне может быть больше одного. Да, и нет смысла расписывать задачи на год вперед, неделя-две - более чем достаточно.<br />
<br />
План должен быть детализирован до отдельных задач длиной меньше недели. Если у нас нет нормирования на входе (а кроме стройки ни где нет такого нормирования), то сделать такую детализацию в начале проекта невозможно. Поэтому в начале проекта будет грубая оценка вех\фич, а по мере приближения фазы реализации, задачи будут уточняться.<br />
<br />
Так что дополнительная детализация до отдельных задач по дню, плюс строгий тайм-боксинг и корректировка детального плана не потребуют больших дополнительных вложений. Тем более что такая детализация всё равно выполняется, только не формально, на уровне отдельных исполнителей.<br />
<br />
Но эффект получается потрясающий, вместо "готового на 90% результата", который неизвестно когда будет закончен, вы получаете объективную картину движения проекта.<br />
<br />
<h1>
4. Использовать подход CCPM</h1>
<i>Это решение в <a href="https://www.linkedin.com/groups/%D0%9A%D0%B5%D0%B9%D1%81-%D0%A0%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B-%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B3%D0%BE-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D0%BD%D1%82%D0%B0-6666684.S.5944787315581804547" target="_blank">LI-дискуссии</a> предложил <a href="http://www.linkedin.com/profile/view?id=11966147" target="_blank">Сергей Потапов</a>.</i><br />
<br />
Проблема "последнего процента" заключается именно в том, что зачастую мы меряем не то. В нашем внедрении <a href="http://en.wikipedia.org/wiki/Critical_chain_project_management" target="_blank"><b>CCPM</b></a> этой проблемы нет, вернее она видоизменена.<br />
<br />
Но ключевой вопрос - "для чего нам нужны измерения?" Если выставить счет по "T&M", то действительно нужно мерять "сколько потрачено". Но приводит ли это к "успеху проекта"? Ведь все подходы измерения прогресса "сколько потрачено" направлены на то, чтобы максимально следовать попытке заглянуть в будущее в виде плана. А можем ли мы точно предсказать будущее? К счастью, нет. С этим и связано то, что реальное прохождение задачи всегда будет отличаться от запланированного. А это автоматически означает, что будут "быстрые 20%" и "медленный 1%". <br />
<br />
Если важен результат, а не усилия по его достижению, то нужно мерять, сколько осталось до результата! Тогда, если бы исполнитель 5-дневной задачи отчитывался в конце каждого дня:<br />
1-й день - мне осталось до завершения задачи 4 дня<br />
2-й день - мне осталось до завершения задачи 3 дня<br />
3-й день - мне осталось до завершения задачи 4 (!!!) дня...<br />
и тут ПМ подошел бы к исполнителю и задал простой и естественный вопрос: "я вижу у тебя возникли проблемы. Как тебе помочь?"<br />
<br />
А) ПМ бы узнал об объективных проблемах не "в последний день".<br />
Б) с бОльшей вероятностью, подключились дополнительные силы и разрулили проблему вовремя.<br />
<br />
Важно, сколько осталось до результата. Иначе "мы перепрыгнули пропасть на 99%" :)<br />
<br />
<h1>
5. Обрезание концов</h1>
<i>Это решение в <a href="https://www.linkedin.com/groups/%D0%9A%D0%B5%D0%B9%D1%81-%D0%A0%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B-%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B3%D0%BE-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D0%BD%D1%82%D0%B0-6666684.S.5944787315581804547" target="_blank">LI-дискуссии</a> предложил <a href="http://www.linkedin.com/profile/view?id=352902319" target="_blank">Alexander Koropec</a>.</i><br />
<br />
На практике ещё применяется обрезание концов: если выполнение работы делает возможным начало следующей связанной работы, ставим 100%, а недостающие переносим на дефектную ведомость. Пример классический: подливка оборудования, небольшие ЖБ-опоры, и пр.<br />
Собственно, метод давно известен в строительстве и специфичен именно для строительства: строительный поток организуется по работам одного типа. Выделяем хвосты в строительный поток, и в значительной степени проблема снимается.</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-922505092501815232015-03-22T23:14:00.000+05:002015-04-23T15:42:49.899+05:00Карта Знаний руководителя проекта. 1 месяц. Полёт нормальный<div dir="ltr" style="text-align: left;" trbidi="on">
Месяц назад я открыл доступ к <a href="http://knowledgemap.pmdoc.ru/ru/" target="_blank">Карте Знаний</a> всем желающим. Зарегистрировались 89 человек. Реально заходили в систему и пытались сдавать тест 49 человек. Из низ 39 человек осилили, таки, тест из 50 вопросов и получили свою <a href="http://knowledgemap.pmdoc.ru/ru/" target="_blank">Карту Знаний</a>.<br />
Думаю, можно считать этих людей репрезентативной выборкой для оценки уровня знаний русскоговорящей аудитории. И причин тому две. Во-первых, они являются участниками профессиональных on-line сообществ и смогли там обнаружить моё объявление. Во-вторых, они были очень заинтересованны узнать свой уровень знаний в сфере управления проектами.<br />
Выводы о своём личном уровне знаний каждый из них сделает сам, а я хочу показать "среднюю температуру по больнице" (кликайте на картинке для увеличения):<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsib_kMDLu_YOt2nKCsGM_aPO31GihrtWqpUbN_Tx0c5mdmh8d3DQItfhyphenhyphenDwJTwCZjAUP7gBROk7g1VmPMejB19cQcjLK_Mx1wNh7T2617uJA9xSg-2Et2fdtuatoAGntjJ3NhSiqRQR0/s1600/km_march_2015.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsib_kMDLu_YOt2nKCsGM_aPO31GihrtWqpUbN_Tx0c5mdmh8d3DQItfhyphenhyphenDwJTwCZjAUP7gBROk7g1VmPMejB19cQcjLK_Mx1wNh7T2617uJA9xSg-2Et2fdtuatoAGntjJ3NhSiqRQR0/s1600/km_march_2015.JPG" height="222" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<b><br /></b></div>
<div class="separator" style="clear: both; text-align: left;">
<b>49% - средний уровень знаний проактивных людей.</b></div>
<div class="separator" style="clear: both; text-align: left;">
Очень мало, на мой взгляд. Опыт использования <a href="http://knowledgemap.pmdoc.ru/ru/" target="_blank">Карты Знаний</a> для подготовки к <a href="http://www.pmdoc.ru/product/pmp/" target="_blank">PMP</a> и <a href="http://www.pmdoc.ru/product/capm/" target="_blank">CAMP</a> показывает, что для гарантированной сдачи <a href="http://www.pmdoc.ru/product/pmp/" target="_blank">PMP</a> нужно выше 80% знаний по каждой области и группе, а для гарантированной сдачи <a href="http://www.pmdoc.ru/product/capm/" target="_blank">CAPM</a> - выше 70%.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Выводы делайте сами...</div>
</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-778917845230861712015-03-14T00:49:00.001+05:002015-03-14T00:49:39.007+05:00Календарно-сетевой график строительного проекта<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/6JzEyNphjrU/0.jpg" src="http://www.youtube.com/embed/6JzEyNphjrU?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-14375624464554801582015-03-02T12:09:00.000+05:002015-03-02T12:09:45.298+05:00<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="background-color: white; color: #141823; font-family: Helvetica, Arial, 'lucida grande', tahoma, verdana, arial, sans-serif; font-size: 14px; line-height: 19.3199996948242px; margin-bottom: 6px;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://ytimg.googleusercontent.com/vi/B7MIJP90biM/0.jpg" src="http://www.youtube.com/embed/B7MIJP90biM?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<div style="background-color: white; color: #141823; font-family: Helvetica, Arial, 'lucida grande', tahoma, verdana, arial, sans-serif; font-size: 14px; line-height: 19.3199996948242px; margin-bottom: 6px;">
<br /></div>
<div style="background-color: white; color: #141823; font-family: Helvetica, Arial, 'lucida grande', tahoma, verdana, arial, sans-serif; font-size: 14px; line-height: 19.3199996948242px; margin-bottom: 6px;">
Кстати, кто помнит видеоролик про 7 перпендикулярных красных линий?</div>
<div style="background-color: white; color: #141823; font-family: Helvetica, Arial, 'lucida grande', tahoma, verdana, arial, sans-serif; font-size: 14px; line-height: 19.3199996948242px; margin-bottom: 6px; margin-top: 6px;">
Все стебались на тему "несчастного эксперта". А ведь один эксперт нашел решение задачке. И по жизни так: соберешь участников команды и они тебе докажут почему так нельзя))) А решение всегда есть! Вопрос в желании его увидеть.</div>
<div style="background-color: white; color: #141823; display: inline; font-family: Helvetica, Arial, 'lucida grande', tahoma, verdana, arial, sans-serif; font-size: 14px; line-height: 19.3199996948242px; margin-top: 6px;">
Собственно, сейчас это желание будет определять тех, кто найдет в кризисе возможность и тех, кто уйдет в прошлое. </div>
<div>
<span style="color: #141823; font-family: Helvetica, Arial, lucida grande, tahoma, verdana, arial, sans-serif;"><span style="font-size: 14px; line-height: 19.3199996948242px;"><br /></span></span><div>
<div style="background-color: white; color: #141823; display: inline; font-family: Helvetica, Arial, 'lucida grande', tahoma, verdana, arial, sans-serif; font-size: 14px; line-height: 19.3199996948242px; margin-top: 6px;">
Смотрите и вдохновляйтесь!</div>
</div>
</div>
</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-86332567925213601342015-01-30T01:14:00.001+05:002015-01-30T01:19:55.117+05:00Документирование длительности проекта<div dir="ltr" style="text-align: left;" trbidi="on">
Команда проекта была оформлена <a href="http://www.pmdoc.ru/docs_of_project_team/" title="Документирование команды проекта">прошлой статьёй</a>, а пока она формируется, мы разберёмся, как документировать сроки проекта, т.е. его длительность. Для этого нам понадобятся <a href="http://www.pmdoc.ru/docs_of_project_scope/" title="Документирование объёмов работ проекта">результаты документирования объёмов работ</a>, несколько экспертов по технологии исполнения задуманного и приложение типа Microsoft Project.
<br />
<a name='more'></a>Документирование длительности проекта - это частный случай планирования сроков проекта и разработки графика. Напомню, что общее управление проектами я стараюсь выносить за рамки <a href="http://www.pmdoc.ru/tag/documenting/">этого цикла статей</a>, и описываю только состав и правила заполнения документов для управления проектами. В общем процессы разработки расписания описаны в <a href="http://marketplace.pmi.org/Pages/ProductDetail.aspx?GMProduct=00101256201">Practice Standard for Scheduling</a>, а мы задокументируем это!
<br />
<br />
<h1>
Созидание графика</h1>
Есть 4 основных способа наполнения графика проекта:
<br />
<ol>
<li>Разработка "сверху-вниз" или от общего к частному. Т.е. мы сначала разбиваем проект на крупные блоки, затем детализируем эти блоки пока не дойдём до отдельных работ.</li>
<li>Разработка "снизу-вверх" или от частного к общему. Т.е. сначала генерируется большое количество задач, которые нужно сделать, а потом они собираются в группы, подпроекты и кластера.</li>
<li>Использование готового графика подобного проекта и адаптация его под нужны и условия нашего проекта.</li>
<li>Использование шаблонов графиков и отраслевых нормативов.</li>
</ol>
Все эти способы легко комбинируются друг с другом. Вот мы и скомбинируем.<br />
<br />
На данный момент у нас уже есть <a href="http://www.pmdoc.ru/product/609/" title="ISO21500-3SCP3 «Иерархическая структура работ»">WBS</a> (после <a href="http://www.pmdoc.ru/docs_of_project_scope/" title="Документирование объёмов работ проекта">документирования объёмов работ проекта</a>), поэтому переносим её в MS Project (или подобный инструмент) и получаем отличную структурированную основу графика верхнего уровня (т.е. начинаем с первого способа). Далее, нужно каждый элемент <a href="http://www.pmdoc.ru/product/609/" title="ISO21500-3SCP3 «Иерархическая структура работ»">WBS</a> декомпозировать на мелкие элементы. И для нас нет никакой разницы, каким способом мы будем это делать. Можем для подпроектов использовать графики из прошлых проектов (способ 3), для конструктивов - шаблоны и нормативы (способ 4), а каждую фазу детализировать снизу-вверх (способ 2). Главное - в результате своей детализации дойти до отдельных работ и получить предварительный <a href="http://www.pmdoc.ru/product/611/" title="ISO21500-3SCP5 «Список операций»">Список операций</a> проекта.<br />
<br />
Но как понять нормально мы детализировали или продолжать дальше дробить задачи? Давай разберём, что такое <em>"работа"</em>.<br />
Как <strong>квант</strong> в физике - неделимая порция какой-либо величины, так и <strong>работа</strong> - это неделимая часть проекта. Для неё сохраняется чёткое правило - она выполняется одним исполнителем в один период управления.<br />
<br />
В свою очередь, размер "исполняющей бригады" и длительность управленческого периода зависят от масштаба проекта. Если проект на годы и в него вовлечено сотни человек, то исполнителем может быть целый департамент компании в лице его руководителя, а управленческий период длинной в квартал. Если проект маленький, то и исполнителем является 1 человек, а период - 1 неделя.<br />
Работа, конечно, может начаться в одном периоде, а закончится в следующем. Но она не может длиться два и более периодов. Так же придерживаемся правила одного исполнителя, чтоб избежать коллективной безответственности. Смотрим на работы длиннее нашего управленческого периода и с количеством исполнителей более одного и продолжаем декомпозицию.<br />
Понятно, что для слишком отдалённых во времени работ мы не сможем это сделать здесь и сейчас. А это и не требуется. Декомпозируйте методом набегающей волны. Можете спланировать работы на месяц-два? Планируйте! Остальные спланируете в течение этого месяца.<br />
Кроме того, поддержание равномерного <strong>периода управления</strong> - это своего рода тактовый генератор проекта. К нему, например, привязываются вехи проекта, и я не рекомендую закладывать больше двух вех в один период или выполнять проект без вех дольше двух периодов. К нему же привязывается финансирование проекта, регулярность поставок, выделение ресурсов и пр. И в этом нет ничего странного и сложного, поскольку всё наше рабочее время состоит из таких периодов - неделя, декада, месяц, квартал... Выбирайте любой период, в зависимости от масштаба нашего проекта.<br />
<br />
Итак, у нас есть <a href="http://www.pmdoc.ru/product/611/" title="ISO21500-3SCP5 «Список операций»">перечень работ</a> и есть <a href="http://www.pmdoc.ru/product/612/" title="ISO21500-4RSR1 «Требования к ресурсам»">ресурсы</a> (<em>подробнее в <a href="http://www.pmdoc.ru/docs_of_project_team/" title="Документирование команды проекта">статье "Документирование команды проекта"</a></em>). Теперь нужно определить длительности работ, расставить эти работы в логической последовательности и задокументировать связи между ними. Все работы в рамках проекта должны быть взаимосвязаны и представлены в виде сетевой диаграммы. Тогда легко определяется критический путь проекта и его общая длительность.
<br />
<br />
<table style="width: 100%px;">
<tbody>
<tr>
<td><span style="font-family: Courier New, Courier, monospace;">Шаблоны документов для разработки расписания:
</span><br />
<ul>
<li><span style="font-family: Courier New, Courier, monospace;"><a href="http://www.pmdoc.ru/product/510/" title="ПМБОК5.4.3.1 «Базовый план по содержанию»"><strong>WBS</strong> (в составе шаблона "Базовое содержание")</a>, <a href="http://www.pmdoc.ru/product/521/" title="ПМБОК6.6.3.3 «Данные расписания»"><strong>Список операций</strong>, <strong>Требования к ресурсам</strong> (в шаблоне "Данные расписания")</a> и <a href="http://www.pmdoc.ru/product/520/" title="ПМБОК6.6.3.2 «Расписание проекта»"><strong>Сетевой график</strong> (в шаблоне "Расписание проекта")</a> по PMBOK (5th edition)</span></li>
<li><span style="font-family: Courier New, Courier, monospace;"><a href="http://www.pmdoc.ru/product/609/" title="ISO21500-3SCP3 «Иерархическая структура работ»"><strong>WBS</strong></a>, <a href="http://www.pmdoc.ru/product/611/" title="ISO21500-3SCP5 «Список операций»"><strong>Список операций</strong></a>, <a href="http://www.pmdoc.ru/product/612/" title="ISO21500-4RSR1 «Требования к ресурсам»"><strong>Требования к ресурсам</strong></a> и <a href="http://www.pmdoc.ru/product/616/" title="ISO21500-5TIM1 «Расписание»"><strong>Сетевая диаграмма</strong> (в составе шаблона "Расписание")</a> по ISO 21500:2012</span></li>
</ul>
</td>
</tr>
</tbody>
</table>
Конечно же, график подготовленный в такой последовательности (<a href="http://www.pmdoc.ru/product/609/" title="ISO21500-3SCP3 «Иерархическая структура работ»">WBS</a> - <a href="http://www.pmdoc.ru/product/611/" title="ISO21500-3SCP5 «Список операций»">Список операций</a> - <a href="http://www.pmdoc.ru/product/612/" title="ISO21500-4RSR1 «Требования к ресурсам»">Ресурсы</a> - Длительности - Связи) далеко не всегда соответствует нашим ограничениям по срокам и загрузке ресурсов. Поэтому нужно "подчистить" свою работу.
<br />
<br />
<h1>
Прибрать за собой</h1>
Я не буду здесь рассказывать о всех способах сжатия и оптимизации расписания. Эти способы хорошо описаны в том же <a href="http://marketplace.pmi.org/Pages/ProductDetail.aspx?GMProduct=00101256201">Practice Standard for Scheduling</a>, в PMBOK или в любой другой литературе по управлению проектами. Я здесь расскажу об одной хитрости, как проверить качество разработки графика самим оформителем этого документа. Особенно это актуально, когда этот оформитель хорошо знает инструмент документирования (MS Project), но ничего не смыслит в технологии исполнения робот проекта.<br />
Такая ситуация встречается сплошь и рядом. Эксперты собрались, "нагенерировали" задач, предоставили какие-то куски графика, указали основные взаимосвязи, прикинули ресурсы и разошлись. Планировщик оформил всё это в одном графике, неясности уточнил у экспертов, и добился приемлемых сроков, применив методы сжатия расписания.<br />
И вроде бы, и диаграмма Гантта есть, и эксперты кивают головой (по крайнем мере каждый подтверждает свою часть графика), но как проверить, всё это в сборе взлетит или не взлетит?<br />
<br />
Итак, хитрость. Нужно просто построить S-кривую по созданному графику. Как строить кривую, смотрите в микро-видео-уроке.<br />
<center>
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="https://www.youtube.com/embed/gtuP_Iq4ccg" width="560"></iframe></center>
Смотрим на полученную S-кривую. На что она больше похожа?
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_gkj2XC9zwkqvJTB_D3wUyYNA9YaoW-3zr_IkGJ7MpGaeqFBvfOzDoMeGd4vcTrCrA-AsP-aE94NyusrmKYa8jPRa9u2NKgPpQJDF17BN8FBy5inn9eHrMwHWvLa0vtVRUP07oCXYg7E/s1600/s-curves.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_gkj2XC9zwkqvJTB_D3wUyYNA9YaoW-3zr_IkGJ7MpGaeqFBvfOzDoMeGd4vcTrCrA-AsP-aE94NyusrmKYa8jPRa9u2NKgPpQJDF17BN8FBy5inn9eHrMwHWvLa0vtVRUP07oCXYg7E/s1600/s-curves.gif" height="357" width="400" /></a></div>
<br />
<ol>
<li>Если на наклонённую букву S (вариант I), то расписание составлено правильно. У нас есть:
<ul>
<li>не очень активное начало (когда все участники ещё собираются мыслями и очень высока вероятность изменений, но изменений ещё пока на бумаге, а не на объекте);</li>
<li>быстрая реализация основной части работ;</li>
<li>и снова не очень активное планируемое завершение, которым мы сможем воспользоваться, если что-то пойдёт не так в основной части.</li>
</ul>
</li>
<li>Если вариант II, то мы спланировали <strong>аврал</strong>. Т.е. в начале есть время на раскачку, но в конце нет времени на непредвиденные ситуации.</li>
<li>Если вариант III, то мы спланировали <strong>провал</strong>. В проекте не предусмотрено время на спокойную подготовку. Все средства и ресурсы с ходу кидаются "в бой". А мы помним закон Мэрфи <em>"Если что-то может пойти не так, оно обязательно пойдет не так. Если всё идеально спланировано и ничего не может пойти не так, то появится что-то, что обязательно пойдет не так"</em>. Но на переделку этого <em>"не так"</em> уже ресурсов может не хватить.</li>
<li>Ну, и вариант IV, хорош своей равномерностью, но не лишён проблем вариантов II и III, хотя, конечно, не так ярко как в этих вариантах.</li>
</ol>
Проверив таким образом свой график, оформитель аргументированно может пообщаться с руководителем проекта и с экспертами для приведения графика в нужный формат.
<br />
<br />
<table style="width: 100%px;">
<tbody>
<tr>
<td><span style="font-family: Courier New, Courier, monospace;">Шаблоны документов расписания проекта:
</span>
<br />
<ul>
<li><span style="font-family: Courier New, Courier, monospace;"><strong><a href="http://www.pmdoc.ru/product/520/" title="ПМБОК6.6.3.2 «Расписание проекта»">Расписание проекта</a></strong> по PMBOK (5th edition)</span></li>
<li><span style="font-family: Courier New, Courier, monospace;"><strong><a href="http://www.pmdoc.ru/product/616/" title="ISO21500-5TIM1 «Расписание»">Расписание</a></strong> по ISO 21500:2012</span></li>
</ul>
</td>
</tr>
</tbody>
</table>
<br />
<h1>
Итого</h1>
С точки зрения документирования, итог планирования длительности проекта выглядит следующим образом:
<br />
<ol>
<li><a href="http://www.pmdoc.ru/product/609/" title="ISO21500-3SCP3 «Иерархическая структура работ»"><strong>WBS</strong></a>, <a href="http://www.pmdoc.ru/product/611/" title="ISO21500-3SCP5 «Список операций»"><strong>Список операций</strong></a> и <a href="http://www.pmdoc.ru/product/612/" title="ISO21500-4RSR1 «Требования к ресурсам»"><strong>Требования к ресурсам</strong></a>, полученные на этапах <a href="http://www.pmdoc.ru/docs_of_project_scope/" title="Документирование объёмов работ проекта">документирования объёмов работ</a> и <a href="http://www.pmdoc.ru/docs_of_project_team/" title="Документирование команды проекта">документирования команды</a>, и дающие нам возможность приступить к разработке расписания проекта.</li>
<li><strong>Оценка длительности операций</strong> и <strong>Последовательность операций</strong> в виде представлений «PA_PERT Entry Sheet» и «Сетевая диаграмма» в <a href="http://www.pmdoc.ru/product/616/" title="ISO21500-5TIM1 «Расписание»">файле MS Project «ISO21500-5TIM1-Расписание»</a>.</li>
<li><a href="http://www.pmdoc.ru/product/520/" title="ПМБОК6.6.3.2 «Расписание проекта»"><strong>Расписание проекта</strong></a>, которое объединяет операций проекта, длительности, зависимости и другую информацию о планировании.</li>
</ol>
<div>
<hr />
</div>
<ul>
<li>Шаблоны всех этих и других документов по управлению сроками проекта можно получить/полистать здесь:
<ul>
<li><a href="http://www.pmdoc.ru/product_tag/pmbok5tim/"><strong>ОСУП.Сроки.Комплект</strong></a> по PMBOK (5th edition).</li>
<li><a href="http://www.pmdoc.ru/product_tag/iso21500_time/"><strong>ИСО21500:Сроки</strong></a> по ISO 21500:2012.</li>
</ul>
</li>
<li>Полный пакет шаблонов, созданных на основе <a href="http://www.pmi.org/PMBOK-Guide-and-Standards/pmbok-guide.aspx">PMBOK (5-й редакции)</a> можно получить здесь: <a href="http://www.pmdoc.ru/product/pmbok_kit/" title="ОСУП.Комплект.v5"><strong>ОСУП.Комплект.v5</strong></a></li>
<li>Полный пакет шаблонов, созданных на основе <a href="http://www.iso21500.ru/">ISO 21500:2012</a> можно получить здесь: <a href="http://www.pmdoc.ru/product/iso21500/" title="ИСО21500:Комплект"><strong>ИСО21500:Комплект</strong></a></li>
<li>Все примеры и шаблоны документов портала PMDoc, связанные с управлением сроками различных проектов, можно получить здесь: <a href="http://www.pmdoc.ru/product_tag/project_time/"><strong>Сроки проекта</strong></a>.</li>
</ul>
<hr />
В следующей статье я расскажу, как документировать бюджет проекта.</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-20692373465396175612015-01-26T17:28:00.001+05:002015-01-26T17:53:15.445+05:003 способа провалить внедрение софта по управлению проектами в строительстве. <div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgAcY83eq80UhJAijbxgJIJXIWjrDskVNAN7HjeOFo4G-OuJZdKVtTgSv7-a7Ux3XOAfUAenq8gN2AqqKQvIuSMPzxr7TokGMJs_cAfNnyej_Lk_nS1UqD0uOVOEVvnsqTdzSIbBMw_oHY/s1600/IMG_5777+(1).JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgAcY83eq80UhJAijbxgJIJXIWjrDskVNAN7HjeOFo4G-OuJZdKVtTgSv7-a7Ux3XOAfUAenq8gN2AqqKQvIuSMPzxr7TokGMJs_cAfNnyej_Lk_nS1UqD0uOVOEVvnsqTdzSIbBMw_oHY/s1600/IMG_5777+(1).JPG" height="211" width="320" /></a></div>
<br />
В силу своей специализации на организации управления проектами в строительстве, я из раза в раз наблюдаю, как клиенты методично наступают на одни и те же грабли при внедрении специализированного софта по управлению строительными проектами.<br />
<br />
По моим наблюдениям компании, которые приобретают специализированный софт для управления проектами в строительстве, месяцев через 6 используют не более 5% от всего функционала. И часто это напоминает попытку забивания гвоздей микроскопом.<br />
<br />
Вот, три ключевых ошибки, которые приводят к таким печальным последствиям и их решение:<br />
<a name='more'></a><br />
1) <b>Отказаться от обучения</b>. Многие клиенты считают, что и так заплатили достаточно денег за сам софт и не готовы вкладываться в обучение сотрудников по его использованию. Если бы речь шла о чем-то стандартном типа Word или Excel, то доля правды в этом есть – сами разработчики закладывают в дизайн софта возможность обучиться интуитивно. Когда же речь идет о специализированном ПО, то вся суть кроется именно в деталях, тонких настройках, которые можно получить только от эксперта.<br />
<b><br /></b>
<b>РЕШЕНИЕ:</b> провести хотя бы минимальное вводное обучение по пользованию ПО - курс молодого бойца. Это позволит максимально сократить издержки на обучении и увеличить шансы успешного внедрения.<br />
<br />
2) <b>Отказаться от регламентации процесса планирования и контроля</b>. Во многих компаниях встречал подход, к управлению который имеет названия «Грибной». Суть этого метода заключается в следующем: «Давайте закроем их в шкафу, сверху навалим навоза, закроем дверь и подождем – авось что-то да вырастет». Не вырастет! Нужен четкий набор правил планирования и контроля, а так же люди обученные применять эти правила на практике. Из моего опыта стандартный срок привыкания к новым правилам составляет 3 месяца.<br />
<b><br /></b>
<b>РЕШЕНИЕ:</b> начать с регламента по коммуникациям т.е. описать ключевые роли на проекте и порядок передаче информации при разработке и контроле календарного графика строительства. Следующим шагом будет описание требований к самому графику. (<a href="http://www.youtube.com/watch?v=d_Rn3zKD8wA" target="_blank">Ссылка на видео о календарных графиках строительного проекта</a> )<br />
<br />
3) <b>Отказаться от роли планировщика</b>. В начале кажется, что руководители линейных подразделений способны каждый сам разработать часть календарного графика по своему виду работ и увязать в общий план. Практика показывает, что неспособны. По отдельности у всех все хорошо, но, когда пытаются собрать все в одно целое – костюмчик не получается. Обязательно должен быть планировщик, ответственный за организацию разработки календарных графиков и дальнейшый недельно-суточный контроль.<br />
<br />
<b>РЕШЕНИЕ:</b> найти планировщика на рынке, но лучше выращивать своих собственных из сотрудников отдела ПТО. (<a href="http://www.youtube.com/watch?v=k1HtSGVOxgM" target="_blank">Ссылка на видео о роли планировщика</a>)<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://sofonov.ru/pm" target="_blank"><img alt="Тренинг управлениея проектами в строительстве" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcwVR2bs8vkd0vXelDHgFxF4m5g4gnA05IQngxEs0jcvVpbNKJz_1C_FcGsmPp-CBmPinT7mAGsftPr-k_4iSyHaVlleoEcOGLvMjsb0m8ZiIicCPX2w156twtxMfeGjpGi5IZBzXAFO8/s1600/construction2.png" height="121" width="400" /></a></div>
<br />
<h3 style="text-align: center;">
<a href="http://sofonov.ru/pm" target="_blank">БЛИЖАЙШИЙ ТРЕНИНГ</a></h3>
</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-75392434281620666282015-01-26T00:02:00.001+05:002015-01-26T00:02:21.630+05:00Обучающее видео «Документирование объёмов работ проекта»<div dir="ltr" style="text-align: left;" trbidi="on">
Второй видео-урок из цикла «Документирование проектов».<br />
После того, как мы формально и документально запустили проект, нужно разобраться, как выявить все объёмы работ нашего проекта и правильно их оформить. В классике проектного управления это называется «Планирование содержания проекта». Данное видео показывает, как это «содержание» документировать.<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/xbznDmL8hFQ?feature=player_embedded' frameborder='0'></iframe></div>
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-24862829066372146272015-01-23T22:06:00.002+05:002015-01-23T22:06:44.685+05:00PMBOK на примере организации экспедиции к Эвересту<div dir="ltr" style="text-align: left;" trbidi="on">
Видеозапись семинара "Trekking Project Management" - PMBOK на примере организации экспедиции к Эвересту. Трейлер:<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/t0PRFTLnQqU?feature=player_embedded' frameborder='0'></iframe></div>
Полная запись семинара (1 час 45 мин): <a href="http://youtu.be/m2rzhnRsX2Y">http://youtu.be/m2rzhnRsX2Y</a></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-88291645167535960192015-01-17T04:12:00.000+05:002015-01-28T17:03:50.305+05:00Документирование команды проекта<div dir="ltr" style="text-align: left;" trbidi="on">
<a href="http://www.pmdoc.ru/docs_of_project_scope/" title="Документирование объёмов работ проекта">Задокументировав объёмы работ</a>, мы понимаем что и как будем делать в проекте. И теперь нужно расписать, кто это будет делать, т.е. задокументировать команду проекта, а вместе с командой определить и остальные человеческие ресурсы проекта, да и все другие ресурсы, требуемые для выполнения <a href="http://www.pmdoc.ru/docs_of_project_scope/" title="Документирование объёмов работ проекта">намеченных объёмов работ</a>.<br />
<br />
Документирование команды происходит от общего к частному, и для начала нам нужно разобраться, какие вообще ресурсы нам потребуются.
<br />
<a name='more'></a><br />
<h1>
От общего...</h1>
Продолжая декомпозировать <a href="http://www.pmdoc.ru/product/609/" title="ISO21500-3SCP3 «Иерархическая структура работ»">WBS</a> мы должны дойти до <a href="http://www.pmdoc.ru/product/611/" title="ISO21500-3SCP5 «Список операций»">списка операций</a>. О самом <a href="http://www.pmdoc.ru/product/611/" title="ISO21500-3SCP5 «Список операций»">списке операций</a>, я подробно расскажу в статье "Документирование длительности проекта"; хочется посвятить этому процессу именно отдельную статью, поскольку для данного документирования применяется особый инструмент, типа Microsoft Project. Сейчас отмечу только одно: <a href="http://www.pmdoc.ru/product/611/" title="ISO21500-3SCP5 «Список операций»">список операций</a> - один из ключевых документов в планировании проекта. На основе этого списка определяются ресурсы проекта, создаются <a href="http://www.pmdoc.ru/product/520/" title="ПМБОК6.6.3.2 «Расписание проекта»">график</a> и <a href="http://www.pmdoc.ru/product/526/" title="ПМБОК7.3.3.1 «Базовый план по стоимости»">бюджет</a> проекта.<br />
<br />
Так вот, берём <a href="http://www.pmdoc.ru/product/611/" title="ISO21500-3SCP5 «Список операций»">список операций</a> и определяем ресурсы, необходимые для каждой работы этого перечня. Ресурсы могут включать людей, финансы, сооружения, оборудование, материалы, сырьё, инфраструктуру и инструменты. Для того, чтобы каждый раз "не изобретать велосипед", желательно создать единую <a href="http://www.pmdoc.ru/product/517/" title="ПМБОК6.4.3.2 «Иерархическая структура ресурсов»">иерархическую структуру ресурсов</a> верхнего уровня для всех своих проектов и оформить её в виде шаблона. Потом просто открывать шаблон, удалять лишние группы ресурсов, а оставшиеся нужные детализировать под требования конкретного проекта. Использование <a href="http://www.pmdoc.ru/product/517/" title="ПМБОК6.4.3.2 «Иерархическая структура ресурсов»">шаблона иерархической структуры ресурсов</a> позволяет вовремя (ещё на этапе подготовки проекта) вспомнить, какие ресурсы мы ещё не предусмотрели для проекта. Так уж устроен человеческий мозг, если перед глазами промелькнёт упоминание о том, что нам может понадобиться в проекте, мы вспомним об этом, а если не промелькнёт - то узнаем о том что забыли, только во время выполнения работы, и будем как угорелые носиться и добывать нужный нам ресурс.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuZQtN5B-O7cl1AwArXhtQzE8xYESjN61PRT7ny2-BD-ZpPqRYoOcnBVcRq6PNxlIiI6TDRxYHBr220qzEIeGlCGttFgWHmtrnAot0ywCR-ziM-tD0F8l3oLA9k-eBGKi83ZU7rdADQvQ/s1600/resource_bs.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuZQtN5B-O7cl1AwArXhtQzE8xYESjN61PRT7ny2-BD-ZpPqRYoOcnBVcRq6PNxlIiI6TDRxYHBr220qzEIeGlCGttFgWHmtrnAot0ywCR-ziM-tD0F8l3oLA9k-eBGKi83ZU7rdADQvQ/s1600/resource_bs.gif" height="166" width="400" /></a></div>
Используя доступную информацию, мы рассматриваем ресурсы совместно с показателями производительности, основанными на навыках и компетентности людей, производительности машин и механизмов, или характеристиках материалов. Результаты должны быть зафиксированы <a href="http://www.pmdoc.ru/product/612/" title="ISO21500-4RSR1 «Требования к ресурсам»">документе "Требования к ресурсам"</a> с указанием размера или объёма ресурса, качества и источника происхождения, а также сроками начала и окончания использования ресурса в проекте.<br />
<br />
<a href="http://www.pmdoc.ru/product/612/" title="ISO21500-4RSR1 «Требования к ресурсам»">Требования к ресурсам</a> определяют типы и количество ресурсов, требуемых для каждой операции в пакете работ. Степень детализации и специфичности описаний <a href="http://www.pmdoc.ru/product/612/" title="ISO21500-4RSR1 «Требования к ресурсам»">требований к ресурсам</a> может различаться в зависимости от отрасли, в которой выполняется проект и масштаба самого проекта.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEAmHCUNMIhBPg01kbkzgOtLVs5P9s1lHyfYxIr317IiXKRA2VG4gzPJdfA6YS3kUZdhtEy6E6vpEf_LCyVM9I1Rsjiw7p89L2ifhe8-9-VNNfS45T7TPrtKrWtq_AiAsuIrg_kagInjw/s1600/resource_req.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEAmHCUNMIhBPg01kbkzgOtLVs5P9s1lHyfYxIr317IiXKRA2VG4gzPJdfA6YS3kUZdhtEy6E6vpEf_LCyVM9I1Rsjiw7p89L2ifhe8-9-VNNfS45T7TPrtKrWtq_AiAsuIrg_kagInjw/s1600/resource_req.gif" height="75" width="400" /></a></div>
<a href="http://www.pmdoc.ru/product/612/" title="ISO21500-4RSR1 «Требования к ресурсам»">Требования к ресурсам</a> - это хорошо. Для малых или регулярно повторяемых проектов этого документа даже достаточно, чтоб организовать поставки ресурсов в проект. Но в больших проектах часто возникает ситуация, когда логист, комплектовщик или поставщик, спрашивает ПМ-а, мол, у тебя тут написан "такой-то ресурс", а как ты планировал его раздобыть? Вот для этого мы и делаем ещё один документ, который называется <a href="http://www.pmdoc.ru/product/613/" title="ISO21500-4RSR2 «План ресурсов»">"План ресурсов"</a>, описывает способ выполнения требований к ресурсам и может включать в себя обоснование оценки каждого ресурса, а также допущения по типам ресурсов, их доступности и требуемому количеству.<br />
<br />
В состав <a href="http://www.pmdoc.ru/product/613/" title="ISO21500-4RSR2 «План ресурсов»">Плана ресурсов</a> входят следующие разделы:<br />
<ol>
<li><a href="http://www.pmdoc.ru/product/517/" title="ПМБОК6.4.3.2 «Иерархическая структура ресурсов»"><strong>Иерархическая структура ресурсов</strong></a>, идентифицированных и оформленных специально для данного проекта.</li>
<li><strong>Матрица ответственности</strong> – структура, приводящая организационную структуру проекта в соответствие с иерархической структурой работ, и помогающая назначить каждому пакету работ ответственное лицо или команду.</li>
<li><strong>Кадровое обеспечение проекта</strong>, позволяющее ответить на ряд вопросов, возникающих при планировании команды проекта, такие как:
<ul>
<li>Будут ли люди выделятся из числа сотрудников компании или привлекаться со стороны?</li>
<li>Должны ли члены команды работать в офисе или они могут работать удалённо?</li>
<li>Во сколько обойдётся привлечение людей с необходимой квалификацией?</li>
<li>Какую помощь руководителю проекта могут оказать отдел персонала и функциональные подразделения компании?</li>
<li>и т.п.</li>
</ul>
</li>
<li><strong>Календари ресурсов</strong>, описывающие необходимые сроки для членов команды проекта, индивидуально или коллективно, а также определяющие, когда должны начаться мероприятия по набору команды и какие ресурсы потенциально доступны в то время, когда запланированы операции.</li>
<li><strong>План высвобождения ресурсов</strong>, который определяет способ и время освобождения членов команды и другие ресурсы, что полезно как проекту, так и членам команды. Когда ресурсы высвобождаются из проекта, расходы, связанные с этими ресурсами не влияют на проект, что позволяет снизить стоимость проекта. Моральное состояние членов команды лучше, когда не происходит передёргивание ресурсов из одного проекта в другой, а все переходы заранее спланированы.</li>
<li><strong>План обучения персонала</strong>, включающий пути помощи членам команды в получении необходимых компетенций и сертификатов, которые будут приносить пользу проекту.</li>
<li><strong>Признание и поощрения</strong>, содержащие критерии для поощрений и описание планируемой системы их использования, что способствует развитию и укреплению желаемого поведения. Установление чётких периодов распределения поощрений гарантирует, что признание и поощрение не будет забыто. Поощряться должно только желательное поведение. Люди мотивированы, если они чувствуют, что их ценят в компании, и это подтверждается наградами полученными ими.</li>
<li><strong>Соответствие</strong>, содержащее описание стратегий выполнения нормативных актов, государственных законов, а также других установленных правил отбора и найма персонала.</li>
<li><strong>Безопасность</strong>, содержащая описание политик и процедур, которые защищают членов команды от угроз безопасности.</li>
</ol>
<table style="width: 100%px;">
<tbody>
<tr>
<td><span style="font-family: Courier New, Courier, monospace;">Шаблоны документов по общему описанию ресурсов:
</span><br />
<ul>
<li><span style="font-family: Courier New, Courier, monospace;"><a href="http://www.pmdoc.ru/product/521/" title="ПМБОК6.6.3.3 «Данные расписания»"><strong>Требования к ресурсам операций</strong> в составе шаблона "Данные расписания"</a> и <a href="http://www.pmdoc.ru/product/532/" title="ПМБОК9.1.3.1 «План управления человеческими ресурсами»"><strong>План управления человеческими ресурсами</strong></a> по PMBOK (5th edition)</span></li>
<li><span style="font-family: Courier New, Courier, monospace;"><a href="http://www.pmdoc.ru/product/612/" title="ISO21500-4RSR1 «Требования к ресурсам»"><strong>Требования к ресурсам</strong></a> и <a href="http://www.pmdoc.ru/product/613/" title="ISO21500-4RSR2 «План ресурсов»"><strong>План ресурсов</strong></a> по ISO 21500:2012</span></li>
</ul>
</td>
</tr>
</tbody>
</table>
Таким образом, мы в общем описали все ресурсы, необходимые для проекта, и процесс их получения в проект, но проекты исполняют <strong>люди</strong>! Ни компьютеры, ни документы, ни процессы, ни машины и механизмы, а именно <strong>ЛЮДИ</strong>! А слаженная работа команды проекта и участие в проекте ключевых заинтересованных сторон – залог успешного выполнения проекта, достижения ожидаемых результатов и принятия этих результатов заказчиками.<br />
<br />
Так давайте задокументируем команду нашего проекта!
<br />
<br />
<h1>
... к частному</h1>
На долю руководителя проекта выпадают задачи управления командой, её развития, улаживания внутренних конфликтов, а также управления ожиданиями заинтересованных сторон — он фактически принимает роль посредника между командой и стейкхолдерами. Поэтому необходимо добиться исполнения всех обязательств от всех сторон, вовлечённых в проект. Роли, обязанности и полномочия соответствующие проекту, должны быть определены в соответствии с его сущностью и сложностью и с учетом кадровой политики компании.<br />
<br />
Поэтому начинаем с документирования <a href="http://www.pmdoc.ru/product/615/" title="ISO21500-4RSR4 «Организационная диаграмма проекта»">организационной структуры</a>, т.е. выявления и описания всех членов команды и других лиц, непосредственно участвующих в работах по проекту. Хотя этот процесс включает в себя назначение обязанностей и полномочий в рамках проекта, наша тема включает только документирование, и мы остановимся только на документальном закреплении этих обязанностей и полномочий, которые могут быть определены на уровне проекта, пакетов работ или конечных работ.<br />
<br />
Ты, конечно же, по помнишь, что костяк команды мы <a href="http://www.pmdoc.ru/docs_of_project_start/" title="Документирование проекта на старте">уже оформили на этапе старта проекта</a>, здесь мы углубляем и расширяем нашу команду всеми известными на данный момент ролями, и, при необходимости, создаём дополнительные <a href="http://www.pmdoc.ru/product/547/" title="ПМБОК9.2.3.1 «Приказ о назначении персонала проекта»">Приказы о назначении персонала</a> и <a href="http://www.pmdoc.ru/product/606/" title="ISO21500-1INI6 «Трудовой договор»">Трудовой контракт</a>. Подробнее об этих документах читай в <a href="http://www.pmdoc.ru/docs_of_project_start/" title="Документирование проекта на старте">статье "Документирование проекта на старте"</a>. Так как проекты, как правило, выполняются в постоянно изменяющихся условиях, процесс формирования команды проекта обычно выполняется непрерывно на протяжении всего проекта.<br />
<br />
<a href="http://www.pmdoc.ru/product/615/" title="ISO21500-4RSR4 «Организационная диаграмма проекта»">Организационная диаграмма проекта</a> – это графическое представление состава команды проекта и отношения между её членами. В зависимости от потребностей проекта она может быть официальной или неофициальной, подробной или обобщенной. Используется эта диаграмма для определения команды проекта, количества персонала, задействованного в проекте; выравнивания персонала в расписании, а также для разработки <a href="http://www.pmdoc.ru/product/533/" title="ПМБОК10.1.3.1 «План управления коммуникациями»">Плана коммуникаций в проекте</a>.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOGJqUafj5rgTm1SKb12gKO2Z99OdSIFRyg4xNb6bcS8THo5YJJ5EvJK9EdK_5crME9oBCzTiJ9m1ZsHHUBkrMfXRTPtI784VqiNCGTETQFEZBEvK6EXFI4rmqRzkXKIrkdU-lkLKnO5A/s1600/obs.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOGJqUafj5rgTm1SKb12gKO2Z99OdSIFRyg4xNb6bcS8THo5YJJ5EvJK9EdK_5crME9oBCzTiJ9m1ZsHHUBkrMfXRTPtI784VqiNCGTETQFEZBEvK6EXFI4rmqRzkXKIrkdU-lkLKnO5A/s1600/obs.gif" height="211" width="400" /></a></div>
А вот теперь самое интересное! На данный момент у нас уже оформлены <a href="http://www.pmdoc.ru/product/609/" title="ISO21500-3SCP3 «Иерархическая структура работ»">Иерархическая структура работ</a>, <a href="http://www.pmdoc.ru/product/615/" title="ISO21500-4RSR4 «Организационная диаграмма проекта»">Организационная диаграмма проекта</a> и, связывающая их, <a href="http://www.pmdoc.ru/product/421/" title="ОУП-ОД-МО «Матрица ответственности»">Матрица ответственности</a>.<br />
<br />
Всё это - красивые рисунки и таблички, красноречиво говорящие о высоком уровне зрелости системы документирования в компании, <b><i>но сами по себе не несущие никакой пользы проекту</i></b>. И тут на сцену выходит <u>реально работающий документ</u>, который связывает все предыдущие документы с <strong>живым человеком</strong>, который в нашем проекте будет выполнять некую роль. Причём это не один документ, это ворох документов под общим названием <a href="http://www.pmdoc.ru/product/614/" title="ISO21500-4RSR3 «Описание роли»">"Ролевые инструкции"</a>, а количество документов в этом ворохе равно количеству ролей в нашем проекта.<br />
<br />
<a href="http://www.pmdoc.ru/product/614/" title="ISO21500-4RSR3 «Описание роли»">Данный документ</a> представляет собой текстовое описание роли и готовится на каждую роль, исполняемую командой проекта и обозначенную в <a href="http://www.pmdoc.ru/product/615/" title="ISO21500-4RSR4 «Организационная диаграмма проекта»">Организационной диаграмме проекта</a>. Информация об ответственности, полномочиях, компетенции и квалификации приводится обычно в общих чертах. Роли в проекте могут быть определены как для отдельных лиц, так и для групп. Эти лица или группы могут быть сотрудниками нашей компании или внештатниками и подрядчиками. Заполненные ролевые инструкции передаются соответствующим участникам проекта и являются для них <a href="http://www.pmdoc.ru/product/502/" title="ПМБОК4.1.3.1 «Устав проекта»">микро-уставом</a> по реализации их микро-проекта в составе нашего большого проекта.<br />
<br />
Цель данного документирования - чтоб у каждого пакета работ был однозначный владелец, и чтобы все члены команды имели четкое представление об их роли, ответственности и полномочиях.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihXZi6eLbmFD-y8Ujasit6LtWfZ2fmVaaGmVM5gQpzTx-WPNOS6jrn6wNZK1XFiBGoqI0dJ3T4Loh5A6Z-sPwyya0GQ9MaeXuRjKFSOtcfpfPZusaZdJNcJ5VBAB8xNMRyOg6zehlushE/s1600/roles.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihXZi6eLbmFD-y8Ujasit6LtWfZ2fmVaaGmVM5gQpzTx-WPNOS6jrn6wNZK1XFiBGoqI0dJ3T4Loh5A6Z-sPwyya0GQ9MaeXuRjKFSOtcfpfPZusaZdJNcJ5VBAB8xNMRyOg6zehlushE/s1600/roles.gif" height="251" width="400" /></a></div>
А теперь представь, что ты описал ответственность и полномочия для каждой роли. Более того, согласовал эти ролевые инструкции друг с другом, т.е. если в полномочия одной роли входит, например, требовать предоставления информации и консультаций от другой роли, то в обязанности этой "другой роли" необходимо внести это "предоставление". Таким образом проектный менеджер организовывает "круговую поруку" проекта, где каждый каждому что-то обязан и имеет полномочия получать. В итоге у руководителя проекта высвобождается куча времени на действительно важные вопросы проекта, а не на разруливание мелких противоречий во взаимоотношениях команды.<br />
<br />
<table style="width: 100%px;">
<tbody>
<tr>
<td><span style="font-family: Courier New, Courier, monospace;">Шаблоны документов для описанию команды проекта:
</span><br />
<ul>
<li><span style="font-family: Courier New, Courier, monospace;"><a href="http://www.pmdoc.ru/product/532/" title="ПМБОК9.1.3.1 «План управления человеческими ресурсами»"><strong>Организационная диаграмма проекта</strong> и <strong>Роли и сферы ответственности</strong> в составе шаблона "План управления человеческими ресурсами"</a> по PMBOK (5th edition)</span></li>
<li><span style="font-family: Courier New, Courier, monospace;"><a href="http://www.pmdoc.ru/product/615/" title="ISO21500-4RSR4 «Организационная диаграмма проекта»"><strong>Организационная диаграмма проекта</strong></a> и <a href="http://www.pmdoc.ru/product/614/" title="ISO21500-4RSR3 «Описание роли»"><strong>Описание роли</strong></a> по ISO 21500:2012</span></li>
</ul>
</td>
</tr>
</tbody>
</table>
<h1>
Итого</h1>
С точки зрения документирования, итог планирования ресурсов и команды проекта выглядит следующим образом:
<br />
<ol>
<li><a href="http://www.pmdoc.ru/product/612/" title="ISO21500-4RSR1 «Требования к ресурсам»"><strong>Требования к ресурсам</strong></a> и <a href="http://www.pmdoc.ru/product/532/" title="ПМБОК9.1.3.1 «План управления человеческими ресурсами»"><strong>План ресурсов</strong></a>, дающие полное описание того, какие ресурсы понадобятся для проекта, и каким образом они будут получены в проект.</li>
<li><a href="http://www.pmdoc.ru/product/615/" title="ISO21500-4RSR4 «Организационная диаграмма проекта»"><strong>Организационная диаграмма проекта</strong></a> и <a href="http://www.pmdoc.ru/product/614/" title="ISO21500-4RSR3 «Описание роли»"><strong>Описание ролей</strong></a>, документирующие команду проекта и определяющие полномочия и обязанности членов команды.</li>
<li><a href="http://www.pmdoc.ru/product/547/" title="ПМБОК9.2.3.1 «Приказ о назначении персонала проекта»"><strong>Приказы о назначении персонала</strong></a> и <a href="http://www.pmdoc.ru/product/606/" title="ISO21500-1INI6 «Трудовой договор»"><strong>Трудовые контракты</strong></a>, легализующие роботу сотрудников в компании в целом и над проектом в частности.</li>
</ol>
<div>
<br /></div>
<hr />
<ul>
<li><span style="font-family: Courier New, Courier, monospace;">Шаблоны всех этих документов можно получить/полистать здесь:
</span><ul>
<li><span style="font-family: Courier New, Courier, monospace;"><a href="http://www.pmdoc.ru/product_tag/pmbok5hrm/"><strong>ОСУП.ЧР.Комплект</strong></a> по PMBOK (5th edition).</span></li>
<li><span style="font-family: Courier New, Courier, monospace;"><a href="http://www.pmdoc.ru/product_tag/iso21500_resource/"><strong>ИСО21500:Ресурсы</strong></a> по ISO 21500:2012.</span></li>
</ul>
</li>
<li><span style="font-family: Courier New, Courier, monospace;">Полный пакет шаблонов, созданных на основе <a href="http://www.pmi.org/PMBOK-Guide-and-Standards/pmbok-guide.aspx">PMBOK (5-й редакции)</a> можно получить здесь: <a href="http://www.pmdoc.ru/product/pmbok_kit/" title="ОСУП.Комплект.v5"><strong>ОСУП.Комплект.v5</strong></a></span></li>
<li><span style="font-family: Courier New, Courier, monospace;">Полный пакет шаблонов, созданных на основе <a href="http://www.iso21500.ru/">ISO 21500:2012</a> можно получить здесь: <a href="http://www.pmdoc.ru/product/iso21500/" title="ИСО21500:Комплект"><strong>ИСО21500:Комплект</strong></a></span></li>
<li><span style="font-family: Courier New, Courier, monospace;">Все примеры и шаблоны документов портала PMDoc, связанные с управлением человеческими ресурсами различных проектов, можно получить здесь: <a href="http://www.pmdoc.ru/product_tag/human_resources/"><strong>Человеческие ресурсы</strong></a>.</span></li>
</ul>
</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-40700627388477262432015-01-14T18:22:00.000+05:002015-01-14T18:25:40.648+05:00Прокачай команду проекта<div dir="ltr" style="text-align: left;" trbidi="on">
<big><b>
Курс «погружения» команды в условия реального проекта</b></big><br />
<br />
В "жирные" времена можно позволить команде проекта, притираться друг к другу по ходу проекта. Даже если они что-то испортят, в силу того что ещё не сработались - достигнутый результат проекта всё спишет.<br />
В кризисный период, разрешать команде "тренироваться" за счёт бюджета проекта - непозволительная роскошь, а проекты реализовывать всё равно как-то нужно. И если у вас намечается сложный и важный проект, то вам критически необходимо сформировать правильную команду и организовать командную работу так, чтоб не нужно было подгонять, переделывать работу и терять время на деструктивные конфликты.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8g5PZS7ucrHPdSO3IAU9Pw8H-sSQO7-_26KVOuYvcPdnO6hcrZEBEK9UxFCSGepU0MFOzDXAelTo6GwwRdtZpTblG8n7hyphenhyphenI1T7IdODkowmJsCMI88Hkl6rAXuHIGTEBl_dKPoX0-tC8g/s1600/IMG_7631.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8g5PZS7ucrHPdSO3IAU9Pw8H-sSQO7-_26KVOuYvcPdnO6hcrZEBEK9UxFCSGepU0MFOzDXAelTo6GwwRdtZpTblG8n7hyphenhyphenI1T7IdODkowmJsCMI88Hkl6rAXuHIGTEBl_dKPoX0-tC8g/s1600/IMG_7631.jpg" height="215" width="400" /></a></div>
А хотелось бы сформировать именно такую команду, и ещё и взглянуть на её поведение прежде, чем доверить ей проект?<br />
<a name='more'></a><br />
Такую возможность вам представляет <a href="http://www.pmdoc.ru/education-by-expedition/teambuilding_attack/" target="_blank">тренинг <strong>«Прокачай команду проекта»</strong></a>. По сути это тот же тренинг, что <a href="http://www.pmdoc.ru/education-by-expedition-%D0%BD%D0%B0-%D0%B2%D0%B5%D1%80%D1%88%D0%B8%D0%BD%D0%B5-%D0%B2%D0%BE%D0%BB%D0%BE%D0%B2%D1%86%D0%B0/" target="_blank">мы проводим в Польше</a>, но с некоторыми значительными изменениями:<br />
<ol>
<li>Это только корпоративный тренинг. В сборном варианте его смысл полностью теряется.</li>
<li>Работа с заказчиком начинается за несколько недель до тренинга. За это время мы узнаём всё о планируемом проекте, проводим тестирование участников и корректируем программу обучения.</li>
<li>Тренинг в классе проходит с более глубоким изучением методологии и инструментов Управления Проектами. Более того, для обучения применяются именно те подходы и инструменты, которые потом будут использоваться для реального проекта.</li>
<li>Подготовка и проведение экспедиции, занимает не 1-2 дня, а как минимум неделю.</li>
<li>Уроки опыта после тренинга и экспедиции включают не только рекомендации участникам, но и корректировку команды для будущего проекта заказчика.</li>
</ol>
<div>
Подробнее о тренинге читайте здесь: <a href="http://www.pmdoc.ru/education-by-expedition/teambuilding_attack">www.pmdoc.ru/education-by-expedition/teambuilding_attack</a>.</div>
<div>
Интересно? Обращайтесь - <a href="mailto:anatoly@savin.pm">anatoly@savin.pm</a></div>
</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-71070169748549835952015-01-12T23:38:00.000+05:002015-01-13T01:19:06.308+05:00Виды запросов на изменения<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6Ei1Lhjpg1t-rTb_5pLs93PdtaXNSse8o-_aEl1YYT3KXf7RPnF1JPACPcrAjYD7mVrbuMMthETFLy_xIdZ-9MmCRxSqa3G3s8_CFWExJf_rKbC5e9vNvZgFtiMQaJU6fvf5mDOvza-k/s1600/change_requests.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6Ei1Lhjpg1t-rTb_5pLs93PdtaXNSse8o-_aEl1YYT3KXf7RPnF1JPACPcrAjYD7mVrbuMMthETFLy_xIdZ-9MmCRxSqa3G3s8_CFWExJf_rKbC5e9vNvZgFtiMQaJU6fvf5mDOvza-k/s1600/change_requests.gif" height="186" width="400" /></a></div>
Как-то меня на тренинге студенты начали "тиранить", чем же отличаются друг от друга запросы на изменения, описанные в PMBOK. Пришлось нарисовать им такую таблицу.<br />
Как говорит сам PMBOK - "<i>Запросы на изменения ... могут включать в себя:</i><br />
<a name='more'></a><br />
<br />
<ul style="text-align: left;">
<li><i><b><i style="font-weight: normal;"><b>Обновления </b>— изменения формально контролируемых документов, планов проекта и т.д., отражающие модифицированные либо дополнительные идеи или содержание.</i></b></i></li>
<li><i><b>Предупреждающее действие</b> — намеренное действие, обеспечивающее соответствие будущего исполнения работ проекта плану управления проектом.</i></li>
<li><i><b>Корректирующее воздействие</b> — намеренное действие с целью привести исполнение работ проекта в соответствие с планом управления проектом.</i></li>
<li><i><b>Исправление дефекта</b> — намеренное действие с целью исправления несоответствующего требованиям продукта или компонента продукта.</i>"</li>
</ul>
Расшифровка таблицы:<br />
<div>
<br />
<ul style="text-align: left;">
<li>Change Request (CR) НЕ нужен только для <b>Обновлений</b>.</li>
<li><b>Обновления </b>- это уровень исполнителей, <b>Предупреждающие действия (ПД)</b> - уровень команды управления проектом, <b>Корректирующие воздействия (КВ)</b> - уровень ПМа, <b>Исправления дефектов (ИД)</b> - уровень спонсора.</li>
<li><b>Обновления</b> ни на что не влияют, <b>ПД</b> влияют на оставшуюся часть проекта, <b>КВ</b> - на запланированные резервы, <b>ИД</b> - на базовые планы проекта.</li>
<li>Источником <b>Обновлений</b> являются мелкие ошибки, <b>ПД</b> - небольшие отклонения, <b>КВ</b> - непредвиденные обстоятельства, <b>ИД</b> - грубые ошибки.</li>
</ul>
</div>
<div>
<br /></div>
<div>
Добавите что-нибудь?</div>
</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-66046863880028312462015-01-02T14:55:00.004+05:002015-01-02T15:07:27.306+05:00<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfnwcPpt_RBMeRjQnBcmuLV_ezJxjcYSowx2-vnnWgmva84Hn33nI2BcLMS9aCcpjrYBwiYu70hgycZ7Bzto1yDB8KH6BSsOdi3mg_EUpTQcFI08RMac9-oQHuVOzsRUqf6Fdhfoq4kvw/s1600/IMG_5884.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfnwcPpt_RBMeRjQnBcmuLV_ezJxjcYSowx2-vnnWgmva84Hn33nI2BcLMS9aCcpjrYBwiYu70hgycZ7Bzto1yDB8KH6BSsOdi3mg_EUpTQcFI08RMac9-oQHuVOzsRUqf6Fdhfoq4kvw/s1600/IMG_5884.JPG" height="256" width="320" /></a></div>
<br />
Коллеги, подзравляю вас с наступившим 2015 годом! Желаю вам профессиональных успехов и побольше сложных и интересных проектов!!!</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-75257848765015447142014-12-23T09:45:00.000+05:002014-12-23T10:05:34.477+05:00Дайджест статей в проектных блогах<div dir="ltr" style="text-align: left;" trbidi="on">
Обзор самых интересных статей в проектных блогах.<br />
<br />
<a name='more'></a><br />
<br />
<a href="http://www.promspecialist.ru/2014/12/baseschedule.html">Базовая модель календарного графика строительного проекта</a><br />
Михаил Софонов (Project Management Professional) рассуждает о корпоративных правилах календарного планирования строительных проектов и не на уровне шаманства групп процессов PMBoK, а нормальным, понятным языком для производственников.<br />
<br />
<a href="http://msprojectdownload.blogspot.ru/2014/12/turboplanner.html">Как правильно установить Turbo Planner для Microsoft Project</a><br />
Вадим Геря (Microsoft Most Valuable Professional по MS Project) написал подробный материалы как правильно установить Turbo Planner, который является отраслевым решением для управления строительным проектами на базе Microsoft Project расширяя его функциональность на управление рентабельностью и ресурсными нормами. Теперь загрузка демоверсии открыта свободно для всех пользователей MicrosoftProject.ru<br />
<br />
<a href="http://www.promspecialist.ru/2014/12/shagi-vnedrenia-up-v-stroitelnoj-organizacii.html">Что делать, когда с планированием на стройке совсем все плохо?</a><br />
Для большинства строительных компаний, представленных на рынке вопросы финансового планирования в большей степени решены т.к. в противном случае они уже давно бы получили «ранение» в виде кассового разрыва, несовместимого с дальнейшей оперативной деятельностью.<br />
<br />
<a href="http://www.promspecialist.ru/2014/12/Metod-cenoobrazovanija-struktura-kalendarnogo-grafika-stroitelnogo-proekta.html">Как метод ценообразования влияет на структуру календарного графика строительного проекта.</a><br />
При моделировании графика строительного проекта обычно рассматриваю множество факторов кторые выступают как ограничения.<br />
<div>
<br />
<a href="http://www.promspecialist.ru/2014/12/statusreport.html">Отчет о ходе проекта на одной странице</a><br />
Простой формой о ходе проекта, которую может использовать руководитель проекта при создании отчета для Заказчика проекта.<br />
<br />
<a href="http://www.promspecialist.ru/2014/12/gameplanner.html">Какой ноутбук подарить планировщику на Новый Год? </a><br />
Планировщик ключевая роль в управлении промышленным проектом. Новый Год хороший повод подарить ему хорошее рабочее место.</div>
</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-54918862898120538882014-12-22T23:49:00.000+05:002014-12-22T23:49:05.043+05:00Обучающее видео «Документирование проекта на старте»<div dir="ltr" style="text-align: left;" trbidi="on">
Обучающее видео из цикла "Документирование проектов".<br />
Запуская новые проекты, мы часто задаёмся вопросом – С чего начать? На самом деле всё просто. Существует отличное правило: «Хочешь разобраться со своими мыслями – впиши их в бумагу». Так и с проектами, хочешь запустить новый проект – начни выражать свои идеи о проекте буквенно-цифровым и графическим способом...<br />
<div class="separator" style="clear: both; text-align: center;">
<object width="320" height="266" class="BLOGGER-youtube-video" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0" data-thumbnail-src="https://i.ytimg.com/vi/GdQuz_F4gWM/0.jpg"><param name="movie" value="https://www.youtube.com/v/GdQuz_F4gWM?version=3&f=user_uploads&c=google-webdrive-0&app=youtube_gdata" /><param name="bgcolor" value="#FFFFFF" /><param name="allowFullScreen" value="true" /><embed width="320" height="266" src="https://www.youtube.com/v/GdQuz_F4gWM?version=3&f=user_uploads&c=google-webdrive-0&app=youtube_gdata" type="application/x-shockwave-flash" allowfullscreen="true"></embed></object></div>
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-96482047491223867.post-78028267468301638402014-12-21T08:27:00.000+05:002014-12-22T10:18:53.123+05:00Нас не догонят: 10.000 профессионалов в Facebook+LinkedIn<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
В 2014 году произошло событие, которое вероятно определит как будут развиваться Сообщества профессионалов в Управлении проектами на 10 лет вперед. Произошло формирование ядра Сообществ. Многие компании и организации уже упустили свой шанс войти в этот процесс и это скажется на них в будущие годы и я поясню ниже почему и упустили и почему скажется. Также разобьем мифы, что "серьезные люди" не сидят в Социальных Сообществах и покажем, что не только они там находятся, но Facebook и LinkedIn предпринимают усилия их собрать вместе, причем в нужном месте.<br />
<br />
Прежде всего отметим, что нам удалось захватить лидерство в этих процессах и организовать комбинированное Сообщество по управлению промышленными проектами более чем на 10.000 профессионалов (<a href="https://www.facebook.com/groups/msproject/" target="_blank">5700 в Сообществе Facebook</a> и <a href="https://www.linkedin.com/groups?gid=6666684" target="_blank">4370 в Сообществе LinkedIn</a>)<br />
<br />
Тут даже важно не количество, а <b>качество аудитории</b> и <b>откуда она берется</b>. Изучение этого показывает, что нас ждут серьезные изменения. Давайте разберемся.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmoTD2Nje0lVyut5XVw14qBkwMTr7jzKtzQ62R9izDqrfS2PkSpNn5XT1zQbHlMubV7ZqxukAb8rsJdWTYlQLK_0TEcWhQtvrxxo_-wumpoi75YN4JFHb92IY_wm7T1v7mDlBYjdNniOqY/s1600/link.gif" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmoTD2Nje0lVyut5XVw14qBkwMTr7jzKtzQ62R9izDqrfS2PkSpNn5XT1zQbHlMubV7ZqxukAb8rsJdWTYlQLK_0TEcWhQtvrxxo_-wumpoi75YN4JFHb92IY_wm7T1v7mDlBYjdNniOqY/s1600/link.gif" height="297" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">LinkedIn получил новый алгоритм приглашение в Сообщество по профессиональному интересу и служебному положению</td></tr>
</tbody></table>
<br />
<a name='more'></a><br />
Прежде всего стоит отметить, что рост групп в LinkedIn и Facebook замедлился, при этом профессиональный вес и авторитет участников увеличился. Это связано с новыми алгоритмами приглашения в группу в социальных сетях.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjc_T3JHFpk4gWoCqHn3V4YIn7rJiMD350G6EMtUIUd07mDlkvmH49qNwIYh99zvjIkF1-fkWLNM6XjuW2uQAKmrUhXIun1KXdG3Pw2HPQXxVlCA3v_HWhwr1J6KpDBMYHaeLYJEjn2rpxl/s1600/face.gif" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjc_T3JHFpk4gWoCqHn3V4YIn7rJiMD350G6EMtUIUd07mDlkvmH49qNwIYh99zvjIkF1-fkWLNM6XjuW2uQAKmrUhXIun1KXdG3Pw2HPQXxVlCA3v_HWhwr1J6KpDBMYHaeLYJEjn2rpxl/s1600/face.gif" height="247" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="font-size: 12.6666669845581px;">Facebook также внедрил алгоритм на изучение профиля профессиональных интересов и приглашения в Группы на базе отрасли и должностного положения<br />
<div>
<br /></div>
</td></tr>
</tbody></table>
В LinkedIn группы неявно делятся на "отстойники" без заточки в отрасль и тип решений. Но если каким-либо образом собираются люди примерно одинаковой отрасли и профессиональных интересов, то LinkedIn считает группу отраслевой и начинает искать среди знакомых уже присоединившихся участников людей из этой же отрасли и такого же статуса. Это снижает скорость роста группы в абсолютных показателях, но происходит "накачивание" группы тяжелыми менеджерами и экспертами из направления, которое нужно основателю группы (если конечно он думает об дифференцированности интересов участников). Как видно по карточке нашей группы LinkedIn она не только выросла за несколько месяцев до 4360 участников, но что важнее видно как быстро увеличивается доля строителей и нефтяников по сравнению с <a href="https://www.linkedin.com/pulse/20141114044825-52165615-%D0%BF%D1%80%D0%BE%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5-%D0%B3%D1%80%D1%83%D0%BF%D0%BF%D1%8B-%D0%BF%D0%BE-%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8E-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8" target="_blank">предыдущими отчетами</a>. Аналогично растет доля и лиц принимающих решения. Чем их больше, чем больше LinkedIn получает в руки "карту социальных связей участников группы" и тем более богатый имеет в выбор в ней и более точно ищет новых участников.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEio-KzlvEyI6dNt6E23Cw8YceUxxbjv4cJCNrpSiq6KeorqTYBF17Urq0Rm9MRvREBXnJAz6gS5RQ_mC6v4v84KrQApSTF5jJGraukWc_5Iw5TGuYclZPj4wsDnmw52q3d0f9gOwqjqyLiW/s1600/397218e.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEio-KzlvEyI6dNt6E23Cw8YceUxxbjv4cJCNrpSiq6KeorqTYBF17Urq0Rm9MRvREBXnJAz6gS5RQ_mC6v4v84KrQApSTF5jJGraukWc_5Iw5TGuYclZPj4wsDnmw52q3d0f9gOwqjqyLiW/s1600/397218e.jpg" height="157" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Если организатор Сообщества изначально делает фокус в лиц принимающих решение (слева), то число влиятельных менеджеров и экспертов будет увеличиваться относительно средних показателей (справа)</td></tr>
</tbody></table>
<br />
<br />
Если вы еще не догадались социальные сети делают дьявольскую вещь. Они обладают алгоритмом автоматического роста групп в геометрической прогрессии и с учетом отраслевого и профессионального фокуса. Второй фактор сдерживает просто взрывообразный рост Сообществ, но удерживает качество участников исходя из общих интересов.<br />
<br />
Если посмотреть в Facebook там происходит тоже самое. Недавно Facebook внедрил "профессиональные профили", с которыми могу работать партнеры Facebook. Хотя вы не заполняете анкету как LinkedIn, но Facebook аккуратно запоминает к какой отрасли и сфере интересов относятся материалы, которые вы лайкаете. "Профессиональные профили" используются также для формирования профессионального профиля группы целиком и поиска по друзьям участников группы тех, кто подходит по такому профилю, затем ему появляется приглашение на вступление.<br />
<br />
Выше опрос в нашей группе Facebook на 5700 профессионалов. Как видите довольно сходная картина с LinkedIn. Мы собрали вокруг себя профессионалов в промышленных проектах, а также в крупном IT.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYiZcInbtGjz3DJkWxUgeX8Y5APXTuTzEWMzdczBSOek02mwrhojkyMP1oSKPEAAVBInIPz0kNQ_yGeeOruJgqwemBbaVHXlPmZ-Nm4MEbgqVoOWrX_CaTJTe-sSM1GIdmBWMEdqMftyBw/s1600/facepos.gif" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYiZcInbtGjz3DJkWxUgeX8Y5APXTuTzEWMzdczBSOek02mwrhojkyMP1oSKPEAAVBInIPz0kNQ_yGeeOruJgqwemBbaVHXlPmZ-Nm4MEbgqVoOWrX_CaTJTe-sSM1GIdmBWMEdqMftyBw/s1600/facepos.gif" height="220" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Наше Сообщество в Facebook, как и в LinkedIn, в большей степени представлено среднем и высшим менеджеров</td></tr>
</tbody></table>
<br />
<div class="separator" style="clear: both; text-align: left;">
Google также сильно участвует в социальном поле через YouTube. Но давайте приглядимся к тому откуда берутся посетили на <a href="http://www.youtube.com/user/MicrosoftProjectRU" target="_blank">каналах YouTube по управлению проектами</a> и заметим сходные моменты с LinkedIn и Facebook.</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiI5_q07kORmAYAP4vzxHT7Szk_712xfqOLgLpWQUabO-_Buo1IEsG9JVuQdN0B08ITo-twpIB-26opgMomXOQUZoTjCUc3XCWwP0VXoLLwho-KQ_pUpd960fvaCEGLsINOC36pkkZwoCWH/s1600/youtube.gif" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiI5_q07kORmAYAP4vzxHT7Szk_712xfqOLgLpWQUabO-_Buo1IEsG9JVuQdN0B08ITo-twpIB-26opgMomXOQUZoTjCUc3XCWwP0VXoLLwho-KQ_pUpd960fvaCEGLsINOC36pkkZwoCWH/s1600/youtube.gif" height="212" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">YouTube догадывается кому интересно видео и предлагает его сам</td></tr>
</tbody></table>
<div>
Если вы поглядите на картинку с источником посещений, то увидите, что профессионалы изучающие Управление проектами на нашем канале берутся не столько с сайта MicrosoftProject.ru, сколько... из самого YouTube. Аналогично Facebook и LinkedIn работает алгоритм изучения интересов тех кто смотрит видео и неявно формируется постоянно растущее "Видеосообщество". В числе подписчиков оно перевалило за 4000 профессионалов, но если Вы еще не поняли, видео с канала Google демонстрируются и рекомендуются их друзьям и коллегам, поэтому общее число просмотров далеко за 640 тысяч.</div>
<div>
<br /></div>
<div>
Давайте еще пример. Наша <a href="http://slideshare.net/msproject" target="_blank">коллекция презентаций по управлению проектами на SlideShare</a> весьма популярна только в этом году около 50.000 профессионалов ей воспользовались. Откуда они взялись? Если посмотреть на статистику, то видим ту же картину, что на YouTube. Презентации предлагаются друзьям подписчиков вашего канала презентаций через "похожие презентации" и через поиск в SlideShare.</div>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtxhWINXMVsqsPNMk6S77v4ZuZd8_wRE8uDZX70saYjr9HGQKRM4f5FAyUAgiqKDRn1rlMl0uddfVskK9_PJJQRIzN6iNkj4_7qg-uugBYlcJ1jnvhEZu91Lvp94q1CDS3olUlVcMDCYmh/s1600/slideshare.gif" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtxhWINXMVsqsPNMk6S77v4ZuZd8_wRE8uDZX70saYjr9HGQKRM4f5FAyUAgiqKDRn1rlMl0uddfVskK9_PJJQRIzN6iNkj4_7qg-uugBYlcJ1jnvhEZu91Lvp94q1CDS3olUlVcMDCYmh/s1600/slideshare.gif" height="215" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">SlideShare также ищет среди друзей подписчиков тех, кому интересны ваши материалы</td></tr>
</tbody></table>
<br />
Как видим Facebook, LinkedIn, Google и SlideShare запустили автоматических спрутов, которые своими щупальцами сканируют сети знакомств участников и подписчиков и определив профиль интересов приглашают вам очень селектированно нужных людей.<br />
<br />
Однако такой механизм буде работать не всегда, т.к. требуется выполнение нескольких условий:<br />
<br />
<ul style="text-align: left;">
<li><b>Наличие "критического ядра" подписчиков</b>. Это где-то 1000 профессионалов для Facebook, LinkedIn и Youtube и около 500 профи для SlideShare. Если ядро меньше, то слишком мала стартовая выборка для алгоритма автоматического роста Сообщества. В результате многие сообщества скатываются до 100-200 человек которые просто знакомы как друзья, но Социальные Сети не считают, что это профессиональная группа, а скорее просто знакомые и все. Поэтому рост не запускается совсем.</li>
<li><b>Наличие тяжелых экспертов в группе, причем не по размеру их эго, а по объективным данным Социальной сети</b>. Социальная сеть формирует некоторый рейтинг участников (что-то вроде AuthorRank в Google). Многие фрилансеры занимающиеся троллингом в группах не знают, что их сообщения подавляются социальными сетями автоматически, т.к. они "не в авторитете" (хотя их мнение обратное). Для авторитета нужны "лайки" от других авторитетных людей, а не троллей или таких же фрилансеров. Поэтому если группа набита фрилансерами с большим эго она не растет, т.к. LinkedIn и Facebook не считают, что это авторитетное сообщество. Но если в группу вступают несколько тяжелых экспертов с реальным рейтингом, то сразу же анализируется сеть их знакомств начинают формироваться прилашения по интересам.</li>
</ul>
<div>
Я это пояснил к тому, что в плане организации Социальных сообществ хорошо действует правило "кто первый встал, того и тапки". Кто первый правильно смог задать профессиональный фокус группы и привлечь тяжелых экспертов в нее, тот получает первым лучшее "стартовое ядро" Сообщества, которое далее невозможно уже догнать по росту, т.к. оно растет обычно в геометрической прогрессии. Причем еще раз отмечу, растет не просто числом, а в нужные отрасли и сегменты профессионалов.</div>
<div>
<br /></div>
<div>
Именно заточенные как нож алгоритмы "поиска нужных людей" делают Социальные Сообщества намного мощнее чем старые очные.<br />
<br />
Сообщества профессионалов конкурируют между собой как экспертами, так и организациями в их составе. В этом плане Сообщества в известном плане клуб из потребителей и поставщиков. Это конечно влияет на продажи. Но что мы видим? Большинство как сторожил, так и новичков на рынке не смогло приспособится к новым условиям и пропустили фазу формирования Сообществ не просто нового типа, а которые могут заменить старые. Это безусловно скажется и на продажах, т.е. экономической устойчивости поставщиков в проигрывающих Сообществах старых типов. Причем догнать уже сформировавшиеся Социальные сообщества невозможно, т.к. у них уже больше стартовое ядро. Как говорится "<b><i>Нас не догонят</i></b>"</div>
<iframe allowfullscreen="" frameborder="0" height="390" src="//www.youtube.com/embed/Hp9sf7QSkPQ" width="640"></iframe>
<br />
<br />
<br />
<br /></div>
Vladimir Ivanovhttp://www.blogger.com/profile/05223453757943695857noreply@blogger.com0