您好,欢迎访问深圳市弘博创新管理咨询有限公司!

400-175-8898

全国咨询热线

您现在所在位置:主页 > 敏捷 >

如何构建紧密合作的敏捷团队

更新时间:2020-05-15

 

001

 

在常见的敏捷实践中,有一个棘手的错误假设:会有一个人负责写故事并执行所有这些故事对话。在Scrum式的敏捷过程中,这个人成为“产品负责人”(Project Owner)。

 

然而,有两大理由可以说明这个逻辑为什么行不通,当然,也有其他许多微不足道的理由。

 

●  第一大理由

要使故事从一个模糊的概念变得小而具体且可以开发,需要展开很多对话。一个人肯定搞不定所有这些对话。而且,如果设置好流程,就要求有人必须在某个节点做某事,很快你会发现这个人就会成为团队的瓶颈。

 

●  第二大理由

一个人的知识技能和视野往往有限,做不到跨学科和多样化,因而无法应付所有这些对话并得出最佳方案。这需要具备不同技能的人之间相互协作。

要求一个产品负责人来写所有的故事和开展所有故事对话,显然是行不通的。

 

 

002

 

另一个糟糕的反模式是委员会设计,即每个人都有平等的发言权,可以参与开发决策。在一个委员会中,当我们只有做一件事情的时间和资源时,往往会倾向于妥协。我和我的前妻在选择餐馆时就经常这么干,她想吃海鲜,而我想要吃墨西哥菜,最后的解决方式是,我们两人都吃了自己不喜欢吃的东西。

 

当委员会不受限于时间和资源时,往往倾向于把所有的事情都做完。你一定用过这样的软件产品:它有着数不清的功能,然而最大的问题是很难迅速找到自己需要的功能并记住它的具体用法。

 

优秀的产品负责人往往会接力做出好的决策。他们可以包容许多人的知识技能和观点。但归根结底,当资源有限或产品的成败在此一举时,必须由他们来做出决策。总有人对决策不满意。

 

我的朋友说得好:要社区设计,不要委员会设计……设计从来都是不讲民主的。

 

 

003

 

在 Marty Cagan 的《启示录:打造用户喜爱的产品》中,他对产品经理的职责描述是“打造一个有价值、可用且可行的产品。”当我第一次看到这句话时,立即想到一个简单的思维图:

 

我们想要的方案是一个对公司和客户有价值的、用户可以使用的并且在给定时间和工具条件下可行的方案。

 

 

但是,不是那么显而易见的是,真正找出位于思维图中间部分的解决方案,需要理解业务、客户、用户和技术的人之间如何去相互协作、并且负责方案成败的人。

 

这些人要实际参加,与干系人、客户和用户进行交谈,实际设计和测试用户界面,实际设计和测试运行产品的代码。

 

 

004

 

正如本文开头所说的那个误解,由产品负责人或产品经理来做开发决策。同时拥有业务、用户界面设计以及工程等各项必备技能,并且能找到最有价值、可用和可行方案的产品经理,这样的角色人间少有,几乎是神一样的存在。

 

所以,大多数高效率组织的做法都是组建小型的、跨职能探索团队来协作寻找正确的方案。要想让一个故事从一个大的、模糊的概念转变为小的、具体的、可开发的方案,就需要做这些工作。

 

探索团队最理想的规模是2-4个人,这是餐桌交谈的规模,这样一来,大家可以快速建立共识。

 

这个团队应该由一个对业务愿景、战略以及产品服务市场有深度理解的产品负责人主导。

 

这个核心团队应该有这样的人,他理解用户,可以自如地和用户合作,力求了解他们的工作方式,并且可以开发简单的UI原型。

 

这个团队也应该包括一个来自开发团队的资深工程师。这个人需要理解系统目前的架构,知道哪些新的技术方案可以用来解决目前的难题。

 

这里有一个真正的秘密,即大多数原创性解决方案通常出自可以真正洞察业务问题和用户问题的工程师。

 

一个紧密协作的探索团队是一个强大的,快速行动的专家团,他们可以快速发现问题并验证解决方案。

上一篇:Scrum Master 在团队中担当怎样的角色?

下一篇:没有了

热门文章

  • 如何构建紧密合作的敏捷团队

    上传:2020-05-15

  • 团队沟通,你是在对话还是自说自话?

    上传:2020-04-21

  • 深度好文,帮你搞清楚什么是增量?什么

    上传:2020-04-21

  • 企业为什么要敏捷转型

    上传:2020-04-21

  • 敏捷教练:巧用设计工作室

    上传:2020-04-21

在线客服

ONLINE SERVICE

联系电话

400-175-8898

返回顶部