IT外企那点儿事(19): 又爱又恨是流程

当你工作过多家公司之后，你会发现流程是一个让你又爱又恨的东西。如果你在大公司待足够长的时间，你多半会讨厌那些纷繁复杂的流程，而如果你在小公司待了一段时间，你可能又会怀念大公司的流程。如果你是一个普通的程序员，你也许会恨这些影响你痛快淋漓写代码的流程，而如果你成为一个管理者，你又会觉得没有流程是多么的头疼。

可能很多人选择去外企，是冲着完善的流程来的。毕竟这是这些大公司多年积累下来的经营管理理念，只有这样才算是见了世面。如果是这样的话，那么请你在入职之前先准备一样东西，什么呢？就是笔记本。因为从入职开始，你会接触到很多的流程，需要记录很多的网址，用户名和密码，不同的流程系统密码要求可能还不一样，说不定就会记混，还是记下来的好。HR有HR的系统，什么工资查询系统，绩效评价系统，股份申购系统等等，Admin有Admin的系统，什么请假系统，预定会议室系统，门卡申请系统等等，IT有IT的系统，什么安装工作机，申请笔记本电脑，申请VPN，申请邮箱，申请正版软件等等。终于熬过的入职关，进入了项目组，还有一大堆账号等着你，什么文档服务器，wiki, ftp, svn, Hudson, jira等等，还有一大堆规范，什么文档格式，什么代码风格，什么单元测试覆盖率，什么开发流程，测试流程，发布流程。眼看着在小公司三个月能够做完的事情，要用个一年半载的。

什么？你不相信？那我就来描述一下这个过程。外企的项目的发起人一般也会是老外，老外有了想法，还不能称为需求，中国这么的项目组基本就要成立了。

• 首先要做的是比较同类产品，市场上当前都有哪些产品是做这个的(包括开源的和商业的)，他们的功能，性能，易用性，架构如何，有何优缺点呢？那好，你研究一个，我研究一个，他研究一个，大家互相share，做tech talk，出各类的报告(一定要符合某个格式哦)，最后要形成一个比较研究报告，发给美国那面，那可不得了，在发给美国之前，中国这面从高层到写报告的人个个重视，一通review，终于觉得无懈可击，于是发给美国老大，老大就是老大，当然不会一次通过，于是打回来改，改了再发，直至老外满意。

• 根据前面的比较研究，美国那面就可以形成一个集各个系统优点于一身的架构，于是中国这面各个模块也会形成自己模块的架构，虽然这个架构还是非常的模糊和初级，甚至和最后的架构相去甚远，但是文档一点不能马虎，又是各种review，最后形成总的架构的一篇文档。

• 然后呢，还不到正式开发，而是进入原型开发，叫做prototyping，来验证这个架构是否合理，原型开放一般要求时间比较的紧，所以各个模块的开发也多选择捷径的方式，导致原型开放阶段的成果，在正式开发的时候要全部舍弃，最终各个模块联调成功，架构能够运行起来，于是各种demo, tech talk, review。

• 下一步呢？该选型了。各个模块要真正开发，具体使用什么技术呢？用xml还是json? 选用哪个第三方库？网络传输使用什么？用哪种数据库？这些都要比较，又是大家分工研究，互相交流，各种比较，各种测试，形成各种文档。

• 直到这个时候，各种正式的文档才开始成型，什么功能规格说明书(Functional Specification)，什么设计文档，各个模块的详细设计文档，测试计划文档，详细测试文档等等，又是各种讨论，各种review，各种会议，最终基本定稿。

