《创业泡沫的“军功章”，高薪低能的程序员分一半》里提到两个观点，我都是很赞成的：1、编程日益简化；2、程序员可以更多的把时间花在编码和思考架构上。我觉得这是个好事情，而且也是社会发展的必然。任何一个行业的蓬勃发展，都需要高度的专业化分工，以及随之而来的大量的熟练产业工人。我感觉过去的几百年工业史可以简化为下面这个模型：
少数天才发明了机器，赚了大钱；
更多的天才涌入机器制造行业，也开始赚钱，
机器越来越多，带动了机器的使用、维护、再制造等一系列行业，整个产业开始繁荣；
产业的繁荣需要更多的人手，不断的吸引人才的加入，直到人才不够了。
这时候，聪明的天才们开始了两条道路的探索：
用机器制造机器，减少的人工的使用（现在很多行业都已经是大量的使用机器人了，你看诺大的车间就没几个人，全部是自动化）
将机器的制造、使用、维护……变得更加简单，哪怕是个蠢才培训一下都能干活（流水线作业，想想卓别林的《摩登时代》吧）
大家对比一下吧，软件行业今天发展到哪一个阶段了？人类社会的发展，是一个永远加速的过程。我很好奇，在我有生之年，能不能看到“程序员就像狗，满街都在走”的奇幻世界。
程序员这个行业，是有门槛，但门槛不是那么高不可攀的。而且随着技术的发展，这个门槛会越来越低。
就像很久很久以前，拜师傅做徒弟学门手艺，入门都得三年；你看现在，把一个农民培训成一个流水线上的产业工人需要多久？我大嫂勉强初中文化，一直带孩子卖票之类的直到40岁，进厂做工人，培训了两个星期，现在还是个小头目。当然，她的工作没什么技术含量。但就算是开车床学挖机，技校培训，连实习上岗，也就最多两年而已。软件行业有什么不一样的？别扯什么算法编译二进制啦，开车床的还需要研究电磁场原理？
所以，这对准备自学成才的同学来说，是个好消息；当然，对已经身处其中的同学来说，那就相当的不妙了！
我这种言论遭到了围攻群殴，其中一个同学留言，“你这样就只能招到流水线工人！”
“咦？！”我拍案叫绝，说得太贴切了！对于绝大多数程序员，你不就是一个流水线上的工人？软件工程师？产品经理还是经理呢！很伤自尊，但我觉得这就是真相，虽然很残酷。
Sorry，跑题了。我是个奸商，所以我着重谈一下，作为用人单位，或者项目管理者，如何利用这种形势吧。
首先，不管泡沫破不破灭，程序员的工资升上去了就降不下了（经济学理论，比较复杂，找不到链接了。不信的话你可以试一下）。
所以，要想降低成本的话，裁员招新人吧！
那么，问题来了：
1、裁员之后，更少的人手，如何提高效率。
2、如何尽快的让新人上岗完成工作任务。
第2点，靠架构靠入职培训，本文暂不讨论，我们着重讨论第1点。我认为，最核心的方法就是对程序员的工作进行有效考核！
在工业时代，工资支付方式的革命就是“计件”——按工作成果而不是工作时间来支付工资，这无疑是最公平最符合人性最具有激励作用，所以也就是最好的制度。这已经被无数的人类实践所证明，90后没经历过改革开放之初农村家庭联产承包责任制，后来的国企内部承包改革等一系列重大事件，我们亲身经历，那种改变，真的只能用一个词来形容，“天翻地覆”！地还是那块地，人还是那些人，以前一个个饿得皮包骨头，现在家家户户吃不完的粮食，为什么？就一个简单的制度改变而已。
但问题在于，程序员的工作很难计量（其实所有行业都一样，好计量计件的，早就按计件支付了，剩下按工作时间支付的，都是难以计件的）。靠代码量来计算？懂行的就知道这明显不科学。有些单位靠功能来划分，这稍微科学点，但还是失之于粗糙。某加班的程序员不满了，“艹，他凭什么就下班了？他的功能明显要简单得多，就看见他在玩游戏！”下班的程序员不爽了，“是我有本事，好吧？你自己磨磨蹭蹭的搞不出来……”
所以问题的关键就转变成如何公平的衡量工作量。我觉得，越精细化，越有可能实现公平。
两个任务，核算都是30个人天的工作量，直接分给甲和乙，甲和乙会不会觉得公平，服不服？里面可能出情况的地方太多了，他硬着头皮接下这个任务，也是因为他也不知道这任务的工作量是多少！大家都只有拼人品了。但总是这样做也不是个事，尤其是在任务重工期紧的时候，矛盾很容易就爆发出来，“草，我忍你好久了……”然后陈谷子烂芝麻的事，就扯出来说，一堆烂帐谁他妈说得清楚？当然，说出来的还算好的，按程序员的常规做法，“say Goodbye，这个坑你自己找人填吧！大爷我不伺候了。”
所以我自己的项目，我就开始尝试一种“任务切分”管理的模式，30个人天确实不好估计，但30分钟的任务应该都没什么争议吧？我事先就把任务一个一个的切出来，我一般要切到一个任务，30分钟以内完成为止。这样做的好处有两个：
1、我自己心里有数。在切这个任务的过程中，我的思路基本上就出来了。可能以前以为是半天就能完成的工作，进行切分之后，就发现漏了一些，自己就要适当的调整开发进度。
2、对开发人员有指导作用。我用的都不是高手大牛，但他们新人也可以顺着这个路子一步一步的做下去，至少其中一些简单的部分可以分给他，复杂的留给我自己做。
3、开发人员偷不了懒，但比较服气。不是每一个任务时间都估得那么准，如果估多了，开发人员偷着乐就是了；估少了，他完全可以提出来。因为任务已经被切得很细很小了，他一提出来什么什么情况，你马上就能反应过来，任务量就相应的调整就是了。
最开始我用excel，后来感觉这个法子还管用，就顺手开发了任务管理系统，越用越觉得不错。所以我现在集中精力在完善这个系统，希望能推广开来，产生一定的社会价值。
当然，工具不是万能的，还是得落实到使用他的人身上。
这个工具不懂代码的项目经理估计是完全没法用了。
另外，用的人还是要有基本的“包容”精神。比如20分钟的任务，开发人员18分钟做完了，项目经理心里就像吃了颗苍蝇一样难受；后者开发人员花了22分钟做完，就要跳起来打人……那这个也没办法了。
这里就不再给任务管理打广告了，我们需要着重强调的，是“将任务进行切分，实现精细化管理”的理念。这是方向性的问题，只要方向对了，碰到的一些枝节问题，都可以再想办法克服；方向错了，那怎么努力都是药丸。其实回过头来看，我的这个理念是建立在一个假设/前提上的：程序员的工作是同质可量化的。这似乎是政治不正确的，现在最热血的说法是，“员工是我们最宝贵的资源”，，保护员工的“积极性”，大力提倡激发员工的“创造性”……
但作为一个在500强大企业打过工，在5个员工的小作坊当过土老板的程序员，只能呵呵，最有创造性的产品怎么都不是出自这些大公司？怎么经常都听到他们要把“最宝贵的资源”都给裁掉呢？
确定绩效
评论里的同学说得很对，忘了说绩效了。
首先，“绩效”不如“计件”。我觉得现在所有的绩效，基本上都是扯淡。在无法可量化的情况下，其唯一的作用就是无事生非，破坏安定团结的大好局面。你说他这个月绩效打80分，凭什么？他加了班？加班应该给加班费啊代码出了bug？谁的代码没bug？都没bug要测试干什么？可能最大的原因是他和你顶了嘴？你看他不顺眼吧？计件就没这些问题，就像业务员拿提成，那是清清楚楚，你敢少给一分钱？他敢找你多要一份钱？
当然，目前的情况下，让程序员做“计件”也太不现实了。当初我们公司开发人员入职，我给他们讲的都是计件，但实际上还是按月发工资。但我有了任务管理系统的记录和统计，每一周每一个月我把数据拉出来，明明白白的告诉他，为什么这个月多给，上个月少给，他基本上也认同。这里必须要说一下，工作量（时间）不是他实际完成工作的时间，而是我认为一个普通程序员（其实就是我啦）完成该工作的时间。比如我给这个任务20分钟，是指我能在20分钟完成，你哪怕花一天才搞出来，那是你的事！不然，你每天的工作量都是8小时，有什么意思？然后根据工作量，就可以统计出来你的绩效了。当然，任务是有难度划分的，还可以包括很多其他因素，比如：验收不合格的比率、按时完成任务的比率等等。
划分任务的工作量
还有同学提到了“划分任务的工作量”问题，是不是项目经理一天到晚就划分任务去了，不用干别的？
我把我的经验贴出来吧！开始的时候，新人入门，没办法，那就是我一个任务一个任务的分，确实有点耗时间，但一个任务要做20分钟，分配一下不过3-5分钟吧？况且新人20分钟根本做不完，所以我还是有大量时间做其他事的。
后来新人成长了，变成老人了，这时候，逐步逐步的让他自己切分任务，比如一个功能点，我把文档给他，让他自己做，做之前，先把任务切分好！他肯定抵触，“我做完就行了，切任务好烦的！”他切不出来——因为他还不能像我一样胸有成竹。我拗不过他，就随他的便，但只有一个要求，你先把你要花多少时间告诉我。他说行，比如一个功能点，他信心满满的说，“120分钟够了”。结果够个屁！哈哈，他两天都搞不出来，想加时间，我不干了呀，你加时间的依据在哪里？任务在做的过程中变复杂了呀，东一榔头西一棒，他怎么说得清楚？还有其他一些原因（比如代码review、commit等），以后再细讲，并且随着他技术的逐步提高，最后他也养成了做之前，先切任务的习惯。其实切任务就是一个理思路的过程，哪怕最开始你的思路有问题，因为任务已经进行了足够细致的切分，出问题的部分也很好标示很好说明，我们再进行调整也很容易。
随时随地看视频
