思考控 - Tony Bai

四月 17, 2012

气氛太平静，投石起波澜。

昨天下午无意中在内部发起了一场关于"何时发布版本"的论战。

论战的背景是这样的：部门内部有这样的一个项目A，它的目标是开发出可被其他项目或产品复用的组件(这里就暂称之为组件吧，我们内部称这类组件为可复用资产)。这个项目已经开发了大半年了，目前处于收尾阶段，绝大部分开发工作已经完成。测试(包括压力测试等)已经测试过至少一轮了；我们的产品线近期准备复用项目A成产出的这些组件，我们希望得到这些组件的某个发布版本。

论战的导火索是我就这件事情回复的一封mail。mail的大致意思是希望项目A能采用可复用资产的方式对组件进行发布管理，尽早在内部公开发布组件版本，以利于其他计划或正在复用这些组件的项目能够尽早的集成，发现问题，反馈意见和建议。

项目A负责人就我的建议回复的mail拉开了这场论战的大幕，其mail的大致内容是："在项目A结项前，相关成果物暂不发布，不通过组织内部可复用资产的方式进行管理"。在接下来的mail中他阐述了几点理由：

(1) 项目A开发工作尚未完全结束，代码每天依旧在修改，手册、测试均未完成；

(2) 项目组人员有限，发布牵扯到开发人员的工作量，无法集中精力于开发工作；

(3) 欲复用这些组件的开发组可以从项目A的配置人员那里获取代码，配置人员发布的版本都是经过基本功能测试的，而且API接口部分已经基本稳定，可以进行研发。等项目完全结束后会加入到部门可复用资产库中的。

如果是按照传统项目的管理方式，以上理由可能无可厚非，但恰恰项目A所生产的组件并非传统项目的成果物类型，所以我针对上面的理由做了进一步的回复，大致意思如下：

(1) 就因为组件开发尚未完全结束，才应该制定阶段发布计划，不能等到最后再发布，否则一旦存在与其他项目的集成问题，修改起来就更加费力，而且还可能导致各个项目延期；另外提早内部公开发布阶段性版本才可以"扩大"组件的使用和测试范围，去"Eating your own dog food"，有利于尽早更多地发现问题；

(2) 产品发布就是开发过程的一部分，不要割裂开来；

(3) 显然项目A是有自己的版本管理的，但没有在显式的位置公开发布版本信息，这些版本对外均不可知；而且在没有外部监督的前提下，内部版本管理可能较为随意，可能后续不便于外部项目对组件问题的跟踪与管理。

(4) 由于组件的需求和设计阶段已经结束，我的建议主要针对组件实现以及之后的生命周期。

显然项目组A负责人认为项目过程中的评审比尽早发布版本后收到的反馈更为重要，于是他发出了下面Mail：“需求阶段和设计阶段的评审更重要，实现阶段和测试阶段会举行例如手册、测试方案的评审，代码评审叫你们，你们有时间参加不？”。

有些火药味儿了^_^。我的回答是："我真不知道什么样的好产品是内部坐着评审出来的，哪个好产品不是在使用后反复修改出来的。如果评审能缔造好产品，那大家就都评审好了！ "。

随后我又举了一个形象的例子，拿一个场景说明提前内部公开发布的必要性。

以微软为例，两个部门：Windows开发部门(以下简称Win)和visual studio开发部门(以下简称VS)。Wins部门正在开发WIN8，与此同时VS部门正在开发visual studio 11。下面有两种场景：

第一种：WIN部门在需求、设计阶段召开了大量会议，也采纳了VS部门的建议，但就是后期迟迟不发布版本。而VS部门急着要与最新的WIN8版本集成，看是否会有集成问题。WIN部门的回复是：等吧，2012年10月WIN8发布时，你们就可以测试了。VS部门也要在10月份发布VS11，无奈VS部门只能暗中找到WIN部门的人偷偷搞到一个WIN8的beta版(例如，build 2012)，然后赶紧做集成。结果发现了大量不兼容问题。VS部门感叹：多亏提前做了，否则10月份又要被Steve Ballmer甩椅子了。

第二种：WIN部门在需求、设计阶段召开了大量会议，也采纳了VS部门的建议，并且WIN部门在开发阶段就定期发布alpha1~alpha10版本，供其他各个部门的新产品集成，及时收集问题反馈，及时修正问题。10月份时，WIN8和VS11都高质量顺利上线。

大家觉得哪种更好些呢？

我举的例子也有些激进(特别是场景1)，这下彻底激怒了那位兄弟。其回复说："有很多问题，很多bug的版本也可以发布？不稳定的版本发布了有何用？谁会用？"。我的回答是"Windows每个alpha版本发布后仍然可能有数千个bug。但它也要内部发布，注意是内部发布，为的是更早的与其他应用集成，发现问题"。

论战到这里，我觉得我的意思基本上算是表达清楚了，于是终止了这略有火药味儿的讨论。

我们的组织内部很少有这种带有火药味儿的激烈争论，但我个人觉得在对团队团结无损害的前提下，这类争论应该多多益善，这样才能产生思维碰撞，产生火花，促进思考，推动改进。

部门经过十几年的发展，固化下来一些目前来看并不合理的惯例，很多人(甚至也包括我自己)的思路尚停留在老路上。所以我经常用下面两句话来督促自己，让自己始终保持OPEN的心态：