• 看到这个地方，很多读者会说，你们这是明显的瀑布模型，现在可都流行迭代开发啊。可是在做这个项目的时候，我们也是号称迭代的，只不过在这个周期中写文档，下个周期做原型，每个周期肯定有output，但是总觉得不是味儿。对于迭代开发，也许是本人经历有限(多经历的都是scrum)，我所看到的是，对于没有真正上线或者没有卖出去的产品，scrum往往弄的有模有样的，可是一旦面临成熟产品，面临客户，scrum往往就有些走型了。不写文档？那客户的需求如何准确把握，最后你又给客户看什么？固定开发周期？如果这些新的功能不能通过功能和系统测试，只要主要bug没改完，这个周期就不能结束，否则这样的产品客户能接受？砍掉功能？都已经给客户承诺了下个版本有这个功能的，你总不能给一个做财务的公司普及scrum的理念吧？开发中间不能有新的任务加进来，不能打断？客户报了一个很严重的bug，必须有一些人停下开发计划来fix。等等等等。

• 对于这个项目来讲，终于盼到开发了，那就一个周期一个周期的来吧。代码是需要测试用例的，这个自然不必说，可是却有相应的工具来评价测试用例的代码覆盖度，并每天发出一个报告来，谁的最低谁不好看，所以那怕一个Getter和Setter，都要调用一下。而且code review是必须的，鸡蛋里挑骨头，代码风格或者设计方面总有各种各样的问题，这些都会记录在案，还要改，对于有些复杂的算法逻辑，改完后有时候功能都变了，直接导致最后测试挂了。测试用例也需要review的，所以仅仅是代码覆盖率，还有各种复杂场景，所以一个说法是测试代码大概是被测试代码的三到五倍，这真的一点都不夸张。

• 最后一个周期结束，产品能不能做一个阶段的发布，当然是QA说了算。QA已经搭建了标准的测试环境(每次都是最新的，保证每次测试环境一致)，写了大量的测试用例。如果发现有bug，那自然是报告出来要改。可是有的bug不是一时半会儿能改完的，到底是推迟这个周期呢？还是放到下一个周期呢？QA会说：当时这个周期开始的时候，你们开发组说要实现这些功能，我们都写了相应的测试用例，现在通不过，当然不能发布。所以要一段code freeze的时间，还要有bug fixing的时间，有的时候这两段时间加起来都够一个周期的长度了。没办法，如果要把这个功能放到下一个周期，根据事先开好的会，发好的邮件，QA肯定是不答应的，这就需要开发组上报一级，由更高级别的人来协调才可以。直到通过了QA的所有测试，阶段发布方才完成。

这个过程有时候令人精疲力尽，每天弄的很忙很忙，但是东西出来的又不多，真正的技术进步就更少了。流程似乎成了程序员职业发展的阻碍，天天文山会海，如何集中精力学习技术呢。后来去一家小公司面试，人家问起你这两年做了什么，他们很惊讶于为什么这么多人两年下来就做了这么个产品，问你们大公司是不是都很空闲啊，不像我们创业企业这样子每天干的热火朝天，加班加点。我回想起来，我也是在天天忙啊。这个困惑我一直不明就里，直到有一天来到一个新创立不久的创业公司。

对于人数不多的创业公司来说，流程就要简单的多：

• 产品人员有了想法，先把各个模块的负责人叫来商量能不能做，能做到什么程度，大家面对面交流，很快大家就能够得到一致的结论。于是产品人员将需求写到wiki上，当然开发过程中遇到当时讨论的时候没有想到的产品细节，拉过人来直接问。

• 为了产品能够尽快上线，业内什么主流用什么，有开源的，现成的，能够包装修改一下使用的最好了，方案达成共识后也是放到wiki上，互相之间的接口也放到wiki

• 每个模块或自己开发，或封装开源，功能很快就能使用，测试仅仅覆盖最重要的功能。

• 不同的模块联调，有问题直接喊，“你发送过来的数据格式不对，咋回事啊？”。很快各个模块就集成在一起了。

