团队复盘,让团队更强

复盘是围棋中的术语,是指棋手在下完一盘棋后在棋盘上重新摆一遍,看哪里下得好,哪里下得不好。下得好的要继承,下得不好的要在重新摆的过程中探究怎样落子更好,由此增长棋力。

柳传志先生第一个将复盘概念引入做事中,是指在头脑中将做过的事情过一遍,看哪做得对哪做得不对,做对了的地方是因为自己的能力还是偶然碰巧,做错了的地方如何才能改正,等等。团队也可以复盘,在项目结束之后、项目的关键节点、出现了重大疑问的时候进行。

 失败的团队复盘

团队复盘是一个有很多人参与并期望得出“真知”的会议,它是讨论会而不是宣讲会。宣讲会由宣讲人对主题进行传达即可,但讨论会需要大家各自发挥自己的聪明才智,然后才有可能得出大家认可并接近事情真相的认识。讨论会要开得富有成效,在全世界都不是很容易的事情,需要很多开会的技巧。稍有不慎,讨论会要么因为无人愿意发言变成主持人的自弹自唱,要么变成争论会,两者都可能造成团队复盘的一无所得。

 

我曾经参与过一个咨询公司对一次投标失败的团队复盘会,当项目经理讲完会议的目的并叙述完从接到邀标信息到投标结果公布的过程后,他要求参加会议的人自由发表自己的看法,谈谈自己对投标失败的认识。他的目光从左看到右,然后又从右看到左,来回了大概两三次。没有人与他的目光对接,有的人将头埋下若有所思,有的人目光呆滞,有的人用手里的笔涂涂画画让人感觉他好像正在记录自己的心得,有的人趴在桌子上什么都不做,但是就是没有人主动发言。空气中充满着静默,人人心头都慢慢升腾起一种奇怪的感觉,似乎时间在那一刻停滞了。过了大约1分钟,经理没有办法,硬性地规定按照从左到右的顺序发言,轮到的下一位,经理就直接点名。每个人都说着自己的话,没有人对其他人的话提出质疑,也没有回应,都把发言当成击鼓传花游戏中那朵讨厌的花,轮到自己了,就赶紧说两句,然后将发言的机会传递给下一位,自己就解脱了。
不仅仅是层次低一点的会议上大家不愿意发言,在高层领导的会议上,主动发言也不是一件顺畅的事情。这在中外皆然。惠普前女CEO卡莉·菲奥莉娜曾经提到过,自己在参加一次高层会议的时候,很多人也不愿意发言。在会议中,大家都想看别人说什么,然后自己好调整思路,掌握主动。卡莉总结说,表现不佳的官僚结构最后总会表现得一团和气。
如果说不发言是一个极端的话,那么,它的对立面闹哄哄的争论就是另外一个极端。它在讨论会上也常见,这主要出现在责任认定的时候,每个人都会尽可能地发言,而且是抢着说,甚至还会不顾礼貌地打断他人说话,目的一般是为了证明事件的责任不在自己和自己的团队身上。

 需要复盘文化

一次失败的团队复盘,很大可能不是因为这次复盘本身的因素,而是缘于企业的复盘文化的问题。要想将团队复盘变成一次“胜利的大会、团结的大会”,企业就必须形成正面的复盘文化。团队复盘,不能流于形式走过场,不能是秋后算账的大会,不能是强调客观推卸责任的大会,不能是寻找替罪羊批斗的大会,而应该是探寻真相求知求真的大会,是观点和思路交锋的大会,是验证逻辑的大会。这样,参与团队复盘的人才不会忙于互相指责、推卸责任,也才能够将关注点集中在事情上,而不是将注意力放在其他人身上,更不是将精力和思想放在如何摘清自己、为自己寻找安全着陆点上。要在企业中形成共识和规定,任何一次复盘,参与复盘的每个人都是安全的,复盘是为了得出规律性的认识,为了以后更好地开展工作。

