Наиболее популярный пример авторитарного управления – империя Генри Форда. В начале прошлого века, благодаря исключительно жесткому, самоличному оперативному руководству, Форд захватил больше 50 процентов рынка автомобилей.

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

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

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

Этот принцип был подмечен еще в Древнем Риме. В период кризиса Рим выбирал диктатора, осуществлявшего авторитарное управление. Когда наступала стабильность, демократическая форма правления восстанавливалась.

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

К сожалению, большинство наших предприятий меняют свою стратегию медленно и не очень охотно. И это в то время, как американское и западноевропейское общества уже в середине прошлого века начали придерживаться гуманистического направления. Руководители компаний этих стран верят в человека и в то, что он постоянно желает развиваться. Захотят ли русские управленцы «примерить» демократический стиль на себя?

Управление по-восточному

Принципиально новый подход к управлению компанией предложил ведущий идеолог Sony Corporation Сигеру Кобаяси. Суть метода – строго следовать дзенбуддийскому принципу «My», что можно толковать как «неопредметливание» или «неовеществление». Применительно к практике Sony Corporation это означает сознательный отказ от составления жестких планов. Должностное лицо компании обязано всегда действовать по обстановке, стремясь не упустить неожиданные выгоды. При этом не надо настаивать на выполнении планов, если предприятие сталкивается с непредусмотренными и непреодолимыми препятствиями

«Демократия российских компаний не за горами…»

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

Кто принимает решения?

В России довольно неплохо прижились многие принципы западного менеджмента. Но, к сожалению, их используют не все отечественные компании. В первую очередь это касается вовлечения персонала в процесс принятия решения. Данный фактор позволяет сотрудникам не только ощущать себя частью компании, но и повышает их ответственность в работе над проектом. Весьма часто получается так, что работник, находящийся в подчинении, может намного профессиональнее разбираться в конкретном вопросе, нежели непосредственный руководитель. Так почему бы не узнать его мнение по конкретному вопросу? Ведь это очень хороший мотивирующий фактор для персонала. Однако в России он пока не работает. В большей степени роль играет обычная психология человека, наделенного властью, – «Пусть будет по-моему!».

В России проблемы с информированностью персонала

Немногие российские компании уделяют достаточно внимания работе с персоналом.

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

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

На что идут отечественные работодатели?

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

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

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

Российские компании близки к демократии

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

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

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

«Западный стиль управления выигрывает перед российским…»

Западный стиль управления часто называют современным или цивилизованным. Российский же подобных эпитетов лишают. В чем причина таких различий? Дело в том, что и в Европе, и в США органически сформировались крепкие традиции деловой культуры с общими корнями. В отличие от бурно развивающейся российской традиции они уже на уровне базовых понятий по-другому понимают такие организационно-культурные феномены, как бюрократия, предпринимательство, лидерство, командность, инициативность, дисциплина.

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

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

На Западе решения принимают молниеносно

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

Оперативность решений – очень важный аспект современного управления, потому что сейчас время «спрессовано» как никогда. И здесь западный стиль управления, бесспорно, выигрывает перед российским. Ведь в отечественном менеджменте отношение ко времени определяется процессом, а не результатом. Часто можно услышать: «вопрос должен вылежаться», «решение нужно подвесить». И это даже тогда, когда данный вопрос является критичным для успеха бизнеса.

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

Все корпоративные культуры отличаются друг от друга

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

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

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

Индикаторы качественного развития

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

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

«Я не представляю свою карьеру в российской компании…»

Аэлита Пурнашкина, менеджер корпоративного отдела маркетинга холдинга IMS Group:

– В нашей компании западным является не только стиль менеджмента, но и стиль общения. Каждый сотрудник может свободно обратиться к топ-менеджеру. Это способствует профессиональному росту сотрудников. Ведь таким образом у них есть возможность оперативно решать все вопросы и при этом постоянно быть на виду у руководства.

- Другой момент, который меня приятно удивил, когда я перешла в западную компанию после нескольких лет сотрудничества с российской, – это забота о здоровье персонала. К примеру, если в течение рабочего дня сотрудник IMS Group почувствовал недомогание, он может позвонить персональному доктору компании. Врач анализирует проблему, затем сам перезванивает сотруднику и предлагает ему принять то или иное лекарство или назначает прием. Если недомогание серьезное, он советует, услугами какой именно клиники человеку лучше воспользоваться. Такой подход очень выгоден самой компании – у сотрудников нет необходимости тратить время на очереди в поликлиниках. В то же время персонал чувствует заботу о себе.

- Другой отличительный фактор – мотивация и обучение персонала. В нашей компании сотрудник проходит обучение уже в первую неделю своей карьеры. В отечественных фирмах не понимают важности инвестиций в персонал. Рядовой сотрудник вряд ли сможет напрямую обратиться к топ-менеджеру со своими идеями, предложениями. Честно говоря, мне сложно представить свой карьерный рост в российской компании.

Источник: http://pm.by/

Источник: http://habrahabr.ru/blogs/arbeit/

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

Возможность предсказывать лежит в основе создания коротких целей. Однако не всё так просто.

Если мы создаем предсказание с максимальной вероятностью (100%), то оно не создает позитивной мотивации. Например, нас не мотивирует то, что мы сидим на стуле, потому что мы с 100% вероятностью подсознательно предсказываем, что он не сломается под нами. Мы получаем только нейтральную реакцию, и даже не обращаем на нее внимание.

Мотивация же относится к тем случаям, когда предсказание не гарантирует достижение цели, но мы своими усилиями, на основе предсказания, всё же достигаем позитивного результата. Притом сила мотивации пропорциональна соотношению двух факторов: «бонус» и вероятность.

Мы даже готовы действовать в области низких вероятностей ради большого «бонуса» (это риск, например в казино). Соответственно если при низкой вероятности мы получили «бонус», мы получаем сильный позитив.

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

Точно также действуют и короткие задачи.

Когда вы ставите короткую задачу, она не должна быть 100% предсказанной, то есть вы не должны детально четко знать каждый шаг по ее достижению. Это снижает «бонус», которым нас мотивирует подсознание. Если вы будете это знать, то такое задание не вызывает позитива, но является растратой ресурсов, так создается «рутина».

