<?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>Airstorms &#187; 度量</title>
	<atom:link href="http://www.airstorm.org/blog/tag/%e5%ba%a6%e9%87%8f/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.airstorm.org/blog</link>
	<description>Building Project Management knowladgement weblog</description>
	<lastBuildDate>Mon, 09 Nov 2009 05:39:53 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>里程碑 (milestone)</title>
		<link>http://www.airstorm.org/blog/2009/06/15/milestone/</link>
		<comments>http://www.airstorm.org/blog/2009/06/15/milestone/#comments</comments>
		<pubDate>Mon, 15 Jun 2009 09:03:38 +0000</pubDate>
		<dc:creator>clockwork59</dc:creator>
				<category><![CDATA[AEC]]></category>
		<category><![CDATA[PM]]></category>
		<category><![CDATA[目标导向]]></category>
		<category><![CDATA[里程碑]]></category>
		<category><![CDATA[里程碑条件]]></category>
		<category><![CDATA[milestone]]></category>
		<category><![CDATA[度量]]></category>

		<guid isPermaLink="false">http://www.airstorm.org/blog/?p=114</guid>
		<description><![CDATA[前一段作一个项目管理的指导，发现项目团队成员对于“里程碑”的理解存在问题，于是有了这篇post《里程碑 (milestone)》。
对里程碑的误解：
A、里程碑＝期限
期限（deadline）其实没有什么可讲的，那是强制性的约束条件，你必须遵守。但是里程碑不是，它充其量在约束方面算是参照系，而不是强制约束。存在这种误解是因为大多数项目会在项目期限处设置里程碑，因而混淆了这两种概念。
B、里程碑会议的滥用
里程碑的很主要的功能就是检查、度量（后面详述），因此里程碑会议成了很多团队必要的检查工具。实际上，会议作为检查工具的作用极其有限，真正完成检查任务的是管理平台或者专门的检验机制（如工程竣工验收体系）。因此“总结会”、“节点会”更多的是一个足够主要的里程碑事件，它将正式确定、认可、批准检验、测量体系得到的结果（如工程竣工验收合格）。
上述观点的另外一层意思就是：不要指望会议本身去完成繁杂的检验、测量工作。可悲的是很多领导恰恰乐于这么做。
里程碑的作用
在项目管理语境中，里程碑是一种项目进展的度量方法或者机制，用于度量项目的进展情况。那么，度量什么呢？
1、度量项目的实际进展。主要的度量方法就是进度管理的一些方法和技巧。在工程管理领域中检查CPM路径的时差 (float) 是一项常规任务，还有如工程计划完成工作量、实际完成计划工作量等等参数。具有可参照意义的是挣值 (EV) 它所反应的项目进展相对科学一点。这种度量是管理层面的。
2、里程碑条件。通常我们会定义里程碑达成的必要条件，诸如项目主要可交付成果的完成、项目阶段的达成等等。对于里程碑条件的度量和检验有必要细分为：
（1）产品、成果导向的条件。这通常需要领域的组织体系、产品、成果的检验方法、体系等等的支撑。（例如产品检验的标准、方法；成果的定义、需求的检查等等）。这项工作绝对不是一个节点可以完成的，它应该是过程检验、测量积累的结果。

（2）管理导向的条件。即对项目工作的检查，可能有：

本里程碑应完成却的未完成的剩余工作；
下一个阶段的准备工作；
目标、计划、范围的修订与变更；
以及必要的风险评估；
等等。

管理条件的检查分布于整个项目管理的绩效测量节点，因此其检验、测量的方法也依赖于检验内容和范围。这些方法应该记录于绩效测量计划或者项目计划中。
总体上，只有完成了所有里程碑条件，我们才可以宣布达成某个里程碑。现在，应该明确里程碑的作用了。提问：
设计工作完成是指：

到了设计成果交付日；
召开了设计评审会议；
设计合同收尾结束；
达成设计工作里程碑的所有条件。


很显然，设计工作的完成在不同领域、不同项目、不同角色下依然存在差距。我们也不能否认里程碑有着时间标尺的属性，它也是个项目进度管理术语。因此发挥里程碑的作用，就全然在于：
里程碑的定义

目标导向。里程碑定义必然同项目目标以及目标分解联系在一起，这正是它参照系作用的核心价值。即，里程碑评价、测量的是项目目标的达成，而不是项目绩效的结果。
里程碑的设置。基于不同的管理角色、不同的管理阶段，会有不同的项目里程碑。主要的是检查点必须附带必要的检查表（检查内容、方法、标准、必要的程序、资源、成本等等）。
后续工作。归档、备案、付款、移交等等工作将在里程碑达成后展开，如果仅仅是一个“到了设计成果交付日”这样的里程碑，你也需要预先计划可能的后续工作（如变更、推迟、索赔以及必要的报告等等）

ok，对于里程碑，你需要有健壮的检验/测量机制、完善的计划以及灵活的运用。比如把里程碑的时间特性用足（投标截止日）、把付款同里程碑捆绑在一起（某工作的付款条件）、或者让某些人围着里程碑打转（性能测试与验收）……
 本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright &#169; 2008 作者 clockwork59  at Airstorm (数字指纹: 24fed2e143ca40ef26657495da818d48)]]></description>
			<content:encoded><![CDATA[<p>前一段作一个项目管理的指导，发现项目团队成员对于“里程碑”的理解存在问题，于是有了这篇post《里程碑 (milestone)》。</p>
<p><strong>对里程碑的误解</strong>：</p>
<p>A、里程碑＝期限</p>
<p>期限（deadline）其实没有什么可讲的，那是强制性的约束条件，你必须遵守。但是里程碑不是，它充其量在约束方面算是参照系，而不是强制约束。存在这种误解是因为大多数项目会在项目期限处设置里程碑，因而混淆了这两种概念。</p>
<p>B、里程碑会议的滥用</p>
<p>里程碑的很主要的功能就是检查、度量（后面详述），因此里程碑会议成了很多团队必要的检查工具。实际上，会议作为检查工具的作用极其有限，真正完成检查任务的是管理平台或者专门的检验机制（如工程竣工验收体系）。因此“总结会”、“节点会”更多的是一个<strong>足够主要的里程碑事件</strong>，它将<strong>正式确定、认可、批准检验、测量体系得到的结果</strong>（如工程竣工验收合格）。</p>
<p>上述观点的另外一层意思就是：<strong>不要指望会议本身去完成繁杂的检验、测量工作</strong>。可悲的是很多领导恰恰乐于这么做。</p>
<p><strong>里程碑的作用</strong></p>
<p>在项目管理语境中，里程碑是一种项目进展的度量方法或者机制，用于度量项目的进展情况。那么，度量什么呢？</p>
<p>1、<strong>度量项目的实际进展</strong>。主要的度量方法就是进度管理的一些方法和技巧。在工程管理领域中检查CPM路径的时差 (float) 是一项常规任务，还有如工程计划完成工作量、实际完成计划工作量等等参数。具有可参照意义的是挣值 (EV) 它所反应的项目进展相对科学一点。这种度量是管理层面的。</p>
<p>2、<strong>里程碑条件</strong>。通常我们会定义里程碑达成的必要条件，诸如项目主要可交付成果的完成、项目阶段的达成等等。对于里程碑条件的度量和检验有必要细分为：</p>
<p>（1）<strong>产品、成果导向的条件</strong>。这通常需要领域的组织体系、产品、成果的检验方法、体系等等的支撑。（例如产品检验的标准、方法；成果的定义、需求的检查等等）。<strong>这项工作绝对不是一个节点可以完成的，它应该是过程检验、测量积累的结果。<br />
</strong><br />
（2）<strong>管理导向的条件</strong>。即对项目工作的检查，可能有：</p>
<ul>
<li>本里程碑应完成却的未完成的剩余工作；</li>
<li>下一个阶段的准备工作；</li>
<li>目标、计划、范围的修订与变更；</li>
<li>以及必要的风险评估；</li>
<li>等等。</li>
</ul>
<p>管理条件的检查分布于整个项目管理的绩效测量节点，因此其检验、测量的方法也依赖于检验内容和范围。这些方法应该记录于绩效测量计划或者项目计划中。</p>
<p>总体上，只有完成了所有里程碑条件，我们才可以宣布达成某个里程碑。现在，应该明确里程碑的作用了。提问：</p>
<blockquote><p>设计工作完成是指：</p>
<ol>
<li>到了设计成果交付日；</li>
<li>召开了设计评审会议；</li>
<li>设计合同收尾结束；</li>
<li>达成设计工作里程碑的所有条件。</li>
</ol>
</blockquote>
<p>很显然，设计工作的完成在不同领域、不同项目、不同角色下依然存在差距。我们也不能否认里程碑有着时间标尺的属性，它也是个项目进度管理术语。因此发挥里程碑的作用，就全然在于：</p>
<p><strong>里程碑的定义</strong></p>
<ol>
<li><strong>目标导向</strong>。里程碑定义必然同项目目标以及目标分解联系在一起，这正是它参照系作用的核心价值。即，里程碑评价、测量的是项目目标的达成，而不是项目绩效的结果。</li>
<li><strong>里程碑的设置</strong>。基于不同的管理角色、不同的管理阶段，会有不同的项目里程碑。主要的是检查点必须附带必要的检查表（检查内容、方法、标准、必要的程序、资源、成本等等）。</li>
<li><strong>后续工作</strong>。归档、备案、付款、移交等等工作将在里程碑达成后展开，如果仅仅是一个“到了设计成果交付日”这样的里程碑，你也需要预先计划可能的后续工作（如变更、推迟、索赔以及必要的报告等等）</li>
</ol>
<p>ok，对于里程碑，你需要有健壮的检验/测量机制、完善的计划以及灵活的运用。比如把里程碑的时间特性用足（投标截止日）、把付款同里程碑捆绑在一起（某工作的付款条件）、或者让某些人围着里程碑打转（性能测试与验收）……</p>
<hr /><small> <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/2.5/cn/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-nc-sa/2.5/cn/80x15.png"/></a><br/>本<span xmlns:dc="http://purl.org/dc/elements/1.1/" href="http://purl.org/dc/dcmitype/Text" rel="dc:type">作品</span>采用<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/2.5/cn/">知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议</a>进行许可。Copyright &copy; 2008 作者<a href="http://www.airstorm.org/blog/about/"> clockwork59 </a> at <a href="http://www.airstorm.org/blog/">Airstorm</a> (数字指纹:<br /> 24fed2e143ca40ef26657495da818d48)</small>]]></content:encoded>
			<wfw:commentRss>http://www.airstorm.org/blog/2009/06/15/milestone/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
	</channel>
</rss>
