<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Комментарии: Fixed-price со скрытым конфликтом</title>
	<atom:link href="http://pm.by/toc/fixed-price-so-skrytym-konfliktom/feed/" rel="self" type="application/rss+xml" />
	<link>http://pm.by/toc/fixed-price-so-skrytym-konfliktom/</link>
	<description>в сфере разработки программного обеспечения</description>
	<lastBuildDate>Mon, 16 Apr 2012 03:54:43 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>Автор: Александр</title>
		<link>http://pm.by/toc/fixed-price-so-skrytym-konfliktom/comment-page-1/#comment-924</link>
		<dc:creator>Александр</dc:creator>
		<pubDate>Wed, 11 Aug 2010 08:09:54 +0000</pubDate>
		<guid isPermaLink="false">http://pm.by/toc/fixed-price-so-skrytym-konfliktom/#comment-924</guid>
		<description>Если не секрет, как продаешь резервы Заказчику?</description>
		<content:encoded><![CDATA[<p>Если не секрет, как продаешь резервы Заказчику?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: Денис</title>
		<link>http://pm.by/toc/fixed-price-so-skrytym-konfliktom/comment-page-1/#comment-923</link>
		<dc:creator>Денис</dc:creator>
		<pubDate>Tue, 10 Aug 2010 17:52:57 +0000</pubDate>
		<guid isPermaLink="false">http://pm.by/toc/fixed-price-so-skrytym-konfliktom/#comment-923</guid>
		<description>Я закладываю где-то 65% буфер на возможные прояснения требования, от которых нам не отбиться.
этого вполне хватает.
Все остальное - размазываю &quot;тонким слоем&quot; по возникающим change requests. При чем идет подряд довольно много проектов от одного и того же заказчика и чем дальше тем легче с ним договориться, т.к. повышается взаимное доверие, следовательно он не опасается, что я &quot;заряжаю&quot; сроки, а я не боюсь, что он выкинет какой-нибудь фокус во время проекта. 
зы - проекты от 7 до 3Х человек.</description>
		<content:encoded><![CDATA[<p>Я закладываю где-то 65% буфер на возможные прояснения требования, от которых нам не отбиться.<br />
этого вполне хватает.<br />
Все остальное &#8212; размазываю &#171;тонким слоем&#187; по возникающим change requests. При чем идет подряд довольно много проектов от одного и того же заказчика и чем дальше тем легче с ним договориться, т.к. повышается взаимное доверие, следовательно он не опасается, что я &#171;заряжаю&#187; сроки, а я не боюсь, что он выкинет какой-нибудь фокус во время проекта.<br />
зы &#8212; проекты от 7 до 3Х человек.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: Александр</title>
		<link>http://pm.by/toc/fixed-price-so-skrytym-konfliktom/comment-page-1/#comment-766</link>
		<dc:creator>Александр</dc:creator>
		<pubDate>Tue, 17 Nov 2009 15:26:44 +0000</pubDate>
		<guid isPermaLink="false">http://pm.by/toc/fixed-price-so-skrytym-konfliktom/#comment-766</guid>
		<description>Этот процесс называется в управлении проектами как &quot;Управление изменениями в содержании&quot;. 
Такой конфликт между Заказчиком и Руководителем проекта даже необходим. Для Заказчика проект - способ улучшить свой бизнес. Поэтому он будет стараться &quot;впихнуть&quot; в проект как можно больше &quot;фич&quot;, которые выражаются в эффекте для его бизнеса. Руководитель проекта отвечает за достижение целей проекта в утвержденные сроки и бюджет. Поэтому он управляет требованиями Заказчика, предлагая на выбор 4 варианта:
а) исключить новые требования из текущего проекта (принцип: &quot;Сделаем в следующей фазе&quot;).
б) включить в проект с увеличением срока и/или стоимости (принцип: &quot;Ваше желание за такие-то деньги и сроки&quot;)
в) включить в проект без увеличения сроков и/или стоимости (принцип: &quot;Сделаем, есть возможность&quot;. Редко, но бывает часто).
г) включить в проект,  исключив уже согласованное содержание на новое (принцип: &quot;Откажитесь от чего-то в пользу нового требования&quot;).

Буферы - вопрос сложный.
Во-первых, как их рассчитать? Теория управления рисками не отвечает на этот вопрос внятно, кроме статистических 15-20% бюджета или сроков на неопределенности.
Во-вторых, как продать резервы проекта Заказчику? Очень часто Заказчик не просто получает детальные планы, но и участвует в их разработке. Так что просто так там не скрыть &quot;буферы&quot;
В-третьих, как поступить с резервами, которые оказались невостребованными? Команде проекта отдать? Или оставить Заказчику? В цивилизованном обществе отдают Заказчику. Но на практике ни разу не встречал.