Если вы ставите короткую задачу средней предсказанности и реализуете ее точно со своей моделью предсказания, вы получаете свой позитив.

Например:

Вы ставите задачу написать модуль для сайта. Вы можете создавать 100% вероятность для этой задачи только в том случае, если делали уже их не раз, а это и есть рутина.

Если же вы не делали его раньше, то по достижению этого результата вы получите бонус.

Собственно почему тогда задачи нужны именно короткие?

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

Если вы предсказываете, что сделаете модуль за 30 минут, подсознание дает мотивацию на достижение, так как считает, что вы будете непрерывно заниматься этим модулем и имеете вероятность его закончить именно через 30 минут.

Если же каждые 5 минут вас начинают «дергать», то подсознание может в результате понизить мотивацию, как эти «дерганья» начинают включаться в модель предсказания, и тем самым ваш модуль «стОит» для подсознания уже гораздо дороже, а такую цену оно возможно не готово платить.

Если такие случаи будут повторяться, то подсознание вырабатывает уже новое предсказание, которое не способно вас будет замотировать даже на этот простой модуль.

Именно поэтому в таких случаях важно или не отвлекаться от выполнения модели предсказания, или уметь очень сильно и четко переключать своё сознание, чтобы также и переключалось предсказание. Это довольно сложно сделать, если вас переключают на другие дела, требующие умственных усилий, но гораздо легче, если эти переключения идут в область 100% предсказаний, например отлучиться в туалет.

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

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

Это лишь краткая часть механизма мотивации на действия в случае определенности цели. Чуть более полное описание вы можете почитать тут (много букв).

HS2.0

Успехов вам в достижении собственных целей.

UPD1

Для тех, кому сразу сложно понять о чем идет речь, немного уточню.

Модели предсказания это не образное понятие, рожденное от наблюдения за человеком. Это принцип функционирования нейросетей неокортекса головного мозга. Именно у человека он развился до такой степени, что он создал механизмы позволяющие ему регулировать собственные мотивации при помощи нейропептидов (эндорфина).

Подробнее о моделях предсказания (как они формируются нейронами и как устроены) можете прочитать в книге «Об интеллекте» Джеффа Хокинса.

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

Прежде всего, о чем идет речь? С понятием «капитальные вложения» все ясно. Большая Советская Энциклопедия сообщает нам, что: «К.в. – средства, направляемые на создание или модернизацию осн. фондов (зданий, сооружений, горн. выработок, машин и оборудования) в процессе их воспроизводства. …Непосредственный результат капитальных вложений — ввод в действие производственных мощностей и непроизводственных объектов, конечный результат — прирост продукции и материальных услуг, а в целом — прирост национального дохода.» То есть капитальные вложения – это вложения финансовых средств предприятия (частный случай – государства) в получение новых или модернизацию старых активов. А что означает слово «освоение»? Этот термин в БСЭ по отношению к капитальным вложениям не встречается ни разу.

Заглянув в толковый словарь русского языка, мы без труда обнаружим несколько значений слова «осваивать», но ни одного, относящегося по смыслу к действиям с деньгами, среди них не встретим. Прямую ссылку я нашел только в Современном словаре русского языка, где одним из значения слова «Осваивать» является «Употреблять, использовать деньги, средства». Видимо, «употребили 100 млн рублей» звучит вызывающе, поэтому использовали менее звучный синоним. Шутка. А если серьезно, далее будем исходить из предположения, что фраза «освоили 100 млн рублей» полностью звучит так: «употребили на намеченные цели 100 млн рублей».

Согласно предположению, термин «освоенные капитальные вложения» означает, сколько капитальных вложений на сегодняшний момент пошло на создание новых и/или модернизацию имеющихся активов, причем эта цифра подтверждена документально – утвержденными формами КС-2 и КС-3. Разовьем эту мысль. Можно ли изначально оценить объем капитальных вложений для строительства конкретного объекта? Конечно можно – иначе понятие «капитальные вложения» не существовало бы. Таким образом, если изначально оценить динамику освоения капитальных вложений по периодам времени, исходя из организации работ по сооружению объекта, можно только по показателю «освоение КВЛ» оценивать степень готовности объекта к сдаче в эксплуатацию. Разумеется, регулярно проводя анализ «план-факт». У меня есть ощущение, что ровно на такой идее построено использование этого показателя большинством Заказчиков и Инвесторов России, и именно поэтому он так популярен.

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

Пример. Пусть есть 2 площадки строительства в средней полосе России. Ведется строительство каких-то одинаковых среднестатистических промышленных объектов по типовому проекту (вся РД есть – это же идеальная модель). Сооружение каждого объекта осуществляет свой Генподрядчик (ГП1 и ГП2 соответственно), причем до 1 июля работы шли полностью синхронно (и здесь модель идеальна). По состоянию на 1 июля обоим Генподрядчикам ставится цель: к 1 августа освоить 100 рублей, строя объект в соответствии с требованиями РД.

ГП1 начал сооружать основной фундамент и фундаменты под оборудование. К 1 августа он полностью закончил сооружение основного фундамента и 2-х из 5 -ти фундаментов под оборудование. Стоимость этих работ составила 100 рублей, то есть цель была достигнута.

ГП2 пошел другим путем. Он решил «набрать» требуемые 100 рублей на других фронтах работ. В результате к 1 августа он начал копать котлован под вспомогательное здание (на 30 рублей к 1 августа), начал сооружение градирни (на 60 рублей к 1 августа), построил 20 метров вспомогательной дороги (на 10 рублей к 1 августа). В сумме работ было выполнено также на 100 рублей, то есть с формальной точки зрения цель также была достигнута.

Давайте сравним результаты наших ГП по состоянию на 1 августа.

У ГП1 на следующий месяц открыты фронты работ по сооружению оставшихся 3-х фундаментов под оборудование, по монтажу колонн и установке оборудования в проектное положение. Это в свою очередь дает возможность до наступления холодов смонтировать кровлю и стены, после чего выполнять обвязку оборудования в закрытом помещении. Таким образом, ГП1 имеет реальные шансы к следующему лету приступить к пусконаладочным работам, а к концу следующего года сдать объект Заказчику.

