协作式产品责任的五大支柱

我做过工程师、经理、测试人员和产品负责人。产品负责人是其中最难的角色之一，作为教练我也常帮助人们应对这一角色。今天我想质疑产品决策必须集中在一个人身上的想法。

“只有一个人承担责任”之类的说法意味着出问题时可以找一个人负责。我想问的是，有人可责备是否真的能帮助团队成功交付产品。

观众列出优秀产品负责人的特质，包括愿景、沟通、协作和知识。我问，我们是否期望一个人具备所有这些品质并掌握所有相关知识。

一种定义将产品负责人视为开发团队的一员，通过管理待办事项实现共同目标。这听起来很协作，但我担心其他描述把问题定义和方案设计都交给负责人一人。

待办事项还不是解决方案：它只是一个假设，即某个想法可能满足用户需求。只有经过测试和交付，我们才能了解问题是否真的得到解决。

确定优先级依赖于理解客户和价值。产品负责人可以与团队交流、利用用户研究评估需求，而不是独自作出所有决定。

要判断交付是否成功，可以向用户收集反馈或与他们一起测试。经理批准功能或吞吐量图表改善，并不能证明该功能解决了客户的问题。

我也质疑向团队隐藏大部分待办事项的做法。如果团队共同承担产品方向的责任，透明有助于大家理解更广泛的背景。

我引用一项关于定制内部业务系统的研究，指出许多功能很少被使用或用户并不知道。我也承认此类研究存在争议和测量困难；重点是检查实际使用情况，而不是假定每个交付功能都有价值。

我将 Frederick Taylor 的科学管理与把一线员工视为知识来源的方法作比较。Taylor 对工作测量的重视让流程受到经验性审视，但把规划与执行分离也反映了对工人的严重不尊重。

我转向 Toyota 生产系统及其对精益和敏捷思想的影响。这个例子可用于理解管理理念，但并不意味着制造业与软件开发完全相同。

在一段 Toyota 员工短片中，一位工人介绍团队成员发现问题时可以停止生产线，也可以提出改进建议。我强调倾听最接近实际工作的人。

我介绍一种建议机制：员工可以作出小改进并报告。我用调整常用工具位置的例子说明，局部变化既可能改善舒适度，也可能提高工作效率。

尊重也应延伸到软件团队。我回忆一家公司希望员工更自主地决策，却仍规定他们如何着装，并追问其政策是否符合它所宣称的信任。

在一个虚构的生产线例子中，工人发现箱子受损并停止生产线。工人、经理和另一名同事一起检查流程，商定修复办法，并决定如何确认修复有效。

小组更新标准化工作记录，使其反映改进后的流程。我区分了支持持续改进的共同记录，与未经团队参与而强加的固定指令。

经理和一线员工带来不同视角：一方可能看到更广泛的系统，另一方了解眼前的工作。同样，产品负责人、工程师和用户也可以共同解决问题。

向团队提出假设，而不是号称确定无疑的解决方案。寻找能以最低成本、最快速度否定假设的实验；主动寻找反证有助于对抗确认偏误。

无论实验是否否定假设，团队都能从中学习。反复进行这一循环，会积累共享的产品知识，并为共识打下更坚实的基础。

我的五项原则是尊重人、拥抱不确定性、开展小实验、持续学习和避免自满。把问题交给团队解决，并相信他们有能力贡献。

详细计划可以让人对不确定性感觉更安心，却不会消除不确定性。小实验帮助团队在全力投入某个方向之前试探情况并学习。

最后，要让质疑即使是根深蒂固的假设也成为安全的行为。团队持续共同学习，而不是把所有判断交给一个人，协作式主人翁意识就会形成。