一个好的复盘文化,能够有效减少山头的影响。山头几乎是企业中的必然现象,科层组织结构的划分,就天然地让不同的人具有了不同的山头。这还只是显性的和不紧密的山头。而为了保护自己的利益,人们之间也可能会结成相互支持的同盟,于是形成隐性的和紧密的山头。
不管是显性的和不紧密的山头,还是隐性的和紧密的山头,在不好的复盘文化激发下,都可能表现出为自己的“山头”辩护的倾向。
2005年,笔者曾经在一个公司的中层会议上看到这种隐性山头的人相互之间的掩护。那是一家不大的咨询公司,大约只有50人,但是,它的组织结构却是矩阵式的,有业务流程的划分,如知识研究部、品牌推广部、销售部和项目实施部。同时,公司还根据咨询领域的不同划分了不同的事业部,比如企业文化事业部、人力资源事业部、战略咨询事业部、集团管控事业部等。此外,还根据行业的不同划分了不同的部门,比如电力事业部、烟草事业部、电信事业部等。这样,整个组织结构就显得复杂和多变,当然,从节约成本的角度来看,这种组织结构确实是有所帮助的,因为不同的人,一会儿可以是人力资源事业部的人,一会儿又可以是烟草事业部的人,这避免了招聘多个人支付多个人工资的现象。
公司中层有8个人,其中的两个人,我们姑且称为A和B吧,是业务流程上下游部门的主管,A负责知识研究,B负责知识研究之后的方案推广。知识研究被公司视为是核心竞争力所在,它发现市场机会,提出咨询模型,同时也制造一些概念,供方案推广部门有话可说。方案推广部门则通过一系列的营销手段,把公司的咨询能力和咨询业务告知社会,扩大公司的影响,塑造公司的品牌。这两个部门虽然都是花钱的部门,但是它们的重要性不言而喻,没有它们,公司无法实现咨询领域和咨询工具的创新,也无法找到新的业务源。正因为如此,老板对这两个部门的工作非常关注,选派的负责人也是自己一手带出来的得力干将。
在会议上,老板问B,为什么公司4月份要推广的咨询业务的相关概念没有在平面媒体和网络上出现,也没有媒体就这个概念来采访自己,媒体上铺天盖地的却是竞争对手对这个概念的解读。公司本来是这个概念的首倡者,现在不但无人知道这一事实,甚至在他人的眼中竟然变成了跟风者和二道贩子。
在老板的逼视下,B不禁有点头皮发麻,眼神也开始闪躲。正在大家等着B说话的时候,A说话了:“嗨,这个事情也怪我。当时公司独创性地提出这个概念后,我认为为推广形成的资料还不够完备,所以就让推广部门暂时晚几天跟媒体联络,准备做一个完善的版本。不想在我们修改的过程中,竞争对手已经先一步推广了,我就想形成一个更新的比他们更好的版本出来,这样媒体才会更有兴趣,也才可能扩大我们的影响。谁知道这次对手是一个有预谋的整体长期方案,它们也在一步步地变,于是我们只能一步步地追,变成时间上一步步拖,所以现在月底了也没有进行推广。”    趁着大家关注A说话的时候,B也整理了下自己的思路。“本来我们提出这个概念的时候,媒体还是很有兴趣的,也有一些媒体联系过想采访老板您。但是在联系的过程中,竞争对手开了一个发布会,行业媒体的记者被邀请去了,因此登载的都是它们的信息。我们中途也将修改后不完备的方案给过媒体记者,他们说没有新意,不好报道。在网络上,我们也发了一些文章,包括您的专栏和相关的论坛等,但因为不是最新的观点,因此也没有产生多大的浪花。”
随着A和B两个人的发言,其他的中层人员也纷纷开始说话。期间A又说:“从这个事件来看,好像竞争对手的推广策略已经改变了,更加系统化了,这个趋势是不是应该引起我们的关注?”
老板说:“A说得非常对,B你要注意多关注下他们的动向,再不能出现类似这次的事情。”
一次关于推广事件的回顾,最后既不是A的责任也不是B的责任,而是变成了竞争对手的责任(因为竞争对手的方式方法变了事情才没完成)。A分担了B的责任,分散了老板对B的火力,而B则为A的做法提供了注解(“他们说没有新意,不好报道”“不是最新的观点,因此也没有产生多大的浪花”),说明了A的想法和做法的正当性,也就间接消除了A的责任。
但真相是什么呢?真相是,A早已将相关的资料提供给了B,只是B当时忙于办理出国的各种手续,把这件事情给忘记了。在后来的多次会议中,我还观察到A、B之间的掩护和佐证,以及他们一起攻击其他的人。A和B之所以结成隐性的山头,除了个人偏好比较一致外,更多的是外力作用,因为他们掌管的都是花钱的部门,不产生直接的收益,因而时常被“带回猎物”的事业部指责,为了自保和对抗,自然而然形成了相互帮衬的山头。
好的复盘文化,将使得大家不是针对他人,而是针对事情。这样,“他人即地狱”的情况不会出现,相互之间的指责和防备之心就失去了存在的基础,如此才能更好地进行复盘,真正发挥复盘的作用,重新把做过的事情过一遍,从而发现问题,挖掘原因,找到规律。
复盘的操作流程
好的团队复盘,还有赖于参与人员之间不同的角色扮演。因为人多,且在复盘的事情中所处的位置也不同,因此,就需要对参与复盘的人进行分工,不同的人承担不同的角色,不同的角色承担不同的职责,不同的职责完成不同的任务。
一般来说,团队复盘中存在三种角色:引导人、设问人、叙述人。引导人主要是为了保证复盘的顺利进行,避免讨论偏离团队复盘设定的方向;设问人则通过自己的提问,引导大家的思考;叙述人则叙述所需复盘事件的情况,同时回答设问人提出的问题。设问人和叙述人,并不是完全固定的,有时候可以相互转化。
团队复盘还必须遵循一定的流程和步骤,这样才能一步步将复盘引向深入,而不会变成漫谈的茶话会。从大的流程来看,联想集团将复盘划分为4个步骤:回顾目标、评估结果、分析原因、总结规律。在本书中,划分得更为细致一些,分为8个步骤:① 回顾目标;② 结果比对;③ 叙述过程;④ 自我剖析;⑤ 众人设问;⑥ 总结规律;⑦ 案例佐证;⑧ 复盘归档。不过,这8个步骤的逻辑框架跟联想集团的划分方法一致,只是更加细化,也更加可具操作性一些。
在一个好的团队复盘文化的笼罩下,遵循一定的复盘流程,每个人都承担好合适的角色,一个成功的团队复盘是可以期待的。

