建设全功能项目团队-基础篇

申请免费试用、咨询电话：400-8352-114

    团队的开发人员撇开需求沉浸在想象中的“完美”程序中；测试人员迷茫的点击着按钮试图搞明白这到底是个什么功能；设计师造出了没有尽头的楼梯，更糟的是，客户爱上了这个设计；团队领导四处救火，力有不逮。种种迹象表明，我们得打破分工带来的壁垒，建设全功能团队——大多数人能完成大多数种类工作的团队。
    在一次闲聊中，女友的母亲说起实习大夫必须轮岗一年才会进行分科学习，我质疑道：“对于致力于心脏病治疗的医生来说，他岂不是在不相干的学习上浪费了一年时间么？”，她母亲笑着说：“不这么作，你怎么确信病人的确患有心脏病呢？”。不知道为什么，我眼前突然浮现出这样的场景?测试人员在怯生生的询问：“这是一个缺陷么（而不是操作系统/浏览器的限制）？”。

     亚当·斯密于1973年在描述大头针工厂的专业化生产时提出了社会分工的好处：提高熟练程度、减少任务切换时的开销、便于机器的应用。我们似乎可以非常自然得推导出重复设计、重复编码、重复测试可以增加相应岗位员工技术熟练度，提升效率，并由此提升企业的盈利能力。

      然而市场的不断变化让重复生产的美梦不在，切换任务变得越来越频繁。IT公司不是大头针工厂，知识工作者毕竟有别与体力劳动者，在劳动主体发生变化的过程中有两件事情的差异被放大了：一是局部优化与整体优化的差异，二是正确的做事与做作正确的事情的差异。

  有一道数学题，假设每个开发人员每天可以完成一个功能，测试人员每天可以测试2个功能，团队由3名开发人员和1名测试人员组成，那么一周内通过测试的功能最多为多少个？

  大多数人的第一反应是5（天）x2（功能/天）=10功能，下面的表格会告诉你，由于负载不均衡，测试人员在周一没有功能可测，团队其实无法在一周内交付10个功能。

表一）

 那么我们改变一下条件，假设团队中有4个开发人员，并且开发人员可以参与测试，结果会怎样呢？

表二）

我们最终能够交付13点，产量提高了60%， 如果我们只留下三名全能人员：

表三）

居然比3个开发人员和1个测试的人员组合还多交付两个功能！

 我们当然有理由质疑第二题的假设：“开发人员可以胜任测试人员的职位”。又或者继续讨论迭代二的数据变化。我对此的的回答是：

 第一，以我的观察来看开发人员之所以不进行测试工作，不是能力不允许，而是主观上认为测试工作是简单、重复而枯燥的，不愿意作。客观上开发人员们比较贵也更难于培养，组织层面不允许这样的“浪费”。

  对测试工作的偏见客观上促成了大量不具备技术能力的人选择测试工程师作为职业，而技能不足则一步导致了测试工作倾向于简单重复。测试人员在很大程度上无法判断什么是正确的事情（作正确的事），从而更倾向于熟练的按照脚本进行操作（正确的做事）。

  第二，我的关注点不在交付8点还是10点，我希望这个例子能够引发大家对于均衡生产的思考。

  软件的需求和实现可以被细化，但它毕竟不是大头针，需求和实现间往往呈现出关联与依赖，换言之，局部效率的增加无法直接转换为整体效率的增加。而整体效率的优化往往依赖于均衡生产（参考表三），即消除生产的波峰(过度生产)和波谷（生产不足），避免任务时松时紧，松时生产力浪费（周一时专职测试人员），紧时加班加点，粗制滥造。

  我倾向于认为亚当·斯密对劳动分工论述的假设是：需求稳定，简单生产。对于IT领域来讲，这些假设还成立么？

 拧螺丝的卓别林
    不难发现，对分工以及个体效率的迷信已经深刻