У ГП2 открыто аж 3 фронта работ, что позволит ему еще пару месяцев формально осваивать нужную сумму капвложений. Но что будет дальше? Поскольку дело происходит в средней полосе России, зима не за горами. Выполняя второстепенные, хоть и «дорогие» работы, ГП2 физически не успеет закрыть «коробку», а значит, либо не начнет монтаж обвязки до весны вообще, либо понесет дополнительные издержки на временные укрытия, обогрев и пр. (если такой вариант технологически допустим). Заметьте: по-прежнему не выполняя запланированных работ, он и дальше будет продолжать демонстрировать освоение нужных объемов капвложений – только теперь через допработы. То есть, увеличивая конечную стоимость объекта.

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

Кстати, физические показатели тоже не решают эту проблему в случае, если они приводятся без привязки к конкретным промежуточным результатам. Снова поясню на примере. На большинстве строек очень любят контролировать количество бетона: «В этом месяце уложено 1570 м3». Не будем сейчас вдаваться в подробности, о каких марках бетона идет речь и т.п. Вопрос в другом: куда конкретно уложено? Как и в вышеприведенном примере про освоенные 100 рублей, 1570 м3 бетона можно уложить разными способами. Их можно использовать при сооружении фундаментов, и тем самым обеспечить завершение проекта в срок, а можно использовать для сооружения градирни, строительство которой можно было бы начать и через год. Таким образом, и физический показатель по укладке бетона можно легко сделать «ни о чем».

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

Я считаю, что одновременно обеспечить и контроль физического наличия полностью завершенных строительных конструкций, и контроль освоения КВЛ вполне реально и даже не слишком трудоемко. Для этого необходимо по уму использовать совокупность комплексного укрупненного сетевого графика (КУСГ) и графика производства работ (ГПР). Из такой связки можно «легким движением руки» получить:

• Сроки завершения работ по сооружению конкретных элементов конструкции
• Освоение КВЛ (стоимость завершенных работ на основе данных локальных смет и дает освоение)
• Выполненные физические объемы (на основе ГПР). Основная сложность – с агрегацией физических объемов в «физобъем более высокого уровня». Я лично постоянно встречаю результаты такой агрегации в отчетах, но ни разу еще не видел записанной методики агрегации. Поэтому что с чем суммируют – чаще всего загадка.
• Трудоемкость. Теоретически ничего сложного нет иметь эти данные в ГПР (главное не поддаться искушению взять трудоемкость из локальных смет – в ближайшее время планирую поделиться своими мыслями и по этой теме), но на практике возникает масса проблем со сбором фактических данных по трудоемкости.

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

Источник: http://kot1914.livejournal.com/

Рассматривая вопрос увязки графиков строительно-монтажных работ и поставок оборудования, прежде всего, необходимо определиться, о каких именно поставках идет речь. Из всех поставок выделим сначала оборудование длительного цикла изготовления (ОДЦИ) и рассмотрим методику согласованного планирования СМР и ОДЦИ. Чем характерны поставки ОДЦИ? Их заказ производится обычно на основании утверждаемой части Проекта, при этом процесс разработки конструкторской документации также требует существенного времени и должен быть учтен в графике. В процессе изготовления заказчик оборудования проводит промежуточный контроль своевременности и качества изготовления. Планируется не только дата доставки и входной контроль оборудования на площадке, но и логистическая цепочка: отгрузка со склада изготовителя, промежуточные пункты доставки. Типовой график поставки ОДЦИ представлен на рис.1. О чем нельзя забывать, так это о необходимости планирования времени на организацию и проведение конкурсных процедур, причем не только на выбор поставщиков/изготовителей, но и конструкторских организаций, и логистических организаций, если доставка относится к ответственности заказчика оборудования. Этапы и нормативные сроки проведения конкурсных процедур указаны в Едином отраслевом стандарте закупок ГК «РОСАТОМ», а также определяются Типовыми положениями торгов и закупочных процедур.

рис. 1. Типовой график закупки ОДЦИ на примере закупки парогенераторов

Поставку остальной номенклатуры оборудования целесообразно планировать, следуя рекомендациям СНиПа: «при организации строительного производства должна обеспечиваться комплектная поставка материальных ресурсов из расчета на здание, сооружение, узел, участок, секцию, этаж, ярус, помещение в сроки, предусмотренные календарными планами и графиками работ». Фактически за этой фразой скрывается модель производственно-технологической комплектации, детально проработанная еще в советское время. Основная ее цель заключается в поставке материальных ресурсов на строящиеся объекты по номенклатуре в строго определенном количестве и в сроки, заданные планом производства СМР. При этом выделяются следующие типы комплектов:

• Технологический комплект – набор конструкций, деталей, материалов и полуфабрикатов, необходимых для строительства объекта, здания, сооружения или выполнения цикла работ;
• Поставочный комплект – часть технологического комплекта МТР, поставляемая на объект с одного завода-изготовителя или от одного поставщика в соответствии с технологией и графиком производства работ;
• Рейсовый комплект – часть поставочного, монтажного комплекта МТР, доставляемая одним транспортным средством;
• Монтажный комплект – часть технологического комплекта, состоящая из сборных строительных конструкций, изделий и сопутствующих деталей, необходимых для сборки монтажного узла, конструктивного элемента.

Планирование начинается с формирования технологических комплектов на основании графика 3-го уровня и рабочей документации (в т.ч. спецификации на оборудование и материалы).

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

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

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

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

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

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

Введем понятие Управляющая компания. Ей является Инжиниринговая компания (или EPC(M)-контрактор), если Заказчик заключает договор на сооружение объекта капитального строительства «под ключ». Если Заказчик непосредственно заключает договоры на разработку рабочей документации, договоры на выполнение СМР с несколькими компаниями, договоры на поставку оборудования и материалов, в этом случае функцию Управляющей компании исполняет сам Заказчик.

Организация работ Управляющей компанией по объектам пускового комплекса может быть выстроена двумя способами:

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

