打造有风格的开发团队

如果你说,你的团队比别人好,那理由是什么?因为每个人有突出的专业能力?因为你们懂得很棒的流程?还是其他的原因?

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

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.根据一些以前没考虑到的场景,提炼改进关键词。

本文文字及图片出自 月光博客

余下全文(1/3)
分享这篇文章:

请关注我们:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注