<?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; FIDIC</title>
	<atom:link href="http://www.airstorm.org/blog/category/fidic/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>央视TVCC火灾-烟花公司责任</title>
		<link>http://www.airstorm.org/blog/2009/03/09/tacc-fire-duty-of-fireworks/</link>
		<comments>http://www.airstorm.org/blog/2009/03/09/tacc-fire-duty-of-fireworks/#comments</comments>
		<pubDate>Mon, 09 Mar 2009 05:08:16 +0000</pubDate>
		<dc:creator>clockwork59</dc:creator>
				<category><![CDATA[AEC]]></category>
		<category><![CDATA[FIDIC]]></category>
		<category><![CDATA[contracts]]></category>
		<category><![CDATA[火灾]]></category>
		<category><![CDATA[违规]]></category>
		<category><![CDATA[违法]]></category>
		<category><![CDATA[TVCC]]></category>
		<category><![CDATA[央视]]></category>
		<category><![CDATA[安全]]></category>
		<category><![CDATA[法律责任]]></category>

		<guid isPermaLink="false">http://www.airstorm.org/blog/2009/03/09/%e5%a4%ae%e8%a7%86tvcc%e7%81%ab%e7%81%be-%e7%83%9f%e8%8a%b1%e5%85%ac%e5%8f%b8%e8%b4%a3%e4%bb%bb/</guid>
		<description><![CDATA[违法燃放行为
依据国务院《烟花爆竹安全管理条例》(GB1995-2004)，对举办焰火晚会以及其他大型焰火燃放活动，实行许可证制度，分级审批。条例规定举办焰火晚会必须持有燃放地公安部门核发的《焰火燃放许可证》，显然，烟花公司在没有《焰火燃放许可证》前提下燃放烟花已经构成违法。但是必须注意到条例规定：
主办单位应当按照分级管理的规定，向有关人民政府公安部门提出申请……

根据公安部发布的《焰火晚会烟花爆竹燃放安全规程》，燃放公司必须向主办方提交“技术设计与组织实施设计方案”，主办方认可该方案后，必须向燃放地公安部门提出燃放申请并提交技术设计与组织实施设计方案。燃放地公安部门审核后，核发的《焰火燃放许可证》。因此可以推导出一个结果：烟花公司提交合格的技术设计与组织实施设计方案才是获得《焰火燃放许可证》充分必要条件。
从公开的信息看，显然北京市公安机关从未接到任何的燃放申请，因此才有“违规擅自燃放”的定性结论。虽然我们不知道业主方（主办方）是否接到了烟花公司提交的方案，但是从常理推测，业主方（主办方）没有必要在这方面知法犯法。
安全管理疏忽
《焰火晚会烟花爆竹燃放安全规程》规定的技术设计方案应包括下列内容：：
   

焰火晚会规模概况，燃放时间、地点以及与晚会活动主题相应的编组燃放文字说明； 
所燃放烟花爆竹的种类与数量及礼花弹发射最大高度、爆炸覆盖面积等有关参数； 
燃放器材的基本情况及点火方式； 
安全距离与安全警戒范围。 

组织实施方案应当包括下列内容：
   

现场组织机构的设置，包括根据焰火晚会活动规模所设置的燃放技术、安全警戒、交通管制、消防、救护、事故应急处理等职能组的组成； 
现场人员分工、岗位、职责； 
烟花爆竹及有关器材的运输和储存、保管安全措施； 
实施燃放时的安全保卫措施； 
事故应急处理措施。 

根据当前掌握的信息，显然烟花公司存在严重的安全管理疏忽行为。这些疏忽是火灾发生的直接原因之一。
故意逃脱运输检查
按照上述法律法规的规定，运输烟花爆竹需要《烟花爆竹道路运输许可证》，而据报道显然烟花公司存在故意违法运输烟花爆竹的行为，即刻意躲避安全执法检查，刻意规避法律规定的申报程序。 
刑事责任
违法违规燃放烟花爆竹，造成人身、财产侵害的负有刑事责任；违规运输烟花爆竹、故意躲避安全检查的同样会被追究刑事责任。但是本文的重点不在这里。
民事责任
严重的安全管理疏忽应该是导致火灾发生的原因之一。在FIDIC条件下，烟花公司作为业主的雇佣人员进入现场，应遵守工程安全管理的一切规章制度、并保障工程的安全。（参照FIDIC2.3、4.6、4.8款的规定）
从民事侵权责任上分析，雇员在从事雇佣活动中因安全生产事故遭受人身损害，发包人、分包人知道或者应当知道接受发包或者分包业务的雇主没有相应资质或者安全生产条件的，应当与雇主承担连带赔偿责任。当然在FIDIC条件下，需要考虑工程保险的覆盖范围，能够被保险覆盖的，讨论民事在人的意义不大。关于保险的问题以后讨论。
 本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright &#169; 2008 作者 clockwork59  at Airstorm (数字指纹: 24fed2e143ca40ef26657495da818d48)]]></description>
			<content:encoded><![CDATA[<p><strong>违法燃放行为</strong></p>
<p>依据国务院《烟花爆竹安全管理条例》(GB1995-2004)，对举办焰火晚会以及其他大型焰火燃放活动，实行许可证制度，分级审批。条例规定举办焰火晚会必须持有燃放地公安部门核发的《焰火燃放许可证》，显然，烟花公司在没有《焰火燃放许可证》前提下燃放烟花已经构成违法。但是必须注意到条例规定：</p>
<blockquote><p>主办单位应当按照分级管理的规定，向有关人民政府公安部门提出申请<font style="background-color: #ffffff" color="#333333">……</font></p>
</blockquote>
<p>根据公安部发布的《焰火晚会烟花爆竹燃放安全规程》，燃放公司必须向主办方提交“技术设计与组织实施设计方案”，主办方认可该方案后，必须向燃放地公安部门提出燃放申请并提交技术设计与组织实施设计方案。燃放地公安部门审核后，核发的《焰火燃放许可证》。因此可以推导出一个结果：<strong>烟花公司提交合格的技术设计与组织实施设计方案才是获得《焰火燃放许可证》充分必要条件。</strong></p>
<p>从公开的信息看，显然北京市公安机关从未接到任何的燃放申请，因此才有“违规擅自燃放”的定性结论。虽然我们不知道业主方（主办方）是否接到了烟花公司提交的方案，但是从常理推测，业主方（主办方）没有必要在这方面知法犯法。</p>
<p><strong>安全管理疏忽</strong></p>
<p>《焰火晚会烟花爆竹燃放安全规程》规定的技术设计方案应包括下列内容：：</p>
<ol>   </ol>
<ol>
<li>焰火晚会规模概况，燃放时间、地点以及与晚会活动主题相应的编组燃放文字说明； </li>
<li>所燃放烟花爆竹的种类与数量及礼花弹发射最大高度、爆炸覆盖面积等有关参数； </li>
<li>燃放器材的基本情况及点火方式； </li>
<li>安全距离与安全警戒范围。 </li>
</ol>
<p>组织实施方案应当包括下列内容：</p>
<ol>   </ol>
<ol>
<li>现场组织机构的设置，包括根据焰火晚会活动规模所设置的燃放技术、安全警戒、交通管制、消防、救护、事故应急处理等职能组的组成； </li>
<li>现场人员分工、岗位、职责； </li>
<li>烟花爆竹及有关器材的运输和储存、保管安全措施； </li>
<li>实施燃放时的安全保卫措施； </li>
<li>事故应急处理措施。 </li>
</ol>
<p>根据当前掌握的信息，显然烟花公司存在严重的安全管理疏忽行为。这些疏忽是火灾发生的直接原因之一。</p>
<p><strong>故意逃脱运输检查</strong></p>
<p>按照上述法律法规的规定，运输烟花爆竹需要《烟花爆竹道路运输许可证》，而据报道显然烟花公司存在故意违法运输烟花爆竹的行为，即刻意躲避安全执法检查，刻意规避法律规定的申报程序。 </p>
<p><strong>刑事责任</strong></p>
<p>违法违规燃放烟花爆竹，造成人身、财产侵害的负有刑事责任；违规运输烟花爆竹、故意躲避安全检查的同样会被追究刑事责任。但是本文的重点不在这里。</p>
<p><strong>民事责任</strong></p>
<p>严重的安全管理疏忽应该是导致火灾发生的原因之一。在FIDIC条件下，烟花公司作为业主的雇佣人员进入现场，应遵守工程安全管理的一切规章制度、并保障工程的安全。（参照FIDIC2.3、4.6、4.8款的规定）</p>
<p>从民事侵权责任上分析，雇员在从事雇佣活动中因安全生产事故遭受人身损害，发包人、分包人知道或者应当知道接受发包或者分包业务的雇主没有相应资质或者安全生产条件的，应当与雇主承担连带赔偿责任。当然在FIDIC条件下，需要考虑工程保险的覆盖范围，能够被保险覆盖的，讨论民事在人的意义不大。关于保险的问题以后讨论。</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/03/09/tacc-fire-duty-of-fireworks/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>利益相关者 (stakeholder)</title>
		<link>http://www.airstorm.org/blog/2008/12/18/stackeholder/</link>
		<comments>http://www.airstorm.org/blog/2008/12/18/stackeholder/#comments</comments>
		<pubDate>Thu, 18 Dec 2008 06:38:49 +0000</pubDate>
		<dc:creator>clockwork59</dc:creator>
				<category><![CDATA[FIDIC]]></category>
		<category><![CDATA[PM]]></category>
		<category><![CDATA[科学]]></category>
		<category><![CDATA[经济]]></category>
		<category><![CDATA[stakeholder]]></category>
		<category><![CDATA[利益相关者]]></category>
		<category><![CDATA[博弈]]></category>
		<category><![CDATA[所有权]]></category>
		<category><![CDATA[代价]]></category>

		<guid isPermaLink="false">http://www.airstorm.org/blog/?p=63</guid>
		<description><![CDATA[很久没有更新了，主要在读书和思考，以便于更好地整顿头脑。先把最近想到的一点体会放在这里吧。
stakeholder 概念
对于已经知道其意义的可以跳过这一段，不过看看“非主流”也有好处。那么何为“stakeholder”呢？在很多翻译词库以及来自教科书的定义虽然不同，但是大体上是一致的：利益相关者 OR 利害相关者。然而什么是利益相关者呢？我这里采用经济学对于所有权的解释来阐述它的含义：
经济学在阐述“所有权”的时候分析的异常透彻：所有权并非同那些矿产、地产等等物质相关，而是同利益相关。当某人取得某地的矿产开发权的时候，或许会造成对邻近农民收益的伤害、会造成对邻近居民健康的伤害……因此所有权获取成本是所有利益损害的总和。也就是说，当你声称拥有某所有权而采取行为的时候，这些行为本身会对其他人的利益造成损害，这些因为你的行为而受到利益侵害的团体、组织、个人被称为Stakeholder。同时你为了行使所有权就必须付出代价，这个代价是由Stakeholder的利益共同作用产生的。因此，从工程管理的角度理解，Stakeholder意指所有与某个项目、某个事件相关的利益群体或个体的总和。更为关键的是，当你听到Stakeholder的时候就应该立即想到“代价”OR“成本”。
另外，还要探究一下stakeholder一词的来源，据说是来自于16世纪的英国赌博业。那个时候，stakeholder是指持有筹码，参与赌博game的人。这里面就包含了这样的意思：从game程序上，你无法永远绕过一个“玩家”，他是game的一部分；同时，由于其手中的筹码，你绝对不可以忽视他的行为，这些筹码和行为也许会成为game的关键。正如05年小布什在第二个任期开始后不久派人到北京来宣布其对华新政时，美国人就巧妙地要求：
We need to urge China to become a responsible stakeholder in the international system（我们应该要求中国成为一个负责任的stakeholder）
这篇当时的时事评论充分说明：stakeholder存在非常浓厚的博弈色彩。
那么，在工程管理工作中如何管理和对待stakeholder呢？
理性、客观、科学
对待stakeholder的问题，科学是最恰当的解决方案。比如对待健康诉求和农作物保护诉求来说，准确地评估其利益损害是首要问题。这方面，客观、理性的数据，以及对问题科学的解析能够迅速让stakeholder明确合理的诉求，也有助于各方冷静理性地预计整体的的“代价”，而不是紧紧盯着自己的利益。在工程领域，系统完整地识别stakeholder是很困难的，而识别项目可能造成的损害却是可行的，科学地管理项目损害是应对stakeholder的问题的关键。
经济与博弈
有些问题却不是科学或者科技可以解决的，比如现在正在进行的气象问题国际谈判，N多科学论文恐怕也很难改变各方的立场。这个时候，在追求和谐、共赢的社会背景中，在寻求stakeholder之间的利益平衡过程中，博弈与经济方法是非常有效的手段。
这方面最有力的案例就是拆迁，有很多成功的，也有很多失败的。灵活的经济手段绝对是方法之一，简单粗暴肯定得不到好的结果。
写在最后：
逆水行舟。早在90年代FIDIC就出版了《project sustainability management guidelines》，其第一句话就提到了stakeholder。说起来有些形而上学：行业进步的动力也来源于stakeholder，不是吗？
 本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright &#169; 2008 作者 clockwork59  at Airstorm (数字指纹: 24fed2e143ca40ef26657495da818d48)]]></description>
			<content:encoded><![CDATA[<p>很久没有更新了，主要在读书和思考，以便于更好地整顿头脑。先把最近想到的一点体会放在这里吧。</p>
<p><strong>stakeholder 概念</strong></p>
<p>对于已经知道其意义的可以跳过这一段，不过看看“非主流”也有好处。那么何为“stakeholder”呢？在很多翻译词库以及来自教科书的定义虽然不同，但是大体上是一致的：<strong>利益相关者</strong> OR <strong>利害相关者</strong>。然而什么是利益相关者呢？我这里采用经济学对于所有权的解释来阐述它的含义：</p>
<p>经济学在阐述“所有权”的时候分析的异常透彻：所有权并非同那些矿产、地产等等物质相关，而是同利益相关。当某人取得某地的矿产开发权的时候，或许会造成对邻近农民收益的伤害、会造成对邻近居民健康的伤害……因此所有权获取成本是所有利益损害的总和。也就是说，当你声称拥有某所有权而采取行为的时候，这些行为本身会对其他人的利益造成损害，这些因为你的行为而受到利益侵害的团体、组织、个人被称为Stakeholder。同时你为了行使所有权就必须付出代价，这个代价是由Stakeholder的利益共同作用产生的。因此，从工程管理的角度理解，<strong>Stakeholder意指所有与某个项目、某个事件相关的利益群体或个体的总和。</strong>更为关键的是，当你听到Stakeholder的时候就应该立即想到<strong>“代价”</strong>OR<strong>“成本”。</strong></p>
<p>另外，还要探究一下stakeholder一词的来源，据说是来自于16世纪的英国赌博业。那个时候，stakeholder是指持有筹码，参与赌博game的人。这里面就包含了这样的意思：从game程序上，你无法永远绕过一个“玩家”，他是game的一部分；同时，由于其手中的筹码，你绝对不可以忽视他的行为，这些筹码和行为也许会成为game的关键。正如05年小布什在第二个任期开始后不久派人到北京来宣布其对华新政时，美国人就巧妙地要求：</p>
<blockquote><p>We need to urge China to become a responsible stakeholder in the international system（我们应该要求中国成为一个负责任的stakeholder）</p></blockquote>
<p>这篇当时的<a href="http://biz.163.com/05/1209/13/24HM0RV300020S2K.html">时事评论</a><strong>充分说明：stakeholder存在非常浓厚的博弈色彩</strong>。</p>
<p>那么，在工程管理工作中如何管理和对待stakeholder呢？</p>
<p><strong>理性、客观、科学</strong></p>
<p>对待stakeholder的问题，科学是最恰当的解决方案。比如对待健康诉求和农作物保护诉求来说，准确地评估其利益损害是首要问题。这方面，客观、理性的数据，以及对问题科学的解析能够迅速让stakeholder明确合理的诉求，也有助于各方冷静理性地预计整体的的“代价”，而不是紧紧盯着自己的利益。在工程领域，系统完整地识别stakeholder是很困难的，而识别项目可能造成的损害却是可行的，<strong>科学地管理项目损害是应对stakeholder的问题的关键</strong>。</p>
<p><strong>经济与博弈</strong></p>
<p>有些问题却不是科学或者科技可以解决的，比如现在正在进行的气象问题国际谈判，N多科学论文恐怕也很难改变各方的立场。这个时候，在追求和谐、共赢的社会背景中，在寻求stakeholder之间的利益平衡过程中，<strong>博弈与经济方法是非常有效的手段</strong>。</p>
<p>这方面最有力的案例就是拆迁，有很多成功的，也有很多失败的。灵活的经济手段绝对是方法之一，简单粗暴肯定得不到好的结果。</p>
<p>写在最后：</p>
<p>逆水行舟。早在90年代FIDIC就出版了《project sustainability management guidelines》，其第一句话就提到了stakeholder。说起来有些形而上学：行业进步的动力也来源于stakeholder，不是吗？</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/2008/12/18/stackeholder/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>WBS概念误区 (一)</title>
		<link>http://www.airstorm.org/blog/2008/06/03/mistakes-concept-about-deliverable-of-wbs/</link>
		<comments>http://www.airstorm.org/blog/2008/06/03/mistakes-concept-about-deliverable-of-wbs/#comments</comments>
		<pubDate>Tue, 03 Jun 2008 03:08:07 +0000</pubDate>
		<dc:creator>clockwork59</dc:creator>
				<category><![CDATA[AEC]]></category>
		<category><![CDATA[BIM]]></category>
		<category><![CDATA[PM]]></category>
		<category><![CDATA[Software]]></category>
		<category><![CDATA[WBS]]></category>
		<category><![CDATA[contracts]]></category>
		<category><![CDATA[deliverable]]></category>
		<category><![CDATA[FIDIC]]></category>
		<category><![CDATA[PBS]]></category>
		<category><![CDATA[可交付成果]]></category>
		<category><![CDATA[合同分解结构]]></category>
		<category><![CDATA[工程量清单]]></category>
		<category><![CDATA[工作分解结构]]></category>
		<category><![CDATA[产品分解结构]]></category>

		<guid isPermaLink="false">http://www.airstorm.org/blog/?p=60</guid>
		<description><![CDATA[可交付成果在PMBOK中有比较清晰的定义，Airstorm这里就不在背书了。直接谈谈容易出现的误解，对于可交付成果的误解集中在2各方面：一是可交付成果的概念本身；二是可交付成果在WBS中的作用。
误解一：可交付成果就是“工程”
工程领域中，项目产品的不确定性没有超出合同双方的经验范围。所以建筑工程承包商可以闭着眼睛告诉客户他们建造的项目产品大体上是什么，客户也基本认可这个大体的范围，即便在细节问题上会有自己的要求（在物理构成上建筑物有97％的共性）。因此，工程领域向来有范例式的WBS构建方法。而这个范例就是工程领域的“定额编码体系”，在建筑领域就是（工程量清单），这种编码体系本身就容易被误解为项目的完整WBS。关于这一点我们稍后讨论。这里仅仅说说其分解特点，“定额编码体系”（工程量清单）的特点就是以可交付成果为导向的分解体系，其大部分分解节点都是以名词为主的（例如钢筋工程，钢筋、预制构件、钢筋笼），即可交付成果通常被理解为有形的工程实体。
在工程领域人员学习WBS的时候，经常会完成一个工程实体分解的WBS。持有这类观点的不在少数，他们在概念里倾向于将工程的PBS替代WBS，其中不乏技术人员和管理者。如果将工程设计WBS分解为：
设计图纸，结构设计图纸，建筑设计图纸，市政工程设计图纸，电气工程设计图纸……
恐怕很难识别设计工作的一些任务，例如，设计前现场勘查，施工过程的现场监督，二次设计图纸的审核等等工作。如果说WBS是一种“范围管理”工具，那么基于产品的分解方法通常比较容易遗漏“过程服务”的成果，这些成果大部分情况下是“无形”的。我们知道产品需求差异会导致设计工作范围的不同，因此在进行设计管理工作的时候就不能仅仅围绕设计的可交付成果展开，还要兼顾面向任务或者活动的部分。实际上，借鉴软件工程的WBS可以看出，设计领域中在项目开始之前进行较为精确的产品分解是不切实际的，所以通常使用任务分解的方式分解WBS。
再有，工程中的采购也难以使用有形的采购产品分解WBS，更多的是采用面向过程的WBS。过程管理对于项目管理是非常重要的，很多时候基于过程的分解更加贴近OBS，或者在更高的WBS层级与OBS匹配。其实过程分解的下一级就是任务分解，而任务分解的下一级就到了工作成果。正如Airstorm在上面所述，服务和产品的叠加才是“工作（works）”，这显然与传统的工程领域知识相矛盾（工程领域中，works专指“工程”或者“永久工程”，参见FIDIC条件），在《系统》一书中介绍WBS概念的时候，特地强调了CWBS【合同分解结构】一词，其概念核心就是是基于产品分解的WBS要通过CWBS（合同分解结构）的方式建立一种管理项目任务的渠道，使得项目工作范围被完整地管理起来。
总结
WBS中的works是一个“包”的概念，是工作任务与工作成果的集合
对待WBS的时候，不应该仅仅将其看作是PBS（产品分解结构），如果必须如此，则需要界定任务分解结构，比较成熟的有合同分解结构CWBS，或者组织分解结构OBS与PBS相结合。
 本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright &#169; 2008 作者 clockwork59  at Airstorm (数字指纹: 24fed2e143ca40ef26657495da818d48)]]></description>
			<content:encoded><![CDATA[<p>可交付成果在PMBOK中有比较清晰的定义，Airstorm这里就不在背书了。直接谈谈容易出现的误解，对于可交付成果的误解集中在2各方面：一是可交付成果的概念本身；二是可交付成果在WBS中的作用。</p>
<h3>误解一：可交付成果就是“工程”</h3>
<p>工程领域中，项目产品的不确定性没有超出合同双方的经验范围。所以建筑工程承包商可以闭着眼睛告诉客户他们建造的项目产品大体上是什么，客户也基本认可这个大体的范围，即便在细节问题上会有自己的要求（在物理构成上建筑物有97％的共性）。因此，工程领域向来有范例式的WBS构建方法。而这个范例就是工程领域的“定额编码体系”，在建筑领域就是（工程量清单），这种编码体系本身就容易被误解为项目的完整WBS。关于这一点我们稍后讨论。这里仅仅说说其分解特点，“定额编码体系”（工程量清单）的特点就是以可交付成果为导向的分解体系，其大部分分解节点都是以名词为主的（例如钢筋工程，钢筋、预制构件、钢筋笼），即可交付成果通常被理解为有形的工程实体。</p>
<p>在工程领域人员学习WBS的时候，经常会完成一个工程实体分解的WBS。持有这类观点的不在少数，他们在概念里倾向于将工程的PBS替代WBS，其中不乏技术人员和管理者。如果将工程设计WBS分解为：</p>
<blockquote><p>设计图纸，结构设计图纸，建筑设计图纸，市政工程设计图纸，电气工程设计图纸……</p></blockquote>
<p>恐怕很难识别设计工作的一些任务，例如，设计前现场勘查，施工过程的现场监督，二次设计图纸的审核等等工作。如果说WBS是一种“范围管理”工具，那么基于产品的分解方法通常比较容易遗漏“过程服务”的成果，这些成果大部分情况下是“无形”的。我们知道产品需求差异会导致设计工作范围的不同，因此在进行设计管理工作的时候就不能仅仅围绕设计的可交付成果展开，还要兼顾面向任务或者活动的部分。实际上，借鉴软件工程的WBS可以看出，设计领域中在项目开始之前进行较为精确的产品分解是不切实际的，所以通常使用任务分解的方式分解WBS。</p>
<p>再有，工程中的采购也难以使用有形的采购产品分解WBS，更多的是采用面向过程的WBS。过程管理对于项目管理是非常重要的，很多时候基于过程的分解更加贴近OBS，或者在更高的WBS层级与OBS匹配。其实过程分解的下一级就是任务分解，而任务分解的下一级就到了工作成果。正如Airstorm在上面所述，服务和产品的叠加才是“工作（works）”，这显然与传统的工程领域知识相矛盾（工程领域中，works专指“工程”或者“永久工程”，参见FIDIC条件），在《系统》一书中介绍WBS概念的时候，特地强调了CWBS【合同分解结构】一词，其概念核心就是是基于产品分解的WBS要通过CWBS（合同分解结构）的方式建立一种管理项目任务的渠道，使得项目工作范围被完整地管理起来。</p>
<p><strong>总结</strong></p>
<h3>WBS中的works是一个“包”的概念，是工作任务与工作成果的集合</h3>
<p>对待WBS的时候，不应该仅仅将其看作是PBS（产品分解结构），如果必须如此，则需要界定任务分解结构，比较成熟的有合同分解结构CWBS，或者组织分解结构OBS与PBS相结合。</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/2008/06/03/mistakes-concept-about-deliverable-of-wbs/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>BIM的4D分析应用</title>
		<link>http://www.airstorm.org/blog/2007/12/18/bim-apps-on-4d/</link>
		<comments>http://www.airstorm.org/blog/2007/12/18/bim-apps-on-4d/#comments</comments>
		<pubDate>Tue, 18 Dec 2007 05:22:08 +0000</pubDate>
		<dc:creator>clockwork59</dc:creator>
				<category><![CDATA[AEC]]></category>
		<category><![CDATA[BIM]]></category>
		<category><![CDATA[Books]]></category>
		<category><![CDATA[FIDIC]]></category>
		<category><![CDATA[PM]]></category>
		<category><![CDATA[4D]]></category>
		<category><![CDATA[结构分析]]></category>
		<category><![CDATA[整合]]></category>
		<category><![CDATA[时变结构]]></category>

		<guid isPermaLink="false">http://www.airstorm.org/blog/2007/12/18/bim%e7%9a%844d%e5%88%86%e6%9e%90%e5%ba%94%e7%94%a8/</guid>
		<description><![CDATA[建筑信息模型BIM在4D领域的应用不如普通3D模型应用那样广泛，这主要还是4D领域的应用还比较“软”。大量的4D应用成果都集中在visual plan方面，这类能让大家看到plan结果的可视化模拟的确威力非凡。
还有一类4D应用就需要大量的建筑构件实体数据参与4D模拟：施工过程分析。很多工程必须对施工过程的结构特性进行必要的分析，看看下图就知道这样做的必要性了：

在传统设计分析方法上，设计人员仅仅通过设定“最不利”状态来分析上述分析域内的问题。但是这样做仅仅可以完成基于工程进度milestone节点上的静态分析，而非全过程动态模拟与分析（即忽略结构特性、结构形状随时间变化而变化的影响）。
时变结构分析
是通过建筑结构类型、材料性质以及施工荷载等随时间和进度变化的时变分析模型，对基于施工方案的施工过程进行结构力学分析、变形计算、性能预算和安全评估。能够更准确的评价建筑结构特性和各项指标。
4D的引入
事实上，时变分析并不是随着4D技术出现的设计分析方法。但是早期的时变分析在时间进程与结构变化上还停留在理论的时间片分割方法，没有考虑施工工艺计划方面的因素，因此其仅仅具备结构分析预测的功能，还不能根据施工方案以及施工进度分析相应的建筑结构特性。而4D的引入则解决了这个问题，4D是基于施工方案以及施工进度扩展的信息模型，它真实的反映了施工计划对建造过程的影响，也就对施工工艺有着更为切合实际的指导意义。由于整合了施工过程分析，使设计分析更加具有针对性，效率更高。。
BIM的信息支撑
现在随着技术的进步，提供全过程动态模拟分析的条件已经具备了。其中BIM就可以为全过程动态模拟提供详实的数据的信息模型。需要说明的是，这个模型也是BIM的扩展，至少需要建筑材料物理特性参数的数据作支撑。而4D模型以及结构分析模型则是BIM扩展模型生成的子集。通过BIM信息框架，4D分析模型将得到分析所需的数据和信息，进而构成时变结构分析模型。
BIM在4D领域的应用
可能的应用包括：


时变结构分析&#8211;结构安全、变形控制
装配及空间冲突问题
气象因素影响分析


airstorm个人觉得，通过整合施工阶段的4D动态分析来延长设计分析时效范围，将提高BIM系统应用的使用价值。同时4D分析的应用，可以科学地分析砼早期强度与结构安全的关系，进而有力地推动建筑行业生产率的提高，套用时髦的词汇，就是BIM的4D分析将减少能耗需求，提高能耗利用率。
 本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright &#169; 2008 作者 clockwork59  at Airstorm (数字指纹: 24fed2e143ca40ef26657495da818d48)]]></description>
			<content:encoded><![CDATA[<p>建筑信息模型BIM在4D领域的应用不如普通3D模型应用那样广泛，这主要还是4D领域的应用还比较“软”。大量的4D应用成果都集中在visual plan方面，这类能让大家看到plan结果的可视化模拟的确威力非凡。</p>
<p>还有一类4D应用就需要大量的建筑构件实体数据参与4D模拟：施工过程分析。很多工程必须对施工过程的结构特性进行必要的分析，看看下图就知道这样做的必要性了：<span id="more-52"></span></p>
<p><img src="http://lh5.google.com/clockwork59/R2YKkqBsUxI/AAAAAAAAAhs/ExEl6vS0xJc/s400/4D-analysis.jpg" alt="" /></p>
<p>在传统设计分析方法上，设计人员仅仅通过设定“最不利”状态来分析上述分析域内的问题。但是这样做仅仅可以完成基于工程进度milestone节点上的静态分析，而非全过程动态模拟与分析（即忽略结构特性、结构形状随时间变化而变化的影响）。</p>
<p><strong>时变结构分析</strong></p>
<p>是通过建筑结构类型、材料性质以及施工荷载等随时间和进度变化的时变分析模型，对基于施工方案的施工过程进行结构力学分析、变形计算、性能预算和安全评估。能够更准确的评价建筑结构特性和各项指标。</p>
<p><strong>4D的引入</strong></p>
<p>事实上，时变分析并不是随着4D技术出现的设计分析方法。但是早期的时变分析在时间进程与结构变化上还停留在理论的时间片分割方法，没有考虑施工工艺计划方面的因素，因此其仅仅具备结构分析预测的功能，还不能根据施工方案以及施工进度分析相应的建筑结构特性。而4D的引入则解决了这个问题，4D是基于施工方案以及施工进度扩展的信息模型，它真实的反映了施工计划对建造过程的影响，也就对施工工艺有着更为切合实际的指导意义。由于整合了施工过程分析，使设计分析更加具有针对性，效率更高。。</p>
<p><strong>BIM的信息支撑</strong></p>
<p>现在随着技术的进步，提供全过程动态模拟分析的条件已经具备了。其中BIM就可以为全过程动态模拟提供详实的数据的信息模型。需要说明的是，这个模型也是BIM的扩展，至少需要建筑材料物理特性参数的数据作支撑。而4D模型以及结构分析模型则是BIM扩展模型生成的子集。通过BIM信息框架，4D分析模型将得到分析所需的数据和信息，进而构成时变结构分析模型。</p>
<p><strong>BIM在4D领域的应用</strong></p>
<p>可能的应用包括：</p>
<blockquote>
<ul>
<li>时变结构分析&#8211;结构安全、变形控制</li>
<li>装配及空间冲突问题</li>
<li>气象因素影响分析</li>
</ul>
</blockquote>
<p>airstorm个人觉得，通过整合施工阶段的4D动态分析来延长设计分析时效范围，将提高BIM系统应用的使用价值。同时4D分析的应用，可以科学地分析砼早期强度与结构安全的关系，进而有力地推动建筑行业生产率的提高，套用时髦的词汇，就是BIM的4D分析将减少能耗需求，提高能耗利用率。</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/2007/12/18/bim-apps-on-4d/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>FIDIC将定义工程咨询全过程服务范围</title>
		<link>http://www.airstorm.org/blog/2007/08/16/the-nine-project-phases-scope-of-service-of-fidic/</link>
		<comments>http://www.airstorm.org/blog/2007/08/16/the-nine-project-phases-scope-of-service-of-fidic/#comments</comments>
		<pubDate>Thu, 16 Aug 2007 10:58:24 +0000</pubDate>
		<dc:creator>clockwork59</dc:creator>
				<category><![CDATA[AEC]]></category>
		<category><![CDATA[FIDIC]]></category>
		<category><![CDATA[PM]]></category>
		<category><![CDATA[definitions]]></category>
		<category><![CDATA[scope]]></category>
		<category><![CDATA[service]]></category>
		<category><![CDATA[工程咨询]]></category>
		<category><![CDATA[服务范围]]></category>

		<guid isPermaLink="false">http://www.airstorm.org/blog/2007/08/16/the-nine-project-phases-scope-of-service-of-fidic/</guid>
		<description><![CDATA[刚刚还在讨论工程采购的“透明度”问题，期间突然想到了前一段时间网上很流行的“晒工资”。觉得也许对于公共工程领域，也许“晒清单”是个“办法”。也就是说“晒”出来的更多是其内部翔实的子目、子项构成，而非总数，这些子目具有更强的可比性，更能够说明问题。
这会儿一则消息映入眼帘：Complementary studies of scope of service definitions launched。FIDIC将展开针对项目9个阶段的服务范围定义研究。中文原文：
为了使采购更加透明、减少甚至消除公开招投标的技术壁垒、消除以价格为主导的选聘程序，FIDIC范围界定工作组正 在制定项目不同阶段咨询工程师提供服务范围的标准定义，这些定义将有助于客户理解所提供的优质服务的种类。该工作组正在与欧洲工程咨询协会联合会 （EFCA）在欧盟资助的一个项目的基础上，共同制定咨询服务的标准化问题。拟议中的项目九个阶段的定义将通过成员协会征求咨询公司的意见。（来自FIDIC中国培训中心）
在当今需要“透明”的领域，FIDIC看来很会与时俱进。但作为我们来说，工程咨询领域的全生命周期服务范围详细定义绝对有着非同一般的意义。你难道不想知道造价咨询服务全生命周期的服务范围及其详细定义？
所以期待早日见到可以给我们带来指导和透明的 全生命周期服务范围详细定义。
 本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright &#169; 2008 作者 clockwork59  at Airstorm (数字指纹: 24fed2e143ca40ef26657495da818d48)]]></description>
			<content:encoded><![CDATA[<p>刚刚还在讨论工程采购的“透明度”问题，期间突然想到了前一段时间网上很流行的“晒工资”。觉得也许对于公共工程领域，也许“晒清单”是个“办法”。也就是说“晒”出来的更多是其内部翔实的子目、子项构成，而非总数，这些子目具有更强的可比性，更能够说明问题。</p>
<p>这会儿一则消息映入眼帘：<a href="http://www1.fidic.org/news/content.asp?articlecode=67Pr&amp;lang=" title="the news about scope of service" target="_blank">Complementary studies of scope of service definitions launched</a>。FIDIC将展开针对项目9个阶段的服务范围定义研究。中文原文：</p>
<blockquote><p><span id="lbdesc">为了使采购更加透明、减少甚至消除公开招投标的技术壁垒、消除以价格为主导的选聘程序，FIDIC范围界定工作组正 在制定项目不同阶段咨询工程师提供服务范围的标准定义，这些定义将有助于客户理解所提供的优质服务的种类。该工作组正在与欧洲工程咨询协会联合会 （EFCA）在欧盟资助的一个项目的基础上，共同制定咨询服务的标准化问题。拟议中的项目九个阶段的定义将通过成员协会征求咨询公司的意见。（来自<a href="http://www.fidic.org.cn/" title="fidic.org.cn" target="_blank">FIDIC中国培训中心</a>）</span></p></blockquote>
<p>在当今需要“透明”的领域，FIDIC看来很会与时俱进。但作为我们来说，工程咨询领域的全生命周期服务范围详细定义绝对有着非同一般的意义。你难道不想知道造价咨询服务全生命周期的服务范围及其详细定义？</p>
<p>所以期待早日见到可以给我们带来指导和透明的 <strong>全生命周期服务范围详细定义</strong>。</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/2007/08/16/the-nine-project-phases-scope-of-service-of-fidic/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>开工日期 (Commencement Date)</title>
		<link>http://www.airstorm.org/blog/2007/05/10/commencement-date/</link>
		<comments>http://www.airstorm.org/blog/2007/05/10/commencement-date/#comments</comments>
		<pubDate>Thu, 10 May 2007 18:18:28 +0000</pubDate>
		<dc:creator>clockwork59</dc:creator>
				<category><![CDATA[AEC]]></category>
		<category><![CDATA[FIDIC]]></category>
		<category><![CDATA[contracts]]></category>
		<category><![CDATA[NEC]]></category>
		<category><![CDATA[工程合同]]></category>
		<category><![CDATA[开工日期]]></category>

		<guid isPermaLink="false">http://www.airstorm.org/blog/?p=38</guid>
		<description><![CDATA[本文试图澄清关于“开工日期”的一些误解，以便加强工程管理的分析和判断能力.
开工日期的多重意义
一直以来，业界有许多人对于“开工日期”都有着错误的理解。一方面是由于对工程合同的熟悉程度不够，另一方面也是由于国内在开工问题上的程序相对复杂。当然，开工日期本身也有多种性质：具有法律意义的开工日期和实际开工日期。具有法律意义的开工日期实际上就是根据工程合同定义或生成的开工日；而实际开工日期更多地指向承包商根据他的进度计划而设定的开工日。通常，实际开工日在承包商实际占有工程现场之后。
实际上在合同角度看，开工日期有两个意义：一个是承包商正式、全面履行合同的起始日期，自此日期起合同双方活动受合同约束。另外一个就是工期的起算时间，虽然对合同双方竣工日期更为重要，但是工期作为合同履行时间仍然从很多方面制约双方利益。
对于开工日期的误解主要有下面几个：

建设工程开工许可证注明的日期，这个错误是很明显的但是还是有很多人有这样的误解。建设工程施工许可证是建设工程开工的法律凭证。取得了施工许可证，表明该建设工程的前期准备工作已经完成，具备开工条件，并享有开工的权利。即，建设工程施工许可证是合法开工的凭证，建设工程施工许可证注明的日期即具有指明证书颁发日的作用，没有确立开工日期的作用。
批准的开工申请书/进度计划声明的开工日期这实际上就是实际开工日期。更多的误解就是将此日期与合同定义的开工日期相混淆。开工日更多的是承包商在工程现场经过筹备和计划实际展开工程施工的日期，其中有两个先决条件：承包商实际占有工程现场，并取得管理权；承包商准备工作完成（诸如施工设备到场等等）。
由总监/工程师颁发的开工令日期，这个误解普遍存在于业界，很多人认为“监理方发布开工令是工程正式开工、合同正式实施的标志。”这个观点的错误在于：漠视承包商的施工准备工作。总监/工程师颁发开工令是承包商提交开工申请后的批复，是施工准备完成后才能通过的动工申请。而施工准备也是履行合同义务的一部分。如果以开工令日期作为“合同正式实施的标志”，那么承包商的施工准备工作就不受合同保护；取得工程现场占有权和使用权的承包商也不受合同约束。
开工日期的定义
FIDIC 对“开工日期”的定义为：承包商收到“中标函”后42天内，或者工程师提前7天向承包商发出开工通知的日期，当中较早的一个。
通常情况下，尽早开工对于合同双方均有利，因此FIDIC采用了“当中较早的一个”这一表述。同时应注意“或者工程师提前7天向承包商发出开工通知的日期”这一表述，但是应注意这里的开工通知不是总监/工程师颁发的开工令。这里的开工通知内容FIDIC有规定：
“我们在此通知，根据合同条件第XXX款，开工日期应为。。。。。”
由此可以看出，FIDIC的开工通知明确的是合同开工日期，总监/工程师颁发的开工令则是明确的实际开工日。
NEC合同对于开工日期的处理则更为灵活：
开工：承包商从第一个工程现场占有日起开始施工作业，并应在竣工日或竣工日前竣工。
承包商的工程进度计划应提交项目经理认可，并表明：开工日、现场占有日和竣工日。。。。。
这也体现了另一种对于开工日期的的处理方式，即第一个工程现场占有日作为双方合同正式实施日期。而对于开工日即实际动工的日期，承包商有权做出自己的计划并根据工程师的批准实施；而工程师也有权审核或制定动工日期。它表明实际动工的日期是需要双方确认具备实际开工的所有前提条件。
总结
开工日期是一个法律概念，它表明双方履行 合同义务的起始日期。而开工日/动工日/实际开工日则是经过双方确认的开工日期，它通常是在承包商占有现场并完成施工准备之后的某个日期。工程师有义务确认开工日，有义务检验承包商施工准备和其他开工条件，并维护雇主利益。
 本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright &#169; 2008 作者 clockwork59  at Airstorm (数字指纹: 24fed2e143ca40ef26657495da818d48)]]></description>
			<content:encoded><![CDATA[<p>本文试图澄清关于“开工日期”的一些误解，以便加强工程管理的分析和判断能力.</p>
<p><strong>开工日期的多重意义</strong></p>
<p>一直以来，业界有许多人对于“开工日期”都有着错误的理解。一方面是由于对工程合同的熟悉程度不够，另一方面也是由于国内在开工问题上的程序相对复杂。当然，开工日期本身也有多种性质：具有<strong>法律意义</strong>的<strong>开工日期</strong>和实际开工日期。具有法律意义的开工日期实际上就是根据工程合同定义或生成的开工日；而<strong>实际开工日</strong>期更多地指向承包商根据他的进度计划而设定的开工日。通常，<strong>实际开工日</strong>在承包商实际占有<strong>工程现场</strong>之后。</p>
<p>实际上在合同角度看，开工日期有两个意义：一个是承包商正式、全面履行合同的起始日期，自此日期起合同双方活动受合同约束。另外一个就是工期的起算时间，虽然对合同双方竣工日期更为重要，但是工期作为合同履行时间仍然从很多方面制约双方利益。</p>
<p>对于开工日期的误解主要有下面几个：<br />
<span id="more-38"></span><br />
<strong>建设工程开工许可证</strong>注明的日期，这个错误是很明显的但是还是有很多人有这样的误解。建设工程施工许可证是建设工程开工的法律凭证。取得了施工许可证，表明该建设工程的前期准备工作已经完成，具备开工条件，并享有开工的权利。即，建设工程施工许可证是合法开工的凭证，建设工程施工许可证注明的日期即具有指明证书颁发日的作用，没有确立开工日期的作用。</p>
<p>批准的<strong>开工申请书/进度计划</strong>声明的开工日期这实际上就是实际开工日期。更多的误解就是将此日期与合同定义的开工日期相混淆。开工日更多的是承包商在工程现场经过筹备和计划实际展开工程施工的日期，其中有两个先决条件：承包商实际占有工程现场，并取得管理权；承包商准备工作完成（诸如施工设备到场等等）。</p>
<p>由总监/工程师颁发的<strong>开工令日期</strong>，这个误解普遍存在于业界，很多人认为“监理方发布开工令是工程正式开工、合同正式实施的标志。”这个观点的错误在于：漠视承包商的施工准备工作。总监/工程师颁发开工令是承包商提交开工申请后的批复，是施工准备完成后才能通过的动工申请。而施工准备也是履行合同义务的一部分。如果以开工令日期作为“合同正式实施的标志”，那么承包商的施工准备工作就不受合同保护；取得工程现场占有权和使用权的承包商也不受合同约束。</p>
<p><strong>开工日期的定义</strong></p>
<p>FIDIC 对“开工日期”的定义为：承包商收到“中标函”后42天内，或者工程师提前7天向承包商发出开工通知的日期，当中较早的一个。</p>
<p>通常情况下，尽早开工对于合同双方均有利，因此FIDIC采用了“当中较早的一个”这一表述。同时应注意“或者工程师提前7天向承包商发出开工通知的日期”这一表述，但是应注意这里的<strong>开工通知</strong>不是总监/工程师颁发的<strong>开工令</strong>。这里的<strong>开工通知</strong>内容FIDIC有规定：</p>
<blockquote><p>“我们在此通知，根据合同条件第XXX款，开工日期应为。。。。。”</p></blockquote>
<p>由此可以看出，FIDIC的开工通知明确的是合同开工日期，总监/工程师颁发的开工令则是明确的<strong>实际开工日</strong>。</p>
<p>NEC合同对于开工日期的处理则更为灵活：</p>
<blockquote><p>开工：承包商从第一个工程现场占有日起开始施工作业，并应在竣工日或竣工日前竣工。</p>
<p>承包商的工程进度计划应提交项目经理认可，并表明：开工日、现场占有日和竣工日。。。。。</p></blockquote>
<p>这也体现了另一种对于开工日期的的处理方式，即第一个工程现场占有日作为双方合同正式实施日期。而对于开工日即实际动工的日期，承包商有权做出自己的计划并根据工程师的批准实施；而工程师也有权审核或制定动工日期。它表明实际动工的日期是需要双方确认具备实际开工的所有前提条件。</p>
<p><strong>总结</strong></p>
<p>开工日期是一个法律概念，它表明双方履行 合同义务的起始日期。而开工日/动工日/实际开工日则是经过双方确认的开工日期，它通常是在承包商占有现场并完成施工准备之后的某个日期。工程师有义务确认开工日，有义务检验承包商施工准备和其他开工条件，并维护雇主利益。</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/2007/05/10/commencement-date/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>从西方判例看工程项目管理经理的职责</title>
		<link>http://www.airstorm.org/blog/2006/12/24/project-managers-duties/</link>
		<comments>http://www.airstorm.org/blog/2006/12/24/project-managers-duties/#comments</comments>
		<pubDate>Sun, 24 Dec 2006 13:29:29 +0000</pubDate>
		<dc:creator>clockwork59</dc:creator>
				<category><![CDATA[AEC]]></category>
		<category><![CDATA[FIDIC]]></category>
		<category><![CDATA[PM]]></category>
		<category><![CDATA[contracts]]></category>
		<category><![CDATA[职责]]></category>
		<category><![CDATA[project manager]]></category>
		<category><![CDATA[判例]]></category>

		<guid isPermaLink="false">http://www.airstorm.org/blog/?p=31</guid>
		<description><![CDATA[ “项目经理”一词本来就是舶来品，我们或许可以从西方判例中看出在AEC领域项目经理PMr.有着怎样的责任和义务。
project manager &#8211;新生事物
随着建设项目日益复杂，提供建设项目的人员的分工日益专业化，在大多数项目中，由于大家都需求有另外的专业人士去协调咨询工程师和承包商的工作，项目经理 应运而生。但是，项目经理的准确的角色和责任仍在不断发展完善。 但到目前为止，尚没有被行业认可的PMr（项目经理一词在国内建筑行业另有含义，因此本文以&#8221;PMr&#8221;作为Project Manager的缩写替代）的定义，也没有正式的工程PMr协会或组织团体。
不同类别的其他专业团体出版的指南为项目经理承担相关的项目任务提供了帮助，RISC和CIOB都出版了相应的工程项目管理指南，但是PMr的职责范围和 管理任务并没有被完整清晰地定义出来。相反，关于PMr在工程项目各个阶段的具体任务都给出了长长的列表，而在列表中有很多任务与建筑师、合同管理师和工 程师的任务有一定程度的重叠。
职业谨慎和职业技能
虽然对项目经理这个特殊的职业没有达成像其它建筑行业所要求的职业谨慎和职业技能共识的标准，PMr的主要义务应该在明示或默示在合同条款规定中。 同时，其他咨询工程师的雇用合同条款对定义项目经理的任务范围也有相当大的影响。事实上，管理工程的任务并没有因为PMr的出现而增加多少，因此PMr更 多地分担了建筑师、工程师在工程管理方面的任务，从而将建筑师、工程师从琐碎的管理工作解放出来，确保其更好地完成专业工作和技术管理工作。在法庭上，当 确定项目经理有关的职业技能和职业谨慎义务时要看项目经理所属的专业协会,并且职业技能和职业谨慎的标准将是期望他作为一个有能力的称职的专业工程师来履 行项目管理等工作应达到的合理的职业谨慎和职业技能。正是由于项目管理是新兴的专业领域，其专业工作的定义尚未得到准确的界定，在判别PMr所要求的谨慎 的标准时，更多的取决于雇用合同具体条款规定和具体项目的要求。
针对PMr的诉讼主张
项目经理的角色被广泛地认为是监督与协调，多数对项目经理失职行为的诉讼主张有：项目经理没有控制好某方面的成本；没有确保其他建筑行业专业人士得到正确的信息；没有预防/防止建筑行业专业人士造成重大失误等等。
1 合同管理
作为工程项目的管理者，不可避免的要涉及工程合同的管理。无论PMr的雇佣合同是否对此明确租出界定，PMr的管理工作多不可能脱离开工程合同的管理。这 与工程项目的行业特征有关。在Royal Brompton Hospital NHS Trust 诉 ZHammond (2003) 88 Con. L.R.1.案例中，法官Lloyd.得出了一些关于项目经理角色的基本看法：
(a) 项目经理是业主的总代表，这点应该被其他咨询人员以及业主清除认识这一点。
(b) 毋庸置言，项目经理角色的核心任务是 &#8220;协调和保护业主的利益是毫无疑义的。&#8221;
(c) 当建筑行业专业人士履行合同管理或者项目管理的角色时，必须同时具备建筑法律基本的原理、准则方面的知识，并且具备将知识应用到建筑合同工程管理和建筑项目管理中。在许多案例中，所需要的不一定是基本的法律知识，而是很好的理解运用建筑合同的标准文本。
这些看法足以说明PMr具有潜在的合同管理责任，判例Great Eastern Hotel Co. Ltd v John Laing Co. Ltd [2005] 99 Con LR 45，是第一个报道的施工管理合同（construction management contract）违约案，业主成功地控告CMr.疏于对分包合同的协调管理。
在Royal Brompton Hospital NHS Trust 诉 Hammond (No.7) 76 Con. [...]]]></description>
			<content:encoded><![CDATA[<p><strong> </strong>“项目经理”一词本来就是舶来品，我们或许可以从西方判例中看出在AEC领域项目经理PMr.有着怎样的责任和义务。</p>
<p><strong>project manager &#8211;新生事物</strong></p>
<p>随着建设项目日益复杂，提供建设项目的人员的分工日益专业化，在大多数项目中，由于大家都需求有另外的专业人士去协调咨询工程师和承包商的工作，项目经理 应运而生。但是，项目经理的准确的角色和责任仍在不断发展完善。 但到目前为止，尚没有被行业认可的PMr（项目经理一词在国内建筑行业另有含义，因此本文以&#8221;PMr&#8221;作为Project Manager的缩写替代）的定义，也没有正式的工程PMr协会或组织团体。</p>
<p style="text-indent: 27pt; line-height: 150%">不同类别的其他专业团体出版的指南为项目经理承担相关的项目任务提供了帮助，RISC和CIOB都出版了相应的工程项目管理指南，但是PMr的职责范围和 管理任务并没有被完整清晰地定义出来。相反，关于PMr在工程项目各个阶段的具体任务都给出了长长的列表，而在列表中有很多任务与建筑师、合同管理师和工 程师的任务有一定程度的重叠。</p>
<p><strong>职业谨慎和职业技能</strong></p>
<p>虽然对项目经理这个特殊的职业没有达成像其它建筑行业所要求的职业谨慎和职业技能共识的标准，PMr的主要义务应该在明示或默示在合同条款规定中。 同时，其他咨询工程师的雇用合同条款对定义项目经理的任务范围也有相当大的影响。事实上，管理工程的任务并没有因为PMr的出现而增加多少，因此PMr更 多地分担了建筑师、工程师在工程管理方面的任务，从而将建筑师、工程师从琐碎的管理工作解放出来，确保其更好地完成专业工作和技术管理工作。在法庭上，当 确定项目经理有关的职业技能和职业谨慎义务时要看项目经理所属的专业协会,并且职业技能和职业谨慎的标准将是期望他作为一个有能力的称职的专业工程师来履 行项目管理等工作应达到的合理的职业谨慎和职业技能。正是由于项目管理是新兴的专业领域，其专业工作的定义尚未得到准确的界定，在判别PMr所要求的谨慎 的标准时，更多的取决于雇用合同具体条款规定和具体项目的要求。</p>
<p><strong>针对PMr的诉讼主张</strong></p>
<p>项目经理的角色被广泛地认为是监督与协调，多数对项目经理失职行为的诉讼主张有：项目经理没有控制好某方面的成本；没有确保其他建筑行业专业人士得到正确的信息；没有预防/防止建筑行业专业人士造成重大失误等等。</p>
<p><strong>1 合同管理</strong></p>
<p>作为工程项目的管理者，不可避免的要涉及工程合同的管理。无论PMr的雇佣合同是否对此明确租出界定，PMr的管理工作多不可能脱离开工程合同的管理。这 与工程项目的行业特征有关。在Royal Brompton Hospital NHS Trust 诉 ZHammond (2003) 88 Con. L.R.1.案例中，法官Lloyd.得出了一些关于项目经理角色的基本看法：</p>
<blockquote><p>(a) 项目经理是业主的总代表，这点应该被其他咨询人员以及业主清除认识这一点。<br />
(b) 毋庸置言，项目经理角色的核心任务是 &#8220;协调和保护业主的利益是毫无疑义的。&#8221;<br />
(c) 当建筑行业专业人士履行合同管理或者项目管理的角色时，必须同时具备建筑法律基本的原理、准则方面的知识，并且具备将知识应用到建筑合同工程管理和建筑项目管理中。在许多案例中，所需要的不一定是基本的法律知识，而是很好的理解运用建筑合同的标准文本。</p></blockquote>
<p>这些看法足以说明PMr具有潜在的合同管理责任，判例Great Eastern Hotel Co. Ltd v John Laing Co. Ltd [2005] 99 Con LR 45，是第一个报道的施工管理合同（construction management contract）违约案，业主成功地控告CMr.疏于对分包合同的协调管理。</p>
<p>在Royal Brompton Hospital NHS Trust 诉 Hammond (No.7) 76 Con. L.R. 148的案例中，由总承包商提出高额索赔，理由是PMr.监督建筑师未按时审核延期申请时存在职业疏忽。索赔建筑师的签证疏忽的同时附带索赔项目经理和其他项目管理团队成员。法官判定对PMr提提的索赔是由于对PMr的职责范围存在误解，PMr的职责是确定合同管理的确定被有效地实施，而不是判别他们是否完全正确。项目经理处理建筑师未按时审核延期申请时的角色，是判定建筑师是否在合理的时间内处理完这类申请。法官判定PMr需要判定是否在合理的时间内完成其任务，事实上就是要求PMr必须具备相应的合同管理技能和知识。</p>
<p>下面的两个判例也同样与合同管理有关：</p>
<ul>
<li>判例Costain Ltd v Bechtel [2005] TCLR 6 在合同管理的公正性方面引起了广泛的争议。合同管理师在与PMr会晤后更多地驳回了承包商的索赔。承包商索赔主张由于PMr不正确的干预导致业主违约，但 是PMr 辩称在NEC合同下，PMr没有公平行为的义务。事实上，承包商并未收到禁令禁止其获得由于任何事件而导致的合理损失的赔偿。</li>
<li>判例Scheldebouw v St James Homes [2006] BLR 113中, 法官判定业主不能利用CMr替代他们自己去管理商务合同，这不符合一个决策者的客观公正责任。</li>
</ul>
<p><strong>2 监督其他工程服务者的绩效</strong></p>
<p style="margin-left: 40px; text-indent: 27pt; line-height: 150%">在Chesham Properties Ltd 诉 Bucknall Austin Project Management Services Ltd (1996) B.L.R. 92的 案例中，原告就批准了额外的工程延期以及承担承包商的费用和损失，同时指控建筑师和PMr。法官认为称职的项目经理应该在发现建筑师、工程师或者工料测量 师等专业人士没有履行各自的职责时，有义务将上述情况通知业主。法官Hicks 裁决书中指出：&#8221;在实际的建造合同中对于具体的组织建立具体的关系方面项目经理有明确的职责，即项目经理有义务在被告履行各自职责时，向原告汇报他们的绩 效缺陷。&#8221; 即作为工程项目组织的管理者，PMr将有义务监控这些组织的绩效，并将他们的绩效缺陷告知业主。</p>
<p><strong>3 沟通协调</strong></p>
<p style="margin-left: 40px">在Royal Brompton Hospital NHS Trust 诉Hammond (2003) 88 Con. L.R. 1.案例中，法官清楚地指出PMr的沟通与协调职责：&#8230;实际上项目经理(虽然是一个素质高的项目经理) 也要一直接受他们的建议。尽管建议的本质基础可能被认为是显而易见的，也要完全的给出，否则项目经理的知识和专家的意见将会影响建议的清楚表达。即要求 PMr必须及时有效地沟通，并且保证各种意见和建议清楚、正确的表达，并被及时的传递。</p>
<p><strong>4 工程经验</strong></p>
<p style="margin-left: 40px">适当的工程管理经验也是必不可少的，在大型工程项目中，PMr的职责更多地履行沟通、协调和更高级别的控制与管理职能，专业技术管理和决策都会有相应的专 业技术工程师或者专业技术服务机构承担，他们有义务向PMr报告各自职责范围内的工作绩效和项目情况。相反，小型项目的项目经理要监督合同本身的运行，直 接接触承包商，完成项目的全部任务，更像工程总干事。但是无论如何，雇主在聘用PMr时，不会无视PMr的工程经验，下面两个判例说明了这一点：</p>
<ul>
<li><span style="font-size: 10.5pt; line-height: 150%"><span style="font-size: 10.5pt; line-height: 150%" lang="EN-US">在Pozzolanic Lytag Ltd诉 Bryan Hobson Associates [1999] B.L.R. 267的案例中:被告工程师被指定为燃料粉末存储库房工程的设计师和工程项目经理。一部分由承包商设计的工程倒塌。法官Dyson认为该工程师作为项目经 理，有义务确定项目投保工程保险并且因此对原告负有责任。他认为事实上项目经理缺乏必要的职业经验去评估承包商提供的工程保险协议的完善性，所以不能减轻 项目经理应该承担的责任。他们不能简单地履行类似&#8221;邮箱&#8221;的职责。</span></span></li>
<li><span style="font-size: 10.5pt; line-height: 150%">在Palermo Nominees Pty Ltd and Micro Bros Pty Ltd诉 Broad Construction Service Pty Ltd [1999] 15 B&amp;CL 20的案例中：项目经理由于没有完全履行合同约定的义务和约定而败诉，原因是没有要求一个外部的顾问（external consultant）提交关于夜总会内部噪音对于项目设计和建造的影响。<br />
</span></li>
</ul>
<p><strong>总结</strong></p>
<p>综上所述，从西方的判例看，PMr的职责除了&#8221;项目管理&#8221;理论所赋予的沟通、协调等职责外，在工程项目领域还需要PMr具有一定的工程合同管理知识、技能 和实际的工程管理经验。从实际的案例看，更多的业主倾向于将PMr看作是整个工程项目组织的管理协调者，因此监控整个组织的绩效并汇报他们的绩效缺陷是 PMr的责任。</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/2006/12/24/project-managers-duties/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>工程项目管理服务范围参考</title>
		<link>http://www.airstorm.org/blog/2006/01/05/conslutant-terms-of-reference/</link>
		<comments>http://www.airstorm.org/blog/2006/01/05/conslutant-terms-of-reference/#comments</comments>
		<pubDate>Thu, 05 Jan 2006 09:46:00 +0000</pubDate>
		<dc:creator>clockwork59</dc:creator>
				<category><![CDATA[AEC]]></category>
		<category><![CDATA[FIDIC]]></category>
		<category><![CDATA[PM]]></category>
		<category><![CDATA[白皮书]]></category>
		<category><![CDATA[TOR]]></category>
		<category><![CDATA[咨询服务范围]]></category>

		<guid isPermaLink="false">http://blog.airstorm.org/?p=8</guid>
		<description><![CDATA[参考《客户/咨询工程师（单位）协议书指南》，FIDIC阐述了TOR(term of reference)委托服务范围的定义和scope of service的相关论述，并在其附录中提供了一个（基于合同文本的）咨询服务范围。其内容来自Mr. Michael Lewis 的文章:perparing the conslutant&#8217;s terms of reference. 作为协议书（agreement）的立场和角度，FIDIC认为TOR(term of reference)以及scope of service应该针对服务的时间和成本性质进行分类，以便与费用支付条款对应。
这里引用FIDIC的咨询服务范围scope of service论述和TOR(term of reference)委托服务范围的定义，主要是为大家提供研究咨询工程师工程项目管理服务范围的范例。
典型的正常服务内容：
1 inception stage of project 项目开始阶段
2 project definition stage 项目定义阶段
3 alternative proposals 被选建议书
4 feasibility anlysis 可行性分析
5 detailed design 详细设计
6 tender document 招标文件
7 tending and award 招标和授标
8 construction supervision 施工管理
9 take-over and commissioning移交和联合调试
10 defects liability [...]]]></description>
			<content:encoded><![CDATA[<p>参考《客户/咨询工程师（单位）协议书指南》，FIDIC阐述了TOR(term of reference)委托服务范围的定义和scope of service的相关论述，并在其附录中提供了一个（基于合同文本的）咨询服务范围。其内容来自Mr. Michael Lewis 的文章:<a href="http://www1.fidic.org/resources/contracts/library_docs/consult_lewis.asp">perparing the conslutant&#8217;s terms of reference</a>. 作为协议书（agreement）的立场和角度，FIDIC认为TOR(term of reference)以及scope of service应该针对服务的时间和成本性质进行分类，以便与费用支付条款对应。</p>
<p>这里引用FIDIC的咨询服务范围scope of service论述和TOR(term of reference)委托服务范围的定义，主要是为大家提供研究咨询工程师工程项目管理服务范围的范例。</p>
<blockquote><p>典型的正常服务内容：<br />
1 inception stage of project 项目开始阶段<br />
2 project definition stage 项目定义阶段<br />
3 alternative proposals 被选建议书<br />
4 feasibility anlysis 可行性分析<br />
5 detailed design 详细设计<br />
6 tender document 招标文件<br />
7 tending and award 招标和授标<br />
8 construction supervision 施工管理<br />
9 take-over and commissioning移交和联合调试<br />
10 defects liability period 缺陷责任期</p>
<p>典型附加服务内容（主要指环境、卫生、安全方面的管理）：略</p></blockquote>
<p>&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8211;</p>
<p><strong>阶段</strong></p>
<p>fidic的对于服务阶段划分, 采用了典型的自然时间顺序分类法.即:投资前\详细规划\设计\采购\实施\运行. 值得注意的是上述阶段数量恰好是大多数项目管理实践和理论所推荐的6个.这些理论认为阶段划分与可交付成果和项目执行的程序有关, 过多的划分项目阶段有可能拆分可交付成果和项目程序及其对应的任务,使具有多重目标的可交付成果和项目程序被人为地割裂而不便于管理. 因此个人认为上述典型正常服务阶段应将2,3,4 合并, 使其更加具有管理特性.当然从提供菜单式服务和给予费用支付的角度考虑划分项目阶段也是非常实际的方法.</p>
<p><strong>职责</strong></p>
<p>FIDIC将职责分为3类：任务、建议和培训。培训被fidic作为单独的职责单独阐述，而且在传统上咨询工程师有为客户提供运营/维护培训的义务，这被视为一种惯例。对于任务和建议，《白皮书指南》指出</p>
<blockquote><p>职责习惯被分为任务和建议，任务含有管理提供的服务绩效性质，建议则必须履行相应的任务建议义务。</p></blockquote>
<p>这一点提醒了我们：项目管理职责除了基本的管理职责之外，项目管理经理/组织还应该具有一定的技术管理职责。根据<a href="http://clockwork59.sitesled.com/PM-2031/Duties%20of%20Project%20Managers.htm">duties of pm</a>的论述，目前在英国已知的工程项目管理案例中关于项目经理的争议主要是项目经理是否应作为专业咨询工程师或履行专业顾问而提供相关服务。大多数判例明显支持项目经理应具有相应的专业素质，以满足工程整体管理的需要。根据《白皮书指南》的论述：</p>
<blockquote><p>&#8230;仅负责运用其技能、谨慎而勤奋地履行其服务。这就是检验标准</p></blockquote>
<p>这将是司法层面界定项目管理职责的绝对准绳。</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/2006/01/05/conslutant-terms-of-reference/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

