没办法了，用敏捷吧？

前言

好吧，我承认，我有点标题党了，我需要澄清的是，我想来分享的是，其实是我们团队这近八年以来工作的过程中，对于软件工程和项目管理的一些小感触。当然，这其中我们也用过敏捷，包括其它的好多软件工程的模式，真的算是酸甜苦辣全有了。后面虽然慢慢的也摸索出了一些模式，但是，其实直到目前为止，问题也无时无刻不在出，当然，有时候，经验的作用就在于，有些个问题，我们也确实能够提前想到，能提前解决一部分了。

我个人挺喜欢Chris Taylor的这样一句话“敏捷理论很美好，但是实践起来还是会有各种各样的问题，也有可能失败。其实理论描述的是理想情况，实际情况往往不尽相同”。我对于软件工程和项目管理模式，也有类似的感觉，“理论很美好，但结合实际，根据问题和当时的环境，进行选择或裁减，更有效的解决问题，才是真正需要解决的问题”

同时，我想说，这篇博客中的思路，和一本书《快速软件开发》有很多类似的地方，而且，我确实参考了其中的不少东西，因为，我个人的经历，也让我确实挺认可这本书中的东西的。

 

精典的“失败”

其实曾经有人问过我，你喜欢什么项目管理模式，我当时告诉他：”因事而定，但不管怎样，一定要尽力避免一些典型错误“

（注注注：底下有的例子，可能只是一句话，但相信我，没有哪个不是后面花了大量汗水和泪水来解决的）

看看这些年我碰到的典型性的问题吧：

和人有关的

• 对有问题的员工失控
  其实说起这个来，相信不少人都有类似的经历，有的人碰到的是员工能力弱，有的碰到的是员工过于自大，有的碰到的是员工过于忽视质量。。。
  我其实也能举出挺多的来，但是举一个让我记的最清楚的吧：09年前后，我们当时在做VX项目，就是在导航中加入真3D的支持，当时这个，至少在美国，我们是第一家准备推向市场的（推出时，市场挺轰动的），所以公司上下特别重视，我的老大（美国人），专门找了一个Java领域做了近15年的工程师（他原来参与过J2ME框架的开发），来帮我们在美国进行支持。 他做的部分是什么我就不具体说了，但当时因为他经验丰富，所以，我们也极少对他有质疑。
  但当真正开始需要联调的时候，问题就全出来了：首先：系统的工作方式，两边的理解，差了好多；其次， 因为他自己认为自己的能力强，所以，自信导致很多事情，让我们这边先查。。。。 我其实都记不清到底有多少种不同的情况了，反正最后，项目整整Delay了近三个月，出了近两千个bug，我们去美国现场开发的时候，每天晚上1点才从公司出来，整整三个月。。。
  后面，我们其实也没有精力再去做什么大的管理模式的改变了，只加了一条并严格执行：任何人，做的design和提交的代码，必须要经过至少两个人的Review。在这件事上的失控，导致我们在后面相当长的时间里，其实都在还账，当时的系统设计的缺陷，让在后面近两年中，相关的模式都没人敢碰。我当时把这东西总结成：一批好工程师，做出来的烂系统
  
• 缺乏各种角色的齐心协力
  这种类型的例子，举不胜举其实。记的当时刚来新Team时，这边的数据处理组的人和工具维护组的人不合，当时的Project manager真的算是尽心尽力的来通过各种方式来Tracking，来安排工作，在他的努力下，没出大事。但效率之低，还有项目过程之坎坷，真是让当事人苦不堪言的。。。
  所以，在那之后，我给项目管理的一个建议是：很多方法都能达到效果，根据团队的情况，找一条最能让大家齐心协力的吧，不要言什么行或什么不行。
• 挫伤积极性
  提起这个来，其实这是我到目前为止的一个心里的痛点。有一个我们公司的原老级的员工，说实话，如果说在项目上，贡献远大于我的员工，离开了。。。曾经的他，帮团队解决了很多问题，我们NBGM组刚成立时，什么都没有，他从0开始帮着大家建立起了整个的技术体系，连美国的架构师都说这哥们还有他带的团队很牛。
  我离开那个团队之前，其实项目管理模式上，我很诚恳的说，也没什么亮点，但成绩上和项目的周期上，往往都是提前的。但我离开那团队后，同时项目管理的人也换了，同时，项目在Tracking上的要求也增加了好多，每天的Standup meeting啊，周会啊，Schedule的tracking啊，跟的其实挺多的了，但越到后期，项目的周期越紧，最后，Delay了差不多整整半年（当然，这里面，需求变化什么的，好多因素在里面）。
  后来，这哥们在项目完成后，也提出离职了，涨工资，也留下住他。当我们后来分析这个项目时，呈现了这样几个特点：1：项目Delay了. 2：需求不明确，总变化；3. 工程师主动性差；4. 代码质量差；5. 在项目良好的Tracking下，项目还是在最小的损失下完成了。
  我当时参与完讨论后，直接给出了这样的评价：1. 需求不明确，总变化这事，不是今天才有的，一直就这样。2：这批工程师，没有新人，全是在这家公司呆了三年的人，做的项目中，难度大的，比这大多了。3：代码质量以前没差过。
  后来这个讨论算是不了了之了，但是，在这之后的其它项目，呈现出对管理成本要求越来越高的趋势，最后，管理跟不上，导致了好多的问题。
  所以，后来我和一个朋友讨论这个事的时候，给出的建议是：不管你用什么管理模式或软件工程开发模式，先考虑一下，你是服务者，是为真正做事的人服务的，以这个为基础来制定相关的方式。

其实，和人相关的要注意的地方，还有挺多的，比如：不要加入过多不现实的预期，英雄主义也要适度，人员素质低等等吧，但是以上的，对我来说，确实是记忆深刻

产品方面

可能有人会奇怪，为什么在讨论软件工程和项目管理模式的时候，会提到了产品方面呢？其实我的感觉就是，所有这些模式，都是为了产品有效的完成的，如果产品上的问题产生了影响，我们就需要在项目管理的过程中，来解决这些问题。

• 需求镀金
  这个例子真是太多了。。。有时候，一个高大上的需求，可能增加的工作量，是很难估计的。。。同时，不光是工作量，还有产生的质量上的影响，也是很难估计的。。。记得很早以前，当时Android大伙还不太熟悉的时候，我们的Product manger按照WM的方式设计Android 的 UI，有的东西很难实现，当时的工作，真是难去了，根本不是说什么管理模式能解决的。
  前几天，还有一个Project manager找到我，向我告一个TL的状，说这个人只会把工作往下分，自己不做具体的事情，没有价值；我当时只问了一个问题，他们几个人做的项目，出过大差错吗？他说这个到没有，只是觉得这样光拿钱不干活不好。。。我就问他，如果一个项目，一个Task，甚至一个Bug过来，除了他之外，谁能在需求上，正确的理解，将需求-技术-质量这三关打通，做出正确的决定。。。这个Project manager不说话了。。。
  所以，我当时建议几个参与项目管理的人：不管什么模式，一定要让这种模式下需求，技术，质量三件事有机会打通，否则的话，光Tracking并不能解决真正的问题，打通了这三关，就会将需求，正确的体现出来，能做什么，不能做什么，都能最早的拿出来分析了。。。项目的开发和管理模式，一定要提供这样的机会。。。
• 开发人员过多的使用新的东西
  其实说到这，我相信不少人都不容易碰到这种烦恼，因为不少公司，大伙是来“上班”的，才不会轻易使用什么新东西呢，不找这麻烦。。。如果有这样的人，公司会当宝贝似的，认为这是一个很大的好事，积极努力的员工，往往会被老板认可。
  但我想说：万事有度，过了，没准就是危害。我之前在Visto工作时，当时Admin模块组的几个人，在看了很多新的资料后，想在一个项目中，将这个模式按新的方法重构。。。我当时快离职了，但是因为在公司里呆的最久吧，老大问我的意见时，我是这么说的：1. 目的是什么，解决什么问题；2. 怎么证明新方式有效；3：有测试方法保证不产生其它影响吗。。。结果，听说这个重构弄了半年后，没让上线，因为不管时机还是质量，都成问题。
  所以，我在带团队时，告诉大家：我鼓励所以有效的技术元素加入我们的产品中，同时，我更鼓励有艺术有技巧的安排它们进入系统，提供更好的功能，更高的效率，更高的质量。
  我们的团队在后面，加入了好多新的元素，但都是在考虑了功能，效率和质量后的，产生的效果正面的多；同时，对于不是很肯定的，我们也拒绝了很多，但大家都很开心，因为这个过程，大家觉得是在提高自己的能力，没有人认为是在打击积极性也。（项目管理，有时候要求高，就在于此，拒绝，也需要技巧）
• 研究导向的开发
  我换了团队后，对这个感触挺深的。新的团队啊，美国的老大们是一批在导航领域中，很资深的专家，他们的技术能力强，但项目管理上，确实偏弱。。。不用举细节的例子了，光一个OSM ( Open Street Map )项目，从我进团队到写这文章时，近两年的时间，也没有产生出什么实际的结果。。。包括数据处理自动化上，也是这样的，一个东西讨论了近两年，也没做出来。。。
  所以，我当时在得到了团队的一定的认可后，给团队这样一个建议：不管我们认为什么样的项目管理模式适合我们，但以下几点，我们一定要按这个做：1. 任何工作，有清晰的目标和Deadline; 2. 根据目标和Deadline，分成阶段；3. 每个阶段，有release, 有测试；4. 最终，有验收。在这个基础上，我们可以根据情况再来看怎么通过好的项目管理模式加强它，但是，这几步，只要需要，就必须做。。。

项目管理过程

好了，说到项目管理过程了，说实话，我从很早之前就很明白，这个的重要性相当高，高于很多所谓的开发技巧和代码能力，因为好多项目的失败，根本不是代码或技巧的失败，而是管理的失败。但我也碰到过一个Project manager，跑到我这来说，Louis，我每天都Tracking，定计划定的特别的细，但是总是后期出问题，而且一出问题的时候，就没时间改了都，这怎么办？对这个问题，我当时建议他看看有没有在项目管理中，碰到了下面的问题但没有提前解决掉的

• 过于乐观的计划
  说起这个了，和我共事的很多Project manager都会和我说这样一句话：计划都是开发定的，开发自己定的自己不能保证，大部分问题当然是工程师的问题，和Tracking有什么关系？。。。听着说真的，挺合理的。。。但我当时也提出了这样一点质疑，项目管理真的是只做Tracking吗，计划合理不合理，项目管理的负责人，不应该通过一些科学的手段来评估一下吗？
  项目的评估手段有很多种，这些手段虽然没有哪一种是真的准确的，但是吧，也不是完全无用的，良好的利用这些模式，与工程师一起，制定一个合理的计划，对于项目管理过程来说，是非常关键的一步。