При этом процесс закупок может быть реализован как собственной службой комплектации, так и отдан специализированной компании.

Таким образом, разработку методологии календарно-сетевого планирования в части увязки графиков СМР и поставок оборудования, а также выпуск организационной документации, регламентирующей процессы взаимодействия участников проекта для обеспечения бесперебойного снабжения стройки, необходимо выполнять с учетом принятой стратегии организации строительства на основании отраслевых и государственных нормативов, а утвержденные документы (в соответствии с СТО-СУПГ-00001-2010 СРО «Союзатомстрой») должны войти в Стандарт управления проектами Организации.

Источник: http://k4-info.com

Что же такое проект?

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

В определенном смысле все проекты одинаковы. У всех есть потребитель (и) и \ или покровитель (и), которые ждут от реализации проекта достижения в определенное время результатов. Проекты часто реализуются с целью создания чего-то нового или осуществления больших изменений, которые можно рассматривать как завершенный вид деятельности. Проект может возникнуть исходя из новых запросов потребителей или пользователей услуг, либо из возможности получить выгоды для организации, либо на основании новых потребностей организации.

Проект – это практическая деятельность, которая осуществляется в определенном контексте и подвержена его влиянию. Общие характеристики проектов:

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

У каждого проекта существуют 3 ключевых измерения – бюджет, время и качество, которые должны быть сбалансированы для успешного управления проектом. Поэтому главной задачей при управлении проектами как раз и является соблюдение баланса этих измерений – уложиться в выделенный бюджет, при этом не выйти за рамки временных ограничений и обеспечить приемлемое качество. Отсюда и вытекают 3 основных признака неудачи проектов:

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

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

Часто встречающиеся недостатки в реализации проектов:

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

На основании своих исследований Элбейк и Томас указали 10 факторов, которые многие определяют как критические для успеха проекта (расположены в соответствии с приоритетами):

1. ясно поставленные цели;
2. четкое планирование и контроль;
3. высокая квалификация менеджера проекта;
4. хорошая административная поддержка;
5. достаточное количество времени и ресурсов;
6. выполнение своих обязательств всеми участниками;
7. широкое привлечение потребителей;
8. хорошие коммуникации;
9. хорошая организация и структура проекта;
10. возможность прекратить реализацию проекта.

Определение границ проекта

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

3 фазы в определении потребностей:

1. Появление потребностей — все заинтересованные стороны должны предупреждать и предвидеть потребности, реагируя на них проактивно;
2. Признание потребностей — осознание потребностей на основе сбора информации и обсуждения с ЗС. Главная задача на этом этапе – превращение возникающей потребности в цели, которые начнут определять результаты проекта;
3. Формулирование потребностей — прояснение понимания потребности с помощью более точного описания ее характерных особенностей. Формулировка того, что должно быть сделано, т.е. определение границ, формулировка проекта.

Проблемы недостаточно точного определения потребностей:

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

Для того, чтобы понять масштабы проекта необходимо иметь следующую информацию:

1. Кто является заинтересованными сторонами (ЗС) и каковы их потребности в проекте?
2. Каковы цели и задачи проекта и каким образом их собираются осуществить в рамках соответствующих ресурсных и временных ограничений? (предназначение и цели)
3. Каковы возможности проекта и угрозы для его успешной реализации?

ЗС и их потребности

Наиболее важные ЗС для проекта:

1. Покровитель проекта – человек или группа людей, которые инициируют и поддерживают проект, обеспечивают ресурсами и поручают Вам его реализацию;
2. Команда проекта – группа людей, готовых выполнять поставленные задачи и осуществлять необходимые виды деятельности; 3.Функциональные менеджеры и другие люди, которые управляют необходимыми Вам ресурсами и обладают полезными для Вас опытом и знаниями;
3. Влиятельные люди или группы, которые, вероятно, подвергаются воздействию проекта или его результатов

В зависимости от особенностей проекта многие другие группы или отдельные люди могут быть заинтересованы в нем:

• потребители, покупатели, пользователи товаров и услуг;
• другие работники организации (из этого или другого подразделения);
• менеджеры и персонал организаций-партнеров;
• высшее руководство Вашей организации;
• акционеры и их представители;
• СМИ;
• конкуренты;
• общественные и государственные деятели, если проект вызывает широкий общественный интерес.

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

Определение предназначения и целей проекта

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

Цели должны соответствовать критериям SMART:

• конкретными (specific) – т.е. Вы должны ясно представлять себе, чего хотите достичь;
• измеримыми (measurable) – Вы должны разработать критерии для измерения процесса достижения целей;
• достижимыми (achievable) – т.е. Вы должны быть уверены в достижении поставленных целей в существующем окружении и при имеющихся ресурсах;
• реалистичными (realistic) – т.е. Вам не следует пытаться достичь невозможного;
• определенными по времени (timebound) – т.е. сроки достижения поставленных целей должны диктоваться реальными потребностями

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

Ясность целей важна для понимания того, что должно быть сделано. Если поставлены четкие цели, то это значит, что имеется определенная система взглядов на конечный результат. На основании поставленных целей происходит структурирование проекта с тем, чтобы его можно было эффективно контролировать и управлять им. Однако иногда возникает необходимость в пересмотре целей, поскольку в процессе осуществления проекта могут возникнуть новые обстоятельства, неизвестные на стадии планирования. Поэтому цели не должны быть «каменными».

Возможности и угрозы

Исследование возможностей и угроз на начальной стадии проекта может быть важным для определения его масштаба. Постоянные обсуждения с ЗС могут выявить многие потенциальные возможности и угрозы, связанные с проектом. Управление рисками (возможными угрозами проекту) будет рассмотрено ниже.

Проверка осуществимости проекта

Целью проверки осуществимости является определение того, будут ли требуемые выходы или результаты достигнуты при использовании имеющихся ресурсов. В процессе проверке рассматриваются следующие аспекты:

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

будет поддержан как в смысле используемых процессов, так и в смысле предполагаемых результатов.

Определить ценность проекта для организации помогут следующие вопросы:

• какова бизнес-причина для выполнения проекта?
• какой вклад внесет проект в достижение общих целей организации?

