注意塑造你的团队风格
如果你说，你的团队比别人好，那理由是什么？因为每个人有突出的专业能力？因为你们懂得很棒的流程？
还是其他的原因？
你有没有遇过以下的问题？
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、根据一些以前没考虑到的场景，提炼改进关键词。