修Bug和新需求，产品经理如何权衡优先级？

修Bug和新需求，产品经理如何权衡优先级？

本文转译自Quora，原文链接见末尾。
Ian McAllister, Director at Airbnb
首先你需要确定一个优先级的评判标准，这样可以大大帮助你去做类似的决定，这个标准框架包括：

• （攻）你的产品或者公司的目标愿景。这个是指导你投资发展业务的最高级别的指导纲领。你的目标可能是增加新用户、提升转化率、留住老用户、提升产品性能、拓展国际市场。需要注意的是，你所做的个别产品项目并不是你的目标。所谓的目标应该是横向通用的，目标应该要尽可能少且精简，在决策中有指导地位。
• （防）基本需求：指其它的东西，比如质量标准、设计标准、可用性、性能指标或者其它基准规范，这些东西可能没有上面说的目标愿景优先级高，但其实也挺重要的，不能忽视。

一旦你有了上述的评判标准框架，你就可以分配一定的资源来满足你的基本需求，并把剩下的资源投入到你的目标愿景上。如果你把很多额外的精力投入到你的基本需求上，那么你就可能在你的目标愿景上投入资源不够，也就没有办法拓展你的业务。如果你发现满足了基本需求后，没有足够的资源来应对目标愿景，那么你的人手也会不够，那你就可以把你的基本需求再往下调整一点。

如果你能够适当的调整资源（比如轮流安排工程师来做基本需求），那么你就可以独立安排（攻防需求）基本需求和目标愿景之间的优先级。根据我的经验，这比根据具体情况确定两者（比如新需求与bug）的优先顺序要简单的多。

Michael Wolfe, five startups and counting
从理论上讲，所有的产品资源投入都应该与业务目标相匹配，所以产品管理团队应该在新需求、质量、规模和工程团队所做的一切事情上投入资源。许多产品经理持有这样的看法。但是，我发现这个东西在实践中总是有一些问题，原因可能如下：

• Bug导致更多Bug。即使是一个用户永远也不会遇到的Bug，也有可能会有一些隐藏原因或者造成连带问题，修复它可能会产生比预期更大的影响。
• Bug会榨干技术支持及工程团队的资源。通常，产品经理们才不会看到工程团队投入了多少资源来修复用户的Bug。
• 产品经理们平时的工作就已经够烦的了，平时就得要时常评估新需求，还要求爹爹告奶奶讨开发资源。然后还要把几十个Bug的修复加进决策范围内，他们就会陷入无数次优先级的讨论，几十个小项目的拉锯战中。
• 讨论质量问题可能会对工程团队带来不好的影响，也可能会拖累企业文化。就算是大老板说质量是首要的工作，那也会导致，产品经理与工程师们无休止的讨论是否应该修复这个Bug以及对应的优先级。
• 工程师有的时候也挺难的，会觉得自己在为产品管理而工作，而且每次做需求都要征求许可。除非他们自己觉得这个东西应该做，偷偷不告诉产品经理的时候，才会觉得自己是在做一个项目。说“产品经理也得处理一些Bug”可以让工程师们说“OK，我需要负责那些东西吗？”

我更喜欢“工程师来决定质量问题”的方法，工程团队决定一个需求在质量达标的时候发布，以及决定当一个Bug出现的时候投入多少资源去解决它。工程团队来决定处理Bug用多少开发资源，剩下的资源就用来开发新需求。