作为产品负责人，你依赖于开发团队来完成工作。但有些团队由于绩效不佳，而没能可靠地交付可工作的软件。这篇文章将讨论产品人员如何应对低绩效开发团队，并帮助组织一起进步。
什么是绩效不佳？
在讨论如何提升团队绩效前，我们先简短的探讨一下，一个高绩效团队是怎样的？我们以基于Scrum流程的敏捷团队为前提，如果满足以下三点，开发团队就能做得很好：
第一，团队可靠地达成约定的Sprint目标，交付了用户体验极佳且满足预期质量的产品增量；第二，团队参与持续发现和战略制定，且定期协助进行产品待办列表的梳理。第三，团队遵守可持续的步调，工作量和强度不会影响团队成员的健康工作习惯。
如果这些需求中有一些无法满足，团队就需要进行改善。以下团队纠结于如何提升绩效的三个常见症状：团队反复过度承诺，或交付缺陷很多的软件；团队成员都指望你一个人，也就是产品负责人，来做产品待办事项的梳理和用户故事的编写；最后，团队成员需要频繁加班来完成Sprint中的工作。
作为产品负责人，你依赖于团队的工作产出，无疑也会受到团队不良绩效的影响。这些包括：无法向（选定的）用户和客户交付可用软件，很难可靠的预测开发进展，很可能由于无法得到开发团队的必要支持而工作过度。因此帮助团队回到正轨对自己来说也是刻不容缓的。同时，你不是老板，不能要求团队成员做什么。再者，一个敏捷的，自组织的团队应该共同对团队绩效负责。这些都使得帮助团队改进变得更有挑战。
分享观点 但不要教人做事
让我们用一个例子来讨论可以如何帮助一个陷入困境的团队。假设你正在负责一个全新的产品，当前的Sprint有一个重要目标：向特定的用户发布产品增量，以验证提供的功能是否对他们有作用。此外，你还邀请了高管赞助人来参加即将到来的Sprint评审会议，以获得他的持续支持。
但在今天的每日站会上，你注意到Sprint的进展令人担忧的慢：许多任务未能完成，有些故事甚至还没开始。看起来开发团队落后于计划，并且很难达成冲刺目标。然而，团队似乎并未感到担忧。
这种情况下，你可能会忍不住想干预，告诉团队需要振作起来，甚至还会给一些成员指派任务。但这是错误的，你会干扰并破坏团队的自管理。一个敏捷团队应当负责计划和跟踪工作，按天审查工作进展，并决定如何开展工作以最大化达成Sprint目标的机会。如果你介入并掌控，你就会像一名项目经理，这在本质上削弱了团队的权力。
但这并不代表你就应当做一名被动的旁观者，看着团队走向失败。如果你认为团队需要你的帮助，可以直接与他们沟通，例如在站会之后。但是，记得在表达观点前，先询问团队的意见。比如你可以说，“进展如何？你认为你们能够顺利达成Sprint目标吗？”然后用心聆听团队成员的反馈。
若你对回答不满意，并认为团队成员没有意识到当前的问题，尝试用不评价和批评的语气表达你的观点。你可以说，“在我看来，开发进展比较缓慢，有几个任务还未完成，有些故事还没有开始。你们觉得是这样吗？”
但让团队来决定该怎么做，不要把你的观点强加给他们。毕竟你也可能是错的：尽管你顾虑重重，但团队也许做得很好。如果你不确定你是否该说些什么，试着和帮助团队实践自管理的Scrum Master聊聊，我们将在后面讨论这一点。
在Sprint结束时进行总结
当新的产品增量完成时，你可以清楚的了解到团队取得了多少成果。基于对产品增量的演示，你可以根据完成定义（DoD），即每项产品增量必须符合的质量标准，来确认哪些待办事项真正被“完成”了。这能成为你判断Sprint目标是否达成，团队工作是否出色的依据。
如果结果表明开发团队没能达成Sprint目标，那么需要给出真实的原因。清晰的表明哪些实现了，哪些没有实现。比如团队只完成了他们拖到这个Sprint的待办事项中的一半，且与Sprint目标相距甚远，那么不要装作团队的表现还行。事实并非如此。他们就是表现不佳。我见过Scrum产品负责人忍受一个绩效不佳的团队，一方面因为他们希望事情会自行改善，另一方面因为他们想回避沟通艰难的窘境。而事实是，如果不开诚布公地讨论这个问题，事情不会有什么好的变化。
同时，与开发团队共情，并友善地谈话。不要对成员发脾气，指责或批评。把团队视作有价值的合作伙伴，承认团队付出的努力。此外，联系实际环境看待团队的表现问题：一个新成立团队或一个经历了重大变化的团队，可能需要几个Sprint来调整，才能可靠的达成Sprint目标。同样的，正在应对重大技术挑战的团队由于不确定性，可能很难准确地做好Sprint计划。
为了给予有帮助的反馈并更好的传达你的信息，你可以说：“你们完成了部分产品待办事项，这很好，感谢你们的努力。但只有一半的工作完成了，显然无法达成Sprint目标，这让我很失望。我希望能了解是什么地方出了问题，我们怎么做才能避免今后再出现类似的情况？”如果你很烦躁或生气，试着在发表意见前先深呼吸并数到十。如果还不够的话，可以休息一会儿，等平静下来后再继续。有负面情绪很正常，但不能表现出来。我曾经目睹一次Sprint评审会演变成大声嚷嚷的争吵，显然这无法解决任何问题，反而让事情变得更糟糕，破坏了信任，且损害了关系。
利用回顾会来确定改进方向
每当遇到绩效问题时，利用Sprint回顾会来识别并解决根本问题。例如，你可能会发现有些进入Sprint的用户故事太大了，或者缺少验收标准，团队在Sprint计划会中没有采用完成定义来识别必要的任务，软件开发环境不稳定，或是未解决的冲突再次出现，使团队进度变慢。
务必要参与回顾会，但不要主导会议，或责备和评判他人。相反的，抱着贡献的心态，询问你能够如何帮助避免同样的问题再次出现。不要假定绩效问题一定是团队的错，而是培养开放的心态，积极听取开发团队成员的意见。你可能会发现，比如，你在梳理产品待办列表时，没有让足够的人参与进来，这有可能导致了太大而不清晰的用户故事，使得团队难以达成Sprint目标。也可能你给了团队压力，让他们把超过团队实际容量的工作纳入Sprint中。这两个问题只有在你准备好了改变自己的行为方式时，才能被真正解决。
如果一个绩效问题在找到了根因并实施了改进措施后继续存在，那么你可能要考虑调整团队组成。假如一个团队的成员在同一个产品中，负责不相关领域的工作，那么将其拆分开也许更有好处。如果个别团队成员持续表现不佳，请他离开团队也可能是必要的。但不要将这些改变强加给团队，而是在回顾会中进行开放，真诚的对话，寻求对每个人都可行的解决方案。这能够建立透明性，给予团队成员发表意见的机会，减少个别成员感到挫败或遭遇了不公平对待的风险。
最后，让Scrum Master来主持会议，提出发掘潜在原因和可执行改进措施的有效方法。如果没有Scrum Master或敏捷教练，找一位有经验的，中立的主持人，来保证每个人的声音被听见，会议没有被个别人主导。
让Scrum Master来辅导团队
尽管你很想帮助开发团队，记住你的职责是管理产品，而不是辅导团队，那是Scrum Master或敏捷教练的工作。如果没有Scrum Master，或这个人暂时没有足够时间或能力，不要犯错误去替代他，当然更不要长期地代替他的工作。这会让你忽视在产品管理方面的一些职责，比如审查和更新产品战略及产品路线图，不要甚至因此影响你自己的情绪，这些都是不可取的。
然而，意识到缺少称职的Scrum Master这个问题需要被重视并与组织中的决策者共同找到解决方案。我个人觉得，如果Scrum Master的角色没有被恰当填补，要求产品人员充当产品负责人角色是不公平的。 关于本文的话题，你有什么想法或经验？欢迎在评论区留言交流。
关于作者:
Roman Pichler 是一位产品管理专家，精通数字产品及敏捷实践，拥有超过20年的产品管理及敏捷项目开发经验，丰富的产品经理及产品负责人教学经验，且已为产品领导者提供咨询超过15年。
关于译者:
Scrum中文网翻译组：Scrum中文网是全球第一个Scrum中文网站，中国最早的Scrum和敏捷教育及推广机构，也是国际Scrum联盟（ScrumAlliance）官方授权教育机构和大规模敏捷SAFe官方机构SAI在中国的授权合作伙伴。Scrum中文网是中国敏捷教练的摇篮，启蒙和培养了数万名敏捷专业人士，帮助数百家知名企业成功转型敏捷。
原文链接：
注：部分图片来源于网络