• 最后产品上线测试，也是开发人员打包放在服务器上，最后集成成一个系统，产品那面用一下最主要的功能，发现没问题就ok了。如果有问题，各个模块的负责人一起查，从源头开始喊，“我发给你的数据没有问题啊”，“你发给我的数据中没有这个，肯定是你那里的问题”。最后所有的bug解决，staging和production系统切换，正式上线。

整个过程如行云流水，各个模块密切配合，主要的精力全部放在主要的功能开发上，而且难以想象的这么快，在最后上线的系统上，就看到了自己想要的功能，真是非常有成就感。

然而随着产品越来越复杂，开发团队的人数越来越多，接连出现的一些问题使得你不得不重新拾起流程。

• 产品想法多变：不能不说，有时候产品和技术是生活在不同的世界里面的。技术人员的世界简单，线性，一切按部就班，事先获得所有的信息，然后集中精力做自己的完美架构，然后一步一步的实现，最后水到渠成。而产品人员的世界复杂，多维，大千世界各种涌现出来的产品设计都能够引起他们的兴趣，遇到什么都想试一把，然后体会产品体验。于是产品今天觉得这个UI好看，明天觉得另外一个更人性化；有时候觉得数据应该全面(准确率要低一些)，有时候觉得准确性更重要(召回率低一些)；时而强调性能高，时而强调功能全。真是恨不得多快好省的把所有的好处都占全了，有时候指着一个大公司做了十年的系统问咱们能不能也做成这个样子，我真想说：大哥，能是能，人家多少钱招的程序员，咱们多少钱招的程序员，人家多少人在开发，咱们才几条破枪，人家开发了多少年，咱们成立才几天？咱是不是得需要时间。既然前面有开发遇到产品的问题拿过来问，那么也就出现了产品如果想有什么改变，就会直接跑到负责那一块的程序员那里，说能不能改成什么样。而且如果产品人员比较多，当多个需求到来的时候，先做谁的，后做谁的？所以产品需要比较详细的，考虑周全的需求说明书，开发团队应该有一个统一的接口来接需求，产品需求需要产品团队(需求提出者或者产品总负责)，开发团队(模块负责人或者团队总负责)坐在一起，统一对各个需求敲定，在一个开发周期内不能改变，如果有进一步的需求，请提交到下个周期的需求里面，而且要对需求之间的优先级达成共识。这样开发人员就不会像无头苍蝇一样，东一榔头西一棒子的，造成重复开发和不必要的开发，做大量的无用功了。

• 高层直接插手：小公司开发，产品，市场，运维等等都在一起办公，大家彼此熟知，所以有时候会出现其他部门的高层直接跑到一个普通的开发人员这里提一个要求，比如产品总监到做数据库的人员这里来说，咱们最后处理的数据都放在数据库里，能不能有个界面，让我们看起来方便一点？再如市场总监跑到抓取的人员这里来说，我们要做一个市场分析，需要一些数据，能不能把你们解析好的数据导出一份来给我们。这个时候，普通的开发人员自然不好意思反对，然而这却无形当中增加了开发人员的工作量，从而影响进度，而且是项目管理人员所不知道的。所以开发人员做任何工作，必须让上级知道，否则应视为无用功。当其他部门人员有特殊的需求的时候，应找开发负责人去说，“我们需要一个界面，看能不能安排个人给我们做一下”，这样如果有比较空的人员，则可以安排。这个流程一旦确立，当遇到直接插手的情况，开发人员也容易拒绝，“您看要不要找XXX说一下，他让我现在做这个，还要得挺紧的”。

• 模块多了bug难以定位：如果模块比较少的情况下，出了问题，大家是能够一层一层查下去，很容易定位bug，然而模块多了，不能出了一个bug就把大家都弄进来吧。所以Code review, 测试用例，如何打印日志，如何捕获异常，形成标准就变得很重要。测试用例可以避免掉很多联调之前的bug，也可以作为证据，这个我测过，我这里没有问题。日志也有一个统一的格式，是哪个类，哪个线程，哪个session，哪个请求的；入口，出口都应该有日志，重要的步骤也应该有日志；异常不要重复打，也不能够吞掉。这样出现了bug，通过查看日志，很快的就能够定位哪个模块，或者哪几个模块。

