<?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>评论：时间和效果</title>
	<atom:link href="http://2simple.cn/2006/08/blog-post_25.htm/feed" rel="self" type="application/rss+xml" />
	<link>http://2simple.cn/2006/08/blog-post_25.htm</link>
	<description>我们已经回来</description>
	<lastBuildDate>Sat, 31 Jul 2010 09:26:40 +0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>来自：鲤鱼</title>
		<link>http://2simple.cn/2006/08/blog-post_25.htm#comment-11385</link>
		<dc:creator>鲤鱼</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://2simple.cn/2006/08/blog-post_25.htm#comment-11385</guid>
		<description>从产品的角度看，是谁都是希望项目越快实现越好，功能越强大越好，质量越高越好。

这三个元素原本来就是相互制约的三角关系，也就是著名的项目的金三角。

一个三角形，你尝试改变其中的一条边，那么就只能通过，改变另外一条或者两条边来迁就它。如果说，产品经理希望缩短开发周期，那么就只能减少功能，或者降低质量来妥协(如果愿意降低质量的话)。

作为项目的开发，通常一般的技术经理都会建议哪些需求可以被分离，可以建议到后期来开发。这个都在情理之中。</description>
		<content:encoded><![CDATA[<p>从产品的角度看，是谁都是希望项目越快实现越好，功能越强大越好，质量越高越好。</p>
<p>这三个元素原本来就是相互制约的三角关系，也就是著名的项目的金三角。</p>
<p>一个三角形，你尝试改变其中的一条边，那么就只能通过，改变另外一条或者两条边来迁就它。如果说，产品经理希望缩短开发周期，那么就只能减少功能，或者降低质量来妥协(如果愿意降低质量的话)。</p>
<p>作为项目的开发，通常一般的技术经理都会建议哪些需求可以被分离，可以建议到后期来开发。这个都在情理之中。</p>
]]></content:encoded>
	</item>
	<item>
		<title>来自：鲤鱼</title>
		<link>http://2simple.cn/2006/08/blog-post_25.htm#comment-11386</link>
		<dc:creator>鲤鱼</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://2simple.cn/2006/08/blog-post_25.htm#comment-11386</guid>
		<description>我想 -- 
无论好坏，项目经理都会对自己的项目负责，要尽量确保自己做出来的产品，能够保证质量，能够不被骂。
既不被用户骂质量差，也不会被团队成员骂需求不明确，或者加班加得太辛苦。

我认为再差的技术经理也不会出于“上班时候留点时间泡MM”“能少写代码就不要去挑战难度”来考虑的。

关于“上班时候留点时间干别的什么事情”，这个问题是任何部门都可能存在的问题，应该主要是由公司的行政或者HR 来考虑和解决的事。
</description>
		<content:encoded><![CDATA[<p>我想 &#8212;<br />
无论好坏，项目经理都会对自己的项目负责，要尽量确保自己做出来的产品，能够保证质量，能够不被骂。<br />
既不被用户骂质量差，也不会被团队成员骂需求不明确，或者加班加得太辛苦。</p>
<p>我认为再差的技术经理也不会出于“上班时候留点时间泡MM”“能少写代码就不要去挑战难度”来考虑的。</p>
<p>关于“上班时候留点时间干别的什么事情”，这个问题是任何部门都可能存在的问题，应该主要是由公司的行政或者HR 来考虑和解决的事。</p>
]]></content:encoded>
	</item>
	<item>
		<title>来自：Jack</title>
		<link>http://2simple.cn/2006/08/blog-post_25.htm#comment-11394</link>
		<dc:creator>Jack</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://2simple.cn/2006/08/blog-post_25.htm#comment-11394</guid>
		<description>产品经理通常从Time to Market， Investigate &amp; Return的角度，而技术经理通常从Time to Result，Difficulty &amp; Resource的角度。

所以一个从技术经理转型为产品经理和一个从产品经理转型为技术经理之间的合作通常会比较顺利。