С уважением.</description>
		<content:encoded><![CDATA[<p>Этот процесс называется в управлении проектами как &#171;Управление изменениями в содержании&#187;.<br />
Такой конфликт между Заказчиком и Руководителем проекта даже необходим. Для Заказчика проект &#8212; способ улучшить свой бизнес. Поэтому он будет стараться &#171;впихнуть&#187; в проект как можно больше &#171;фич&#187;, которые выражаются в эффекте для его бизнеса. Руководитель проекта отвечает за достижение целей проекта в утвержденные сроки и бюджет. Поэтому он управляет требованиями Заказчика, предлагая на выбор 4 варианта:<br />
а) исключить новые требования из текущего проекта (принцип: &#171;Сделаем в следующей фазе&#187;).<br />
б) включить в проект с увеличением срока и/или стоимости (принцип: &#171;Ваше желание за такие-то деньги и сроки&#187;)<br />
в) включить в проект без увеличения сроков и/или стоимости (принцип: &#171;Сделаем, есть возможность&#187;. Редко, но бывает часто).<br />
г) включить в проект,  исключив уже согласованное содержание на новое (принцип: &#171;Откажитесь от чего-то в пользу нового требования&#187;).</p>
<p>Буферы &#8212; вопрос сложный.<br />
Во-первых, как их рассчитать? Теория управления рисками не отвечает на этот вопрос внятно, кроме статистических 15-20% бюджета или сроков на неопределенности.<br />
Во-вторых, как продать резервы проекта Заказчику? Очень часто Заказчик не просто получает детальные планы, но и участвует в их разработке. Так что просто так там не скрыть &#171;буферы&#187;<br />
В-третьих, как поступить с резервами, которые оказались невостребованными? Команде проекта отдать? Или оставить Заказчику? В цивилизованном обществе отдают Заказчику. Но на практике ни разу не встречал.</p>
<p>С уважением.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: Денис Журавлев</title>
		<link>http://pm.by/toc/fixed-price-so-skrytym-konfliktom/comment-page-1/#comment-681</link>
		<dc:creator>Денис Журавлев</dc:creator>
		<pubDate>Tue, 29 Sep 2009 07:55:16 +0000</pubDate>
		<guid isPermaLink="false">http://pm.by/toc/fixed-price-so-skrytym-konfliktom/#comment-681</guid>
		<description>Буфер закладывать конечно необходимо, однако найти  балланс очень трудно, если он будет большой то стоимость проекта будет неконкурентна, если маленький, то нет гарантии что его будет достаточно.  

Также я пока еще не встречал заказчика который бы в начале проекта подтвердил что будут изменения и необходимо закладывать запас на них, как правило для него в fixed price это не выгодно делать. 

Также необходимо опасаться неоднозначных требований, которые можно трактовать двояко, а иногда и трояко. Даже, несмотря на все уверения, что они будут по ходу уточнены. По закону Мерфи любой риск который может сработать, обязательно осуществится.</description>
		<content:encoded><![CDATA[<p>Буфер закладывать конечно необходимо, однако найти  балланс очень трудно, если он будет большой то стоимость проекта будет неконкурентна, если маленький, то нет гарантии что его будет достаточно.  </p>
<p>Также я пока еще не встречал заказчика который бы в начале проекта подтвердил что будут изменения и необходимо закладывать запас на них, как правило для него в fixed price это не выгодно делать. </p>
<p>Также необходимо опасаться неоднозначных требований, которые можно трактовать двояко, а иногда и трояко. Даже, несмотря на все уверения, что они будут по ходу уточнены. По закону Мерфи любой риск который может сработать, обязательно осуществится.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: Hemule</title>
		<link>http://pm.by/toc/fixed-price-so-skrytym-konfliktom/comment-page-1/#comment-672</link>
		<dc:creator>Hemule</dc:creator>
		<pubDate>Mon, 28 Sep 2009 16:09:58 +0000</pubDate>
		<guid isPermaLink="false">http://pm.by/toc/fixed-price-so-skrytym-konfliktom/#comment-672</guid>
		<description>Даже в случае fixed-price исполнитель ведь может закладывать буфера по стоимости, скрытые, либо явные (отдельно оговорив это с заказчиком). В российской практике, конечно же, активно практикуются скрытые буфера.</description>
		<content:encoded><![CDATA[<p>Даже в случае fixed-price исполнитель ведь может закладывать буфера по стоимости, скрытые, либо явные (отдельно оговорив это с заказчиком). В российской практике, конечно же, активно практикуются скрытые буфера.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

