1703950742
一般来说,二三线城市的技术人员成本是一线城市的60%~80%,高校林立的二三线城市里,人才济济,只是本地互联网公司数量较少,难以形成市场化的人才培养机制,以至于毕业生在毕业后的几年里,技术的深度和广度跟一线城市的从业者拉开了距离。因此,如果一个公司本身已经形成了一套人才培养的机制,通过在二三线城市建立研发中心,能够获得优秀的技术人才,也能够大幅节省成本。
1703950743
1703950744
当建立起异地团队后,首先出现的问题是异地沟通效率低下的问题。为了更好地了解这个问题的现象和本质,我们首先来看一张异地沟通协作示意图,如图3-13所示。异地团队一般所采用的是网状沟通方式,这种沟通方式的效率非常低下,产品设计人员为了给异地的开发人员讲解需求,需要做一次统一的需求讲解,所有的开发人员参与,当开发人员在实际开发中发现问题后,又需要再次找产品设计人员,当10个开发人员,每个人有2个问题需要跟产品设计人员沟通时,就有至少20次异地沟通,要知道异地需求讲解通过电话、语音等即时通讯工具,是比较低效的事情。
1703950745
1703950746
1703950747
1703950748
1703950749
图3-13 异地团队网状沟通图
1703950750
1703950751
比较有效的办法是,建立“异地沟通接口人”的方式,涉及到这种需求讲解、方案说明的情况,都可以通过这种异地接口人先进行沟通,并且确保内容完全沟通彻底,通常这个接口人的沟通表达能力较强、对业务需求和技术方案都非常熟悉,才能胜任这个角色。如图3-14所示就是异地接口人的沟通示意图,异地接口人负责进行异地工作的沟通,再有效传达给团队,把异地沟通数量减少90%以上,更多的是同地团队成员跟接口人的沟通。
1703950752
1703950753
1703950754
1703950755
1703950756
图3-14 异地团队沟通接口人方式
1703950757
1703950759
3.4.2 每日晨会,暴露问题
1703950760
1703950761
异地团队协作进行项目开发时,最致命的问题是,在开发过程中项目经理很难发现异地团队出现的问题,只有等到项目联合调试的时候才暴露出问题,但是这个时候已经晚了,严重影响了项目的交付质量。
1703950762
1703950763
异地团队之间的每日晨会,能够很好地解决这个问题,每日晨会的形式跟敏捷开发里的“每日站会”是相同的,需要团队成员都参加,每个团队成员只需要讲3个问题:昨天我完成了什么?今天准备完成什么?目前遇到的困难是什么?讲的过程中不允许打断,讲完就结束每日晨会,时间控制在15分钟以内。
1703950764
1703950765
Team leader和项目经理,记录下问题项,晨会结束后找到相关人员,帮助解决出现的问题。这样的晨会必须持之以恒,以便养成团队主动反馈问题的习惯,另外这对于异地团队之间培养默契是非常重要的。
1703950766
1703950767
有条件的情况下,可以通过视频会议的方式进行每日站会,如有必要,可以打开电子白板,两地团队看到同样的信息。
1703950768
1703950770
3.4.3 异地“白板”,进度透明化
1703950771
1703950772
对于异地开发团队来说,能够及时地反馈出每个团队成员的工作进度,是非常重要的。建立一个“电子白板”(如图3-15所示)就能够让两地的团队成员,实时地看到每个人的进度,如果你的团队正在使用敏捷开发,那么你可以考虑建立在线的一个敏捷开发工作平台,让团队成员通过网络访问敏捷开发工作平台,把每天的进度录入到工作平台中,让整个开发过程透明化,便于管理人员及时发现问题,及时解决问题。也为管理工作积累数据,日后通过分析这些数据,来发现团队开发效率的短板。
1703950773
1703950774
1703950775
1703950776
1703950777
图3-15 异地“电子白板”
1703950778
1703950780
3.3.4 最佳实践案例:异地团队的3种高效组织架构
1703950781
1703950782
下面我们通过某互联网公司的上海、武汉两地团队的例子,来向大家介绍搭建高效异地团队的3种架构方式。
1703950783
1703950784
案例3-5 搭建高效异地团队的3种架构方式
1703950785
1703950786
第1种,三七团队。
1703950787
1703950788
以10个人的开发团队为例,有3个人:PD(产品设计)、DL(domain leader)、AA(应用架构师)在业务中心所在地—上海,其他的诸如TL(Team leader)、开发、测试在武汉,所以叫三七团队。
1703950789
1703950790
应用场景:需要频繁交流、强调沟通职能的domain,偏前端的应用、未成熟且快速增长业务。这种结构下,PD和DL最接近产品的业务方,可以随时面对面深入讨论功能需求和产品走向,允许在短暂降低DL和开发团队之间的沟通效率的情况下,尽量保证功能开发和产品大方向不会受到较大的影响。
1703950791
[
上一页 ]
[ :1.703950742e+09 ]
[
下一页 ]