这里写目录标题
最近抽空在家粗读了一般书：《程序员的度量：改善软件团队的分析学》
书点评描述，度量在软件开发中的应用，例如有些公司号称，三个人干五个人的活拿四个人的工资。
这里人数很容易确定，技术也可以通过标准化的考核衡量，那么五个人的工作量怎么衡量，这就牵扯到了团队的管理，对于一个外行来说，无法衡量一个需求的具体工作量，软件系统纷繁复杂，表面上看起来一样的系统，内部实现可能千差万别。
团队管理另一个棘手的问题是人员的考核，现在大部分公司都实行271 比例，末尾淘汰制，从管理的角度看无疑是提高团队的竞争力，但具体实行的时候，一个团队的成员怎么确定那个1.
不同的成员在技术上有不同的侧重，同一个需求，实现起来可以由好几种方式，怎么达成共识，怎么衡量哪种技术方案最合适。
这点很考验管理者的能力。
这篇文章我从一个技术团队管理者的角度分析目前互联网企业或者技术团队的管理工作，对于棘手的问题结合实际经验给出一些方向提示，和大家一起交流。
一、程序员的工作内容
程序员是一个新兴的行业，从个人pc机的普及到目前的互联网时代，不仅仅技术在发展，程序员的工作内容也在不断变化，今后全栈的技术人员将越来越少，更多的程序员岗位将精细化。
目前程序员主要工作内容是 对接产品人员提出的需求，评审需求是否合理，给出实现方案，方案评审通过之后，编写代码，自测，提测，测试之后版本发版。
写代码是程序员的主要工作，代码不仅仅考虑业务逻辑的实现，同时需要考虑性能，新的功能点对旧业务逻辑是否兼容，历史数据的处理，对未来的业务预留接口。
如果是分布式系统需要跟随团队联调，固定一个发版时间。
程序员是产品业务逻辑的实现人员，在领域驱动开发中，技术人员被定义为核心。
但是在中国的物联网企业中，技术驱动、技术创新的公司很少，大部分公司都是业务驱动，直白点说就是赚钱，传统的业务利用网络模式服务。
表现出产品经理的话语权很重，经历过一家产品经理负责的公司，公司所有版本的实现、上线由产品经理负责推动，实践下来就是需求实现不完整，或者实现的需求不是运营想要的样子。一方面和产品经理能力有关系，一方面是权责不对等导致。
作为技术人员，一定得为自己的代码负责，作为开发团队管理人员一定要为自己的团队成员的代码负责。
技术团队管理不是传声筒，也不是产品团队的乙方。
二、程序员的考核
考核制度是公司的一部分，对于员工的考核给管理人员提供重要信息，对于程序员来说，工作内容的考核涉及方方面面的利益，从老板的角度看，希望自己的员工性价比高，技术好，能加班，要求少，从员工的角度看，希望公司氛围好，不加班，待遇超过行业平均。
程序员不同于一般的流水线工人，产出没有办法衡量，当然有些重复的性的代码工作可以衡量，但仔细想写程序不就是避免重复性的工作吗，从目前看，程序员的能力和收入成正比，如果一家公司的程序员平均工资在行业水平之下，那么大概率这个公司的程序员水平在行业平均水平之下。写出的代码质量可想而知。
目前大部分企业的考核是有直属上级决定，这点就涉及个人的偏好。
造成每年考核之后一批人的离职。这对于技术团队来说是不健康的状态，也容易影响氛围。
现阶段看了，对于程序员的考核设置一些标准化指标，例如bug数
设计概要的质量等数据，尽量做到公平合理。
考核的时候，有些上级会询问下级对于其他同事的看法，这也是一种考核手段，但这点对于私下小团队就失效了，如果大家私底下沟通好呢，如果上级考试询问下级这个问题，尽量只夸人。
同时你也要了解，上级的能力不足把控团队的人员。
三、程序员的工作量
《程序员的度量》书中主要用体育明星的衡量做类比，思考程序员的度量，
相对于体育明星在公众下展示自己的技能，程序员更多的时候再角落里默默的写代码，测试可以从成品角度衡量需求是否完成，但是如果你不看代码，你无法准确判断出他的工作量和质量，而且必须是专业的人来review。
但现实是一部分领导的技术能力不足，无法衡量下属的工作量、质量。
作为一个管理者，一定要具备一定广度和深度的技术，对于自己团队成员的代码能够快速review。
通俗来说，就是你的团队成员突然缺失，团队管理者要有能力及时补位。
补位是暂时的，管理者侧重全局的把控，具体的业务逻辑实现不必须亲自参与。
软件行业仍在快速发展，欢迎同行交流。