• 没有足够的风险管理
  这个道理不用多说了吧，其实目前好多的开发模式，都在偏向于提前的发现风险，因为风险是很多软件最后“失败”的直接原因。。。这里面的风险，不光是技术风险，还包括了人员风险、客户风险。。。我印像挺深的是一个Project manager在公司的meeting上提出，最近项目做不完，不是项目管理的问题，是人员出现了变化。。。当时我的Boss很直接的问，只有5%的人员变化，你的项目管理方案都不能解决，难道项目管理就是全对的了？当时所有人都不说话。。。
  当然，技术风险就更别提了，“感觉”这种方式是没问题的，最后出了问题时，不光是项目受影响，士气影响，信心影响，产生的结果也是长远的，所以，我们公司的iDev2.0的项目管理模式中，风险管理被很明确的标成了重中之重
  所以，后面凡是在项目的管理方案的review时，我都会先问，你发现了哪些风险点，这些风险点，你怎么做的？这些解决后，项目失败的可能性，会大大的降低
• 设计低劣
  不用多说这个了吧，我相信很多从技术出身的人，做过两年，就会深有感触 ，设计要是出问题了，最后，收拾残局吧，事情会多的有点像2/8理论那样，不过，是写代码时间占20%，改bug的时间是80%，这时候，什么项目管理啊，就很难起作用了，最后的结局就是，催也没用。而且，还要欠一堆的技术账。。。（上面的提到的VX项目，其实后期就是这样，所有的delay，都是因为改bug，最可怕的是，当时甚至出现了越改越多的情况）
  所以，我们的团队当时，设计质量的review, 被当成最高优先级，而且，不轻易计较成本。。。
• 缺少质量保证
  大概10年的时候吧，我和Visto的一个Manager，有机会在一起聊天，我们认识很久了，虽然不特别熟，但他也算是什么都说，他提到认为敏捷没用，因为他们试过后，发现bug数啊什么的，全少不下去，而且因为大家对这种方式不熟悉，还反而比以前要慢一些。
  我当时从头听到尾后，突然有似曾相识的感觉，然后我和他说了这样一句话：你们目前的情况，不是因为QA的测试能力差，而是Dev的测试能力差；在每个交付的过程中，不能够真正的保证这个阶段的质量。。。
  在这之后，其实做为Dev的manager，我也有意的参与了好多测试的工作，把测试领域的一些思路介绍给了开发团队，有意的让测试和开发合作更多，尝试来解决每个迭代周期，质量由Dev和QA，共同来保证。。。至少在原来的Core SDK组，起到了不错的效果。。。
  所以，我当时给几个Project manager的建议还有：管项目其实也要管人，帮助大家提高质量意识和质量能力，比流程化的东西，更重要。
• 追赶计划
  真要出了问题怎么办？其实要是早几年，我也不说别的，肯定是减掉应该减的，简化能够简化的，然后，让计划看上去是达到的。。。没办法，压力啊。。。但是，可能是因为我们一直在做我们自己的产品的原因吧，在VX项目半年后，我就改变了我的想法了。。。我当时告诉我的团队“只要大家重视了意识，也用了团队的力量来尽量保证质量了，那么，如果还出问题，不要急着往前赶，先来让大家意识到这个问题，一起找出办法来。。。”
  其实我在说这话的时候，并不是为了让大家别有太大的压力，而是VX项目后期留下的技术账，真的是让人太累了，后面凡是碰到这部分代码的feature，全都没法按时完成，就因为当时这部分赶计划时，欠了太多的技术账。。。
  所以，我对项目管理的建议是：1. 不要最后一分钟才说计划完不成了；2. 不要因为完不成，而轻易舍弃不能舍弃的东西；3. 具体问题具体分析，只要不掩埋起来就行，因为早晚还要碰到，到时候，死的更惨。。。

其实要说项目失败中的精典案例，真的挺多的，所以有一次有人问我，如果新的项目来了，你会怎么选择开发模式或项目管理模式呢，我当时告诉他，我会根据产品，技术，人员的不同特点，来选择开发过程模型，在没人分析这些之前，我不会轻易说哪个更好的（开发有四维，只有另外三维定了，才最有可能定下来开发模式这一维），同时，不管我选择了什么，我都要看看，这些不应该犯的错误，是不是能够在开发过程中避免掉。。。少犯错，成功的概率才高。。

 

做好团队，打好基础

虽然主题还是开发和项目管理过程的东西，但我也想说，因为过程是人来执行的，其实，本质上和人有不可分割的关系，所以，团队是个避不开的话题。。。在我工作的这些年中，如下的经历其实不少，比如

• 没有项目经理，好像也没谁提什么高大上的项目管理，但项目做的挺成功的。。。
• 有了项目经理，但好像平时不理我们，就是Tracking点进度，我们做的也不错。。。
• 有了项目经理，引入了敏捷，引入了“War-Room”模式，挺成功的。。。
• 敏捷和“War-Room ”模式没变，关键的人才走了两个（20多人呢），项目慢了，而且还差点失败。。。
• 不提敏捷了，也没有War-Room了，用了iDev2.0，项目进展，又顺利了。。。
• 管理模式没变，人员流动大了，项目好一段时间，都做不成，直到人员重新培训完成了，才回到正轨。。。

所以，其实不难理解，团队的重要性，真的像鱼和水的关系，没有足够的“水”，鱼是游不起来的。。。我听过一些老板说过，工程师不重要。。。但反过来，我到真没听哪个老板说过，团队不重要的。。。

说到团队，有几点真的挺重要的了就

• 用天才，但不要过多
  其实我本人并不完全同意这种说法，因为如果天才能有效的合作在一起，形成的战斗力是巨大的；我一直都很好奇我的US领导给我讲的InstrantGram 在有几千万用户，被几亿美金收购时，只有十几个员工的故事，当然，我的领导也没有机会接触这个团队，但是也很佩服他们。当然，因为是在国内，小米招聘所花的时间和代价，以及所得到的收益，也让我感觉很是钦佩。。。
  但回到现实中时，我确实也发现，天才多的时候，有一个弊端，就是很容易不统一，导致执行力有时候，反而要低的多。。。凡是天才，或是经验丰富的人，都会愿意把自己的想法或思路体现出来，不管是设计还是管理，都会这样，当出现冲突时，都会尽力的来证明自己的想法是对的；对于一个沟通能力强的人来说，可能会用一些技巧，但对于沟通能力弱的人来说，用的，可能就是“蛮横”了。不管是哪种类型，都至少会花时间来证明自己的想法，如果这种“证明”多了，那不可避免的就是，好多无用功花的会很多。。。对于项目来说，这至少不是好事。。。当然，后期的时候，团队中很多人都越来越Senior时，我采取的方式就是通过模块化让大家各自都有自己负责的领域，而且不断的加上挑战，这样，问题会弱化好多，至少我认为这是一种：良性竞争，同时也是良性相互学习。。。
  当然，我也确实看到过坏的一方面，后来公司转型的过程中，一批“天才”的管理者，其实在初期就是因为意见不统一，弄的公司一团糟，没有统一的思想，没有统一的行动，对公司的影响，真的挺致命的。
• 工作（或合作模式）要匹配
  其实说到这点，我有时候也会为很多manager鸣一下不平，毕竟有时候就算是发现一个人的长处，但是因为各种原因，不能安排好的情况也不在少数。但是在这点上，确实也是考量一个manager能力的地方。。。
  我真的碰到过不少，被大家认为能力一般的人，出去之后很优秀的，比如原来的一个QA，当时听别人对他的评价是，过于散漫，而且，小毛病太多；后来这哥们被”挤“出了公司，当时因为一起出过差，他还跑到我这来好好的抱怨了一番，我当时感觉，这个人似乎有点思路，但因为接触的不深，所以，也不好说什么；后来，这个人在一家公司当上了Director，一家游戏公司，做的很不错的。。。 所以，用好人，对管理者来说，是大事
  我团队中的工程师的个性啊，风格啊，真的挺多的，比如
  • 老实人，甚至平常都不都别难和任何人说话的。
    • 优点：安排事情容易。
    • 缺点：沟通主动性和能力，都会偏弱。
    • 建议：放到需要耐心和毅力的地方去，他们虽然不一定做的快，但会做的好，而且稳。。。当然，也需要适当的提高大家的沟通能力，但我一直提倡的是，最好把重点放到提高”工作中的沟通能力“，我见过原来有的manager，看一个人能力不错，还想提高大家的社交上的一些能力，反而导致有的人离开，因为他的性格，真的不喜欢这些。。。不要尝试改变人的性格，为了工作缓解一下就好了。。。
  • 很活泼的，100多人的公司，一多半和他很熟的。
    • 优点：沟通能力强，心地不错。
    • 缺点：有可能大多数沟通能力，都用到闲事上了
    • 建议：说实话，这样的人有的时候，在团队中的影响力，比manager和boss，可能都不小；他们活泼，很容易让人接近，也很容易影响别人，很容易让团队有一个不错的氛围。有的时候甚至会形成一种”民间团队“似的组织。和他们，保持一个不错的关系，多关心多帮助，肯定不会有坏处的，他们有时候给出一些对公司的正面的评价，比你自己说很多，效果都要好。如果这样的人能力不错，又和你保持着一个过的去的关系，对你来说，算是服分吧，有时候，不经意的在他们面前表扬一下别人，会比你自己去表扬那个人，效果来的还要好。。。对他们的技术能力，最好是尽全力的帮助，不要让他们差的太多，因为他们如果技术上差的比较多，或比较偏，就会产生挺不小的影响。
  • 抢尖拨上的人，对名誉很看重的。
    • 优点：需要时，会很努力
    • 缺点：得不到需要的名誉时，会有不小的副作用
    • 建议：我的几个Leader，在开始做工程师时，都体现出来这方面的特点，所以我个人很喜欢这类的工程师，我的建议很简单：能给的尽量给，而且出了错，揽到自己身上来。。。沟通，尽量放到1-1的时候做，不在人前做太多；有了好的方法，尽快分享给他们，但不轻易替他们做主；很多的不错的管理者，都是这种性格的人，碰了足够的壁后，磨练出来的，这样的人愿意跟随你，是件挺好的事。
  • 努力，但慢的厉害的人。
    • 优点：真的很努力，而且，还很稳定，团队有困难的时候，他们也会默默的支持
    • 缺点：项目周期上，产生的压力不小。
    • 建议：对他们，招聘的时候要尽量避免招进来，如果招进来了，要尽量避免因为能力问题而让他们离开；这批工程师最大的特点就是努力，他周围和他接触过的人如果了解了这个事情，会很”同情“他们，在中国，努力而低调的人，总会得到同情的，所以。。。
  • 为了钱，跳槽次数很多的人
    • 优点：钱多的时候，很努力，而且也会表现的很专业
    • 缺点：不会和你一起共渡困难的
    • 建议：在你发展壮大的时候，引进他们，让你更壮大；但如果出现风吹草动的时候，也不要把宝压在他们身上。。。当然，有的人跳槽很多是因为客观原因，这就又两说了。（我们公司出现变化的时候，后来统计的，真的是当初这类型的工程师，没有几个留下来的，弄的我们挺背动的）
  • 为了技术，因为挑战才来团队的。
    • 优点：技术能力强，而且会越来越强。
    • 缺点：对技术的热衷，会让他对”普通“的工作，没什么兴趣，而且，会让别人感觉，性格有点”怪“
    • 建议：这样的人，其实不容易碰到，有多少要多少，不要因为缺点而不敢用。。。真心的对待他们，说出你需要他们支持的地方，有挑战的地方，有困难的地方，他们大多数人会成为20%的人做80%工作的类型的工程师，所以，这些人是财富。。。
  • 只喜欢某一种技术类型的人（比如只喜欢前端开发）
    • 优点：相关的技术类型，会成为专家。
    • 缺点：有时候太过分了，会让工作安排不太容易。
    • 建议：用，毕竟对于不少时候，某个领域的专家，在这个领域做的事，可能是其它人几倍的效率，但同时，不要太多，一个领域有一个两个就够了，然后再提倡一下全栈的概念，毕竟，未来的趋势是一专多能型人才。同时，对他们的这种心态，也要有一定的包容心。
  • 能力很不错，但居家过日子心态更重的人。
    • 优点：稳定，对工资什么的，相对同等水平，要求偏低
    • 缺点：他们不会接受长时间的加班式的工作
    • 建议：在这件事上，真是仁者见仁，智者见智了；如果你的公司相对清闲，但技术能力要求高，他们确实会适应你；但如果你的团队本身的压力大，你不妨要仔细考虑一下了。。。
  • 一心想进入管理层的人
    • 优点：这个和对名誉感看的很重的人相比，还真有一定不同，他们看重的是权，而且，是实权，也就是说，他们有野心；有野心的人，努力的程度，比别人就会高的多；
    • 缺点：有野心的人，其实也是不安的人，在某些情况下，产生的负面作用，也大
    • 建议：事实上，我们原公司就有不少人，被提成了manager，但最后，离开公司时，产生了巨大负面作用的人，弄的当时提拨他们的manager，后面都不敢再提拔人了。。。我对这批人的建议是：同意他们的要求，然后给出观察期；他们会很努力的达到要求，同时你需要花大量的时间来看，他们能不能成为和你志同道合的人；如果行，他们会是你未来的帮手；如果不行，不要轻易因为其它客观原因让他们真的到这个位置来，因为志不同的人，最后产生风险的可能性就太大了。
  • 完成好本职工作，就ok的人
    • 优点：能尽力的完成本职工作
    • 缺点：完成是个人的目标，不是很有兴趣帮着团队更进一层
    • 建议：在团队核心比较成熟之后，我们需要这样的人进入团队，然后一起配合完成工作；但在核心成熟之前，慎用；因为容易让团队的氛围，从一开始就降的太低了。
  • 技术落后了的人
    • 优点：容易因主技术，而认同团队，从一开始就努力
    • 缺点：技术的差距，有的是意识转变就能很快跟上来的，有的是需要花很长时间的
    • 建议：很简单，兴趣在，帮；兴趣不在，放弃吧；技术团队中，技术差而且自己并不想上进的人，很多时候可能成为坏例子

