Scrum_tp

如何提升研发团队的绩效?

作为产品负责人,你依赖于开发团队来完成工作。但有些团队由于绩效不佳,而没能可靠地交付可工作的软件。这篇文章将讨论产品人员如何应对低绩效开发团队,并帮助组织一起进步。

什么是绩效不佳?

在讨论如何提升团队绩效前,我们先简短的探讨一下,一个高绩效团队是怎样的?我们以基于Scrum流程的敏捷团队为前提,如果满足以下三点,开发团队就能做得很好:

第一,团队可靠地达成约定的Sprint目标,交付了用户体验极佳且满足预期质量的产品增量;第二,团队参与持续发现和战略制定,且定期协助进行产品待办列表的梳理。第三,团队遵守可持续的步调,工作量和强度不会影响团队成员的健康工作习惯。

如果这些需求中有一些无法满足,团队就需要进行改善。以下团队纠结于如何提升绩效的三个常见症状:团队反复过度承诺,或交付缺陷很多的软件;团队成员都指望你一个人,也就是产品负责人,来做产品待办事项的梳理和用户故事的编写;最后,团队成员需要频繁加班来完成Sprint中的工作。

作为产品负责人,你依赖于团队的工作产出,无疑也会受到团队不良绩效的影响。这些包括:无法向(选定的)用户和客户交付可用软件,很难可靠的预测开发进展,很可能由于无法得到开发团队的必要支持而工作过度。因此帮助团队回到正轨对自己来说也是刻不容缓的。同时,你不是老板,不能要求团队成员做什么。再者,一个敏捷的,自组织的团队应该共同对团队绩效负责。这些都使得帮助团队改进变得更有挑战。

分享观点 但不要教人做事 

让我们用一个例子来讨论可以如何帮助一个陷入困境的团队。假设你正在负责一个全新的产品,当前的Sprint有一个重要目标:向特定的用户发布产品增量,以验证提供的功能是否对他们有作用。此外,你还邀请了高管赞助人来参加即将到来的Sprint评审会议,以获得他的持续支持。

但在今天的每日站会上,你注意到Sprint的进展令人担忧的慢:许多任务未能完成,有些故事甚至还没开始。看起来开发团队落后于计划,并且很难达成冲刺目标。然而,团队似乎并未感到担忧。

这种情况下,你可能会忍不住想干预,告诉团队需要振作起来,甚至还会给一些成员指派任务。但这是错误的,你会干扰并破坏团队的自管理。一个敏捷团队应当负责计划和跟踪工作,按天审查工作进展,并决定如何开展工作以最大化达成Sprint目标的机会。如果你介入并掌控,你就会像一名项目经理,这在本质上削弱了团队的权力。

微信图片_20220330101635

但这并不代表你就应当做一名被动的旁观者,看着团队走向失败。如果你认为团队需要你的帮助,可以直接与他们沟通,例如在站会之后。但是,记得在表达观点前,先询问团队的意见。比如你可以说,“进展如何?你认为你们能够顺利达成Sprint目标吗?”然后用心聆听团队成员的反馈。

若你对回答不满意,并认为团队成员没有意识到当前的问题,尝试用不评价和批评的语气表达你的观点。你可以说,“在我看来,开发进展比较缓慢,有几个任务还未完成,有些故事还没有开始。你们觉得是这样吗?”

但让团队来决定该怎么做,不要把你的观点强加给他们。毕竟你也可能是错的:尽管你顾虑重重,但团队也许做得很好。如果你不确定你是否该说些什么,试着和帮助团队实践自管理的Scrum Master聊聊,我们将在后面讨论这一点。

在Sprint结束时进行总结

当新的产品增量完成时,你可以清楚的了解到团队取得了多少成果。基于对产品增量的演示,你可以根据完成定义(DoD),即每项产品增量必须符合的质量标准,来确认哪些待办事项真正被“完成”了。这能成为你判断Sprint目标是否达成,团队工作是否出色的依据。

如果结果表明开发团队没能达成Sprint目标,那么需要给出真实的原因。清晰的表明哪些实现了,哪些没有实现。比如团队只完成了他们拖到这个Sprint的待办事项中的一半,且与Sprint目标相距甚远,那么不要装作团队的表现还行。事实并非如此。他们就是表现不佳。我见过Scrum产品负责人忍受一个绩效不佳的团队,一方面因为他们希望事情会自行改善,另一方面因为他们想回避沟通艰难的窘境。而事实是,如果不开诚布公地讨论这个问题,事情不会有什么好的变化。

同时,与开发团队共情,并友善地谈话。不要对成员发脾气,指责或批评。把团队视作有价值的合作伙伴,承认团队付出的努力。此外,联系实际环境看待团队的表现问题:一个新成立团队或一个经历了重大变化的团队,可能需要几个Sprint来调整,才能可靠的达成Sprint目标。同样的,正在应对重大技术挑战的团队由于不确定性,可能很难准确地做好Sprint计划。

为了给予有帮助的反馈并更好的传达你的信息,你可以说:“你们完成了部分产品待办事项,这很好,感谢你们的努力。但只有一半的工作完成了,显然无法达成Sprint目标,这让我很失望。我希望能了解是什么地方出了问题,我们怎么做才能避免今后再出现类似的情况?”如果你很烦躁或生气,试着在发表意见前先深呼吸并数到十。如果还不够的话,可以休息一会儿,等平静下来后再继续。有负面情绪很正常,但不能表现出来。我曾经目睹一次Sprint评审会演变成大声嚷嚷的争吵,显然这无法解决任何问题,反而让事情变得更糟糕,破坏了信任,且损害了关系。

微信图片_20220330101646
利用回顾会来确定改进方向 

每当遇到绩效问题时,利用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中文网是中国敏捷教练的摇篮,启蒙和培养了数万名敏捷专业人士,帮助数百家知名企业成功转型敏捷。

原文链接:

https://www.romanpichler.com/blog/dealing-with-performance-issues-on-the-development-team/

注:部分图片来源于网络