需求优先级

思考的角度：

需求优先级标准

在实际工作中，其实是需要综合考虑的。之前有看过一篇文章，好像是亚马逊（具体哪个公司忘了），因为用户量的疯涨，原有的架构已经无法满足要求了，只好重建架构。但是，重建的同时，旧的系统一直在依据需求进行维护、改进，而不是不管不顾。这样一年后，新老系统成功无缝对接，做到了架构优化的同时兼顾了用户需求。

我们在实际操作中，可能并不会面临这样的问题。但是，应该有并行改进的观念。需求 A 耗费的开发时间可能比较长，但在进行 A 的时候，可以不断插入 B 类需求，小的需求随时解决改进，不需要等 A 全部完成再开始其他的需求。

在一些公司，可能会有谁的话语权比较大，先解决谁的需求的情况。CEO 可能会说我们需要加一个A 功能，同时用户在不断呼吁 B 功能。产品经理此时需要做出决策，判断到底是先上 A 功能还是 B 功能。如果认为 B 的优先级大于 A，需要拿出具体的决策依据（数据、反馈等），尽量说服 CEO。

总之，优先级并没有明确的规定，需要统筹考量，依据实际情况酌情而定。