文档首页 > > 理论实践> 持续开发与集成>

分布式开发的喜与忧

分布式开发的喜与忧

分享
更新时间:2021/02/27 GMT+08:00

关于办公场景

无论是异地分布式软件开发或是外包,可以接触到实际客户的一端称为On-Site,另一端则称为Off-Site。而Off-Site又可以根据地理位置分为三类:On-Shore(在岸,指在同一个国家或同一个时区内),Near-Shore(近岸,在接近的国家和地区中)和Off-Shore(离岸,通常在时差6小时以上),如下表所示。

Off-Site

On-Shore

Near-Shore

Off-Shore

分布式开发

北京办公室:成都办公室

印度分公司:中国分公司

硅谷总公司:中国或印度分公司

软件外包

北京某公司:成都另一公司

东京某公司:大连另一公司

欧洲某公司:中国另一公司

关于彼得原理

彼得原理是美国学者劳伦斯·彼得在对组织中人员晋升的相关现象研究后得出的一个结论。在各种组织中,由于习惯于对在某个等级上称职的人员进行晋升提拔,因而雇员总是趋向于晋升到其不称职的地位。彼得原理有时也被称为“向上爬原理”。

彼得指出,每一个员工由于在原有职位上工作成绩表现好(胜任),就将被提升到更高一级职位;其后,如果继续胜任,则将进一步被提升,直至到达他所不能胜任的职位。由此导出的彼得推论是,每一个职位最终都将被一个不能胜任其工作的员工所占据。层级组织的工作任务多半是由尚未达到不胜任阶层的员工完成的。

这个过程往往是单向的、不可逆的,也就是说,很少被提升者会回到原来他所胜任的岗位上去。因此,这样“提升”的最终结果是企业中绝大部分职位都由不胜任的人担任。这个推断听来似乎有些可笑,但绝非危言耸听,甚至不少企业中的实际情况确实如此。这样的现象还会产生另外一种后遗症,就是不胜任的领导可能会阻塞了胜任者提升的途径,其危害之大可见一斑。

因为这种情况最终会把一个晋升的梯子摆在每个管理人员面前,让每个人都成为排队木偶。为了避免人们都成为排队木偶,扭转“体系萧条”的颓势,彼得博士提出了“彼得处方”——《彼得原理》。

关于团队建设

团队建设也是有生命周期的。必然要经历组建期(Forming)、风暴期(Storming)、规范期(Norming),然后才是高绩效期(Performing)。管理到一定程度后,一定是全生命周期的管理,应该是一个闭环和持续改进的过程。

第一步,选人。千里马常有,而伯乐不常有。因为我们都不可能是专职的伯乐,所以要打破应聘要求的条条框框,多花时间在简历分析和面试沟通上。要亲自参与面试,而不是简单地给出需求,全部交给HR部门来完成。更重要的是换位思考,选择一个人才进入团队的时候,首先要考虑他能够带给成员的是什么,是否适合这个团队。如果团队中每个成员的胜任力都很优秀的话,自然能够带来优秀的业绩和团队绩效。

在找到了合适的人后,第二个重点就是为合适的人分配适合的工作。我们需要看到每个人的短处,但是我们关注的却是各尽所能地发挥每个人的长处。所以要对人员的技能做评估,对团队角色的职责做出明确定义和划分,定义好团队之间的操作规程和流程。

第三步,通过团队建设来保持整个团队的积极性和热情。首先是要建立团队愿景,很重要,是树立团队精神和建立大家共同价值观的基础。然后是制定团队的规则和纪律,这应该是大家共同制定出来的、必须要遵守的。对于团队的建设,一方面是偏重应用的,主要是指团队学习和培训组织等,提升团队的知识技能;另一方面是关于价值观、时间管理、心态、职业精神等方面的培训,便于形成团队共有的价值观。团队之所以不同于团伙,正在于团队中所有成员的价值观都是和团队价值观同向,共同的愿景才可能产生共同的合力。

第四步,建立竞争机制。在团队内营造一份良好的、积极向上的竞争氛围。

第五步,建立奖惩制度。驱动人们的理由无非有两个,一个是赢得欢乐,另一个就是逃离痛苦。这也就是管理大师们常说的X/Y理论。

最后,就是回顾并不断地调整团队,重新回到起点。

领导力

