<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Управление проектами &#187; Управление</title>
	<atom:link href="http://pm.by/category/articles/management/feed/" rel="self" type="application/rss+xml" />
	<link>http://pm.by</link>
	<description>в сфере разработки программного обеспечения</description>
	<lastBuildDate>Thu, 02 Sep 2010 12:57:47 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Прибыльность проекта</title>
		<link>http://pm.by/articles/calculating-project-profit/</link>
		<comments>http://pm.by/articles/calculating-project-profit/#comments</comments>
		<pubDate>Sun, 17 Jan 2010 20:34:19 +0000</pubDate>
		<dc:creator>Сергей Синькевич</dc:creator>
				<category><![CDATA[Статьи]]></category>
		<category><![CDATA[Управление]]></category>
		<category><![CDATA[финансы]]></category>

		<guid isPermaLink="false">http://pm.by/?p=191</guid>
		<description><![CDATA[Для чего запускаются проекты?.. В большинстве случаев ответ очевиден — с целью извлечения прибыли. На словах звучит неплохо, но когда дело доходит до цифр &#8212; часто начинаются проблемы. Оказывается, что не всегда очевиден даже размер полученной прибыли в прошлом, а ведь нам хотелось бы еще и считать предполагаемую на будущее&#8230;
Чтобы немного разобраться в этом достаточно тонком вопросе, давайте рассмотрим [...]]]></description>
			<content:encoded><![CDATA[<p>Для чего запускаются <a title="что такое проект?" href="http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82">проекты</a>?.. В большинстве случаев ответ очевиден — с целью извлечения <a title="что такое прибыль" href="http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%B1%D1%8B%D0%BB%D1%8C" target="_blank">прибыли</a>. На словах звучит неплохо, но когда дело доходит до цифр &#8212; часто начинаются проблемы. Оказывается, что не всегда очевиден даже размер полученной прибыли в прошлом, а ведь нам хотелось бы еще и считать предполагаемую на будущее&#8230;</p>
<p>Чтобы немного разобраться в этом достаточно тонком вопросе, давайте рассмотрим такую часто встречающуюся ситуацию: Вы &#8212; менеджер проекта в проектной организации. Пусть Ваша организация занимается заказной разработкой программного обеспечения. Одновременно ведется множество разных проектов. Конкретно Ваш проект длится уже давно и планируется еще надолго. Заказчик платит за проведенную для него работу помесячно и без задержек.</p>
<p>Далее пробуем посчитать &#8212; насколько же ваш проект выгоден? :-)</p>
<p><span id="more-191"></span></p>
<p>Воспользуемся простейшим определением из <a title="и всё-таки, что же такое прибыль?" href="http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%B1%D1%8B%D0%BB%D1%8C" target="_blank">википедии</a>, гласящим о том что прибыль &#8212; это превышение в денежном выражении доходов от продажи товаров и услуг над затратами на производство и сбыт этих товаров и услуг. Существуют разные типы как учёта, так и классификации прибыли (<a title="Бухгалтерская прибыль" href="http://ru.wikipedia.org/wiki/%D0%91%D1%83%D1%85%D0%B3%D0%B0%D0%BB%D1%82%D0%B5%D1%80%D1%81%D0%BA%D0%B0%D1%8F_%D0%BF%D1%80%D0%B8%D0%B1%D1%8B%D0%BB%D1%8C"><em>бухгалтерская прибыль</em></a><em>, </em><a title="Экономическая прибыль" href="http://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D0%BF%D1%80%D0%B8%D0%B1%D1%8B%D0%BB%D1%8C"><em>экономическая прибыль</em></a><em>, </em><a title="Валовая прибыль" href="http://ru.wikipedia.org/wiki/%D0%92%D0%B0%D0%BB%D0%BE%D0%B2%D0%B0%D1%8F_%D0%BF%D1%80%D0%B8%D0%B1%D1%8B%D0%BB%D1%8C"><em>валовая прибыль</em></a><em>, </em><a title="Чистая прибыль" href="http://ru.wikipedia.org/wiki/%D0%A7%D0%B8%D1%81%D1%82%D0%B0%D1%8F_%D0%BF%D1%80%D0%B8%D0%B1%D1%8B%D0%BB%D1%8C"><em>чистая прибыль</em></a>). Однако, давайте для начала не усложнять, и рассмотрим простую формулу в виде разности двух упомянутых выше понятий: <strong>Прибыль = Доход &#8211; Затраты</strong>.</p>
<p>Итак, вы знаете что за предыдущий месяц по договору вы получили от заказчика 1000 тугриков. Это, собственно, и есть весь <a title="что такое доход" href="http://ru.wikipedia.org/wiki/%D0%94%D0%BE%D1%85%D0%BE%D0%B4" target="_blank">доход</a> за оказанные Вами для заказчика услуги.</p>
<p>Давайте теперь посчитаем <a title="что такое затраты?" href="http://ru.wikipedia.org/wiki/%D0%97%D0%B0%D1%82%D1%80%D0%B0%D1%82%D1%8B" target="_blank">затраты </a>на оказание этих услуг. Что же происходило? :) Программисты программировали, тестировщики тестировали, и так далее &#8212; обобщая, люди тратили рабочее время на заказчика. Зарплата всех работников, задействованых в проекте, суммарно составила 600 тугриков. И сколько же у нас получается прибыли для организации? 400 тугриков?</p>
<p>Конечно же, нет. Для начала давайте вспомним, что в прошедшем месяце мы дополнительно купили для нужд программистов специализированную программную компоненту, стоимостью 100 тугриков. Что ж, добавим её к затратам, проверим чтобы больше ничего не забыли &#8212; вуаля, получаем прибыль в 300 тугриков?..</p>
<p>И снова стоп. Кроме затрат на собственно оплату труда, компания несет множество других затрат: аренда офиса, затраты на оборудование (те же компьютеры, интернет и т.д.), оплата труда административных работников  и прочие косвенные затраты, которые также надо учитывать при расчете прибыльности.</p>
<p>Однако, эти затраты уже не так легко посчитать в применении к одному отдельно взятому проекту в организации. Для этого необходимо некоторое соглашение о правилах расчетов, или же, говоря другими словами, необходимо иметь некую <em>модель проектных затрат</em>,  которая и поможет провести все необходимые расчеты. В приведенном выше примере такая модель добавит, скажем, еще 200 тугриков к общим проектным затратам, снизив полученную нами прибыль до 100.</p>
<p>В следующих заметках мы попробуем составить нашу <em>модель </em>и научиться ею пользоваться.</p>
<p>Если у вас есть что добавить по этому вопросу &#8212; добро пожаловать в комментарии :-)</p>
]]></content:encoded>
			<wfw:commentRss>http://pm.by/articles/calculating-project-profit/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Исполнитель и многозадачность.</title>
		<link>http://pm.by/articles/management/ispolnitel-i-mnogozadachnost/</link>
		<comments>http://pm.by/articles/management/ispolnitel-i-mnogozadachnost/#comments</comments>
		<pubDate>Mon, 11 Jan 2010 19:09:33 +0000</pubDate>
		<dc:creator>Денис Журавлев</dc:creator>
				<category><![CDATA[Управление]]></category>
		<category><![CDATA[Многозадачность]]></category>

		<guid isPermaLink="false">http://pm.by/articles/management/ispolnitel-i-mnogozadachnost/</guid>
		<description><![CDATA[Многозадачность для исполнителя имеет свои особенности, в отличии от <a href="http://pm.by/managers/menedzher-i-mnogozadachnost/">многозадачности менеджера</a>, которые необходимо осознавать и эффективно ими пользоваться.
Представим ситуацию: есть 1 программист и 3 менеджера разных проектов, все нагрузили его работой, и сидят счастливые в ожидании, когда работа будет выполнена, и они получать свою часть прибыли. Хочу сказать, что ситуация вполне реальная, возможно у программистов выражена не так ярко, но для дизайнеров, более чем типичная.]]></description>
			<content:encoded><![CDATA[<p>Многозадачность для исполнителя имеет свои особенности, в&nbsp;отличии от&nbsp;<a href="http://pm.by/managers/menedzher-i-mnogozadachnost/">многозадачности менеджера</a>, которые необходимо осознавать и&nbsp;эффективно ими пользоваться.</p>
<p>Представим ситуацию: есть 1&nbsp;программист и&nbsp;3&nbsp;менеджера разных проектов, все нагрузили его работой, и&nbsp;сидят счастливые в&nbsp;ожидании, когда работа будет выполнена, и&nbsp;они получать свою часть прибыли. Хочу сказать, что ситуация вполне реальная, возможно у&nbsp;программистов выражена не&nbsp;так ярко, но&nbsp;для дизайнеров, более чем типичная.</p>
<p><span id="more-190"></span></p>
<p>Честный программист оценил каждую задачу в&nbsp;3&nbsp;дня. И&nbsp;приступил к&nbsp;выполнению. Менеджер, как человек ответственный, не&nbsp;забывает напоминать несчастному программисту о&nbsp;том, что заказчик ждет с&nbsp;нетерпением его задачу уже вчера. В&nbsp;результате чего, программист, переключаясь между задачами все&nbsp;же успел уложиться в&nbsp;первоначальные оценки и&nbsp;выполнить все задачи без задержек.</p>
<p>Однако в&nbsp;результате переключений на&nbsp;выполнение каждой задачи потребовалось ~7&nbsp;дней. Первый менеджер получил задачу на&nbsp;4&nbsp;дня позже чем мог&nbsp;бы, соответственно были задержаны другие задания связанные с&nbsp;выполненным далее по&nbsp;цепочке (тестирование, релиз и&nbsp;т.п.), была задержана оплата и&nbsp;т.п.</p>
<p><img src='http://pm.by/wp-content/uploads/multitasking_1.png' alt='multitasking_1.png' width="450"/></p>
<p>На&nbsp;картинке 1&nbsp;изображен идеальный вариант, когда не&nbsp;было проблем и&nbsp;проволочек, представим чтобы было если&nbsp;бы вторая задача была задержана на&nbsp;1&nbsp;день. В&nbsp;результате срок завершения каждой из&nbsp;задач сдвинулся.</p>
<p><img src='http://pm.by/wp-content/uploads/multitasking_2.png' alt='multitasking_2.png' width="450"/></p>
<p>В&nbsp;случае если&nbsp;бы самих менеджеров с&nbsp;их&nbsp;задачами поставить в&nbsp;очередь, задачи выполнялись&nbsp;бы последовательно и&nbsp;картина получилась совсем другая:</p>
<p><img src='http://pm.by/wp-content/uploads/multitasking_3.png' alt='multitasking_3.png' width="450"/></p>
<p>Конечно, в&nbsp;определенных случаях менеджера-проекта устроят оба варианта. Особенно если задачи имеют некоторые риски, которые неплохо было&nbsp;бы прощупать на&nbsp;ранних этапах работ. Однако на&nbsp;мой взгляд последовательное выполнение задач (и&nbsp;даже проектов) имеет больше преимуществ, чем мультизадачность.</p>
<p>В&nbsp;заключение приведу несколько общих рекомендаций:</p>
<ul>
<li>Создавайте очередь задач исполнителю с&nbsp;определенными приоритетами. Необходимо однозначное понимание что, зачем следует выполнять. Очередь необходима для того чтобы исполнитель мог переключаться на&nbsp;следующую задачу, при завершении текущей (а&nbsp;не&nbsp;сидеть в&nbsp;ожидании), либо при невозможности выполнения текущей (на&nbsp;время разрешенная появившихся вопросов) опять&nbsp;же дело не&nbsp;стаяло на&nbsp;месте.</li>
<li>Все задачи должны быть в&nbsp;одном месте (системе, программе или т.п.) Чтобы задания не&nbsp;терялись и&nbsp;не&nbsp;размывались между системами. Чтобы была возможность контролировать, кто, чем занимается в&nbsp;данный момент, сколько у&nbsp;кого уходит времени.</li>
<li>Каждая задача помимо приоритета должна иметь оцененный срок выполнения, чтобы менеджер мог эффективно управлять своими ресурсами.</li>
</li>
]]></content:encoded>
			<wfw:commentRss>http://pm.by/articles/management/ispolnitel-i-mnogozadachnost/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Московский метод</title>
		<link>http://pm.by/articles/management/moskovskij-metod/</link>
		<comments>http://pm.by/articles/management/moskovskij-metod/#comments</comments>
		<pubDate>Sun, 03 Jan 2010 21:44:04 +0000</pubDate>
		<dc:creator>Денис Журавлев</dc:creator>
				<category><![CDATA[Управление]]></category>

		<guid isPermaLink="false">http://pm.by/articles/management/moskovskij-metod/</guid>
		<description><![CDATA[<p>Начну с&#160;истории из&#160;реальной жизни. Был у&#160;нас один заказчик, который предпочитал сам выставлять приоритеты требованиям и&#160;багам. Все начиналось классически&#160;&#8212; High, Medium, Low. Однако в&#160;какой-то момент он&#160;решил усовершенствовать эту систему и&#160;добавил Very High. Но&#160;со&#160;временем и&#160;этого оказалось мало, появился приоритет Urgent. Наверное, это может продолжаться и&#160;дальше.</p>]]></description>
			<content:encoded><![CDATA[<p>Начну с&nbsp;истории из&nbsp;реальной жизни. Был у&nbsp;нас один заказчик, который предпочитал сам выставлять приоритеты требованиям и&nbsp;багам. Все начиналось классически&nbsp;&mdash; High, Medium, Low. Однако в&nbsp;какой-то момент он&nbsp;решил усовершенствовать эту систему и&nbsp;добавил Very High. Но&nbsp;со&nbsp;временем и&nbsp;этого оказалось мало, появился приоритет Urgent. Наверное, это может продолжаться и&nbsp;дальше.</p>
<p><img style="margin-left: 0px" title='MoSCoW method' border="0" hspace="25" alt='MoSCoW method' align="left" src="http://pm.by/wp-content/uploads/moscow_star.jpg" width="200" height="148" />В&nbsp;другом проекте, при приоритизации требований, использовались аналогичные приоритеты (1,2,3). И&nbsp;нам как разработчикам не&nbsp;всегда удавалось определить логику которая двигала людьми из&nbsp;бизнеса при приоритизации, особенно вызывал внутренний конфликт высокий приоритет юзабилити требований, при низких приоритетах функциональных. </p>
<p><span id="more-182"></span></p>
<p>Однако прогресс не&nbsp;стоит на&nbsp;месте. И&nbsp;один из&nbsp;консультантов Oracle UK&nbsp;Consulting, Dai Clegg предложил логичный и&nbsp;понятный метод приоритизации для бизнес анализа и&nbsp;разработки ПО&nbsp;&mdash; <i>MoSCoW prioritization</i>.</p>
<p>Этот метод приоритизации чаще всего используется при фиксированных дедлайнах, когда все внимание должно быть обращено на&nbsp;самые важные требования. И&nbsp;при его использовании можно ожидать более высоких ROI на&nbsp;проекте, так как всё сосредоточено на&nbsp;главном, жертвуя второстепенным.</p>
<p>MoSCoW&nbsp;&mdash; легко запоминающаяся аббревиатура:</p>
<blockquote><p><b>M</b>&nbsp;&mdash; MUST have this.</p>
<p><b>S</b>&nbsp;&mdash; SHOULD have this if&nbsp;at&nbsp;all possible.</p>
<p><b>C</b>&nbsp;&mdash; COULD have this if&nbsp;it&nbsp;does not affect anything else.</p>
<p><b>W</b>&nbsp;&mdash; WON&rsquo;T have this time but WOULD like in&nbsp;the future.</p>
</blockquote>
<p><b>Must have&nbsp;&mdash; Жизненно необходимые</b></p>
<p>Требования отмеченные как MUST have должны быть включены в&nbsp;текущую поставку. Если хоть одно из&nbsp;требований не&nbsp;сделано, поставка считается провальной.</p>
<p><b>Should have&nbsp;&mdash; Обязательные</b></p>
<p>Требования SHOULD have также критичны для успеха проекта, но&nbsp;не&nbsp;необходимы в&nbsp;ближайших поставках. Такие требования имеют workarounds, то&nbsp;есть имеются обходные пути для выполнения требований, и&nbsp;могут быть отложены на&nbsp;будущие поставки продукта.</p>
<p><b>Could have&nbsp;&mdash; Пожалуй можно реализовать</b></p>
<p>Требования COULD have менее критичные требования, обычно относящиеся к&nbsp;&laquo;nice to&nbsp;have&raquo;. Чаще всего менее трудоёмки чем первые 2&nbsp;категории.</p>
<p><b>Won&rsquo;t have (but Would like)&nbsp;&mdash; Можно и&nbsp;не&nbsp;делать, но&nbsp;хотелось&nbsp;бы</b></p>
<p>Наименее критичные или не&nbsp;самые подходящие в&nbsp;данные момент времени. И&nbsp;как результат данные требования не&nbsp;планируются в&nbsp;ближайшие поставки. Также эти требования часто первыми исключаются из&nbsp;последующих поставок, при реприоритизации. Однако это не&nbsp;делает их&nbsp;менее важными, и&nbsp;эти требования относят к&nbsp;отряду улучшений на&nbsp;будущее. Вот этот тонкий момент иногда сбивает пользователей с&nbsp;толку, так как данные требования стоят в&nbsp;одном ряду с&nbsp;остальными.</p>
<p><b>Ссылки:</b></p>
<p><a href="http://en.wikipedia.org/wiki/MoSCoW_Method">http://en.wikipedia.org/wiki/MoSCoW_Method</a></p>
<p><a href="http://www.projectsmart.co.uk/moscow-method.html">http://www.projectsmart.co.uk/moscow-method.html</a></p>
<p><a href="http://www.coleyconsulting.co.uk/moscow.htm">http://www.coleyconsulting.co.uk/moscow.htm</a></p>
]]></content:encoded>
			<wfw:commentRss>http://pm.by/articles/management/moskovskij-metod/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Задо-прикрывательное управление проектами</title>
		<link>http://pm.by/articles/ass-covering-project-management/</link>
		<comments>http://pm.by/articles/ass-covering-project-management/#comments</comments>
		<pubDate>Fri, 25 Jan 2008 13:51:56 +0000</pubDate>
		<dc:creator>Денис Журавлев</dc:creator>
				<category><![CDATA[Статьи]]></category>
		<category><![CDATA[Управление]]></category>
		<category><![CDATA[команда]]></category>

		<guid isPermaLink="false">http://pm.by/articles/ass-covering-project-management/</guid>
		<description><![CDATA[Можно дать много определений управлению проектами. Я бы сказал, что определение будет отличаться в зависимости от того как движется проект, его размера, состояния клиента на момент окончания и т.п.
И, безусловно, существуют проекты, которые можно, по крайней мере частично, определить как задо-прекрывательные.]]></description>
			<content:encoded><![CDATA[<p><img style="margin: 5px 0px 0px" alt="Задо-прикрывательное управление проектами" src="http://pm.by/wp-content/uploads/42-17577994.jpg" align="right"></p>
<p>Можно дать много определений управлению проектами. Я&nbsp;бы&nbsp;сказал, что определение будет отличаться в&nbsp;зависимости от&nbsp;того как движется проект, его размера, состояния клиента на&nbsp;момент окончания и&nbsp;т.п.</p>
<p>И, безусловно, существуют проекты, которые можно, по&nbsp;крайней мере частично, определить как задо-прекрывательные.</p>
<p><span id="more-72"></span></p>
<p>Это происходит, как правило, когда выполняется хотя бы&nbsp;одно условие:</p>
<ul> 
<li>Клиент постоянно меняет границы проекта (scope).
<li>Существует значительные задержки, которые не&nbsp;могут быть четко приписаны одной из&nbsp;сторон.
<li>Проектые группы не&nbsp;любят друг друга.
<li>Выбор поставщика является политическим решением. </li>
</ul>
<p> 
<p>Понятно, что методы управления проектом могут не&nbsp;нравиться большинству людей, но&nbsp;не&nbsp;вам, так как вы&nbsp;являетесь ключевой фигурой, принимающей решения. Обычно вы&nbsp;просто следуете определенным правилам. Если же&nbsp;вам не&nbsp;повезло и&nbsp;вы&nbsp;рабодаете в&nbsp;режиме задо-прекрывательства вам лучше пойти и&nbsp;получить/уточнить эти правила.</p>
<p>Иначе вам придеться добавлять кучу функциональности, которая не&nbsp;планировалась. Или реконфигурировать среду множество раз, вместо того, чтобы сделать это за&nbsp;один раз. Или быть обвиненным в&nbsp;проблемах, за&nbsp;которые вы&nbsp;не&nbsp;были ответственны. Или платить штрафы, которые являются совершенно не&nbsp;справедливыми. Ничего приятного в&nbsp;этом конечно нет.</p>
<p>С другой стороны, когда вы&nbsp;ведете проект в&nbsp;таком стиле, который, если это возможно, я&nbsp;рекомендую избегать, проект может доставить вам большую радость если у&nbsp;вас будет прикрыт зад, в&nbsp;то&nbsp;самое время когда это действительно понадобится.</p>
<p>Все это касается получения доказательств того, что действительно было договорено. Это не&nbsp;всегда так легко, как кажется. Как действовать, когда вы&nbsp;в&nbsp;конечном итоге оказались в&nbsp;этой ситуации?</p>
<ol> 
<li><strong>Письмо о&nbsp;принятых решениях и&nbsp;дальнейших действиях (<nobr>Follow-up</nobr>).</strong> <br />В такой обстановке вы&nbsp;не&nbsp;получите больше информации на&nbsp;бумаге или в&nbsp;электронных письмах. Большинство сообщений будет сделано по&nbsp;телефону. Почему? Чтобы не&nbsp;было доказательств. Не&nbsp;было стресса. После важных (с&nbsp;вашей точки зрения) телефонных звонков просто потратьте <nobr>какое-то</nobr> время, чтобы написать письмо о&nbsp;дальнейших действиях и&nbsp;договоренностях : <em>&laquo;Как мы&nbsp;договорились в&nbsp;ходе нашего телефонного разговора &hellip;&raquo;. </em>Вы должны действовать, как будто вы&nbsp;просто хотите подтвердить или уточнить согласованные детали.</p>
<li><strong>Успокойтесь.</strong> <br />Вы будете получать сообщения, которые вызовут у&nbsp;вас гнев. Нечестные, не&nbsp;соответствует действительности. Вы будете торопиться гневно отвечать на&nbsp;такие письма. Подождите. Успокойтесь. Когда вы&nbsp;в&nbsp;гневе, есть вероятность написать то,&nbsp;о&nbsp;чем можно в&nbsp;дальнейшем пожалеть. Хитрость здесь заключается в&nbsp;том, чтобы написать ответ мгновенно, но,&nbsp;вместо отправки сообщения прочитать его, а&nbsp;затем удалить. Затем написать ответ еще раз.&nbsp;В экстримальных ситуациях я&nbsp;посылаю письмо с&nbsp;третьего раза.
<li><strong>Просите доказательств.</strong> <br />В атмосфере когда пытаются подловить на&nbsp;чем либо другую сторону вы&nbsp;часто сталкнетесь с&nbsp;ситуацией, когда <nobr>кто-то</nobr> имеет в&nbsp;виду или подразумевает <nobr>что-либо</nobr>, о&nbsp;чем вы&nbsp;еще не&nbsp;договаривались или не&nbsp;делали.&nbsp;В этом случае просите доказательств . Не&nbsp;рассматривайте эту ситуацию как нормальное положение дел, и&nbsp;утверджайте, что ничего подобного не&nbsp;обсуждалось и&nbsp;нигде не&nbsp;оговаривалось. И&nbsp;поскольку правда на&nbsp;вашей стороне, скорее всего вы&nbsp;больше не&nbsp;услышите подобных обвинений.
<li><strong>Будьте активны.</strong> <br />Рассматривайте это как игру. Вы не&nbsp;только должны защищаться, но&nbsp;вы&nbsp;можете также атаковать противника. Подумайте немного должна ли&nbsp;вам <nobr>что-то</nobr> другая сторона. Если да,&nbsp;то&nbsp;просто напишите красивое письмо: <em>&laquo;Так как Вы еще не&nbsp;завершили вашу задачу мы&nbsp;не&nbsp;можем продолжать этот проект в&nbsp;этой области, и&nbsp;это предлагает задержку в&nbsp;&hellip;&raquo; </em>Вы будете удивлены, каким образом это может улучшить участие другой стороны в&nbsp;завершении их&nbsp;работы.
<li><strong>Обострение (Escalate).</strong> <br />Исспользуйте организационные структуры обеих компаний (своей и&nbsp;клиента).&nbsp;В зависимости от&nbsp;проблемы, иногда, давайте о&nbsp;ней знать более высоким чинам,это может значительно помочь в&nbsp;ее&nbsp;разрешении. Особенно, когда все действия разворачиваются слишком далеко от&nbsp;вас. Здесь я&nbsp;не&nbsp;буду давать вам простых советов, когда следет эскалировать, если не&nbsp;остается ничего другого. Вы должны попробовать оценить ситуацию и&nbsp;пойти на&nbsp;то,&nbsp;что вам показалось наиболее подходящим в&nbsp;данный момент. Помните, что чрезмерные эскалации могут привести к&nbsp;добавлению вас в&nbsp;&laquo;в&nbsp;черный список&raquo; не&nbsp;умеющих принимать самостоятельные решения.</li>
</ol>
<p> 
<p>Небольшое замечание: я&nbsp;не&nbsp;рекомендую доводить ваш проект до&nbsp;состояния прикрытия задов. Но&nbsp;к&nbsp;сожалению, это часто не&nbsp;ваше решение и,&nbsp;в&nbsp;редких случаях вы&nbsp;можете изменить его. Помните, вы&nbsp;не&nbsp;беззащитны.</p>
<p>Оригинал статьи: Pawel Brodzinski <a href="http://blog.brodzinski.com/2008/01/ass-covering-project-management.html"><nobr>Ass-covering</nobr> Project Management</a></p>
<p> <br />
<blockquote>
<p>В этой заметке не&nbsp;описаны ситуации когда сам менеджер проекта приводит проект к&nbsp;такому печальному состоянию. Несколько рекомендаций:</p>
<p> 
<ul> 
<li>Если вы&nbsp;работаете с&nbsp;клиентом первый раз, то&nbsp;причин сильно доверять ему мало.
<li>Наладьте процесс управления изменениями на&nbsp;своем проекте.
<li>Закрепите методы управления проектом на&nbsp;бумаге.
<li>Не позволяйте клиенту управлять вашим рабочим процессом. Будте буфером между клиентом и&nbsp;командой.
<li>Требуйте подтверждения всех новых требований после собраний в&nbsp;писменной форме, это заодно позволит определить правильно ли&nbsp;вы&nbsp;поняли &ldquo;хотелки&rdquo;.</li>
</ul>
</blockquote>
]]></content:encoded>
			<wfw:commentRss>http://pm.by/articles/ass-covering-project-management/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>Из двух стилей управления выбираем… оба!</title>
		<link>http://pm.by/articles/management/management-style/</link>
		<comments>http://pm.by/articles/management/management-style/#comments</comments>
		<pubDate>Mon, 17 Dec 2007 11:25:50 +0000</pubDate>
		<dc:creator>Денис Журавлев</dc:creator>
				<category><![CDATA[Управление]]></category>
		<category><![CDATA[методологии]]></category>

		<guid isPermaLink="false">http://pm.by/articles/management/management-style/</guid>
		<description><![CDATA[С проблемами в управлении персоналом сталкивается, за редким исключением, каждый руководитель. Развитие бизнеса во многом зависит от стиля отношений между сотрудниками фирмы. По мнению экспертов журнала «Консультант», авторитарный и демократичный подходы к менеджменту должны дополнять друг друга. Как же найти эту золотую середину?]]></description>
			<content:encoded><![CDATA[<p>С проблемами в управлении персоналом сталкивается, за редким исключением, каждый руководитель. Развитие бизнеса во многом зависит от стиля отношений между сотрудниками фирмы. По мнению экспертов журнала «Консультант», авторитарный и демократичный подходы к менеджменту должны дополнять друг друга. Как же найти эту золотую середину?Оценивая прибыльность проекта, менеджер заявил: «Как шеф скажет, так и будет. Признает проект выгодным – насчитаем прибыль. Откажется – вычислим сумму убытков». Абсурдная ситуация? Вовсе нет. В компании с авторитарным стилем управления такое иногда случается.</p>
<p>Наиболее популярный пример авторитарного управления – империя Генри Форда. В начале прошлого века, благодаря исключительно жесткому, самоличному оперативному руководству, Форд захватил больше 50 процентов рынка автомобилей.</p>
<p>Этот факт мог бы служить веским аргументом в пользу автократии, если бы не дополнялся другим. В течение следующего десятилетия, благодаря тому же стилю управления, Форд терял рынок и деньги.</p>
<p>Как показала история, авторитарный стиль эффективен в нестабильных ситуациях. Он предназначен для захвата власти или рынков. Главное его преимущество – скорость принятия и исполнения решений.</p>
<p>Демократический стиль эффективен в ситуации, когда необходимо удерживать и постепенно увеличивать завоевания, создавать внутреннюю стабильность в фирме. Его сильная сторона – детальная проработанность решений.<br />
Этот принцип был подмечен еще в Древнем Риме. В период кризиса Рим выбирал диктатора, осуществлявшего авторитарное управление. Когда наступала стабильность, демократическая форма правления восстанавливалась.<br />
Руководители российских компаний долгое время придерживались авторитаризма. Отечественный бизнес исходил из предпосылки, что человек неорганизован, немножко ленив, его надо контролировать. Сегодня, когда в России появляется все больше представительств западных компаний с их демократичными взглядами на персонал, применять жесткие методы уже не результативно.</p>
<p>К сожалению, большинство наших предприятий меняют свою стратегию медленно и не очень охотно. И это в то время, как американское и западноевропейское общества уже в середине прошлого века начали придерживаться гуманистического направления. Руководители компаний этих стран верят в человека и в то, что он постоянно желает развиваться. Захотят ли русские управленцы «примерить» демократический стиль на себя?</p>
<h3>Управление по-восточному</h3>
<p>Принципиально новый подход к управлению компанией предложил ведущий идеолог Sony Corporation Сигеру Кобаяси. Суть метода – строго следовать дзенбуддийскому принципу «My», что можно толковать как «неопредметливание» или «неовеществление». Применительно к практике Sony Corporation это означает сознательный отказ от составления жестких планов. Должностное лицо компании обязано всегда действовать по обстановке, стремясь не упустить неожиданные выгоды. При этом не надо настаивать на выполнении планов, если предприятие сталкивается с непредусмотренными и непреодолимыми препятствиями</p>
<h3>«Демократия российских компаний не за горами&#8230;»</h3>
<p>На сегодняшний день большинству отечественных компаний присущ авторитарный стиль управления. Многие годы именно такой подход превалировал на наших предприятиях. Но со временем авторитаризм все больше вытесняется демократичным подходом в работе. Однако полный переход к демократии, на наш взгляд, утопия. В бизнесе обязательно должна быть авторитарная составляющая, которая бы органично дополняла демократическую. В идеале компании хорошо бы достичь необходимого и достаточного баланса между этими сторонами управления. В то же время надо следить, чтобы чаша весов не перевесила в одну сторону и не наступила полная демократия или полный авторитаризм.</p>
<h3>Кто принимает решения?</h3>
<p>В России довольно неплохо прижились многие принципы западного менеджмента. Но, к сожалению, их используют не все отечественные компании. В первую очередь это касается вовлечения персонала в процесс принятия решения. Данный фактор позволяет сотрудникам не только ощущать себя частью компании, но и повышает их ответственность в работе над проектом. Весьма часто получается так, что работник, находящийся в подчинении, может намного профессиональнее разбираться в конкретном вопросе, нежели непосредственный руководитель. Так почему бы не узнать его мнение по конкретному вопросу? Ведь это очень хороший мотивирующий фактор для персонала. Однако в России он пока не работает. В большей степени роль играет обычная психология человека, наделенного властью, – «Пусть будет по-моему!».</p>
<h3>В России проблемы с информированностью персонала</h3>
<p>Немногие российские компании уделяют достаточно внимания работе с персоналом.</p>
<p>Все процессы на предприятии так или иначе идут благодаря работе каждого отдельного работника. Но всегда ли сотрудники российской компании осознают это? Конечно, нет. Зачастую на отечественных предприятиях информация о достижениях компании, ее общей стратегии не доходит до персонала. Принятые наверху решения могут не доноситься до сотрудников в полной мере. Таким образом, возникает ситуация, когда персонал, работая в одном направлении, начинает сопротивляться тем нововведениям и сменам курса, которые происходят в организации. Последствия этого понятны.</p>
<p>Конечно, в нашей стране есть яркие примеры, когда отлаженное сотрудничество отделов и подразделений компании приносит очень хорошие результаты. Но достичь этого очень трудно. При этом следует помнить, что результаты такой кропотливой работы не всегда видны сразу. В большинстве случаев их можно оценить лишь косвенно, да и то через некоторое время. Сейчас, к сожалению, наблюдается тенденция, когда многие руководители российских компаний просто недооценивают важность работы с персоналом, его информированность.</p>
<h3>На что идут отечественные работодатели?</h3>
<p>С приходом в нашу систему элементов западного управления поменялся и подход к продвижению сотрудников по служебной лестнице. Сейчас недостаточно просто хорошо и качественно выполнять свои обязанности. Настало время, когда руководители наших фирм отдают предпочтение людям со смелыми идеями. Эта тенденция, без сомнения, навеяна Западом.</p>
<p>Сегодня руководство российских компаний понимает, что привлечь настоящего профессионала можно только с помощью сильной мотивации. В этой связи хорошей тенденцией стало то, что с недавнего времени крупные отечественные предприятия постепенно начинают использовать так называемые «белые» схемы оплаты труда. Данный подход не только обеспечивает сотруднику возможность увереннее смотреть в завтрашний день, но и повышает статус работодателя. Наряду с этим многие крупные российские компании внедряют различные системы поощрения сотрудников. Например, премии, корпоративные мероприятия, тренинги, семинары.</p>
<p>Конечно, пока не все гладко на нашем российском рынке и немногие компании подходят так серьезно к работе с персоналом. Но, на наш взгляд, в российских фирмах сотрудники чувствуют себя комфортнее и увереннее. Все-таки западный стиль работы не подразумевает гибкости по отношению к персоналу. Он основан на том, что в организации каждый сам за себя. В России же люди более склонны к коллективизму.</p>
<h3>Российские компании близки к демократии</h3>
<p>Охотно ли сотрудники с опытом работы в западной компании устраиваются в российскую? Все зависит от обстоятельств. Рассмотрим, например, Московский регион. Ритм жизни в нем намного быстрее. Поэтому переход из западной компании в российскую может быть довольно мягким как для руководителей среднего звена, так и для топ-менеджеров. Для последних такая смена работы скорее обусловлена невозможностью реализовать свои амбиции на прежнем месте. Переход же в российскую компанию может дать новый толчок в работе, открыть новые горизонты. То же самое применимо и к смене российской компании на западную, но тут есть и нюансы. Такой переход обусловлен большей престижностью, более высокой заработной платой, лучшими социальными условиями. Но, как уже было сказано, крупные российские компании медленно, но верно переходят к системам мотивации сотрудников, ответственнее начинают подходить к своему главному «золотому запасу» – людям. Поэтому, на наш взгляд, в скором времени российские компании не будут уступать западным.</p>
<p>Резюмируя, хотелось бы сделать акцент на особой специфике работы отечественных предприятий. А заключается она в том, что наши фирмы развиваются по своему собственному пути. Конечно, они обращаются к опыту коллег из западных компаний и перенимают положительные моменты. Но все же в российских организациях выработан собственный стиль работы, который непосредственно создается самими работниками и руководителями. В таких фирмах огромное влияние имеют человеческие отношения. Именно этот путь развития в управлении позволяет российским компаниям быть независимыми и профессиональными на рынке.</p>
<p>В некоторой степени можно допустить, что компании с западным капиталом мало чем отличаются от российских. Ведь работают в них в основном наши же менеджеры с национальным менталитетом. Разница лишь в том, что ими руководят западные управленцы, которые не всегда понимают суть отечественного бизнеса.</p>
<h3>«Западный стиль управления выигрывает перед российским&#8230;»</h3>
<p>Западный стиль управления часто называют современным или цивилизованным. Российский же подобных эпитетов лишают. В чем причина таких различий? Дело в том, что и в Европе, и в США органически сформировались крепкие традиции деловой культуры с общими корнями. В отличие от бурно развивающейся российской традиции они уже на уровне базовых понятий по-другому понимают такие организационно-культурные феномены, как бюрократия, предпринимательство, лидерство, командность, инициативность, дисциплина.</p>
<p>Западные компании пришли к тому, что значимость такого нематериального актива, как качественное корпоративное управление, находится в одном ряду со стоимостью основных активов и брендов. В российской же ситуации до сих пор больше ценятся материальные активы.</p>
<p>Миссия компании, стратегия, ценности, человек как их носитель и исполнитель – неотъемлемые компоненты управленческих практик для лучших западных компаний. Но, увы, не для отечественных. Безусловно, люди в команде должны не только разделять ценности и принципы, руководствуясь которыми они будут достигать поставленных целей, но они еще должны их принимать. Вот, собственно, коренное отличие западного подхода к менеджменту, ориентированного в первую очередь на результат и максимальное использование ключевых компетенций сотрудников. Именно этот фактор дает осязаемые преимущества в конкурентной борьбе перед традиционным российским подходом.</p>
<h3>На Западе решения принимают молниеносно</h3>
<p>Для управления компанией очень важно, чтобы дистанция между персоналом и топ-менеджментом была минимальной. То есть любой сотрудник может совершенно спокойно обратиться к директору, не испытывая при этом страха; высказать свое мнение, даже если оно некоторым образом отличается от позиции руководства. Короткая дистанция власти обеспечивает качественную обратную связь и высокую скорость принятия решений.</p>
<p>Оперативность решений – очень важный аспект современного управления, потому что сейчас время «спрессовано» как никогда. И здесь западный стиль управления, бесспорно, выигрывает перед российским. Ведь в отечественном менеджменте отношение ко времени определяется процессом, а не результатом. Часто можно услышать: «вопрос должен вылежаться», «решение нужно подвесить». И это даже тогда, когда данный вопрос является критичным для успеха бизнеса.</p>
<p>Например, в компании с западным стилем менеджмента очень четко сформулированы позиции лидерства и ответственности. Работа построена по горизонтальному принципу. Полномочия делегируются максимально, чтобы сократить расстояние от руководителя, принимающего решение, до исполнителя. Это обеспечивает и качество, и скорость принятия решений. При этом все сотрудники очень много общаются, что дает всем необходимый контекст понимания цели. Но как только решение принято, всем известно, кто за него несет ответственность. Это очень важный момент. При российском стиле управления часто невозможно понять, кто же все-таки принял то или иное решение, а кто отвечает за его последствия.</p>
<h3>Все корпоративные культуры отличаются друг от друга</h3>
<p>Само по себе понятие «управление» достаточно сильно связано с персональной культурой первых лиц компании. При этом совершенно не важно, российская это фирма или западная. Возьмем скандинавский стиль менеджмента, отличительной чертой которого является неиерархическая, «плоская» модель управления. То есть ответственность в компании децентрализована и распределена между топ-менеджерами. Они обходятся без секретарш и решают вопросы со своими сотрудниками напрямую, без барьеров. Согласитесь, такой подход отличается от американского. И это несмотря на то, что обе культуры являются западными.</p>
<p>Яркой иллюстрацией служит следующий пример. Американский менеджмент столкнулся с немецким в процессе объединения Daimler и Chrysler. На встрече в Детройте топ-менеджеры американской компании приехали на одном большом микроавтобусе, а представители немецкой компании на отдельных дорогих машинах. Этот случай хорошо иллюстрирует разницу корпоративных культур.</p>
<p>Поэтому, когда мы говорим о западном стиле управления, следует помнить, что корпоративные культуры конкретных компаний сильно разнятся. Но и бюрократическая, и предпринимательская модели в западных компаниях применяют схожие управленческие практики.</p>
<h3>Индикаторы качественного развития</h3>
<p>Анализируя теорию и практику, следует заметить, что российский менеджмент переживает сейчас очень интересное время становления. Исторически капитализм в России строился на базе управленческих принципов советской эпохи, то есть качественно другой экономической формации. Новые собственники поняли, что такого рода практика управления ограничивает развитие бизнеса, и начали агрессивно внедрять технологии западного образца. Это привело к появлению смешанных моделей, так как в ряде случаев внедрение западных практик проходило формально, без учета российских особенностей.</p>
<p>Индикаторов качественного развития управленческой среды России, на наш взгляд, два. Первый – бурный рост образовательных учреждений. Стали появляться факультеты менеджмента в ведущих университетах, бизнес-школы. В них преподает все больше и больше западных специалистов. Второй – это возникновение в крупных компаниях корпоративных университетов. В их рамках происходит переосмысление ценностей и обучение современным принципам управления. Они позволяют обобщить опыт и знания, накопленные корпорацией, формируют единую корпоративную культуру. Право на жизнь имеют и демократическая, и авторитарная модели. Их эффективность зависит от роли человека в организационной культуре.</p>
<h3>«Я не представляю свою карьеру в российской компании&#8230;»</h3>
<p><strong>Аэлита Пурнашкина</strong>, <em>менеджер корпоративного отдела маркетинга холдинга IMS Group</em>:<br />
– В нашей компании западным является не только стиль менеджмента, но и стиль общения. Каждый сотрудник может свободно обратиться к топ-менеджеру. Это способствует профессиональному росту сотрудников. Ведь таким образом у них есть возможность оперативно решать все вопросы и при этом постоянно быть на виду у руководства.</p>
<p>- Другой момент, который меня приятно удивил, когда я перешла в западную компанию после нескольких лет сотрудничества с российской, – это забота о здоровье персонала. К примеру, если в течение рабочего дня сотрудник IMS Group почувствовал недомогание, он может позвонить персональному доктору компании. Врач анализирует проблему, затем сам перезванивает сотруднику и предлагает ему принять то или иное лекарство или назначает прием. Если недомогание серьезное, он советует, услугами какой именно клиники человеку лучше воспользоваться. Такой подход очень выгоден самой компании – у сотрудников нет необходимости тратить время на очереди в поликлиниках. В то же время персонал чувствует заботу о себе.</p>
<p>- Другой отличительный фактор – мотивация и обучение персонала. В нашей компании сотрудник проходит обучение уже в первую неделю своей карьеры. В отечественных фирмах не понимают важности инвестиций в персонал. Рядовой сотрудник вряд ли сможет напрямую обратиться к топ-менеджеру со своими идеями, предложениями. Честно говоря, мне сложно представить свой карьерный рост в российской компании.</p>
]]></content:encoded>
			<wfw:commentRss>http://pm.by/articles/management/management-style/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Чему ужастики могут научить в управлении</title>
		<link>http://pm.by/articles/management/what-horror-movies-can-teach/</link>
		<comments>http://pm.by/articles/management/what-horror-movies-can-teach/#comments</comments>
		<pubDate>Wed, 05 Dec 2007 12:04:58 +0000</pubDate>
		<dc:creator>Денис Журавлев</dc:creator>
				<category><![CDATA[Управление]]></category>

		<guid isPermaLink="false">http://pm.by/articles/management/what-horror-movies-can-teach/</guid>
		<description><![CDATA[
Существует много вещей которым можно поучится из старых фильмов ужасов,  в которых НЛО выглядят как тарелки, гиганские муравьи появляются в ходе ядерных опытов, и  когда мурашки атакуют, главными защитниками города должны стать старшекласники. Однако в этих же фильмах есть и серъезные уроки, которые можно извлечь для управления. Вот несколько из них:
Человек который смеёться [...]]]></description>
			<content:encoded><![CDATA[<p><img src='http://pm.by/wp-content/uploads/j0400680-732161.jpg' alt='j0400680-732161.jpg' align="right" /><br />
Существует много вещей которым можно поучится из старых фильмов ужасов,  в которых НЛО выглядят как тарелки, гиганские муравьи появляются в ходе ядерных опытов, и  когда мурашки атакуют, главными защитниками города должны стать старшекласники. Однако в этих же фильмах есть и серъезные уроки, которые можно извлечь для управления. Вот несколько из них:</p>
<p><strong>Человек который смеёться над опасностями будет застрелен</strong>. Когда лесник говорит, &#8220;Ты что сумащедший? В лесу никого нет кроме енотов и оленей,&#8221; вы знаете что он покойник. <em>Самоуспокоенность приходит перед смертью.</em></p>
<p><strong>Самый вежливый не всегда самый добрый.</strong> За редким исключением, герой с самыми изощренными манерами &#8211; злодей. Если кто-то выглядит льстивым, он и есть льстец. <em>Обращайте внимание на свою интуицию.</em></p>
<p><strong>Если вы чувствуете что что–то серъезное идет не так, не проверяйте это сами. </strong>Поверьте мне в этом. Глухой звук в подвале это не неисправный водяной нагреватель. <em>Если вы должны исследовать, что может быть главной проблемой, возьмите с собой массивного союзника.</em></p>
<p><strong>Когда люди продолжают исчезать, должна быть общая причина</strong>. &#8220;Когда час назад здесь было 10 человек, а теперь только 5. Какое совпадение!&#8221; <em>Чем быстрее вы определите причину ухода, тем лучше. Тем временем, вы должны приложить особые усилия чтобы удержать тех кто еще поблизости.</em></p>
<p><strong>Когда грозит опасность, не разделяйтесь.</strong> &#8220;Давайте посмотрим. Мы столкнулись со смертельной угрозой, ну давайте-ка отправим Ральфа на чердак, Мери в сад,  Рекса на кухню, а Элен в то место, за домом, которого нас просили избегать. И давайте организуем наши поиски  вполночь при выключенном свете&#8221;. <em>Держитесь вместе и больше общайтесь. </em></p>
<p>Оригинал: <a href="http://www.execupundit.com/2007/01/what-horror-movies-can-teach-you-about.html">What Horror Movies Can Teach You About Management</a></p>
]]></content:encoded>
			<wfw:commentRss>http://pm.by/articles/management/what-horror-movies-can-teach/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Как уложиться в сроки</title>
		<link>http://pm.by/articles/management/terms/</link>
		<comments>http://pm.by/articles/management/terms/#comments</comments>
		<pubDate>Wed, 08 Aug 2007 17:17:21 +0000</pubDate>
		<dc:creator>Денис Журавлев</dc:creator>
				<category><![CDATA[Управление]]></category>

		<guid isPermaLink="false">http://pm.by/upravlenie/terms/</guid>
		<description><![CDATA[Одна из проблем разработки программного обеспечения это несоблюдение запланированных сроков. Самая важная, на мой взгляд, проблема это непонимание заказчиком какое воздействие оказывает его бездействие на проект. Как одно из решений это перекладывание ответственности за действия заказчика на его самого.]]></description>
			<content:encoded><![CDATA[<p><img src="http://pm.by/wp-content/uploads/contract.jpg" alt="contract" align="right" /></p>
<p>Одна из проблем разработки программного обеспечения  это несоблюдение запланированных сроков. Самая важная, на мой взгляд, проблема это непонимание заказчиком какое воздействие оказывает его бездействие на проект. Как одно из решений это перекладывание ответственности за действия заказчика на его самого. Чтобы это сделать наименее болезненно необходимо договориться &#8220;на берегу&#8221;(как говорил ВИ).</p>
<p>Для этого в стандартный контракт, чтобы избежать всякого непонимания, необходимо включить примерно следующее положение:</p>
<p><strong>Обязанности Клиента</strong></p>
<p>В дополнение к своевременной оплате, как оговорено далее в пункте 10, клиент дает свое согласие на следующее:<br />
- Изучить, подписать и вернуть «Описание проекта» в течении пяти рабочих дней с момента получения документа. Любые изменения в «Описание проекта» будут вноситься в письменном виде и заверяются подписью Клиента.</p>
<p>- Изучить, подписать и вернуть «Техническое задание» в течении пяти рабочих дней со дня получения документа. Любые изменения в «Техническое задание» будут вноситься в письменном виде и заверяться подписью Клиента.</p>
<p>- Изучать, подписывать и возвращать запросы на пояснения, в течении двух  рабочих дней со дня получения.</p>
<p>- Отвечать на все звонки и электронные сообщения в течении  одного рабочего дня. В случае неполучения ответа на звонок или электронное сообщение, Исполнитель может по своему усмотрению изменять расписание работ по проекту.</p>
<p>Также необходимо записать все обязанности со стороны клиента например</p>
<p>- Клиент обязуется предоставить Исполнителю одного инженера на один месяц в начале работ над проектом в сроки, установленные в расписании работ по проекту. Инженер должен иметь квалификацию не ниже степени бакалавра и владеть программой &#8220;АБВ&#8221; на высоком уровне.</p>
<p>- Клиент обязуется предоставить Исполнителю оборудование &#8220;Клмн&#8221; не позднее одного месяца после начала работ. В случае неполучения оборудования, Исполнитель может по своему усмотрению изменять расписание работ по проекту.</p>
]]></content:encoded>
			<wfw:commentRss>http://pm.by/articles/management/terms/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Футбольная мудрость</title>
		<link>http://pm.by/articles/management/footbal/</link>
		<comments>http://pm.by/articles/management/footbal/#comments</comments>
		<pubDate>Sat, 30 Jun 2007 16:58:37 +0000</pubDate>
		<dc:creator>Денис Журавлев</dc:creator>
				<category><![CDATA[Управление]]></category>

		<guid isPermaLink="false">http://pm.by/upravlenie/footbal/</guid>
		<description><![CDATA[Когда плохо играет один игрок, меняют игрока; когда плохо играют все игроки, меняют тренера.
Вдобавок статья по теме Football-Driven Development]]></description>
			<content:encoded><![CDATA[<p>Когда плохо играет один игрок, меняют игрока; когда плохо играют все игроки, меняют тренера.</p>
<p>Вдобавок статья по&nbsp;теме <a href="http://www.agilemanagement.net/Articles/Papers/FDDisFootball.html" target="_blank">Football-Driven Development</a></p>
]]></content:encoded>
			<wfw:commentRss>http://pm.by/articles/management/footbal/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Оценка времени проекта</title>
		<link>http://pm.by/articles/management/project-estimations/</link>
		<comments>http://pm.by/articles/management/project-estimations/#comments</comments>
		<pubDate>Wed, 28 Mar 2007 17:15:43 +0000</pubDate>
		<dc:creator>Денис Журавлев</dc:creator>
				<category><![CDATA[Управление]]></category>

		<guid isPermaLink="false">http://pm.by/upravlenie/project-estimations/</guid>
		<description><![CDATA[Достаточно часто (90% случаев из моего лично опыта) оценки разработчиков на выполнения заданий или проектов в последствии расходятся с реальными цифрами. Это происходит по многим факторам. В этой статье перечислены некоторые, не столь очевидные на первый взгляд, но которые наиболее часто упускаются из виду.]]></description>
			<content:encoded><![CDATA[<p><img src="http://pm.by/wp-content/uploads/healingtimeflow.jpg" align="right" /></p>
<p>Достаточно часто (90% случаев из моего лично опыта) оценки разработчиков на выполнения заданий или проектов в последствии расходятся с реальными цифрами. Это происходит по многим факторам, и я хотел бы перечислить некоторые, не столь очевидные на первый взгляд, но которые наиболее часто упускаются из виду.</p>
<p>Итак, что мы не учитываем при оценке проекта:</p>
<p>1. Чтение блогов и новостей, разгребание почты по утрам. (15 минут в день)<br />
2. Перерывы на кофе/чай. (2-3 в течении дня 10 минут на каждый)<br />
3. Еженедельное командное собрание для разбора полётов. (1 час)<br />
4. Другие собрания. Проектные собрания для решения текущих вопросов. (дважды в неделю 3 часа)<br />
5. Решение проблем с железом, не работает комп или сеть или нет тока. (раз в две недели пол дня)<br />
6. Мелкие проблемы с ПО (не грузится студия, поставился патч после которого винда перестала адекватно работать). (дважды в неделю по часу)<br />
7. Заполнение time journal-ов и других формальных документов. (час в неделю)<br />
8. Походы в WC. Да это тоже занимает время. (10 минут в день)<br />
9. Написание необходимых емейлов (4 часа в неделю)<br />
10. Написание ненужных емейлов (4 часа в неделю)<br />
11. Удаление спама (30 минут в неделю)<br />
12. Болезни, прочие личные причины отсутсвия на работе (1 день в месяц)</p>
<p>Это все должно быть учтено перед тем как называть какие-то сроки заказчику или начальнику. Я встречал еще одну интересную теорию измерять работу в эффективных часах, т.е. чистое время затраченное только на работу, однако я не поддерживаю этот подход т.к. для разные люди эффективное рабочее время могут понимать по разному, а клиента больше интересует календарные графики, чем эффективные часы программистов.</p>
<p>Попробуйте проанализировать ваш рабочий день, и учесть его особенности. Удачи в оценках!</p>
]]></content:encoded>
			<wfw:commentRss>http://pm.by/articles/management/project-estimations/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Российский и западный IT менеджмент вчера и сегодня</title>
		<link>http://pm.by/articles/management/rossijskij-i-zapadnyj-it-menedzhment-vchera-i-segodnya/</link>
		<comments>http://pm.by/articles/management/rossijskij-i-zapadnyj-it-menedzhment-vchera-i-segodnya/#comments</comments>
		<pubDate>Mon, 22 May 2006 16:54:04 +0000</pubDate>
		<dc:creator>Денис Журавлев</dc:creator>
				<category><![CDATA[Управление]]></category>

		<guid isPermaLink="false">http://pm.by/upravlenie/rossijskij-i-zapadnyj-it-menedzhment-vchera-i-segodnya/</guid>
		<description><![CDATA[Интересная заметка на тему стравнения как у них и как у нас, на мой взгляд у нас PM это либо самоучка, либо тот кто получил оброзование там.]]></description>
			<content:encoded><![CDATA[<p>Интересная заметка на&nbsp;тему стравнения как у&nbsp;них и&nbsp;как у&nbsp;нас, на&nbsp;мой взгляд у&nbsp;нас PM&nbsp;это либо самоучка, либо тот кто получил оброзование там.</p>
<p><a href="http://blogs.gotdotnet.ru/personal/gaidar/PermaLink.aspx?guid=bb9c55fe-0a0e-4c5a-a80e-96be0220b0f2">http://blogs.gotdotnet.ru/personal/gaidar/PermaLink.aspx?guid=bb9c55fe-0a0e-4c5a-a80e-96be0220b0f2</a></p>
]]></content:encoded>
			<wfw:commentRss>http://pm.by/articles/management/rossijskij-i-zapadnyj-it-menedzhment-vchera-i-segodnya/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