多从对方的角度去想，自然就能接受砍需求以及改需求了。</description>
		<content:encoded><![CDATA[<p>产品经理通常从Time to Market， Investigate &amp; Return的角度，而技术经理通常从Time to Result，Difficulty &amp; Resource的角度。</p>
<p>所以一个从技术经理转型为产品经理和一个从产品经理转型为技术经理之间的合作通常会比较顺利。</p>
<p>多从对方的角度去想，自然就能接受砍需求以及改需求了。</p>
]]></content:encoded>
	</item>
	<item>
		<title>来自：sume</title>
		<link>http://2simple.cn/2006/08/blog-post_25.htm#comment-11546</link>
		<dc:creator>sume</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://2simple.cn/2006/08/blog-post_25.htm#comment-11546</guid>
		<description>“如果你准时发布的产品是一个低质量的产品，人们通常记住的是产品的低质量，而非你能准时完成产品。”

“如果你延期发布了一款很棒的产品，人们通常记住的是令人倾倒的产品，准时发布还是延期发布已无关紧要。”

在软件产业的历史上，充满了推迟发布但是获得巨大成功的产品。例如：
1）Windows 1.0平台上的Microsoft Word，最初计划是1年，结果开发了5年。
2）Microsoft Windows 95比原计划推迟了1.5年，当成为软件史上销售最快的产品之一。

只有在以下类型的项目中，速度优先级高于质量：
该类项目中存在一个时间点，如果在此点不能发布产品，你根本就没有必要再继续开发它了！</description>
		<content:encoded><![CDATA[<p>“如果你准时发布的产品是一个低质量的产品，人们通常记住的是产品的低质量，而非你能准时完成产品。”</p>
<p>“如果你延期发布了一款很棒的产品，人们通常记住的是令人倾倒的产品，准时发布还是延期发布已无关紧要。”</p>
<p>在软件产业的历史上，充满了推迟发布但是获得巨大成功的产品。例如：<br />
1）Windows 1.0平台上的Microsoft Word，最初计划是1年，结果开发了5年。<br />
2）Microsoft Windows 95比原计划推迟了1.5年，当成为软件史上销售最快的产品之一。</p>
<p>只有在以下类型的项目中，速度优先级高于质量：<br />
该类项目中存在一个时间点，如果在此点不能发布产品，你根本就没有必要再继续开发它了！</p>
]]></content:encoded>
	</item>
	<item>
		<title>来自：sume</title>
		<link>http://2simple.cn/2006/08/blog-post_25.htm#comment-11547</link>
		<dc:creator>sume</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://2simple.cn/2006/08/blog-post_25.htm#comment-11547</guid>
		<description>“如果你准时发布的产品是一个低质量的产品，人们通常记住的是产品的低质量，而非你能准时完成产品。”

“如果你延期发布了一款很棒的产品，人们通常记住的是令人倾倒的产品，准时发布还是延期发布已无关紧要。”

在软件产业的历史上，充满了推迟发布但是获得巨大成功的产品。例如：
1）Windows 1.0平台上的Microsoft Word，最初计划是1年，结果开发了5年。
2）Microsoft Windows 95比原计划推迟了1.5年，当成为软件史上销售最快的产品之一。

只有在以下类型的项目中，速度优先级高于质量：
该类项目中存在一个时间点，如果在此点不能发布产品，你根本就没有必要再继续开发它了！</description>
		<content:encoded><![CDATA[<p>“如果你准时发布的产品是一个低质量的产品，人们通常记住的是产品的低质量，而非你能准时完成产品。”</p>
<p>“如果你延期发布了一款很棒的产品，人们通常记住的是令人倾倒的产品，准时发布还是延期发布已无关紧要。”</p>
<p>在软件产业的历史上，充满了推迟发布但是获得巨大成功的产品。例如：<br />
1）Windows 1.0平台上的Microsoft Word，最初计划是1年，结果开发了5年。<br />
2）Microsoft Windows 95比原计划推迟了1.5年，当成为软件史上销售最快的产品之一。</p>
<p>只有在以下类型的项目中，速度优先级高于质量：<br />
该类项目中存在一个时间点，如果在此点不能发布产品，你根本就没有必要再继续开发它了！</p>
]]></content:encoded>
	</item>
</channel>
</rss>