对每种不同风格的人，其实都有相对就应的方式，来找出他们匹配的工作来，当然，这时候你要看你的团队，有多少的承载能力；如果没有太大的承载能力，我的建议就是，找出和你性格和类型相似的人，不为别的，这样会降低你的管理成本（因为相似，所以你能理解他们，因为这种理解，配合起来会容易的多，管理成本的降低，是显而易见的）

当然，在一支团队壮大的过程中，不可能完全找和你类型相近的人，所以，这时候就需要你根据情况来看看如何让不同性格的人，来在工作中，体现自己的长处，避免自己的短处了（当然，说实话，我还是建议可能的情况下，招聘时注意选择人尽量适合团队，至少不要偏出去太多，否则，未来总会有你自己handle不住的时候）。。。

• 团队平衡
  上面说了我团队中好多种不同的类型的工程师，因为后期，项目所需要的人数大大增加，所以，坚持只招一种类型的工程师，很不现实的，所以，这时候，不同的人进入团队，合理的让大家一起工作，就成了重中之中，我相信，不同的团队有不同的组织方式，没有办法统一形成一种模式，所以，只来提提我带过的几个团队的模式吧
  • 一到两个对技术或对名誉很看重的人，做为团队的技术带头人
  • 老实人也好，求稳的人也好，在团队中做为带头人的支持者
  • 如果可能，可以选择一些：目前技术一般，但很努力的人，做为最后一层，这样，让团队内部的学习氛围很足。
  • 团队内或团队外，找一些沟通能力很强的人，增加一些”民间组织”人的文关怀因素
    
    这种模式尝试了几个团队，至少到目前为止，感觉效果还不错，大家的上进心都能充分体现出来，而且项目的进度和稳定性，也都有一定的保证，氛围的和谐，也让团队的稳定性，在公司不出大问题的情况下，情况还不错。。。每种类型的人都各取所需，项目的情况也相对顺利。。。
    
• 去掉不合适的人
  当了八年的manager之后，参加过一个manager讨论会，我当时发现2/3的manager，都说自己没有辞退过员工，我当时还在想，你们真幸运；但后来，和一个猎头的朋友聊天时，他却直言，他们在帮人推荐manager的时候，没有fire过人的manager，是肯定不轻易推荐的，因为大多数时候，这些manger少了一份责任感，得过且过心态重，没有自己的带团队的战术体系的想法。
  后来想想也对，如果你有了自己的战术体系，而且来执行它，除非它万能的，但不管怎么样，也会有不适应的人，这时候，得过且过就是放下自己的战术体系，要不，就会有极端的事情发生。当然，也许你会问，当初招聘的时候干嘛去了，我想说的是，好多大点的公司，其实你用的人，很可能不是你招的。。。
  对几种类型的人，我建议要尽量的去掉：
  • 技术上无法再提高到我们要求的人（我在Core SDK时就碰到了一个，培训了三个月，最后Leader直接告诉我，换个新毕业生都行，这样的人，没法留）
  • 与团队风格格格不入的人（说实话，这样的人离开，我其实觉得挺可惜的，毕竟，他们不是能力不行，但有时候做为管理者，确实要看团体利益）
  • 恨公司的人（可能大家会觉得奇怪，怎么还有这种人，但说真的，真有，背地里做小动作很多，不尽快弄走，危害很大）
  • 大家都评价他不行，但他自己不认可的人（来Core的时候，碰到了两个，离开的过程挺麻烦的，但是收效，确实不差）
• 进行激励
  我在给我带的几个Manager进行培训的时候，对激励，给出了很高的重要性，我当时说的时候，很直接的说
  • 你要是不会激励，就别带团队，也别“组织”大家做任何决定。。。
  • 激励的时候，别玩虚的；别觉得你足够聪明，谁都不傻，玩虚的，很快就会被看穿的。

当然，激励的方式，可是多种多样的，在上面的两个原则下，而且说实话，我愿意把激励分成两个大部分来做（我原来专门还和大家讨论过“谁说批评不是激励？关键是要看方法”）

• • 正面激励
    • 最有效的几个激励点
      • 成就感：对目标理解的认同，同时，实现这个目标的路上，自己又有自主权
      • 发展机遇：举个例子啊，我尝试过用一个明星式的员工，做为和他工作过的人努力的目标，这个激励效果真的挺不错的，大家为了达到同样的水平，每个人都很努力。
      • 工作乐趣：要是这份工作有挑战，有技术含量，又能说明重要性，其实“工作”乐趣对喜欢的人，很大的，这个，比天天喊口号和1-1 talk，起的作用大多了（当然，我在这里要强调的是“工作”乐趣，原来的QA团队，他们也很“乐趣”，但感觉有点偏，就是在大家一块干别的东西的时候，乐趣才能上来，工作时，又全下去了，其实这种乐趣，我个人觉得反而有一定的害处，至少在工作时，要能感觉到乐趣，其它的起的应该是辅助作用）
      • 成为主管的机会：这个不多提了，中国的工程师，其实对于40岁之后的压力，确实在这方面有很直接的想法。
    • 注意
      • 及时评价，晚了，效果打折扣好多的
      • 具体点，虚的其实没用，没准还有副作用
      • 让他感觉你在关注他，而且后面会更支持
  • 侧面批评
    • 提前说好，好坏评价都会有，别弄突然袭击，同时，不要同着别人
    • 错误要具体，而且要以帮助的方式来做
    • 别让他感觉到你是失望的，要让对方感觉到你是关心他，而且还会持续的关心的
    • 批评完事就要过，以后，少提了。

管理好风险

我还是想强调一点，如果团队成熟了，风险管理得当，至少事情失败的可能性，就会降低很多，所以，不管选择什么开发模式，事实上这点，重中之重。。。

曾经有一个Project manger，在和我分享经验的时候，给我看了一张风险管理表，来给我介绍他的项目管理理念，因为我一直很重视风险管理，所以，他估计是感觉我会和他有共鸣呢。。。但我看着表的时候，突然有一种不好的预感，这个真的好详细啊，我和做这个项目的team合作过，他们很资深，但在弄表格这种文字工作的事上，一直都不太感兴趣，这张表，和以前有挺大的不同；后来我深入的和几个参与者聊了聊，原来是PM按自己原来的模式，算“强制”要求大家弄的，而且花的时间还挺多的。。。我后来和这个PM聊了聊，我告诉他，很可能项目最大的风险，来自于他，因为他的工作模式，让其它人，不愿意像以前一样尽心的参与了，只是要求我做什么，我就做什么。。。这也是我和这个PM后来总结的，项目最大的风险，往往就来自于人的风险，不要忽视这个。。。最好的项目管理模式，要是没有人愿意做，也很难做成。（其实后来公司很多政策，我觉得都不错，但也最后因为上层的五个人想法不统一，没有最终弄成，其实项目，也类似）

 

当然，因为是重中之中，所以

