前段时间，我做为软件工程顾问支持的一个部门提了一个需求，说希望能有一种方法来度量研发团队的绩效。
我说，我的角色定位是教练，不是裁判，所以恐怕不能在度量绩效上帮助到你；不过，有一点我想特别提出来，以避免你们在制定绩效指标的时候掉入陷阱。这个陷阱就是认为我们做软件就是为了开发特性，做得好就是以很快的速度开发了很多特性。
真相是：做软件是为了满足用户需要。考虑到投入产出比，我们的目标应该是：做尽可能少的特性，尽可能多的满足用户需要。
有人可能会用一些市面上比较成功、同时80%的功能平时都不怎么用的软件来反对上面的这种说法。
我的回应是，这些软件之所以取得成功，很大可能是因为它那20%的常用的功能比同类软件的那20%的功能更能满足用户需要，而不是因为它有更多的功能。（同时，一个产品是否能获得商业上的成功，除了产品本身带给用户的价值之外，也受到达市场的时机、运营策略等其他的因素影响。）
所以，度量做软件是否做得好，看看用户有没有持续在使用你的软件/特性，问问他们觉得你的软件在哪些方面帮助到了他们，他们对你的软件的评价如何，可能更能回答研发团队是否做得好这个问题。
欢迎大家留言，说说你的看法。
END
精选文章
需求定义不清？看这一篇就够了（赠需求分析工具箱和需求文档模板）
“轻松做软件”是IT人的效率公众号，不加班必备
科学工作，少走弯路，快来关注吧！
