如何成为优秀的Product Owner？.docx

如何成为优秀的Product Owner？在整个敏捷Scrum开发的过程中，Product Owner起着至关重要的作用。Product Owner，即产品负责人，代表利益相关者的利益：代表客户的意愿，从业务角度保证Scrum团队做正确的事；同时代表项目的全体利益干系人，负责产品列表（Product Backlog），排出优先级，编写条目化的需求（用户故事），从而使项目价值最大化的人。Product Owner 职责确定产品的功能。决定发布计划（发布日期和发布内容）。为产品的profitability of the product (ROI)负责。根据市场价值确定功能优先级。（即根据功能客户的价值/投资回报率对来确定优先级）在Sprint调整功能和调整功能优先级。接受或拒绝接受开发团队的工作成果。Product Owner主要工作搜集用户故事采取用户访谈、问卷调查、与客户面对面沟通，挖掘用户需求。记录用户故事如实反映用户的真实意图。为什么使用用户故事？需求规格说明书：冗长的文档，专业的描述，离用户距离很远；企图开发之前描述完整的、精确的、详细的需求；包含所有需求需求无明确的优先级；包含非功能性的需求无法被验证用户故事：简短的用户故事，一目了然的格式，离用户距离更近；掌握了必要的信息，可以继续前行；随时记录需求，按需要及时展开；有优先级的排序，先开发重要的；成果可以被验证需求讨论主要是在Sprint计划会议，通过团队和Product Owner之间不断的提问和回答问题不断补充需求背景和细节。强调面对面沟通、随时随地、充分的沟通。参与估算和Sprint计划会议排列用户故事的优先级；参与团队使用故事点对用户故事进行估算。与团队共同确定每个Sprint Backlog。维护产品列表产品列表，是所有待开发功能的列表，Product Owner根据产品的发展和从客户那里得到的反馈，不断对产品列表进行更新、调整。验收产品，参与Sprint评审会议召开Sprint 评审会议，判断每个用户故事是否完成。优秀Product Owner品质始终都在懂业务善于沟通果断得到授权的为团队指出正确的目标Product Owner由谁来担任为便于讨论，简单的将项目分成两类：第1类是只在一个组织内的项目，比如按商业合同为甲方开发；第2类是会在多个组织部署的项目，比如产品开发。Scrum中没有项目经理角色，但对于目前实际项目来说，项目经理都是安排的，尤其在按商业合同开发中，项目经理尤其重要。下文是基于存在项目经理来阐述的。第1类项目对于第1类项目，担当Product Owner的人员有3种可能。最终用户方的代表项目经理团队中安排专人1）在目前的市场条件下，只有极少数最终用户方的代表担当Product Owner，需要同时满足如下条件：用户方领导明确授权给代表，并且代表本人愿意担当责任；实际中很多代表虽然有授权，但是不愿意承担责任。代表了解Scrum，同意采用Scrum方式，并愿意担当Product Owner。2）项目经理担当Product Owner，通过两者职责的文字对比，可以发现项目经理是适合担当Product Owner的，现实中也有PM担当Product Owner的实例。在条件允许的情况下，推荐PM担当Product Owner。项目经理担当Product Owner的条件是：项目人员规模在20人以下，5~9人的典型Scrum团队人数最合适；项目经理懂技术，懂Scrum。项目经理有足够的时间与用户交流。3）在条件不满足时，只能安排专人担当Product Owner。专人Product Owner的条件有：Product Owner得到PM的明确的分级别授权，哪些问题是可以Product Owner拍板的，哪些问题是需要和PM商量的。Product Owner要得到用户的认可，有足够的时间与用户交流。第2类项目第2类项目也是常见的，产品开发项目属于这一类，这类项目的特点是没有明确的用户，只有潜在的用户。来自于最终用户的代表显然没有了。分析这类项目的主要参与方有：领导或Boss：就是那些为了达到特定的商业目的我们的软件投资的决定者，或者那些对决定有着关键性影响的人。目标最终用户。合作伙伴。项目团队成员：就是Scrum中的“猪”，编码实现软件的工程师们。第2类项目一般是内部项目，也许有些组织已经按Scrum取消了项目经理角色。内部人员：同一个组织里的人员或其他部门人员，包括销售，市场，售前等。Product Owner在这类项目中存在如下突出的困难：虽然了解了一些市场情况、潜在用户的需求等等，但难于判断哪些是优先，有没有遗漏。为了确定功能，需要与各方交流沟通，各方响应未必迅速、有效。当各方（市场、销售、合作伙伴等等）的要求有冲突时，Product Owne