• 一定要有好的风险管理计划，而且要重视
  我虽然并不建议把风险管理表做的又大又全的，但是我却一直要求，风险点上的分析，花的时间一定不能少，而且，要在最好的状态下来做，尽量让它足够想的全，不太好说的地方，尽量的在项目的前期来试，不要轻易放过
  当然，团队磨合期的时候，大家也问过我，风险往往是没有发生的东西，这个提前想，太难了；在这种时候，我会灌输大家这样一种思想：想要让项目安全，最好的方式就是大家提前在脑子中，把各种情况都过一遍，找出问题点来：如果我们不去做，一定会出问题的；如果做了还是没找全，我们尽力了，谁也不要怪，能力就在这呢；我们每想到的一个风险点，就是给自己未来，解决了一个麻烦，让我们自己能舒服些。。。（当然，我也会举出公司之前做项目的时候的例子，因为目前还有人亲身经历了当时的困苦，所以，很容易让大家相信）
  在这个思想下，至少我带的团队，项目前期风险讨论的时候，都会尽心尽力，因为谁也不想后期加班到死，有的时候就算这样还完不成任务。
• 监控好风险
  这里面其实有个故事，两年前吧，我换新team的时候，同时这个team还换了一个project manager，这个PM基本不懂技术，而且对新team做的东西，也不了解（有点后台安排过来的嫌疑），当时他来的时候，其实挺困惑的，因为不知道怎么下手。Team里的人都有不少年的工作经验了，所以对这样一个PM，根本也不重视，甚至有人和我说，这个人多余的。。。
  刚到一个Team就碰到了这样的矛盾，我也挺棘手的，让这个PM学习Team的知识，远水解不了近渴啊；要是说让几个Leader认可这个PM，就更别的提了；互相之间的矛盾看着就越来越重起来了，后来，我建议这个PM换种工作模式
  • 和大家承认，对于这个Team的东西，不熟悉，需要大家的帮助
  • 对于分给这个项目的Schedule上的事情，不管用什么方法，由PM来找出来，并和US确定，来帮几个TL解决这方面的沟通麻烦。
  • 和TL讨论项目的Task List，还有风险点，但一定要以TL为主，风险点的内容就算不懂，也记录下来
  • 追踪Task状态和风险点状态，不能深入就不要深入，依赖TL来做
  • 最关键的是前十个风险点（所以，需要和TL一块来定优先级，同时包括我。。。）

这种方式下来，PM也顺利了，TL也还可以，关键是，项目顺利程度，比以前大大增加了。。。所以，监控好风险点，就算不能一个人来完成，也一定要让团队有这个机制，只是，一定要注意，充分发挥有能力的人在风险点解决过程中的能力。

• 不同情况下，选择不同的风险化解方式
  来看看常见的风险，和我的建议吧
  • 功能无限蔓延
    • 别说功能不能加：我相信现在的很多新的开发模式，都是为了能够拥抱功能变化而产生的，所以，功能的改变或增加，其实要当成常态来看待，风险中的这一部分，要先接受着看待
    • 别轻易说能加或能变：相信我，不是说你的团队能力强，就可以接受所有的变化，我们做NexGen时，开始过于乐观的估计我们对变化的接受能力，等到开发到一定程度时，发现越来越停不住，最后，延期半年后，项目又以草草的方式结束了。
    • 功能的改变，沟通要做好，而且，注意取舍；这时候，我到真的觉得项目管理的工具会起到挺关键的作用了（当然，前提是里面的数据得是对的），功能的改变，特别是大的功能的改变，最好能够：
      • 沟通好：不光是和开发，还有测试，运维，市场什么的，让大家都因此有足够的能力做出改变（变更委员会，在这里确实是一个好主意）。。。我经历的项目中，没有沟通好导致最后代码写了，没测试，没上线的，不少次了，等真用时，又出问题，但时间太短了，又没法真的解决，这表情况，真不止一次。。。
      • 做出取舍：其实最怕的不是变，而是只往多了变，往复杂了变，而时间上，又是固定时间。可能是我的能力不够吧，但就算我的团队最强大的时候，其实对这种方式的功能蔓延，都没有真的有能力解决，有的时候，看着project plan上，觉得能行，但真做起来，又因为这些变化导致了新的因素的加入，让原来的plan不在准确了，导致了不少的问题。。。所以，做出取舍，为了取舍给出足够的信息，是项目团队和产品团队共同需要考虑的问题。
  • 质量不定
    在这点上其实我又想起来NexGen项目了，我当时记的挺清楚的，最开始的时候，我们定了一个demo质量的目标日期，开始的时候，大家都把这个当demo来看，可当demo完成后，上面要求基于这个，1个月内弄成产品，马上就傻眼了，因为什么呢，代码质量一般，测试力度一般，功能虽然在这，但和产品，差的，还老远呢，弄的上面也不满意，工程师，更是累死累活的小半年，去赶项目。。。
    • 质量的制定标准，一定要提前大家都同意
    • 记录风险的同时，还要记录下来“技术债”，如果出现变化，一定要清楚的知道这些技术债，根据它来做正确的建议。
    • 测试时，在有限的时间内，越多越好，越快越好；
    • 避免对质量盲目乐观（测过了和测好了，根本不是一回事）
  • 计划过于乐观
    参与过项目管理的人，特别是负责人，应该都会碰到类似的问题吧，计划是大家出的，也加入各方的人员参与，感觉上应该没问题了，但最后，计划上还是出了不少问题，在后期，要么开发玩命赶，最好草草收场；要么，功能被砍掉，Product team很不情愿，但也没办法；要么，只能延期。。。
    所以，一套好的项目评估方式，其实特别重要，这里不多说了，底下再说。。。
  • 设计欠佳
    不说了，这个应该容易理解，但确实不容易做好。
  • 研发导向的开发
    上面提到过了，这里不细述了，不管什么项目，最好
  • 人员薄弱
    就像上面提到的一个观点一样，不管你用什么管理模式，“人”才是最需要考虑的因素，因人而异是一个很重要的事情，如果在这上面出了问题，那，不管是招聘，还是培训，或是其它的什么什么方式，都要加强。。。这里面，有几点算是我个人的一些心得吧
    • 招募顶尖人才
      这个，所有的公司都在做；但是吧，其实，有时候，不是你有钱就能真招来的，有几个因素让顶尖人才其实不愿意来你这
      • 你的招聘是在生人圈子里招的，比如招聘网站什么的，顶尖人才，往往没时间弄这些
      • 你的公司名声不好，就算是顶尖人才，也不愿意冒这个风险
      • 你的诚意不足，认为你是出资人，对方是来打工的；一般顶尖人才，合作才是吸引他们的最生要的手段
      • 你这空间不足，各种规矩让人受不了，外行管理内行，更是让他们觉得效率不高，不愿意来
        
        所以，要想找到足够好的人才，最好是：
      • 进入工程师的各种圈子，了解大家后，就容易招聘多了，特别是人家要是认可你后，就更是容易了
      • 别把公司的名声做的太差。
      • 如果你认为对方值，姿态要给出来，最好是真心的，不然，就算装，也要装出重视来
      • 规章制度上，越少而精越好，有些个自由度，对于好工程师来说，是会提高效率的。
        
    • 对关键人才，“有效臃余”不是坏事
      和我的Boss聊这个话题的时候，他虽然同意，但是觉得这样成本过高了，但是吧，从项目的角度来说，最好做好平衡，因为
      • 人随时可能提出离职来的，现在外面的机会很多，也很有吸引力，所以，不要觉得人家不会离开你，就算你做的再好
      • 有个“竞争者”，会让事情更保险一些，我估计看到这的不少人也发现了，我其实想说的是，项目能按时按质量完成，大多数时候对大项目来说，就挺不错了，所以，有个backup，对这个，有挺显见的好处的。
    • 培训一定要做到位，不要敷衍了事
      我原来的公司经常做培训，而且，往往在工程师向上层反映问题的时候，培训过少也是一个挺重要的“问题”，但说实话，有时候我感觉，好多培训像是在过家家似的，就是为了培训而培训，讲的人，有的或是敷衍，或是只用心了一部分，但没有到位；听的人，就算是愿意去听的，也是听完了就完；这样的培训，最后达到效果的，真不多。。。关于培训，我之前的经验有这样几点
      • 公共知识不专门做培训：而是通过“导师+提问”来做；比如Android开发，网上一堆的资料，培训其实作用很难说有多大，“分配导师—>自己学习—>提问—>再学习”这样的方式，在带团队时，确实会减少不少的管理成本，同时效果要好的多，不光系统，而且工程师发散的思维和学习能力也容易体现的更好。
      • 专业知识专业讲解：之所以我提到专业讲解，是因为专业知识这部分，外界资料少，而且就算有资料，其实也和你的差的挺多的，这部分如果不专业讲解，其实一个人可能要花上好多时间，在不同的项目中体会，才能了解到。。。对这部分的培训，其实更需要的是引起足够重视的培训策略
        • 全面性介绍，而不是指几个地点就完了
        • 重点部分，深入进去，至少有一个例子来串一下过程
        • 背后的思路和发展历程，需要体现出来
    • 团队建设
      这个话题太大了，我后面会在其它的博客里，单独再说的。。。
  • 测试不足
    这点呢，我想说一下，给测试留出足够的时间来，如果你没有一套有把握的测试策略和工具的话，不要轻易因为Schedule 压力就压缩测试时间。。。同时，快速的测试策略和方法，一定要贯彻下来，不管你用敏捷还是其它的管理模式，要是测试策略和方法上导致快不起来，其实很难有戏（我有一篇博客是专门说测试的，这里也不细提了）
    当然，我不是说测试的问题一定是靠时间来解决的，好的测试策略，会大大降低测试时间；但你不要轻视测试策略，好的测试策略，比好的开发架构，还能设计呢

 

做好项目评估，要不，你可能都没机会选择开发模型

之所以加了这么一段，是因为第一次我用敏捷时，我就喜欢上了敏捷的理念了，而且我也特别相信，他能够提高开发的速度，和尽量的保证质量，拥抱变化；但第不幸，其实第一次使用的时候，项目是失败的，因为项目的评估上，出了很大的问题。。。

当时的项目是VX，是一个将真实3D技术，加入导航的一个项目，这个功能在09年的时候，我们公司是第一家在美国推广的，所以，当时产生的效果还是不错的，但当时，项目虽然上线了，可是并不能算成功，因为

• 延期了差不多半年，而且是累死累活的才“按时”弄完
• “技术债”多去了，后面的好长时间都没有彻底解决，后面的各个功能碰到这块领域，都很头疼。

这个项目后，虽然我对敏捷开发感兴趣了不少，也算是较早关注敏捷的人之一，但是，更让我关注的是，项目评估了，因为这个，才是后面问题的根源所在。。。当时的VX项目，我们评估了以下几点

• 项目的scope是个中等的项目
• 开发周期差不多要半年
• 大概需要15个人（Server, Client和Core的人全要参与）

但事实上是

• 这是个大型的项目，大家过于轻视了Server和Core上的工作量
• 开发周期最后用了一年
• 差不多最后有40个人直接参与
• 测试中产生的bug数量就有近3000个，改bug的时间都超过了3个月，还包括有相当一批因为时间放到以后的release才改的。

 

