这是敏捷开发一千零一问系列的第四篇。（在这里提问，之一，之二，之三，问题总目录）
这个系列的文章太多，除了用于总结性篇章外，请访问“问题总目录”查找感兴趣的具体问题。
初始问题
对于不断更新的需求，导致需求优先级的判断出现了错误，知道项目周期后期才发现，怎么办？
答案
1. （临时方案）确保所有排序均是由PO完成的
常常出现所谓现场客户、由客户出PO、由一个销售当PO的情况，都是应该避免的。
PO一方面要熟悉具体的需求和原始目的（广度与细度的要求），另一方面则应该对产品的商业目标、终极目的了然于胸（高度与深度），才能站在企业立场而非简单的客户价值立场。
从这一方面看，“有无限时间陪着我们的现场客户”和“一个销售”，其细度有余，高度不足，很容易带入歧途；而由“客户出PO”则会被客户牵着鼻子走，客户的想法一变，项目就会变化，也不符合企业的利益。
2. （最终方案）优先级排序应该基于较为稳定的商业计划，要确保有产品总监或项目总监来把控产品或项目方向
一般的产品经理和项目经理排列优先级的依据一般有两个：一个是客户价值方面，一个是开发因素方面（比如对架构的影响、需求间的依赖）。但这些都相对浅薄的理解。
真正决定什么优先的因素，是产品或项目的商业目标，并因此制定版本计划，在版本中体现优先级。
作为产品，每个版本都是为了打败某个竞争对手，取代某个已有产品，获取某类客户的过程。从这个角度看，若商业目标明确了，那么要做什么功能才能达到商业目标，应该也是相对明确的（或者说，只有商业目标变化时，才需要发生重大的变化，不会突然有人一拍脑袋又变了）。
这一点要求产品研发需要产品总监来做好产品的商业计划，并与具体负责的产品经理不断制定和沟通产品版本计划，并进而明确版本中应该实现的功能。
作为项目，看似是为了完成需求规格上面的描述，其实是为了支撑客户的某个业务。这个客户业务，乙方要有人明确是什么，并最好能预见未来的业务。这样除非这个业务的优先级发生变化，项目任务不会发生重大变化。
另外一个要做好的事情则是项目切忌不能客户说什么做什么，或者什么项目都做，而是要想好自己企业的主营业务是什么，有什么可以平台化以进行积累的东西，才能在做大的同时做强，成为某个领域不可替代的供应商。
这一点要求应该按业务领域设立项目总监，对外不断审视领域的投资价值、分析客户群，对内推动核心业务的开发而抑制周边业务的开发。有了这个主心骨，就只有符合实现想好的业务方向的项目才接，自然也就不会发生重大的变化。
项目要想被乙方控制，初期很难做到，甚至说如果这样是找死；但是如果做了很久还处于什么项目都做，客户说什么做什么的状态，则是在等死。
案例
1. 一个军工项目
这个项目发生在某年的10.1阅兵仪式上，但可别就此认为所有需求都与此有关，里边还是掺杂了甲方很多人的想象，面对强势的甲方，这些需求很难拒绝。
不过项目负责人还是很清楚那天这个软件到底会被用来做什么的，所以核心功能被提前4个月完成并经常使用（因此也很少有缺陷）；而其他功能被扔在最后零星且“凑合”地实现。在最后期限逼近的时候，所有纯粹的想象都烟消云散，最重要的功能顺利运行。
2. 一个产品
这个数字电视产品研发时，国外已经有两家企业运营一段时间了，因此主要工作就是“抄袭”他们的功能。在抄袭了一段时间后，终于成为国内的佼佼者，但是现在反观走过来的几年，反而冒出一身冷汗，为什么呢？
原来直到10年后的今天，有很多功能仍然没有“被使用”，原因就是国内电视台有自己的业务规矩，比如年龄分级、赛事区域禁播这些功能，在国外是很热门的，但在国内至今也没有运营。这些功能的优先级在国内和国外排，会截然不同，这不是一个开发问题，而是一个客户的业务问题。
如果不是因为当年这个领域的竞争不像现在的互联网行业这么强，加之团队的工作能力极强，结局很可能不是现在的样子。
补充
很多问题的发生，并不局限于要在开发组的范围内找答案，而一定要追究最终的原因（无我）。
很多时候人们只现在在自己范围内找答案的原因，是因为自己可以控制，可以解决。但实际上如鞥这些答案解决问题不彻底，问题就会永远存在。
但如果遇到了别人的答案，则应该遵循劝人、帮人、替人解决问题的方法。有时候在这家企业、这个部门、这个项目上有可能失败，但就像共振一篇中所提到的，如果因此而放弃，则必定失败；不但如此，还会失去在那家企业、那个部门、那个项目的成功准备。