如果要以 "产出" 来评价某个角色的绩效, 可以看看这个包装设计的视频:
我们回头来看, 可以问:
· 这些事真的要交给和项目无关的专业人士来做?
· 当我们给专业人士介绍需求的时候, 是否花了足够的时间让对方理解我们要的是什么?
· 专业人士做完之后, 我们要做什么样的QA? 光保证没有明显的语法错就够了?
很多年前, 当COBOL 还是主流商用语言之一的时候, 我曾在一个在软件团队里负责测试工作。职责之一, 是写各种测试用例, 来保证系统的代码覆盖率到达80% 以上。做过实际项目的工程师都知道, 程序里很多语句是用来处理种种异常情况的, 这些情况大多数情况下不会发生。但是这些语句如果没有被覆盖的话, 这个模块的覆盖率就会下降, 我就达不到80% 的目标。所以我花了很多时间构造各种奇怪的测试数据, 把程序中的那些犄角旮旯都尽可能覆盖掉。至于这些犄角旮旯在实际中是否会发生, 对用户的影响如何, 程序是否应该这样设计, 我都不太关心。只要覆盖率达到80%, 老子的活就干完了!
我这几年做了不少内部的技术创新项目, 和许多技术牛人, 领域专家有愉快的合作。有几个项目在演示的时候得到好评, 于是我们就想把它变成实用的工具。这时，项目的重点从“演示酷技术”转变为“解决实际问题”。有时候最酷的技术未必解决了所有问题, 这时我自然就建议用其它技术去补充。但是有些技术牛人反而不乐意了, 几经讨论，我理解了原来有人想使用“纯纯的”，“完全是我自己的” 技术! 至于实用不实用是次要的, 关键是要用“我的” 技术！
问题: 画地为牢的分工
在一个长期而复杂的项目中, 我要求所有新来的成员, 包括外包公司的新成员, 在加入团队的时候, 先找到系统当前100 个数据方面的问题, 并用内部工具修复。我认为这能有效地让新人了解系统的复杂性, 弱点, 和维护的流程。 外包公司的员工很爽快地答应了, 但是我们一些专家反而有不同意见。专家认为, 外包公司的人是来做测试用例的设计, 所以不必做其它事情, 我们期望他们一上手就能设计出高质量的测试用例，不应该给他们那些低级的手工操作任务…