看看当时为什么评估会出现这么大的偏差吧，一般的评估，会需要以下几个方面，我来分析一下当时每一步都差了什么，最后导致这么大的不同吧

• 估算产品规模
  几个原因当时导致了这个问题
  • 政治原因：我们公司的几个Director啊，全都想自己弄出点东西来，然后提升自己的影响力，所以当时在评估时，确实明显感觉有意的往下压时间，然后通过时间下压，来让大家觉得自己的管理能力很高
  • 技术原因：轻视了某些细节对整体带来的影响，这个在后期发现，例子挺多的，比如，过于轻视了core team处理所谓“简单”问题所需要的时间，还有integration 的复杂度
• 估算风险部份
  风险管理在上面我们提到过不少了，这个项目中，其实不是没做过风险管理，比如Opengl部分，做的风险管理就不错，还专门做了个demo，来证实技术可行性，但确实，以下几个方面，我们做的就差多了
  • 人员风险评估
    • 其实项目中加的很多新人，过高的估计对方的能力，没有加上有效的措施，是一个很大的问题
  • 很多过于乐观的”第一次“的评估
    • 第一次这么多团队一起合作，过高的估计了我们的沟通效率
    • 第一次使用新数据，过高的估计了数据的正确性
    • 第一次在Android上使用NDK，过高的估计了NDK的稳定性
  • 低估了一些关键部分的风险
    • 太低估了性能问题，第一次发现性能问题时，虽然我建议把这个优先级放高，但进度压力让我们先放下它了，事实证明，后期花的巨大的时间，和前期的不重视，有直接的关系，因为雪球越滚越大，后面连查找，都成问题了。
    • 太低估了Integration testing，很多时候，进度压力就是在大大的压缩集成的时间，当然集成测试就更别提了，本来测试的方案就不好，集成测试的时间又短，所以，最终出现了所有feature都做完了，但项目的质量让进度不可控制的局面。
    • 太低估了测试风险：就是在这次的教训之后，才让我这个开发经理，更花时间在测试方式的学习上了，我们当时看到了测试策略，看到了测试case，但是，却没有人注意这里面的脱节，导致关键feature在后期，出现重大的问题却最晚被发现。
    • 低估了团队对文档的依赖：这家公司以前，文档化做的虽然不是特别全，但是还可以，但因为这是一个大项目，时间又紧，所以，文档上花的时间变少了，同时辅助以更加快捷的”story”模式，但是如此大的团队，在没有适应这种模式之前，突然的改成了这种模式，各种不适应，就全来了。
• 估算工作量
  估算工作量有时候看上去是件容易的事，但事实上，直到目前，我所在的公司，还有不少工作量估算和真实工作相差甚多的情况，要么过多，要么过少，过多则资源浪费，过少，加班或者无法按时完成，虽然工作量估算大多数时候不可能100%准确，但尽量的不要偏差太大，对于项目来说，很重要。在我所经历的项目中，估算时不太好的原因，我见过的有如下几个
  • 拍脑门式的估算，只凭经验，而且，还没有review。
  • 过于保守。
  • 项目管理式的估算，完全不考虑灵活性因素（有的部分没有那么复杂，但估算后时间很长，弄的真正需要花时间的地方，花的太少）
  • 一边压时间，一边加功能点。
  • 不重视工程师的估算，或没给工程师足够时间分析下的估算
• 估算进度
  对于这部分，我到真的挺喜欢迭代式开发的，因为每个迭代后，因为有了可运行的build，所以对进度的估算会相对准确的多，但即使使用这种方式，有时候也会出问题，比如
  • 不重视质量下过于乐观的看待进度
  • 风险点没有解决的情况下过于乐观的看待进度
  • 政治原因来分析进度
  • 拍脑门式估算
  • 不重视工程师的估算，管理者自己来评价
• 定期修正
  说实话，谁都犯过错，只要改了，就还是好的，但是对于定期修正这事，我们有时候，或不愿意做，或做的不好，或干脆怕做；这时候如果发现问题，最简单的模式就是几种
  • 让工程师玩命加班来修正回原来的评估来
  • 舍弃一些”质量“来让速度快起来
  • 舍弃一些”大功能中的小功能“来让速度快起来
  • 压缩测试来让速度”快“起来

正是因为以上这些原因，所以，有的时候，项目就算苦苦弄完，也可能技术债一堆，后面也很难弄。。。也许我错了，如果估算错了的话，我不知道什么样的软件开发模式能够真的解决这些问题，所以，我在我团队中，会加强对估算的要求，至少从以下几个方面来做

• 评估一定要做到：谁来做，谁评估
• 评估方法不能拍脑门式的，至少要有：专家式+历史经验值式
• 不要轻易追求进度快，保证质量和追求进度要平衡
• 对于普通的工作的评估不能轻视（不要在阴沟里翻船）
• 评估结果的review一定要重视，多通过不同的问题和分析，来看看评估的准确性（能用脑子想到并解决的，总比最后做一半的时候碰到再解决，省时间多了）
• 评估中觉得不确定性的东西，会影响结果但一时找不到解决方法的，一定要记录下来，由专人负责沟通和解决这些问题。

 

虽然大多数时候评估并不好做，但我个人建议还是要尽力做好它，因为我确实接触过一些管理者，他们建议采用”敏捷“的一些开发模式的原因之一就是想尽量避开估算（因为需求前期不清楚啊），说实话，我个人的经历其实让我觉得这是一个挺大的误区，”敏捷“能够帮我们来减小估算没有做好情况下的风险，但由它来”避开“估算，项目的风险，在大多数大点的项目中，很难解决。。。所以我在后来的项目中，不管使用什么开发模式，对于估算的要求，都是很高的，这有点像是开发模式中的”概要设计“，由它来进行最初层的风险控制，而不是全都交给开发阶段来做。

 

注意需求”文档“

在公司早几年的时候，我在我的团队中，推行”敏捷“开发的一些思路和方式，有的时候，感觉确实在做好了风险分析和评估后，效率什么的，会大大的加强，但是吧，因为整个公司范围内不是全部推行的，所以，个人感觉良好，但对项目的推动作用，还是有限的，只局限于我们一个”角落“。我也尝试在整个公司建议过，但是因为我们是一家跨国公司，工程师团队分布在三个地方，”敏捷“中要求的很多沟通，成本确实很高，所以，大家全都不是很放心，一直没有推行成功。

后来，在我们公司后来来的新的CEO Austin的大力支持下，我们开始了一个量身定做的”新“敏捷模式：iDev2.0

先来说说Austin吧，他算是一个很有经验的老PM了，在来我们公司当CEO之前，曾经在5家上市公司当过不同level的PM或Director ，管理过的人数最多时，得有上千人了，他根据RUP和他自己的经验，设计出了不少根据不同公司特点的开发模式，对于我们公司的特点，他设计的模式命名为iDev2.0，对这个模式，他是这样定义的

• 将整个产品过程分成四步
  • Phase 1: Should we do it?
    从商业机会上来分析，我们是不是应该做这个项目，做的好处大概是什么样的，cost大概是多少
  • Phase 2: Can we do it?
    从技术和团队的角度来看看，我们有没有办法来做这个项目，特点重要的是
    • 技术上的风险点要在这个阶段全部解决
    • 团队上的不足点，要在这个阶段全部解决
    • 风险点的测试和重要功能模式的测试，也要完成
  • Phase 3: Construction
    这时候，技术上的风险点全部都验证完成了，剩下的主要工作是
    • 代码进一步完成
    • Bug的修复
    • 系统测试
    • 准备交付
  • Phase 4: Deployment
    这个阶段的重点是交付，包括文档，代码，配置环境。。。
• 每一步都按照最长2周这样的迭代周期来做，每个迭代周期要求
  • 每个周期要将风险点功能提前完成
  • 每个周期的功能列表提前定义
  • 每个周期的开发交付物必须是可运行的build，不能是文档或代码。
  • 每个周期的build，必须经过测试，而且，重要的bug必须要修复后才能宣布周期结束
  • 本周期所需要做的功能，需要在本周期前确定，但不需要在项目一开始就确定。
  • 每个周期最初阶段的沟通工作，要加强

其实我相信有过跨团队工作经验的人，会觉得这个就是为跨地区团队设计的一个”敏捷“开发模式，看上去它：

• 保留了敏捷的一些特点，比如
  • 持续交付
  • 欢迎需求改变（每个周期前改变，都可以）
  • 可工作软件是首要的进度度量标准
  • 有利于自组织团队的形成
  • 简化了一些工作，不必在开发开始前就想好一切，可以随进度开展再来调整
• 让跨地区团队的敏捷可行性高了些，比如
  • 业务人员和开发人员天天在一起不可能时，每个迭代周期前可以充分沟通
  • 面对面交谈耗时太大时，至少周期前沟通，然后后面大家都有足够的时间来coding和做相关的工作

虽然当时我觉得这个新的方式真的挺好的，而且因为是CEO推广，所以整个公司上下都开始采用，这个方式真的是大大的提高了不少原来不太好解决的问题。。。说真的，效率的提高和风险的控制，确实有很大的帮助。但这个过程中，也发现了这样一个问题，就是沟通最后还是容易脱节，脱节在哪呢：文档。。。

可能大家觉得文档在敏捷时，不应该是弱化的吗？但说实话，带队这么多年，做自己的产品时，文档其实在以下几方面，重要性可不低

• 项目多部门合作时。
• 大部队的测试团队没有及时跟近，后期才介入时。
• 员工离职后，技术被带走时。

为什么在CEO推行iDev2.0的情况下，文档上还能出问题呢

• Product manager们其实都挺忙的，以前写文档给的时间多，现在这两周两周的压力，大家写文档的时间少。
• 使用迭代式之后，前期的思路容易不准确，后面要改，一改又影响开发。影响了开发后，又影响测试；因为这些一连串的影响，如果文档速度要慢下来的话，对效率的影响，就非常直接了。
• 因为改变的会比其它的模式下多，所以事实上文档就算前期写了，后期改的也多；文档不同于代码，如果有什么地方前后没有衔接上的，对于几十上百页的文档来说，如果没有专人负责，就容易出现不一致的情况，也容易导致后续的步骤出现问题。

因为，事实上在后期，当大家对于iDev2.0越来越接受的时候，对文档的抱怨很直接了，相关的人对这件事讨论了好久，最终大家似乎同意增加对文档维护的力量，但事实上做的也不多，因为别的组做不了，Project 和 Architecture组的人又太少。

之所以我们并没有完全采用故事墙的模式，当时确实实践的过程中发现一些问题

• 我们的需求文档中，有技术的东西在，有的不太容易用故事来说明
  虽说这是一个不太”对“的事，但因为一直做的是公司自己的产品，所以，需求文档中也是一直习惯加入技术分析的内容