(1)、忠言逆耳利於行；

(2)、向前迈出一步总比原地踏步强。也许迈出这一步后，摆在你面前的是另一番别有洞天的景色。

由劝退一名员工所想到的

这周五我做了一件"恶事" – 劝退了一名员工。这样的事情在部门成立10年的历史中发生的次数都是屈指可数的，但却真实地让我给碰到了。

我以前只是有招人的经验，但从未做过"开人"的事情，这是第一次，心里总有些不忍。原计划由这名同事的直接Leader与他谈这件事情，但这名女leader更是抹不开面子，索性我就直接上阵了。过程还算顺利，这名同事表面上也没有太多意见，但我心里清楚：他肯定很郁闷，这个周末估计会很失落。我们也不想这样的事情发生，但之所以做出这个决定也是因为这名同事"所作所为"实在是太不给力了。

这名同事进入我们产品线大约有一年半时间，他并非是我们招入的，而是由领导从其他项目组安排过来的(恰逢那时我们缺人)。最初安排他做开发侧的技术支持角色，负责产品的升级支持以及生产环境问题的解决，算是隶属开发运维团队。但一段时间后他似乎没有得到运维团队内部的信任，给他派的活儿都是很边缘的，生产环境遇到大的问题基本都绕过他而直接找到原开发人员解决，形成这一局面的原因无非有二：一是他无法独立地及时解决生产环境中的问题；二是在自己无法解决的情况下，也没能很好地协调他人将问题解决。长此以往大家索性就不找他了。团队内部不能养闲人，我们还是给了他机会 – 尝试让他做些开发团队的工作，把他直接安排到上面提到的那位女Leader的项目组里面。经过了大半年，他给出的成绩单却是：失去了所有团队对他的信任，大家把他彻底孤立了起来。团队并非一开始就失去对他的信任，而是不断给他机会，给他的工作都是相对比较简单的，时间上也相对宽松。但即使这样，他也是不断延误进度，提交上来的东西也是频频出错，耽误了自己不说，还耽误了其他团队的整体进度，大家逐渐开始对他都不耐烦了，我这里也不断收到大家对他的抱怨，局面就是这样形成的。年中面谈时，还曾明确给他指出了不足，并就改进绩效计划达成一致，但他依旧没有达到我们的预期。木桶理论告诉我们：在一个团队里，决定这个团队战斗力强弱的不是那个能力最强、表现最好的人，而恰恰是那个能力最弱、表现最差的落后者。于是我们从全局考虑，从团队的整体考虑，我们做出了上面那个无奈的决定。

我做了一下换位思考，如果我是这名同事，到底是什么原因让我走到了这步田地呢？下面我就来帮他分析分析。

首先，我想这位同事没有走好融入团队的第一步棋 – 赢取团队的初始信任

对于一个刚刚进入团队的新人（无论是有工作经验的还是刚毕业的新人），赢取团队的初始信任都是最最重要的。下好这第一步棋其实并不难，把你的直接上司分配给你的第一个任务做好即可。当然如果要赢得超出预期的信任，那就得做的完美一些。在这个阶段，你最好能专心投入，甚至“牺牲”一些个人时间（对于程序员来说，这很容易理解^_^），快速地熟悉新环境、行业领域业务知识、产品以及团队风格。一旦你的第一个任务达到或超过了大家的预期，团队对你的信任也就建立了起来，后面的事情就变得自然而然了；而一旦你搞砸了第一个任务，那就相当于从团队成员那本来就积蓄不多的情感账户中取款，那后续走势如何就要看这个团队的耐心了，他们到底会给你多少次犯错的机会呢！

其次，能力不足且没有努力做出改进

赢得信任需要有资本，这最起码资本就是个人从事这个行业工作的能力。绝大多数行业中处于能力平均水平的人维持一份稳定的工作都不难。但问题就在于如果这个人没能认识到自己能力的不足，或是即使认识到能力不足，但也不努力改进，那这个人就危险了。我的这位同事身上显然就发生了这个问题，这一年多以来他的能力或技能只能说是原地踏步，在IT这个行业里，大家都知道这意味着什么。

最后，态度！

俗话说："世上无难事，只怕有心人"。这句话从侧面反映的是一种做事的态度，而我的这位同事被诟病最多的就是做事的态度上。我从多方面反馈了解到，他似乎就没有把分配给他的任务当成自己的事来做，总是囫囵吞枣，不断犯错，不断被指出，之后依旧不断重复犯错，似乎一点改进的意识都没有。如果把工作视为可敷衍了事的事情，那后果可想而知。

也许还有一种更为深层次的原因，我也不敢肯定，那就是他也许根本对程序员这个行当不感兴趣。缺少动力，行将就木，做一天和尚撞一天钟，因此有了糟糕的表现。如果真是这样的话，那就是严重地对自己不负责任了！说得严重些叫浪费生命，也许他换个行当就能出类拔萃呢。

在组织层面如何为避免此类事情发生呢？也许只能严把入口。但说起来容易做起来难，仅仅通过几次面试，很难全面地去认识一个人。刘未鹏不是写过一篇文章叫"怎样花两年时间去面试一个人"吗，显然也印证了这一点。

最后还是要对这位同事说一声：你还年轻，这仅仅是一时的挫折，绝不应该就此消沉，反思一下，找到一条更适合自己的路，好好的走下去。