Затраты и выгоды для оценки проекта

Для составления бюджета проекта финансовые затраты делят на две главные категории:

• стоимость разработки- затраты, возникающие в период между началом проекта и моментом, когда начато производство продукции. Они присущи всем проектам и обычно включают в себя затраты на команду проекта.
• операционные затраты – затраты, возникающие с началом выпуска продукции и обеспечивающие поддержание данного процесса (пример – ежедневно расходуемые материалы, используемый капитал). Они не возникают в проекте, в котором продукт продается один раз сразу после завершения проекта.

Выгоды в управлении проектами делятся также, как в финансовом учете на:

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

Ваши оценки должны включать в себя:

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

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

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

Существует несколько методов оценки денежных потоков по проекту (подробно рассматриваться здесь не будут):

• Чистая текущая стоимость (Net Present Value — NPV);
• Внутренняя норма отдачи (internal rate of return — IRR);
• Срок окупаемости;
• Анализ эффективности затрат.

Риски и ситуационное планирование

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

Существуют 4 стадии управления риском:

1. Выявление риска – определение, какие риски могут влиять на проект, и описание характеристик каждого из них.
2. Оценка влияния – оценка риска с точки зрения диапазона возможных результатов, касающихся проектов, и потенциального влияния каждого из них.
3. Планирование запасных вариантов с целью снижения влияния наиболее вероятных рисков.
4. Обеспечение того, что риски всегда находятся в поле зрения.

Основные категории риска:

• материальные риски – возможность утраты или повреждения информации, оборудования или зданий вследствие несчастного случая, пожара или стихийного бедствия;
• технические риски, возникающие когда системы не работают или работают недостаточно хорошо для получения необходимых результатов;
• кадровые риски – вероятность неучастия ключевых работников в реализации проекта или недостаток квалифицированных кадров;
• социально-политические риски, возникающие, когда проект лишается поддержки вследствие смены власти, изменений в политике высшего руководства организации или протестов со стороны общественности, СМИ, пользователей услуги или персонала;
• правовые риски – угроза правовых действий из-за того, что некоторые аспекты проекта могут рассматриваться как незаконные.

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

Оценка риска и анализ влияния: ключевые вопросы

Оценка риска — измерение вероятности превращения риска в реальность; анализ влияния – измерение чувствительности проекта к каждому определенному риску. Ключевые вопросы состоят в следующем:

• что такое риск – как я его узнаю, если он возникнет?
• какова вероятность его осуществления – высокая, средняя или низкая? насколько серьезную угрозу он представляет для проекта – высокую, среднюю или низкую?
• каковы признаки или причины риска, которые нам следует искать?

Стратегии обращения с рисками:

1. Избежание риска — например, отказ от контракта;
2. Снижение риска — например, регулярные проверки могут снизить вероятность производства продукта низкого качества;
3. Защита от риска — например, страхование от возможных случайностей;
4. Управление риском — например, использование письменных соглашений в тех сферах деятельности, где возможны разногласия;
5. Перемещение риска — например, передача ответственности за выполнение рискованного задания в рамках проекта другой организации, у которой больше опыта.

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

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

Основание для действий по проекту

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

• ожидаемым результатам;
• ресурсам, которые будут вложены для достижения этих результатов;
• времени, необходимому для достижения этих результатов.

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

Перечень заголовков резюме:

• Название проекта;
• Покровитель проекта;
• Местоположение – адрес покровителя, местоположение проекта, контактные адреса;
• Имя менеджера проекта и название его организации, если она отлична от организации, спонсирующей проект;
• Дата согласования резюме с покровителем проекта;
• Дата начала и завершения проекта;
• Обоснование и предназначение проекта с обзором основных идей;
• Основные цели с указанием критериев качества и успеха;
• Подробное описание того, как достижение этих целей принесет выгоды бизнесу или организации, спонсирующей проект;
• Масштаб и границы проекта;
• Ограничения;
• Предположения;
• График проекта;
• Основные результаты и соответствующие им даты (вехи проекта);
• Оценка затрат;
• Механизмы обеспечения ресурсами;
• Механизмы отчетности и мониторинга;
• Механизмы принятия решений – полномочия и подотчетность менеджера проекта и проведение повторных переговоров;
• Механизмы и каналы коммуникаций;
• Подпись покровителя проекта с указанием даты, звания и должности

Заключение

В данной статье, как можно более кратко и конкретно, были рассмотрены теоретические основы этапа подготовки проекта. Для этого использовалась литература Школы бизнеса МИM ЛИНК, выпускником которой и является автор. В учебном курсе данной школы подробно изучается шестиэтапная модель управления проектом, и если появится заинтересованность со стороны хабрасообщества, можно будет продолжить серию статей на эту тему.

Источник: http://habrahabr.ru/blogs/pm/

У регулярной сверхурочной работы множество вредных последствий — как для команды, так и для компании. Давайте их рассмотрим.

Истощение

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

Недоработки

Чем больше времени люди тратят на работу, тем меньше его остается не только на отдых, но и на личную жизнь во всех ее проявлениях. Следовательно, на работе они будут менее сосредоточенны и больше отвлекаться. В пределе они неизбежно начнут решать личные вопросы в рабочее время, участятся прогулы, больничные и времена «удаленной работы» — и с этим будет крайне сложно бороться. Сочетание этих факторов называется недоработками (undertime).

Демотивация

Еще одно очевидное последствие постоянных сверхурочных — демотивация. Кому нравятся эти гонки на выживание? Кому приятно вновь и вновь слышать от руководства «ваше беспокойство оправдано, проект неизбежно провалится, но мы должны продолжать пытаться написать что-то приемлемое к сроку»? Лично мне не хотелось бы провести в такой компании много времени.

Текучесть кадров и утрата неявных знаний

Со временем истощенные и утратившие всякую веру сотрудники начнут искать другую работу — и найдут ее. Как следствие, будут необратимо утеряны неявные знания о том, что уже сделано по проекту. Тем самым дальнейшая работа еще усложнится — люди, которые понимали, что и как здесь крутится, здесь уже не работают.