领导力应该体现在影响力上,而不是依靠组织赋予的地位权利(Position Power)。在一个团队中,影响力和说服力要比权力更重要,团队成员之所以相信你,愿意跟随你,不是因为恐惧,而是因为真的爱你、相信你。有些人可能不是一个团队领导,但却有无比的影响力和号召力,这尤其说明了这一点。

作为团队领导,很关键的一点就是看你是不是真的“用心去领导”。我觉得关键的一点就是要去了解团队每一个成员的需求与渴望,去跟他们进行心与心的沟通。这一点也是符合马斯洛的需求层次理论的。

作为团队领导人,首先需要了解你的团队成员在每个阶段的需求,然后尽可能地满足。要跟X理论和Y理论有机地结合起来。

通过Scrum管理和协调异地团队的指导原则

通过Scrum管理和协调两个不同地理位置的团队,是一个非常有挑战性的工作。

最高指导原则就是沟通、沟通、再沟通。对于一个分布式团队,最重要的就是解决沟通的问题。因为缺乏面对面的沟通,还由于时间、文化、语言的不同,需要付出更多的人力和财力才能获得预期的结果,而且小的误解也会迅速放大。这需要在团队建立之初,就考虑好这个问题。沟通不要怕多,一定要充分才行。对这个问题,有一个非常著名的康威定律(Conway's Law)。

康威定律的原始表述是这么说的:让四个人开发编译器,你就会得到四个编译器。

这个表述更具有一般性:“产品必然是其组织通讯结构的缩影”。简言之就是“方法决定结果”或是“过程变为产品”。这个定律无非在告诉我们开发人员间的高效面对面的沟通,对于好的产品和设计是至关重要的,由于沟通不顺畅,分布式的团队往往会损害到软件设计。

坚持每日站立会议。有条件的话,最好进行可视会议,这样双方都可以看到对方的表情,感受到对方的情绪变化。无论如何,面对面地交流才是最有效的方式。如果你们有条件的话,要让处于两地的团队到对方出差,互相熟悉,特别是Off-Site一端要到On-Site一端去,去与客户进行交流,了解客户需求与环境,这样才能更容易理解On-Site一端的语义上下文和环境。

方式方法会有很多,关键还是要建立好一个沟通交流机制与规则,如每天立会的时间、能否准时开会、问题的跟踪解决机制等。

指导原则之二是使用正确的实践和工具。成功的软件开发团队所使用的实践中,众所周知的有:共同的编码标准、源代码控制服务器、一键建立和部署脚本、持续集成、单元测试、错误跟踪、设计模式以及应用程序块。与本地团队相比,分布式团队必须以更严格的标准应用这些实践。

分布式开发,如何让对方知道对方、乃至整个团队任务的最新进展,单单靠每日的立会是不够的。最好采用一些在线工具进行项目跟踪,现在已经有了一些很好的在线敏捷项目管理工具。

采用工具进行代码管理,才能保证双方的每日提交,更容易集成起来。持续集成对于异地团队至关重要。

要把需求和验收条件描述清楚、简单明了,尽可能地减少误解。做到DoR(Definition of Ready,就绪的定义)。

Sprint的计划会议一定要一起开,最好是一方的人员到对方去,大家坐在一起,面对面地制订计划。而演示,可以远程进行,但也要所有的团队成员都参加才好,因为这是一个很好的分享成果的机会。而回顾完全可以分别进行,然后再相互交流回顾结果与改进计划。

分布式开发的要点

  1. 招聘员工准则:聘之以态度,授之以技能(hiring for attitude, training for skills)。
  2. 团队建设的生命周期准则如下:
    • 选择合适的人才。
    • 设立清晰的愿景、明确的目标。
    • 合理用人。人尽其才,才尽其用,充分发挥每个人的优势。
    • 建立良性竞争机制。
    • 建立奖惩与监督制度。
    • 建立完善的培训系统,关注员工的个人发展。
    • 评估并不断改进团队。
  3. 领导力应该体现在他的影响力上,而不是依靠组织赋予的Position Power。
  4. 用心去领导。要了解团队每一个成员的需求与渴望,去跟他们进行心与心的沟通。按照马斯洛的需求层次理论进行针对性的激励。
  5. 情境领导力。根据情境去领导(Situational Leadership)。没有最好的领导力,只有最适合的领导风格,管理者要根据员工的不同情境灵活调整自己的领导风格和领导形态。
  6. 尽管一个组织必须重视管理人员成长可能性,并通过提供更大的发展空间等手段来激发他们的潜能,但彼得原理可以作为一种告诫:不要轻易地进行选拔和提拔。

    解决这个问题最主要有以下三大措施:

    • 提升的标准更需要重视潜力而不仅仅是绩效。应当以能否胜任未来的岗位为标准,而非仅仅在现在岗位上是否出色。
    • 能上能下绝不能只是一句空话,要在企业中真正形成这样的良性机制。一个不胜任经理的人,也许是一个很好的主管,只有通过这种机制找到每个人最胜任的角色,挖掘出每个人的最大潜力,企业才能“人尽其才”。
    • 为了慎重地考察一个人能否胜任更高的职位,最好采用临时性和非正式性“提拔”的方法来观察他的能力和表现,以尽量避免降职所带来的负面影响。如设立经理助理的职位,在委员会或项目小组这类组织中赋予更大的职责,特殊情况下先让他担任代理职位等。
  7. 成功企业有以下两大用人之道:
    • 适当引进外来人才,避开“彼得原理”所涉及的后果。
    • 在企业内部逐步提升,重视潜力,重要的职位大多数由胜任的人担任。

用经营产品的方式经营团队

产品面临的环境是复杂的,培养一个团队也是。产品需要经营和维护,培养一个团队也是。经营产品,与经营团队有许多异曲同工之处。用经营产品的方式来经营团队,我们来看看这里有哪些可以借鉴之处。

  1. 产品需要不断探索和尝试,去发现产品被客户认可的点,并将其发挥到极致;管理中,识别你希望看到的行为,让其变成持续不断的实践,然后用纪律来保证这些实践顺利进行。
  2. 产品会做A/B测试,同样的,领导者也可以尝试用不同的方式来管理团队流程,不断设定方向,获得反馈,主动试验,持续优化。循序渐进的试验,正如同产品演进一样。
  3. 伟大的产品,会让每个参与在内的人激动不已;伟大的团队,会让成员愿意和团队一起解决问题,共同奋斗,获取成功。
  4. 大而全的产品未必人人喜欢,小而美但解决具体问题的产品会更受欢迎;团队也是一样,人多力量大是错觉,要认识到小而精的团队的威力。
  5. 不要违反人性,产品如此,团队也是如此。
  6. 产品操作要简单,步骤要简洁,不要让用户思考,不要设置障碍;团队管理要遵循尽可能简洁的工作流程,不要束缚团队成员的动力。
  7. 做正确的产品,比正确地做产品更重要;公司建立起各种规章制度,目的是让人正确地做事,而员工通常更需要知道的是,他们最需要完成的工作是什么,即什么是正确的事情。用正确的人,做正确的事,然后才是正确地做事。
  8. 尊重用户,不要试图控制和欺骗;遵循成年人法则,像对待成年人那样对待员工,尊重、坦诚、透明,而且他们很喜欢这样。
  9. 商业环境瞬息万变,产品需要小步冲刺,快速迭代;经营团队,不要再制定什么年度计划,而是更多的时间来做季度计划。
  10. 伟大的产品自己会说话;伟大的团队员工能讲(真)话。
  11. 站在用户的角度设计产品,以同理心去共情;要培养基层员工的高层视角,员工需要以高层管理者的视角看事物,感受到自己与所有层级,所有部门,必须解决的问题建立真正的联系,公司才能发现每个环节上的问题,员工才是真正的合伙人。
  12. 不要质疑用户的问题,每一个反馈,每一个无法满足的诉求,都可能是产品改进的点。领导者不要把员工的提问当成挑战,永远不要低估问题与想法的价值,回答不上来的问题,是最好的改进机会,而不是尴尬的事情,把每一次问答,当作学习的机会。
  13. 把员工当客户,重视员工的体验和感受;不要想当然的主观臆断用户如何使用产品;员工对业务的无知,是领导者的失职,用简单直白的方式对业务进行解释并非一件易事,公司和全体员工分享的信息通常不是太多,而是少得可怜。
  14. 简单,勇气,沟通,透明,反馈,对产品和员工都适用。
  15. 如果你想知道用户怎么想,去现场调研;如果你想知道员工在想什么,没有比直接询问他们更好的办法了。

本文内容节选自《敏捷无敌之DevOps时代》,作者:王立杰、许舟平、姚冬(清华大学出版社)。

分享:

    相关文档

    相关产品