出处:http://www.xzbu.com/3/view-4514448.htm

TDD,BDD and ATDD

  • TDD:测试驱动开发(Test-Driven Development)

测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD的基本思路就是通过测试来推动整个开发的进行,但测试驱动开发并不只是单纯的测试工作,而是把需求分析,设计,质量控制量化的过程。TDD首先考虑使用需求(对象、功能、过程、接口等),主要是编写测试用例框架对功能的过程和接口进行设计,而测试框架可以持续进行验证。

  • BDD:行为驱动开发(Behavior Driven Development)

行为驱动开发是一种敏捷软件开发的技术,它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。主要是从用户的需求出发,强调系统行为。BDD最初是由Dan North在2003年命名,它包括验收测试和客户测试驱动等的极限编程的实践,作为对测试驱动开发的回应。

  • ATDD:验收测试驱动开发(Acceptance Test Driven Development)

TDD 只是开发人员的职责,通过单元测试用例来驱动功能代码的实现。在准备实施一个功能或特性之前,首先团队需要定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划(包含一系列测试场景)来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员,强调如何实现系统以及如何检验。

20140325091542500

[图书]腾讯方法

这是国内第一本深度讲述腾讯产品研发与团队转型的书。

介绍了腾讯三个不同生命周期的产品的开发过程,包括如何踏足新领域开发新产品;如何救活一个即将半路夭折的产品;如何让一个老产品持续盈利。本书呈现了互联网产品开发时会遇到普遍问题和解决方法,涉及大企业如何内部创业,并迅速组建新的项目团队;如何实现跨部门的合作;在面临新团队和紧急开发任务时如何提高团队沟通效率;在产品研发方面,如何定位产品、如何敏捷开发、如何测试和迭代等。

三个案例皆为第一手材料,具有非常强的可读性和参考价值。

GitLab分支使用策略

  1. 创建一个主仓库dev,保持和线上同步,随时可被部署线上和fork一份最新代码;
  2. 每个成员fork一份dev分支代码;
  3. 在自己fork出来的代码里做开发工作;
  4. 开发完成后发出一个合并请求 pull request,等待被其他有合并权限的同事合并代码,合并代码需要进行code review,而不是简单的合并,并且要处理合并冲突的;
  5. 如果主仓库dev有新更新,需要先fetch,合并到自己的仓库里,若有冲突,那么处理先冲突。

[转]为什么每个团队都需要 Code Review?

不少开发团队和创业公司都在纠结是否要执行 code review,既希望改进代码质量,又担心带来的负担会拖慢项目进度。实时上,在软件开发中质量和效率往往并不是二选其一的关系。能产出高质量代码的团队通常效率也非常高。
在我作为工程师的职业经历中,自动化测试和 code review 可说是能同时提高代码质量和开发效率的两个最有效的手段。所谓 code review,和学术界的 peer review 类似。Peer review 是由同事或同行对一位作者的作品进行查阅并提出建议和问题,只有当所有提出的问题都得到满意的答案后,作品才能发表。对于 code review 来说,作品就是代码,发表就是把代码 commit 到官方代码库。
在 Code Complete 这本书中讲述了两个很有说服力的案例。在一项对同一个团队开发的很多个程序进行对比的研究中,没有经过 review 的程序平均每 100 行有 4.5 个错误,而经过 review 的程序平均每 100 行只有 0.82 个错误,也就是说 80% 的错误在 review 中被修正了。AT & T 的一个 200 多人的部门在开始执行 code review 后,开发效率提高了 14%,而错误减少了 90% 左右。
除了减少缺陷,避免在诊断错误上浪费时间,review 的过程还可以通过相互的督促保证代码有好的可读性、文档、风格,并同时检查测试覆盖率等开发过程中的规范,从而提高团队的协作效率。对于所有复杂的事情来说,总是越早发现问题,解决问题的成本越低。
对于经验不足或者刚开始一份新工作的人来说,通过 code review 可以得到更资深的人帮助,更快熟悉现有的规范和架构,在新的环境和团队中快速提升。
对于资深的工程师来说,让其他同事 review 代码,有利于在团队中传播经验、知识和好的实践。身边的同事水平提高会让自己的工作也更高效。并且谁都有需要休假的时候,无论是公司还是个人都不希望有太多工作因此而停滞,如果有平时就熟悉自己工作的同事,这个问题就很好解决。
像很多其他事情一样,code review 最难的就是迈出第一步。一旦开始,花在 review 过程的每一分钟都会很快被成倍地赚回来。如果你不在一个可以一下改变团队流程的位置上,那么至少可以和认同这件事的少数同事先开始实践,当价值开始体现的时候,相信其他人会乐于效仿。