Потеря качества и технический долг

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

Непредсказуемость

Становится сложнее предсказать дальнейшее развитие проекта. Посреди следующего этапа или проекта может внезапно вылезти ошибка с предыдущего и пустить его под откос. Кроме того, из-за сложности учета времени, действительно потраченного на работу в напряженном режиме, становится сложнее оценить эффективность команды в нормальном режиме. Расписание на следующие проекты становится все более ненадежным. Впрочем, об этом можно не волноваться, всегда можно поработать сверхурочно, чтобы нагнать расписание… Черт. Где-то я это уже слышал.

Менеджеры и клиенты

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

Почему же об этой проблеме не извещается клиент? Да потому, что это сложный разговор, и большинство людей (включая менеджеров) таких разговоров боятся и избегают их любой ценой. Легче сказать «бегом за работу!» команде, чем «мы это не сможем» — клиенту. На самом деле о таких вещах говорить надо — хорошие отношения с клиентом должны быть основаны на уважении, доверии и открытости, в том числе и в те моменты, когда дела идут плохо.

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

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

Вывод

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

Вы все еще хотите работать сверхурочно?

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

Следует отметить, что речь идет не об эпизодических сверхурочных, когда баг обнаруживается накануне запуска проекта и его действительно надо исправить прямо сейчас, а о регулярных сверхурочных, когда ими «лечат» отставание от графика на месяц-другой или просто используют как инструмент уменьшения сроков разработки при планировании. Для изматывания команды дополнительной работой требуется от 2 до 6 недель, в то время как первая неделя характеризуется всплеском продуктивности. Кроме того, сверхурочные по инициативе команды и по приказу сверху — это таки две большие разницы, что тоже следует учитывать.

О вреде сверхурочных сказано немало, но эта статья зацепила меня 100%-ой точностью в описании ситуации одной команды, которую я имею возможность наблюдать. Регулярная (оплачиваемая, но принудительная) работа по выходным, «никто не уйдет домой, пока ошибка не будет исправлена», вечное «кто виноват?» вместо «что делать?»… За полгода из команды «1 менеджер + 5 исполнителей» уволилось трое исполнителей, остальные описанные симптомы тоже налицо. И да, в такой команде я бы не хотела работать :-)

Я не буду полностью приводить в своем блоге эту статью, поскольку она весьма объемна. Желающие могут прочитать ее по вышеуказанной ссылке. Мне кажется, в этой статье достаточно подробно указаны 3 основных идеи Теории ограничений:

1. Длительность задач (или работ – не важно) следует задавать таковой, чтобы отражать 50% вероятность их завершения за указанный срок.
2. Конкуренцию за ресурсы в плане следует выявлять и устранять как можно раньше.
3. С помощью буферов следует «защищать» конечный срок окончания проекта от срыва из-за срыва сроков отдельных задач.

Прокомментирую применение этих 3-х идей к управлению строительными проектами.

Про длительность

На первый взгляд, все очень логично. Исполнитель может выполнить задачу и раньше, и позже назначенного срока. А раз так, то проще включить в план длительность задачи, которая получится с вероятностью 50%. В теории. Но теперь приблизимся к грешной земле и зададимся вопросом: а о каком плане идет речь? Какие задачи с помощью этого плана собираются решать?
Давайте традиционно рассмотрим нарочито простой пример (№1): есть заказчик-застройщик и есть генподрядчик. Планируют строить ОБЪЕКТ – что-то большое и сложное. В общем, долго будут строить. И разрабатывает генподрядчик комплексный укрупненный сетевой график (КУСГ), и принимает решение указывать такие длительности работ, которые могут получиться с вероятностью 50%. Дальше генподрядчик должен согласовать свой план с заказчиком. А заказчик возьми и задай простой вопрос: «А длительность ты откуда взял?» «На основе 50%-ной вероятности!» – отвечает генподрядчик. От цитирования ответа заказчика воздержусь – приведу лишь общий смысл: «Мне есть очень мало дела до Вашей теории ограничений и Вас лично. Дайте обоснование стоимости работ и завершите разработку котлована к 1 мая.» Для заказчика принцип «Не мудри – пальцем покажи» часто самый действенный.

Простой пример №2. Тот же генподрядчик разрабатывает график производства работ (ГПР) для собственных и подрядных сил и снова оценивает длительность работ в соответствии с принципами теории ограничений. Зачем он разрабатывает этот график? Вариант «для удовлетворения требований заказчика» не рассматривается, поскольку этот вариант рассмотрен выше. Так вот генподрядчик может преследовать несколько целей. Первая из них – определение реальной продолжительности строительства . Теоретически эта цель может быть достигнута и с помощью теории ограничений. Но однократно. Потому что для регулярного контроля сроков сооружения объекта, необходимо выстроить процесс оперативного управления стройкой на основе единого графика. То есть, вторая цель – оперативное управление стройкой – требует выдачи недельно-суточных заданий на основе графика. Но как давать задание, если длительности работ там не понятны простому труженику? Понятны – это варианты типа «потому что объем такой, а вас пятеро» или «потому что шеф так требует, иначе вы денег не увидите». Аргумент «потому что вероятность 50%» не поймут. И воспримут в варианте «шеф потребовал, а не то денег не будет». Но если руководитель сам не готов к такой постановке вопроса, и деньги все-таки будут и при первом срыве сроков, и при всех последующих, то он рискует в дальнейшем наблюдать, как работяги «кладут» и на все его прочие требования.

Про ресурсы

Когда на стройках могут встретиться случаи конкуренции за ресурсы? Вариант 1. Нескольким подрядчикам нужен ресурс генподрядчика. Типичный пример – кран грузоподъемностью 1000 т. Вариант 2. Внутри зоны ответственности одного подрядчика.

Начнем с варианта 1. Такие случаи обычно можно посчитать по пальцам одной руки. Они сразу на поверхности и неизбежно всплывают заранее – при разработке графика производства работ или даже КУСГ. Решаются коллегиально на уровне здравого смысла. К слову сказать, задача управления крановым временем с помощью технологий календарно-сетевого планирования вообще не решается – слишком детальный процесс. Как организовать работу, чтобы 1000-тонным краном не поднимать грузы в 200 кг – это вопрос ПОСа вообще и детального планирования производства работ в частности. Так что здесь полное согласие с теорией ограничений – если здравый смысл есть, то все организуют как надо, а если нет, и теория ограничений не поможет.

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

