产品负责人PO至少需要面对的两个方向：
1、PO必须很好地理解组织中利益干系人、客户和用户的需求及优先级。该场景下，PO担任的是产品经理的角色，确保能给出正确的解决方案。
2、PO必须要和开发团队交流要构建的特性及构建顺序。PO还必须保证接收标准已明确定义，并且已满足测试验证的标准。PO不需要写详细的测试用例，但要保证完成概要测试用例的编写，让团队可以确定在什么情况下达到PO定义的特性完成标准。该场景下，PO做的是业务分析师和测试人员的工作。
主要职责：
管理经济效益：PO要确保在版本、冲刺和产品列表层面持续做出良好的经济决策。
版本层面的经济考量：产品开发过程中，重要的经济价值信息会不断涌现，PO需要一直在版本级别综合考虑范围、日期、预算和质量。
冲刺级别的经济考量：PO要确保每个冲刺都能带来良好的投资回报（ROI）。优秀的PO在花费公司资金时就像花费自己的一样谨慎。在大多数情况下，PO都知道下一个冲刺的成本是多少（冲刺的持续时间及团队成员的人力成本）。在掌握这些信息后，PO在制定冲刺计划时要扪心自问：”在这个冲刺中，如果是我自己出钱的话，我愿意化这么多钱去构建这个冲刺中计划完成的特性吗？“如果答案是否定的，优秀的PO就会重新审视改变计划。
产品列表的经济考量：PO要负责排列Product Backlog的优先顺序。在经济情况发生变化时，Product Backlog的优先级可能会变化。
参与规划：PO是做组合规划、产品规划和冲刺规划的重要参与者。
在做组合规划时，PO与内部干系人一起把产品放到组合列表正确的位置并确定产品开发工作的起止日期。
在做产品规划时，PO与利益干系人一起制定产品愿景。
在做版本规划时，PO与利益干系人及团队一起确定下一个版本的内容。
在做冲刺规划时，PO与开发团队一起确定冲刺目标。PO还会给出有价值的意见，让开发团队根据实情选择在冲刺结束时能够交付的一组PBI。
梳理产品列表：PO负责管理Product Backlog的梳理活动，包括PBI的建立、细化、估算和排列优先顺序。PO不会自己执行所有的梳理工作，研发团队大概会拿出10%的工时协助PO完成梳理工作。例如，PO不一定写所有的PBI，其他人可能也会写。PO不会估算PBI（研发团队评估），但在估算期间要负责解答问题，澄清疑问。不管采用什么方式，最终仍由PO确保梳理活动有助于价值交付过程的顺利进行。
定义接收标准并验证：
PO负责为每一个PBI定义接收标准。只要达到这些条件，PO才确信功能需求和非功能需求已经满足。PO可能还会写对应于接收标准的接收测试用例，或者找主题事务专家（SME）或研发团队协助编写。不论哪一种方式，PO都应该保证只有建立这些接收标准（常常指具体的接收测试用例），PBI才能纳入冲刺计划会议中进行宣讲。如果没有这些接收标准，团队对PBI的理解就不完整，不能将它移入冲刺。因此，很多Scrum团队都明确把接收标准作为”就绪“定义检查表中的一项内容。
PO最终负责确认PBI是否满足接收标准。PO可以自己执行接收测试，也可以找专家用户帮助他确认PBI是否符合必要条件。团队可以帮助创建一个用户测试的基础设施，让产品负责人或特性SME更有效地执行测试，但对PBI是否满足要求，最终应由PO判断。
PO要在执行冲刺的过程中验收接收标准，而不是等到冲刺评审时再验证。PO需要在特性完成后做一些测试，发现错误和误解并让团队成员在冲刺评审之前修复。因为团队在评审时只允许演示已经完成的特性，所以PO必须确保在评审之前执行接收测试，让团队知道哪些特性满足”完成的定义“。
与开发团队协作：PO必须经常与开发团队保持紧密合作。PO需要积极投入，尽心尽力，每天都参与团队活动，及时给出必要的反馈。在使用Scrum时，我们一次构建一个特性，而不是一次按一个阶段构建。这意味着在创建某个特定的特性时，需要在一个冲刺中执行所有活动（设计、代码编写、集成、测试）。因此PO必须要一直积极参与。
与利益干系人协作：PO是内外部利益干系人团体的唯一代言人。PO必须与整个利益干系人团队紧密合作，集思广益，形成一个统一的愿景来指导产品开发工作。在某些情况下，工作量可能超出PO的能力范围，此时PO可以找其他人帮助自己履行这个角色的职责。
PO的四个重要特征：
网友评论