产品经理最重要的职责之一就是提需求，最不能接受的事情之一就是被技术团队砍需求。经过目前的项目，我发现砍需求基本上基于两个考量，项目时间和项目效果。
任何产品都是要在有限的时间内推出，如果是一个无限长时间的项目，那么理论上可以接受任何需求，包括把人类进化成纯能力的形态，这样的项目也是没有任何意义的。有限的时间就意味着只能实现有限的需求，如果项目经理说，这个不太核心的需求我们一期暂时没有人手实现，但是已经预留了位置，二期马上可以搞定，我就比较放心。
任何产品推出来都是给用户用的，用户可能是人，也可能其他生物，总之在使用的过程中，产品才能发挥价值。如果一个理想状况下非常好的需求，在现实物理条件下会导致整个产品的效果变差，那么它就不是一个合理的需求。对于网络服务来说，任何需求最后都要面临网卡吞吐能力、CPU能够驾驭内存的能力、磁头移动时间、磁盘转数等客观条件的检验，霸王硬上弓，绝对不是理性的选择。
以上所言都是基于产品团队与开发团队有良好的信任基础和职业素养，比如开发团队有时候会主动提出一些需求或者坚持某些需求是不能被搁置的，产品经理最重要的职责之二，就是控制产品节奏，最少具备哪些特性就可以算是一个“可以见人”的产品，再加上哪些特性，算是一个“过得去”的产品，然后再变成一个“差不多的”“还不错的”“非常好的”“完美的”产品。如果开发团队没有足够的职业素养，那项目成本就高了，砍需求往往会出于“上班时候留点时间泡MM”“能少写代码就不要去挑战难度”等考量。
从产品的角度看，是谁都是希望项目越快实现越好，功能越强大越好，质量越高越好。
这三个元素原本来就是相互制约的三角关系，也就是著名的项目的金三角。
一个三角形，你尝试改变其中的一条边，那么就只能通过，改变另外一条或者两条边来迁就它。如果说，产品经理希望缩短开发周期，那么就只能减少功能，或者降低质量来妥协(如果愿意降低质量的话)。
作为项目的开发，通常一般的技术经理都会建议哪些需求可以被分离，可以建议到后期来开发。这个都在情理之中。
鲤鱼
2006/08/26 15:50
我想 —
无论好坏，项目经理都会对自己的项目负责，要尽量确保自己做出来的产品，能够保证质量，能够不被骂。
既不被用户骂质量差，也不会被团队成员骂需求不明确，或者加班加得太辛苦。
我认为再差的技术经理也不会出于“上班时候留点时间泡MM”“能少写代码就不要去挑战难度”来考虑的。
关于“上班时候留点时间干别的什么事情”，这个问题是任何部门都可能存在的问题，应该主要是由公司的行政或者HR 来考虑和解决的事。
鲤鱼
2006/08/26 16:04
产品经理通常从Time to Market， Investigate & Return的角度，而技术经理通常从Time to Result，Difficulty & Resource的角度。
所以一个从技术经理转型为产品经理和一个从产品经理转型为技术经理之间的合作通常会比较顺利。
多从对方的角度去想，自然就能接受砍需求以及改需求了。
Jack
2006/08/28 11:48
“如果你准时发布的产品是一个低质量的产品，人们通常记住的是产品的低质量，而非你能准时完成产品。”
“如果你延期发布了一款很棒的产品，人们通常记住的是令人倾倒的产品，准时发布还是延期发布已无关紧要。”
在软件产业的历史上，充满了推迟发布但是获得巨大成功的产品。例如：
1）Windows 1.0平台上的Microsoft Word，最初计划是1年，结果开发了5年。
2）Microsoft Windows 95比原计划推迟了1.5年，当成为软件史上销售最快的产品之一。
只有在以下类型的项目中，速度优先级高于质量：
该类项目中存在一个时间点，如果在此点不能发布产品，你根本就没有必要再继续开发它了！
sume
2006/09/20 10:37
“如果你准时发布的产品是一个低质量的产品，人们通常记住的是产品的低质量，而非你能准时完成产品。”
“如果你延期发布了一款很棒的产品，人们通常记住的是令人倾倒的产品，准时发布还是延期发布已无关紧要。”
在软件产业的历史上，充满了推迟发布但是获得巨大成功的产品。例如：
1）Windows 1.0平台上的Microsoft Word，最初计划是1年，结果开发了5年。
2）Microsoft Windows 95比原计划推迟了1.5年，当成为软件史上销售最快的产品之一。
只有在以下类型的项目中，速度优先级高于质量：
该类项目中存在一个时间点，如果在此点不能发布产品，你根本就没有必要再继续开发它了！
sume
2006/09/20 10:37