Про буфера

Мне очень понравилась идея про буфера, когда я первый раз прочитал книгу Голдратта. Но потом я задал себе один вопрос, и до сих пор не нашел на него ответа. Этот вопрос такой: «Как обосновать наличие буферов перед заказчиком?». Ведь и в варианте «Не мудри – пальцем покажи», и варианте «подкованного», т.е. знающего теорию ограничений, заказчика, конфликт интересов никто не отменял. В процессе переговоров у заказчика будет огромное искушение «нагнуть» подрядчика именно за счет буферов. Ведь и так любой заказчик старательно выискивает «соломку», заботливо подстеленную для себя подрядчиком в части сроков выполнения работ, под которыми он готов подписаться. А тут эту «соломку» ему честно показывают – ну как не воспользоваться? Думаю, что именно это, а вовсе не незнание заказчиком Голдратта ставит крест на применении теории ограничений в строительстве.

Косвенно эта моя гипотеза подтверждается списком компаний, успешно применяющих TOC, приведенном в той же статье. Перечислю только их сферы деятельности:

• Установка и разработка телекоммуникационных сетей
• Разработка лекарственных препаратов
• Разработка автомобильной продукции
• Разработка сложных медицинских изделий
• Управление воздушным движением
• Коммунальные услуги
• Проектирование и производство мебели по техническим условиям заказчиков
• Разработка нового высокотехнологичного продукта
• Разработка продуктов для беспроводных технологий новых поколений
• Подготовка и упаковка пищевых продуктов
• Ремонт и переоборудование самолетов

Заметим – ни одного строителя. Ни заказчика, ни генподрядчика, ни подрядчика. Доминирует НИОКР. Мне кажется, вполне очевидно почему. Внутри себя компании по силам применять любую методику – главное, чтобы руководство не теряло интерес к этой методике и продолжало требовать ее применения, а исполнители были дисциплинированы. И для оценки длительности «творческой» деятельности принцип «вероятности 50%» мне кажется очень подходящим. Вспомним: «Часто ряд задач в рамках проекта выполняется без наличия какого-либо прошлого опыта в этой области»… Исходя из вышеприведенного примера (№2), получается, что принцип оценки длительности работ «вероятность 50%» можно применять только в том случае, если график ИСПОЛЬЗУЕТСЯ ТОЛЬКО для верхнеуровневой координации работ, но НЕ ИСПОЛЬЗУЕТСЯ для выдачи заданий конечным исполнителям.
Также как и буфера – «внутри себя» их можно согласовывать и ими управлять в полном соответствии с заветами Голдратта.

Вывод

Хороших теорий много. Но одинаково хороших для всех отраслей человеческой деятельности – одна-две в поле зрения. И Теорию ограничений Голдратта, при всех ее очевидных достоинствах, признать универсальной нельзя. Она не решает ни одной типичной проблемы на стройке, но создает дополнительные сложности. Так что метод критического пути применительно к планированию строительных проектов предпочтительнее – в частности за счет своей большей простоты.

Учитывая, что данная заметка – результат моего умозрительного анализа, а также то, что мне не известен ни один практический пример применения теории ограничений Голдратта не только в российской, но и международной практике строительства, было бы интересно обсудить данный вопрос со специалистами, имеющими практический опыт в этом вопросе.

Источник: http://kot1914.livejournal.com/

Под катом — пошаговая инструкция получения PMP на базе PMBOK4.

Требования

Для того, чтобы вашу заявку на сдачу PMP приняли, необходимо выполнить следующие условия:

• Получить высшее образование.
• Получить 3 года (4500 часов) опыта управления проектами.
• Потратить 35 часов (PDUs) на обучение в сфере управления проектами.

Попробовать сдать PMP можно и со средним образованием, но в этом случае требования к опыту строже — 5 лет (7500 часов).

План

1. Зарегистрироваться на сайте PMI.
2. Оплатить членский взнос 129$.
3. Подать заявку на сдачу PMP.
4. Оплатить сертификацию 405$.
5. Прочесть PMBOK4 один раз.
6. Прочесть Rita PMP Exam prep 6 Edition первый раз.
7. Пройти тесты Rita Fast Track до тех пор, пока результат не превысит 75%.
8. Назначить дату сдачи в тестовом центре Prometric.
9. Просмотреть Rita PMP Exam prep 6 Edition второй раз.
10. Пройти еще как минимум 2 посторонних теста.
11. Просмотреть Rita PMP Exam prep 6 Edition последний раз.
12. Приехать в тестовый центр и сдать экзамен.

Все это заняло у меня 3 месяца и ~600$.

Членство в PMI

Это необязательный пункт, но с ним суммарные расходы на сертификацию немного ниже. Плюс, как члену PMI, вам полагается бесплатная электронная версия PMBOK.

Подача заявки

При подаче заявки, необходимо будет детально описать из каких проектов состоит ваш опыт. Процедура нудноватая и занимает несколько часов, но по-другому вы никак не обозначите необходимый ПМский опыт. Также, нужно будет указать как вы набрали свои 35 PDUs. Здесь годятся всевозможные тренинги и конференции, в которых вы участвовали. Неважно, внешние или внутренние — если ваш PMP сертифицированный коллега провел двухчасовой тренинг по управлению рисками, это честные 2 PDU.

Проверка заявки

PMI может случайным образом отобрать вашу заявку для проведения аудита. В этом случае, вам необходимо будет собрать письменные подтверждения вашего образования, опыта и обучения и отправить почтой. Мне в этом плане повезло, моя заявка под аудит не подпала.

Материалы

PMBOK вы получите бесплатно, но одного его для подготовки маловато, обязательно раздобудьте Rita PMP Exam prep. Неплохой список бесплатных тестов можной найти здесь.

Сдача