• 故事墙的模式对于面对面沟通的要求过高
  没有面对面的沟通，只是拿到了有限的故事墙上的信息，对于远程的团队来说，不是努力不努力的问题，确实容易出现理解上的偏差，这种偏差，有的时候，在后期产生的影响是巨大的
  （User Story 需要的是：Card, Conversation和Confirmation）
• 故事墙模式对于状态多的产品，复杂度一点都不低
  对于我们的产品，有不少地方要根据不同的条件，有不同的组合结果的产生，故事墙模式最后看上去，也没省多少力，而且，事情都是这样，只要一多，整理和管理起来就乱了，而且也容易出错。

后期的讨论中，我们商量过使用Jira和一些商业软件来进行需求管理，我个人很喜欢Jira，对于跨地域的团队管理，其实相信它能够给的帮助挺大的，但有几点不太好弄的地方

• 原来的需求要导致Jira，工作量巨大。
• Jira也需要人来写来维护，人员和时间上的要求，一样挺高的。

 

所以，后期我在我的团队中，推广的是几种文档模式的组合模式

• Requirement Matrix
  类似User Story，但在它的基础之上，用思维导图的方式，列举出相关的条件，和可能的结果；（这里面参考了”探索式测试“的一些思路，重点将输入输出，状态，代码路径等考虑的全一些，这样，不仅仅是在探讨新的需求，同时，也在探讨新需求对于原系统可能产生的影响上，有不少的参考价值），同时，因为思维导图的模式文字量小，而且相对word，也易于维护；
• 代码注释让文档易于维护
  其实好多的文档都碰到这样的问题，项目忙的时候，老文档很少有人维护，但一旦不维护，用不了多久，参考价值就会降低。所以有不少人都提倡：”代码是最好的文档“，这样一种概念，对这种概念，在看了很多文档不同程度的过期后，我也算某种程度的支持吧，因为有的时候文档要真没时间维护，过期的它反而会更容易让人产生误解。
  但我也知道，这句话其实也有问题，要是几百万行代码中别人想找出东西来，太难了，所以，我要求团队
  • 架构图要一直更新，这个因为工作量相对小，所以要求严格
  • 每个component 对外接口的注释，必须要清晰，Code review部分，对这部分的注释，重视程度要极高。
  • 每个Component都要求一份类似Requirement Martix的文档，Componet需要处理的输入输出，状态，错误处理等，如果有所改动，要求必须更新。

当然，我之所以在这里提到了文档，还有另一个原因，我们公司后来”变革“的时候，走了好大一批人，文档没有做好的Team，其实说白了吧，什么开发模式也解决不了后期大家需要花大量的时间来重新学习这个过程，所以，良好的文档化对于公司自己的产品来说，不光是为了项目的运行，还有人员流失的风险。

 

选择合适的模式，而不是”最先进“的

在我开始在团队内部小范围推广”敏捷“之前，其实公司在US总部也做过类似的事情（07或08年吧），特别好玩的是一个War-Room的尝试（没有别的公司的人，全是自己公司的），当时其实大家觉得结果挺成功的，但后来没有继续下去，问到原因时，告诉我的是成本太高了。。。

我当时还觉得奇怪，怎么会成本太高了呢，如果速度能起来，其实成本应该是低了才对啊，当时我的US老大给我的解释是

• War-room的人要求专注，也就是干不了其它的事了，对于一个”大“公司来说，这些个精英全专注到一件事上了，要是时间短还行，时间要长，别的地方就耽误了，灵活性确实不够
• 不一定能如期完成（当时尝试的例子，其实主要也是因为没有真正意义上的如期完成，所以也有一些反对声音的）。。。敏捷开发模式不一定能保证开发按时完成的例子，网上应该也有一些资料和讨论了吧。。。因为当时公司的要求就是在一个很短的时间内完成项目，所以，因为这个目标没有达到，所以，虽然这种模式很叫好，但是，也没有完全的达到”要求“
• 质量控制不好做：估计听到这个的人会觉得挺奇怪吧，也可能是当时管理这个项目的人的能力问题吧，但是因为我们的系统挺庞大的，所以，war-room里虽然有十几个精英，但是也不可能想的特别的全，所以，后期的质量上，也确实出了一些问题

当然，我到觉得敏捷很好，因为

• 持续的高效率的完成高质量的工作
• 项目计划有弹性，在一个死板的公司中，项目提前的可能性要大的多
• 团队容易感觉到被信任感，氛围会好很多
• 团队的技能会多样化，而且工程师的成长速度快
• 团队对于产品的理解，能达到一个较深的层次。

当然，说到这，大张旗鼓的推行敏捷，其实在当时阻力也不小，因为新的概念一出，很多人要么不认可，要么不知道，所以，阻力和质疑很大，所以，我选择的是暗渡陈仓的模式，在下面的几个点上来推行

• 内部迭代
  我们组在没有实行iDev2.0之前，就开始执行这个，以周为单位
• Daily Standup meeting
  在这个meeting上，只讨论一下进度，15分钟为限，让大家能够快速的sync up一下；同时，对于很多人来说，在这个meeting前完成任务，也成了他”被逼“要做的一件事。
• 尽快集成
  当时虽然没有提到一定要什么时候集成，但是我要求凡是code review都要是集成和测试后的review，这个，让集成的频率，在当时算是很多的了
• 项目总结评审
  当时虽然没有全都做，但是关键模块的总结会，包括很多技术讨论会，我的要求挺高的，而且
• 任务看板（Excel版）
  这个任务看板虽然在后期，大家觉得越来越”沉重“，但是在初期的时候，收到的效果确实不错；后期越来越沉重的原因其实也简单，”权利“上的政治斗争因素，越来越重了(这个就不提了)。。。

 

但是，说实话，这些年的工作经历，也让我学会了一种思想方式：就是根据情况选择最好的模式，而不是所有情况下都套用一种模式。。。在软件工程这件事上，其实不少种方式都可用，而且有的模式，对于你想要的东西，没准比先进的东西更高效。

当然，之所以我将开发模式放到这么靠后来谈，主要是因为，我还是建议大家，重视之前提到的东西，避免”常见“的失败的例子，控制好项目的风险点，做好评估，这样，再采用了合理的开发模式，起到的作用就会大好多了，而且，项目的成功率也会大好多。

之所以我提了好多”敏捷”，也说明了我对他很喜欢，但确没有直接的建议一定要使用敏捷，主要是因为开发模式的种类挺多的，而且每种开发模式事实上都有其优点和缺点

 

先来说说我所了解的开发模式的大概分类吧

• 以软件需求完全确定为前提的瀑布模型。
• 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型
• 以形式化开发方法为基础的变换模型

所以，选择什么样的开发模式，不妨从你现在有什么来做为依据进行选择

• 纯瀑布模型
  现在采用纯瀑布模式的公司可能越来越少了，但其实，这种模型在易于理解，但相对复杂的项目中，有着天然的优势，就是周期可控性强（有时候就算不能在大的项目中完全采用，但在项目的某一部分采用，优势也明显）
  • 适用于：易于理解但复杂的项目。
  • 缺点：缺少灵活性。
• 螺旋模型
  这是一种以风险为导向的模型。
  • 兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控，使软件在无法排除重大风险时有机会停止，以减小损失。
  • 快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法，每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。
  • 强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统
  • 模型往往适应于内部的大规模软件开发，对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更。
• 基于构件开发的模型
  • 一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径
  • 与目前的微服务思路，有很多的相似处
  • 面向服务（SOA），远程组装等有不错的优势
  • 对于开发和测试相对容易，而且在一定程度上容易保证产品质量
• 智能模型（基于知识的开发模型）
  • 瀑布模型与专家模型的结合，对于涉及大量专业知识的领域，有很好的作用
  • 开发人员一般不是这领域的专家，对特定领域的熟悉需要一个过程，所以，需求在初始阶段很难定义的完整。
• 增量模型（和目前的互联网的模式，很相似）
  • 融合了瀑布模型的基本成分和原型实现的迭代特征。
  • 本质上是迭代的，但要求每个增量发布一个产品
  • 这种模型人员分配灵活，刚开始不用投入大量人力资源
• WinWin模型
  • 强调风险分析和标识，使开始人员和用户对每个演化层出现的风险有所了解
  • 主要优点是客户和开发者能达到一种平衡，实现双赢，但需要额外的谈判技巧
• 原型实现
  • 最大的特点是能够快速的实现一个可实际运行的系统初步模型，并逐步求精的来完善
  • 一定程度上限制了开发人员的创新，不容易考虑整体性和长期维护
• RAD（强调极短开发周期）快速应用开发
  • 使用大量可复用的构件来进行快速开发
  • 使用自动化软件工具来辅助软件创造
  • 对信息系统很有效
• RUP
  • 渗透了以下一系列思想：迭代式开发，管理需求，使用构件，可视化建模，重视质量，控制变更
  • 四个阶段：初始阶段，细化阶段，构建阶段，移交阶段。
  • 做为大中型软件开发很合适，但对于小团队小软件，过于复杂了。
• XP敏捷方法
  • 采用用户故事替代需求分析
  • 简单计划策略，不需要长期计划和复杂模型，开发周期短
  • 全过程采用迭代增量开发，反馈修正和反复测试，软件质量有保证
  • 能够适应频繁的需求变化，提供用户满意的高质量软件。
  • 对于大中型软件，风险性大了些，特别是沟通和文档上的要求不同。
• 第四代技术
  • 通过规范自动生成代码
  • 目前成熟度还偏低。

在这么多模式下，个人的建议是，看看你要做的项目的情况吧，就像上面我提到几次的iDev2.0，其实就是RUP，敏捷，加上螺旋模型的，再根据我们公司这种系统比较大，开发速度呢，也要求比较快的公司来定制的。虽然中间出了不少的问题，但是，大方向，我到觉得值得支持。。。

当然，我同样也会建议大家，就算你的团队所做的项目并不完全适用敏捷模式呢，但你也不妨碍在小范围内使用，因为这个对工程师的成长，帮助很直接，一支有战斗力的团队，才是项目成功的最重要因素。（我个人，不太同意”码农“和”软件蓝领“的概念）

 

出问题了，也不要怕

提到这儿，我也不知道我的团队的人有没有机会看到，我到真的要真心感谢一下他们，因为谁也不会说参加或主持的项目，没有出过问题，出了问题后，其实是很麻烦的，各种压力会随之而来，但我过去带的几个团队，在关键的时候齐心协力，帮了我们很多的忙。

所以，下面我可能会给你一些建议，来解决这些麻烦，但前提是：你的团队够强大，心够齐。。。