• 架构复杂，每个模块影响加大，选型更加重要：随着架构变得复杂，很多模块可能被多个模块进行调用，从而这个模块的稳定性，性能就影响较大，很可能产生蝴蝶效应。所以选型就不是一个模块的事情了，需要相关模块一起讨论，输入输出是否兼容，性能是否达到标准，是否能够适应其他模块未来的扩展需要等等。

• 重构和性能改进没有基准：当软件或者系统开发到一定的程度，一定面临者重构和性能改进的问题，这两方面都会带来代码的巨大改动。然而如何保证改动前的代码和改动后的代码除了架构和性能得到了提升外，功能并没有改变呢？是不是有这样的现象，原来出现过一个bug，后来改好了，然后就被人遗忘了，在重构的过程中，由于引起bug的场景比较不常见，所以也没有注意，在新的代码中没有进行处理，结果又出现了。这其实还是幸运的，是自己的测试人员又发现了这个bug，那还有没有在重构或者性能改进的过程中遗漏的bug呢，难道这些不可掌控的东西最后交由用户去发现么？所以一定量的测试用例，功能测试，系统测试的集合就相当重要了，当一个bug出现的时候，要新加一个测试用例来测这个bug。是这些测试集合来保证，当进行了较大的代码修改后，对于用户来讲，功能是稳定的。

• 团队扩大难以亲密合作：当队伍比较小的时候，大家是能够比较亲密合作的，有事没事的大家能够坐在一起，打开天窗说亮话，在工作上，也是一门心思向前冲，目的就是把产品做好，每个人都很投入，很努力。但是人慢慢的多起来，情况就变了，大家不能经常的交流了，开始有小团体了，成果和责任不是太好鉴定了，人开始有私心了。有了事情谁来做，出了事情谁负责？新人来了怎么办，都把系统的故事从头说？有人离职了怎么办，他的那一摊谁来接？所以要有文档至少是wiki，为了查阅方便，要符合一定的格式。新人来了，通过看文档或者wiki，就能够知道系统的大概面貌；有人离职，其负责的模块也在文档或者wiki，容易交接。有了新的任务到来，每个开发人员身上有几个任务，还需要多少时间，一清二楚。除了问题，产品没有定义清楚问责产品，开发没有实现落实到模块，QA没测出问题就放行问责QA，如果责任人没有签字就上线问责运维。

所以，流程看起来反而成了程序员的一种保护，尤其是对于老老实实，不爱争辩，专心技术的程序员的一种保护，没有了这些流程，产品可以欺负你，让你需求总变，高层可以欺负你，让你任务不断，测试可以欺负你，让你bug总现，开发人员中不老实的人欺负你，让你忙的团团转。

那说到这里，有人可能会问，流程到底是好还是不好呢？本人的观点是流程的复杂程度应该与公司的发展阶段相适应。创业的小公司的优点就是小而灵活，成本低，开发速度快，能够快速的推出新的产品来尽早的占领新的市场，因而流程就应该简单，直接，实用，少做形式主义，必然会重视人的能量，相信我们一帮有理想的人在一起能够创建不一样的产品。而大公司则实力雄厚，有钱，甚至店大欺客，所以往往不见兔子不撒鹰，因为等某项产品成熟了，再复制也来得及，从而会弱化人的因素，期望无论是谁来做，都不会影响公司的正常运转，因而流程复杂，容错，大家都做给高层看。如果小公司自不量力，请来大公司的管理者用大公司的思路来管理，则可能天长日久做不出产品，从而资金链断裂。如果在大公司不搞形式主义，如同广阔的沙滩上，如果不是闪亮的贝壳，谁会发现壳中的珍珠呢。