Экзамен представляет из себя 200 вопросов, по 4 варианта ответов на каждый. Длительность экзамена 4 часа, ответы можно помечать, чтобы вернуться к ним позже. Для успешной сдачи, необходимо ответить верно на 61% вопросов. Рабочая стратегия — ответить на все 200 вопросов, помечая те, в которых не уверен, после чего пройти помеченные. Первый проход занимает около 3х часов и, при хорошей подготовке, оставляет около 60-70 вопросов помеченными, на что вполне хватает оставшегося часа.

По результатам экзамена, вы получаете распечатку своих результатов и, если все хорошо, уже на следующий день сможете найти себя в PMP registry.

Удачи!

Источник: http://habrahabr.ru/blogs/pm/

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

Другая ситуация. Для проекта понадобилась система прав доступа и ее реализовал один из участников команды. Библиотека получилась мощная, гибкая и в целом удобная. Ее начинают активно использовать и спустя какое-то время замечают что многие игнорируют правила работы с библиотекой (соглашения) в результате чего код запутывается, появляется много дублирования, постоянно возникают ситуации что доступ к функционалу имеет не тот кто должен и никто не в состоянии быстро разобраться в хитросплетениях правил доступа.

Что объединяет эти ситуации? Недостаточный контроль за процессом. Контролировать можно совершенно по разному и ниже я хочу поделиться своими мыслями по поводу того как лучше это делать и почему.

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

Примеры:

Внешние ключи в базе данных — внутренний контроль.

По умолчанию «все запрещено» с помощью acl — внутренний контроль.

Менеджер смотрит коммит к тикету — внешний контроль.

Статический анализ кода — внешний контроль.

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

Внутренний контроль

— База должна самостоятельно поддерживать свою целостность (fk, check) и быть максимально строгой в отношении входных данных. Тогда большинство ошибок разработки будут выявлены на самых ранних этапах.

— Всегда используется принцип «все что не разрешено — запрещено».

— При проектировании внутренних компонентов нужно стремиться к минимизации правил которых придется придерживаться в процессе и спользования. Иногда даже ценой потери гибкости (но так чтобы это не стало проблемой и препятствием). И философия python в помощь.

— Пользуйтесь моками в тестах только в случае острой необходимости (внешняя служба), иначе на каждую строчку в реальном коде придется менять несколько строк в тесте, и в конце концов это станет невыносимым бременем для всей команды.

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

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

— Код который пишется или используется первый раз (первый демон, первое использование acl или любого другого компонента) должен быть написан очень качественно, ведь в дальнейшем все будут ориентироваться именно на него.

— Программирование в парах повышает качество кода.

Внешний контроль

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

— Организуйте процесс разработки так, чтобы весь код проходил через «главного разработчика». Используйте не соглашения, а правила самой VCS, дающие доступ на запись в trunk (master) только ему.

— Используйте непрерывную интеграцию. И красный флаг не должен становиться нормой.

— Выработайте требования к коду и проводите ревью.

Конечно же это не все. Ниже несколько примеров применения описываемого подхода в реальном коде.

У нас в проекте куча демонов, фреймворк предлагает наследовать класс и переопределить метод run. Естественно, что в этом методе можно написать целиком код небольшого демона (что на практике часто и делали). Добраться до такого кода и протестировать его — почти нереально. Логичное решение — попросить всех писать отдельные классы для каждого демона, а в методе run делать только вызов. Но это работает только при максимальном внешнем контроле, поэтому лучше перекрыть прямой доступ к этой части фреймворка и требовать передачи класса демона в свой прокси-код. Всю работу по запуску сделает он, а написать неправильно — просто нельзя либо очень трудно. Наверное это и есть «синтаксический уксус ©».

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

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

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

Я думаю что у многих найдется что сюда добавить. Буду рад услышать ваш опыт.

Источник: http://habrahabr.ru/blogs/pm/

В любом проекте команде требуется от 2-4 месяцев для вливания нового участника и восстановления после замедления:

• Новичок должен быть подготовлен: изучить ваш код, как ваше приложение работает, правила оформления кода, ваш стиль работы…
• Новичок нарушит формирование команды (смотрите модель Такмена), что весьма существенно, если команда уже достигла производственной стадии. Это происходит, поскольку новичок изменяет каналы связи и вынуждает участников пересмотреть отношения во всей команде.
• Новичок будет для команды обузой, нуждающейся в поддержке при изучении новых задач.
• Новичок увеличит сложность общения (число каналов связи) в команде.

Все это приводит нас к открытию закона Брукса (книга «Мифический человеко-месяц» 1975 год):

Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.

Физика людей не изменилась за прошедшие 35 лет. Так что мы можем сделать для решения этой проблемы?

• Скажите «нет» добавлению участников, если уже слишком поздно. Довольно часто, 4-5 месяцев до релиза — слишком поздно.
• Не можете сказать «нет» — примите во внимание, что было сделано на проекте Udall (книга «Surviving Object-Oriented Projects», Алистер Коберн): остановите большой проект, начните небольшой и включите только тех сотрудников, кто может способствовать его удачному завершению. Хотя иметь сидящих сложа руки сотрудников накладно — это может быть выгоднее, чем позволить им затормозить проект.
• Включайте всех новых сотрудников одномоментно. Это позволит вам пройти через все негативные моменты один раз, а не при добавлении каждого нового участника.
• Создайте новую команду из новичков и одним-двумя старыми участниками. Они не сделают многого, но, по крайней мере, они не будут мешать другим.
• Привлеките новичков к исследовательскому тестированию, с упором на истории текущей итерации.
• Предложите им написать или отрефакторить автоматизированные приёмочные тесты.
• Привлеките их к чтению и написанию unit-тестов. Начните с изучения существующих unit-тестов — это способствует пониманию кода. Если тесты ещё не «хорошие», найдите время для их усовершенствания. Если с тестами всё хорошо, перейдите к незначительному рефакторингу основного кода — в конце концов вы можете доверять собственным тестам, не так ли :)
• Используйте парное программирование с другими разработчиками.

Просто помните: привлечение сотрудников на проект — способ замедлить его разработку.

Источник: http://habrahabr.ru/blogs/pm/