打造有风格的团队

　你有没有遇过以下的问题？

1.您的开发人员完成了一个功能，只测试了主流程，看起来不错。于是它被标记为完成并转给QA测试。 QA发现了一个严重的bug，只需要在正常流程走到一半的时候点一下取消的按钮。

2.您的开发人员分配到一个子任务，开发一个API，API的需求写得很详细。他很快完成，开始与调用者做集成测试。此时他发现，他做的，跟调用者原来的预期差别很大。

3.还是您的开发人员，他要修复一个Bug.他检查了现有的代码，发现这代码很丑陋。但是要修复很容易，如果他只是希望修正这个问题，只是两行代码的改动。不过代码还是很丑陋，以后要改功能还是**很复杂，除非重构。他默默选择了简单的修改，没跟人讨论。

4.你的QA人员在测试一个新功能，功能跟需求描述是100%符合的，但是他在使用的时候觉得有些地方不顺畅。他让这个功能测试通过。

5.我们的开发人员每次要跑起整个开发环境，都要从4个代码库更新代码，在4个工程里面点构建， 然后再启动3个应用服务器，以及启动数据库。他们慢慢的习惯这样的麻烦。

6.我们有个开发人员，在上海，有个美国的同事，是QA.两人有差不多半天的时差。上海的开发人员快下班了，他手头的功能还剩点扫尾的工作就可以给美国的QA测试。估计还要30分钟。开发人员决定先下班，第二天再继续做。于是美国QA多等了一天才进行测试。但除了这个开发人员以外没有人知道这一点。

7.你的UI开发人员做了一个漂亮的HTML原型，100％展示了设计师要的UI效果。但在原型中使用的UI库跟现有应用程序中使用的冲突。要嘛工程师需要花费大量的时间重构现有代码，或者UI开发人员使用不同的库来重做他的原型。

在以上所有的例子中，有没有人违反流程？没有，除非我们把上面所有的情况写进流程。如果给我时间，我还可以列出数百个流程里面没有规定的情况。所以不可能有一个流程可以规定所有的情况。

　但他们是不是可以有不一样的做法？

＃1，他可以选择将问题提交给QA测试前，完成简单的冒**测试； 也可以选择先像QA尽量跑一下所有的流程，尽量确保QA找不出Bug来。

＃2，他可以选择完全只看产品经理的描述；也可以选择在开发之前跟调用者讨论一下。

＃3，他可以选择尽快修复bug；也可以选择将代码的问题提出来讨论，看要不要重构。

＃4，他可以选择只听产品经理的；也可以选择从用户的角度把反馈提出来。

＃5，他可以选择忍受这种繁琐的手工活；也可以选择建一个脚本来自动完成。

＃6，他可以选择常规节奏按时下班；也可以选择多留下来半个小时，让QA提早测试。

＃7，他可以选择尽快实现UI效果；或者做之前跟开发人员讨论一下。

如果把他们的思路不断抽象归纳一下，就是：总是考虑下游人员的工作，像用户一样思考，改进一切可以改进的事情等等。这些思路，不是专业技能，不是流程，但就是这些思路，构成你的团队文化，让你的团队不一样。新团队一般不**有一致的思维方式，大家的各有各的视角和立足点。

一个训练有素，经验丰富的团队，他们碰到各种场景，一起处理过各种问题，最终他们建立了一种默契。属于团队自己的默契，于是他们花更少的时间就可以把问题沟通清楚；他们可以更快的达成一致的行动方案；他们可以更快的反应；他们可以用更少的尝试找到答案。这是一支有强烈风格的团队，而且很高效！

谁来打造文化？通常是团队的领导者。如果领导者能够进入项目的每一个细节，关心每一件小事。那么，团队每个成员自然而然**去注意每一个细节，因为他们知道他们老大关注这个。如果领导者在做每一个环节的时候，都**考虑下一个环节怎么做，那么成员自然**学着多考虑一步。如果领导者总是在想着怎么提高效率，减少手工流程，时时在问这个问题。成员也**拥有这种思维。如果领导者总是站在用户的立场考虑问题，做尝试，成员在考虑问题的时候，就**像领导一样，问自己，如果我是一个用户，我**怎么样？

　如果想打造有自我风格的团队？试试这样：

1.花时间回想你碰过的所有场景，把那些场景下组员应该怎么想的思路抽取出来，总结成简短的话。

2.这几句话就是你们团队文化的关键词。

3.告诉你的团队这些关键词。

4.往后留心跟这些关键词有关的场景。

5.如果团队成员的思路跟你想要的文化符合，鼓励他们。

6.如果团队成员的思路跟文化不一致，指出来，告诉他们你是怎么想的，后者自己亲自做给他们看。

7.让你的成员以同样的方式这样指导新来的人。

8.根据一些以前没考虑到的场景，提炼改进关键词。

来源：月光博客

作者：王伟杰