• 项目需求不明晰
  介绍完项目软件项目管理周期模型后，可能大家会觉得，需求初期不明确时，原型啊，敏捷啊什么的，都可以来帮助解决，包括我介绍的iDev2.0，其实中间也有相当的部分是来看如何解决这部分东西的，但其实参与项目比较深的人都会发现，需求的不明确，有时候并不完全是这些模式能够解决的，很多时候，需求在初期不明确不可怕，可怕的是到后期，直到被用户发现问题的时候，才”不得不“明确时，对项目的影响就变的非常直接了。
  我参与的项目中最差的一次，大概是几年前吧，项目到后期，到客户那出了一堆的问题后，发现这些都是当初需求讨论的时候，没有考虑到的，又重新对这些”bug”定义需求，根据需求呢，安排“改bug式”的做新feature, 弄的最后项目上上下下都很难受。。。（测试时干嘛去了？好问题，后来也因此，改变了不少测试的管理模式，别的blog里再来聊这个吧），在这个项目之后，对于项目成败的关键，我们改变了不少工作方式来解决它，如果你也碰到了同样的问题，不妨从现在开始，就试试底下的这些方式吧
  • 从“人”的因素上，重视需求
    其实好多时候，需求的不明确，都是来源于大家不愿意沟通这事，因为之前沟通的时候，产生过各种各样的问题，所以后面干脆不愿意沟通了。所以，如果你的团队发生了这样的问题，将是一个大的问题，这时候，作为管理者，直接参与进沟通环节，在这方面不单是要加强大家的意识，而是要直接给出帮助，做好带头羊。（有时候，“口号”在这时候，起到的作用可能会有限了，不是说你重视质量等等这些口号，大家就会真的信，或真的）
  • 需求的确认方式，用理论让它更合理和有效化
    其实我挺认同敏捷模式的这样一点，就是“Card”—>”Conversion”—>”Confirmation”，但团队的管理中，我也发现这样一个特点，如果US来了一个需求，Conversion更像是中国团队在听US团队在变，而且”Confirmation”更是很被动，听完后就同意了，或有时干脆是“默认”的。这样，最后的结果是，沟通也沟通了，但需求其实只是“被”明确的，这样就变成，只能到后期再来补充，而且是发现问题之后再来补充。
    如果你的团队也发现这样的问题，其实不妨加强团队的一些测试理论，用一些“测试方法”来测试需求，这样，你会发现有好多问题在Confirmation之前可问，这些问题就算现在不能解决，但只要记录下来，也不至于跑到最后期，被用户发现时再返回来讨论了。我在开发团队中提倡使用探索式测试的一些方式来测试需求，后期让需求这件事，变的容易的多了，直接的体现就是，工程师本身对需求细节部份的问题，多了不少，直接让”Confirmation“的质量高了好多，提高了需求讨论这部分的质量，为后期的工作，打下了不错的基础。
    
• 设计上过于先进
  这个例子要差不多三年前了，当时我们US的Architecture叫Tom R，这个人是个对技术非常热钟的人，和他的合作，真是痛并快乐着，他的Review，是我所接触过的人中，最细最深入的一个。当然，对于不少工程师来说，这个哥们可就是很”可怕”的一个了，在他手里，有的人的 code review，两周都过不去，即使这code，在别人的眼中，早就成为Perfect的了。。。对于项目管理者来说，也是挺可怕的，因为他不100%关心项目进度，这时候也很为难，因为工程师这边的东西，也确实是不能在埋怨了，大家做的足够好了其实（至少从项目管理的角度来说，这代码质量足够好了）
  记的最清楚的是他在JCC中推行无锁化Java 代码，这个idea可能是从NoSql 中学到的吧，这个确实会减少很多影响性能的因素，但是在一个已经存在的近30万的代码中，做这样一个要求，其实难度相当大的。我们的工程师苦不堪言，项目进度呢，又越来越难保证，并且大伙的情绪也是越来越低，因为工作太难干了，其实这非常类似之前提到的”设计镀金“式的麻烦，当时解决这个问题，用了以下的一些”小技巧“：
  • 对内：
    • 和工程师们多介绍一下这个人在各方面的厉害之处，不为别的，如果双方对于各自己的优势能力都认可，沟通起来，就容易的多了，沟通对于这种情况的重要性，极高的
    • 多谈谈自己对质量的看法和重视程度，同时，也从”工程师“的角度，来谈谈重视质量对于职业生涯的重要性。大家重视质量，沟通起来，隔阂也会小的多。
    • 答应大家会帮助来解决这个问题（让大家觉得你和他们站在一起来解决问题，很重要）
  • 对外：
    • 加强和对方的私人关系，虽然不必过近，但是有些私人关系，会让工作，容易起来。
    • 认同质量的重要性和对方对于质量的要求是值得推荐的（你要是表现出不认同的态度，阻力就肯定会大的多的）
    • 对于项目的Schedule的压力，也和对方聊聊，看看对方的建议是什么（虽然有的人表达方式不一样，但好的工程师没有不关心Schedule的其实，除非他真的觉得，Schedule的事，他可以解决）
    • 建议对方在某些方面加强要求，但某些方面，记录下来日后改进（而且，记录和Track的工作，由”高层“直接负责）
• 矛盾和冲突
  讲项目管理模式的时候说矛盾与冲突，这个看上去似乎有点跑题，但是带过项目的人，都会理解，要是矛盾和冲突解决不好，那管理模式也会大打折扣，失败的概率高大多了就，来说说我碰到的矛盾和我当时的解决方法吧（当然，对这点，我的心得是，如果矛盾发生了，不要觉得说教能够真的解决它，最好是初期就深入的参与，越早解决越好，如果拖到了后期，其实可能是不能真正的解决问题了；同时，当发现了苗头后，不要轻易的在双方争执的点上下结论，因为双方都觉得有道理的时候你下的结论，可能埋下更深的种子，以后更能解决）
  • 项目管理者和关键开发人员的矛盾
    这些年来，我团队中其实来来往往的工程师也不少，有的工程师离开了，挺可惜的，但是大多数时候，我还挺平稳的，因为”铁打的营盘流水的兵“吗，但也有特别可惜的，我们团队中的原来的原老之一的离开，对我来说，心理上的打击就要大的多了，毕竟，当时可是一块”出生入死“的人。
    他的离开的原因挺简单的：”他和PM之前的冲突“。从他的角度，认为PM管的过宽，导致他要做很多paper work来满足PM的要求; PM的角度其实也对，因为Paper work虽然不少，但是对于项目的安全性，是有作用的。他的离开其实让我惊醒了很多，有的时候，工程师愿意在这里工作，并不是真的因为你给的工资够高，而是因为你的环境对他来说，是合适的，如果你的环境不在适用于他了，那么，离开你也很正常了。。。而且，其实凡是在找自己适合的工作环境的人，而不是只为钱多少的人，往往都是有想法，有目标，而且，效率最高的。。。
    所以我也没法说如何解决这些矛盾，只是给出自己的一个建议：如果你的团队中有这样的人，做为管理者，不管是人员管理者还是项目管理者，根据人的情况做出应有的协调来，这个对于当前项目，对于长远项目，都是有利的；而且说实话，对于一批自我管理能力很强的人，很多管理方式，其实都应该做为服务方式，这样反而效果会最好。
    所以，我在这件事之后，花了不少时间来根据不同工程师的特点，来调解管理者根据工程师的特点来进行管理方式的”裁减“，当然，最好的方式其实是让一些管理工作下放，让自我管理和自管理团队在小范围内工作起来，矛盾就少了不少。（我对控制欲望较强的管理者的建议是：根据不同的团队的特点，进行一下控制力的裁剪，是很必要的一件事，否则，团队初立时顺利的事，团队成长起来后，反而会越来越难办）
  • 中国和US工程师之间的矛盾
    中美之前的文化差异，其实这种矛盾，到真的很正常了。。。当然了，其实不少和美国人接触过的管理者都会发现，大多数美国人特点很鲜明，所以，接触起来并不难，只要掌握好几个点就好弄多了（当然，做为管理者，需要将这种风格，也和你的团队能够介绍的清楚些，这样，了解对方后，再来沟通，矛盾就会少很多了）。。。当然，也需要具体问题具体分析，因为毕竟几十上百万人的工程师团体中，个例或什么的，还是有的
    • 直爽
      美国人的直爽，并不像山东大汉一样，有什么说什么，而是说，他们在需要提出意见的时候，会提的非常直接，并且希望你给出解决方案来（当然如果是日常的事，他们其实尊重个体，所以，大多数人并不喜欢参与细节）。。。这个对于不少中国的”等待“式的工程师，会觉得别扭一些，对方提了要求了，但是有时候并不说明如何去做，只是靠着一堆的流程来进行约束。
      所以，这个要解决起来并不困难，在和US的沟通过程中，多培养你的团队提自己想法的能力，如果目前团队还没这么成熟，你就要参与提想法，然后让大家去沟通，这样，信任关系一旦建立，后面的事情就容易多了（我的团队在后期，其实US和中国的沟通，大多数时候都不需要通过我了，团队之前的沟通问题解决了，效率会大大的提高）
    • 喜欢夸奖
      美国人在这点上和中国人的差距，就真的明显了，美国人善于鼓励别人，特别喜欢在任务完成后，来说”good”, “perfect”, “fantastic” 之类的话，如果对这点上没有理解的很透，其实没准在工作上，会进入误区，这点上，要和团队来解释清楚这种不同，比如：对方说good，其实背后的意思是还有改进空间；Perfect呢，也就是相当于中国人说的挺好；Fantastic呢，才是差不多的类似中国式的夸奖。当然， 这些词语，其实都是对你的认可，因为美国人虽然喜欢夸奖，但大多数时候，都是真心的，不做假。理解了这些东西，让大家明白不要自傲，会对未来的合作，有利一些。
    • 注重员工个人和家庭
      美国人很注重员工的人个和家庭生活，我的团队中如果有谁家里有事需要照顾，美国的老大们有时候给出的照顾，我们都觉得难以理解，有的工程师家里老婆生的是慢性病，美国老大们建议中国的管理层每周给这个人两个半天的假期来照顾家人。美国人本身也是，工作之外和家人在一起的时光，是很重视的；这种情况下听上去是好事，但是有时候，员工在和美国管理者接触后，在和中国的管理者接触，会不喜欢中国的管理，让我们这的工作不好做。这时候，平衡之术就很重要了，第一要认可美国式的管理，员工需要的，尽量来帮助解决；第二要让大家看到，中国式管理对大家未来有好处，特别是：没有富人的钱，但有富人的病，其实风险还是在我们自己这边的。
    • 对质量有着很高的要求
      这应该是很多美国工程师共有的特点了，质量上的“苛刻”其实是很多刚加入美国公司的人体会到的最难处理的一件事。。。在这点上，我到真没有别的可说的，让团队意识到这点的重要性和好处，是中国团队管理者需要做的一件事，毕竟，这点上，大家要明白，大多数时候，美国工程师是不会让步的。在这点上的冲突挺难解决的，最好的方式，就是让对方看到，你对质量的要求，比他们更高。。。
    • 固执
      其实我发现，有时候中国人也很固执，但是，有时候吧，我们可以通过换种方式来解决；但美国人的固执不同，不容易通过其它方式来解决；我经历过的固执的美国人里，有的因为技术而固执，有的因为权利而固执，这个确实是很难办的；虽然通过一些方式能够解决一点，但是我建议，大家最好能够在合作的过程中也了解一下每个人的特点，然后不要轻易碰这个领域，因为碰上了，往往会产生不小的麻烦。
      当然，因势力导也会帮你解决一些个本来很难解决的东西。。。
    • “狠”
      这点上，其实最近的很多裁员啊等等的消息应该也能警醒一下中国的工程师了，其实我个人的经历算很直接的，US在公司裁员的过程中，前一天还在对中国团队大大赞赏，后一天，就出现了大范围的裁员，让很多人措手不急；这点上的对策其实也简单，就是不管对方说什么，大力的提高自己的能力吧；因为只有这样，双方才真正是平等的。
  • 团队中关键工程师的矛盾
    其实这就是一种快乐的“痛”，很多时候，如果你的团队中，真的有几个关键工程师的时候，你应该是幸福的了，但如果这几个人要是闹来闹去的，还真的挺麻烦的
    • 技术上的矛盾
      技术上的矛盾，有的人可能觉得挺好解决的，但事 实上，这从某种角度来说，又是最难解决的一件事，因为大家都会认为自己技术上是对的时候，这个时候，如果对于管理者来说，没有足够强的技术背景，处理起来确实会挺难的，这种情况下，我建议的解决方案有
      • 如果管理者有足够的技术能力：参与进讨论，并且和大家一起做出决定来；这条路如果走的通，事实上对于团队建设是个很好的磨合作用。
      • 如果管理者技术能力偏弱：找一个第三方的人，技术很强的，参与裁判（如果是外资公司，最好是由外国人来做），并共同拿出一套方案来。
      • 忌讳：不懂装懂式的下结论；人情式的下结论；不讨论就下结论；
    • 性格上的矛盾
      其实这种在团队中更多，有的人天生活泼，有的人天生沉闷。有的人喜欢风头，有的人只喜欢呆着。。。这样，性格原因，导致平常的一些小事就会积蓄很多矛盾，等到真正共事的时候，这些矛盾可能会体现在工作上，不管管理者多么的强，也不可能团队中所有的“小事”全都知道，所以，出问题时，可能会一釆雾水的
      这时候，我的建议是
      • 管理者本身要真心的接受所有不同性格的员工，你要是有偏见，底下就会真的控制不住。
      • 体现出你的公平来，以事情为目标的风格，在团队中要养成，这样，大家关注点是一个的时候，性格问题会减弱很多。
      • 出现问题时，和大家在一起时，更加平和的讨论解决方案，不要轻易的因为压力而下判断，让大家把话说出来，但是前提是，以解决事情为目标。
      • 出现问题后，1-1的和双方聊聊，认可对方的做事方式，同时，介绍一下对方的性格，争取互相了解的多些，（同时也建议，为了工作，双方各让一步，但这话要根据情况再来看）
    • “权利”上的矛盾
      这是最难解决的一件事，对“权利”欲望重的人，有时候和别人产生矛盾后，很难以解决。在这件事上，我见过不同风格的manager，比如，如果出现这种问题，有的人会给大伙分成不同的组，把能闹的放到某个组中当leader；也有的会淡化或边缘某个人，最后导致这人的离职。在这件事上，我的建议是
      • 对于能闹的人，要重视，因为对“权利”有欲望的人，才会有动力，动力足的人，产生的正面作用，如果引导的对，会是相当高的。对于他们的想法，如果是在可控制范畴内的，更多的加以鼓励，没有坏处。
      • 不要轻易使用提拨来解决问题，让事情“看上去”解决了。能闹的人被提拨，往往是很多管理者的一种做事方式，但说实话，这种方式大多数时候就是又埋了一个更大的雷，在以后。当这个雷爆炸时，可能你原有的其它的和平，也会被打破。。。定下来提拔的标准，真心的帮他们达到这个标准，达到了之后再来提拔，才是最好的解决方案，这样
        • 他的能力足够了，团队的认可度也高
        • 你们在这个过程中，也有了足够的信任，这种信任，会大大的降低风险。
  • 管理者之前的矛盾
    其实不少时候，公司里最大的损失，是管理者之间矛盾的损失，做成了管理者，其实大多数时候至少个人沟通能力相对就较强了。我所见过的管理者之前的矛盾，主要在两方面
    • 不服气
      其实这种不服气，更多的时候，就是大家从一个事情的不同角度看问题时，看到的不同的方面，然后就有了自己的见解。这些见解呢，如果沟通的不到位，就会出现互相不服气的局面，这件事，其实有利有弊
      • 利：一种良性的竞争，会让各种不同的方案都浮出水面，而且大家会尽力的来试（赌气嘛）
      • 弊：如果沟通过少，这种不服气，容易形成“看法”，最后，当真正需要合作的时候，就会出现问题。
    • 权利
      人可以向上走，但得到的东西，又被拿走，将会是巨大的心理落差，这种情况下，产生的矛盾很可能是不可调和的。在这里，我的建议挺简单的
      • 我们不要假设这个问题是可以轻易调和的
      • 我们不要假设通过制度和流程就可以解决这个问题。看上去制度可以解决问题，但因为制度是人来执行的，如果不能面面俱到的话，就会出现执行时的互相掣肘的情况。
      • 如果双方的能力足够强，最好的方式就是各自负责各自的领域，但通过沟通，来让双方进入“良性竞争”
  • Boss和工程师之前的矛盾
    可能很少有人会觉得，boss和工程师之前，差着中间的几层呢，会有什么矛盾啊，但这种情况，也确确实实的存在，相信在很多需要做Line manager管理的管理者来说，都会发现这样一个问题：如果员工对公司最高层不认可，底下的工作，基本上白做，人员流失解决不了，积极性不高，也解决不了。。。（对于工程师和Boss来说，矛盾往往出现在以下几点 1. 工程师认为老板不尊重工程师；2. 工程师认为老板抠；3. 工程师认为老板说话不算话。。。老板对于工程师的看法呢，其实对于真正的资本上层来说，也有这样一些说法：1. 工程师不重要；2. 我是发你工资的，你要尊重我，并听我的；。。。怎么样，看上去，矛盾不容易调和吧）。。。所以，说实话，中层管理者，管理任务之一，也是管理“Boss”，或者说，工程师可以不认可Manager，但是不要轻易让工程师不认可Boss.
    在这方面，如果我们发现了问题，我建议中层管理者能够花更多的时间来处理它，能够让双方的”利益“真的能够在一起，否则，这个矛盾，会是最大的一个风险，不管你有什么样的团队，事实上也经不住这样的考验，对于这个问题的解决，我的建议是这样的
    • 与老板关于工程师的沟通，多些（形式也要多样些），这样，让老板有机会更多的认可工程师，这样，出现问题时，老板也容易理解和接受。
    • 对于能力较差的工程师，或有其它问题的工程师，不要轻易姑息；因为有时候，老板们的政策，会因为这些人或现象而有所”固执“，产生让大多数人不理解或不认可的政策或行为，这点上，例子太多了
    • 与老板更多的沟通，以结果为导向的政策机制，管结果的政策多于管过程的政策，因为
      • 大多数好的工程师其实是有自己的想法和要求的，如果这样提倡，其实工程师团队的支持和积极，反而容易越来越好（真的有点像”太阳和北风“的故事其实）
      • 在赢利保证的基础上，给出工程师最大的空间，技术也好，发展空间也好；而且，宣传上，这种空间要提高，这样”志同道合“的人，才会真正的为这个空间而贡献自己的力量
      • 不要轻易说我们这的工资，给的足够高了；这话，其实越是优秀的工程师，越不爱听。。。
      • 定位好自己的核心竞争力，然后推广它”阿里擅长的是运营，腾讯擅长的是产品，百度擅长的是技术，这就是公司的基因“，你公司的基因是什么，会决定你公司能留下什么人，而且这批人会为这事努力工作的。
    • ”别太假”
      所以把这点单独拿出来，其实主要是想说明这样一个很重要的事，就是好多”矛盾“，其实就是因为工程师感觉自己被”骗“了，所以，很多事，其实就算不承认一些失误，也不要轻易的用”遮儿“过去的方式来做。因为目前的工程师团队，也因为社交软件的流行，有了自己的圈子。最后，事情反而会越弄越差。。。
• 进度跟不上了
  我把这个，叫做天天发生的事情，有好多公司，进度跟不上了，就会玩命的加班，加班后呢，进度也未必跟的上，然后再加班，最后，恶性循环后，可能会因为一点小事，多米诺牌倒掉（最近听说过展讯公司的一些情况，因为一个Leader长期的加班，导致猝死，结果几乎整个公司的工程师，全在外面找工作，走了一大批的核心，弄的后面的项目，更加的困难了）。所以，为了减小相关的损失，在这种情况下，我的建议是
  • 进度跟不上时，最好是从技术之外来看看，是不是有解决方案（12306的问题，估计很多人了解一些了，定票网站刚一上线时，因为用户量的巨大，导致很多人，根本上不去，当时就算用了最先进的技术，也没有真正的解决问题，后来，将需求改成分时段的抢票后，效果好了不少了）
  • 核心的事情，一定要做，如果这些都做不完，延期可以接受的；
  • 不要因为不让大家加班，而放弃太多的功能，适度即可：其实很多时候，在项目开展前，就要和大家来宣传质量意识，评估意识，这样，尽量避免因为这带来的加班上的风险，如果很不幸碰到这些问题，也不要轻易的调整导致为了不加班而放弃太多的东西；这不是在惩罚工程师，而是大家要”同甘共苦“，毕竟，一只同甘共苦的有战斗力的团队，才是最重要的，经历过共苦的团队，才会真的强大。

 

其实在这个过程中，真的有挺多要说的，但是篇幅原因吧，不必说的过多了。。。但我确实很想再强调一点，项目和团队，有着不可分割的关系；所以，不管用什么开发模式，保证项目的同时，也要来考虑如何通过这些方式来让团队更加有的战斗力，同时，选择合适的项目运作方式，你会发现，项目的成功，原来不是真的必须花命才能做到的。。。

当然，在这个基础上，我会强烈建议更多的考虑敏捷的应用，因为他当中有乐趣，而且对于团队的成长，有着十分直接的作用。。。

转载于:https://my.oschina.net/LouisYang/blog/418587