项目管理（一）计时计件
不满意，重写了：项目管理（一）任务分配
+++++++++++++
“凡事预则立不预则废”，所以还是决定花两天时间，专门完成这个系列博客。关注我博客的同学都知道我开发了一个任务管理系统，这本来只是我随手做的一个项目管理小工具，但后来用得顺手，在上面花的时间也越来越多，所以隐隐有点觉得，还真可以把这事当成一个小事业来做。所以也借这个博客系列，整理一下我的思路，和大家一起分享我关于项目管理的一些经验和想法。都是我自己揣摩的，不一定靠谱，所以希望园子里的童鞋们大胆质疑，使劲拍砖！
鞭子
还是很多年前，记得有一次，我和黎叔一起去他的工地。他的一个侄儿在工地上帮他看现场，见黎叔来了，就要卖力一些，戴着安全帽夹着一个小包，在工地上走来走去，还不是吆喝两声：“用心点！”，“你这里搞快点！”，“这里这里，来个人……”黎叔看了一会儿，走到他跟前，对他说，“你还差个东西啊！”他很迷茫，就去摸他的安全帽。黎叔笑眯眯的接着说，“你还差根鞭子在手里！谁做得慢就给他一鞭子，是吧？”我在旁边想笑不敢笑，差点憋成内伤。
但这些年来，我自己开过公司，也待过很多家公司，这个场景却让我记得越来越深刻。我经常不由得想，管理者手里究竟有没有拿着“鞭子”？该不该拿着“鞭子”呢？
拿着鞭子，凶神恶煞，“谁做得慢就给谁一鞭子”的监工形象，来源于各种影视作品，讲的肯定是古代的事了。但时至今日，有形的鞭子早就没了，但无形的呢？各种KPI考核、扣奖金、裁员……没有这根鞭子，员工还能好好干活么？估计很难，我们国家改革以前的“大锅饭”，甚至我待过的一些赫赫有名的外企，“大公司病”里最重要的一点，被管理者偷奸耍滑混日子（或许都包括我自己，呵呵）的越来越多，一个重要的原因就是管理者手里没权，没有“鞭子”。
胡萝卜
但“鞭子”慢慢的退出历史舞台，除了文明进步、日益严格的劳动法律法规以外，我觉得最重要的原因，还是管理者发现：“胡萝卜”比“鞭子”更管用。
历史的发展似乎也印证这一点。按主流的说法，最初，我们实行的是残酷的奴隶制，监工手里拿着鞭子使劲抽；后来，封建社会，地主们就聪明了，多少地收多少租子，农民多劳多得，这就把农民的积极性给刺激起来了。其实，仔细想想，还真是这个道理。第一、“威逼”是有成本的，而且这个成本不低，至少监工要吃饭吧？第二、发自内心的驱动力是无比强大的，被人推着走和自己撒开脚丫子往前跑，完全是两个概念。这个，对比一下改革开放前后“包产到户”的效果就一目了然了。
还想到了一个例子，以前我们都说金字塔是奴隶们修的，后来西方有考古学家就说了，“不对，奴隶做不了这么精致的活。应该是自由工匠做的”。还有很多考古证据，我是外行，但想想这个推论，其实是很有道理的。
误区
综上，很多管理者就把“威逼利诱”当成了法宝，奉行“赏罚分明”；俗一点，“打个巴掌，给个枣吃”。但这样有用么？我觉得，有时候有用，有时候没用。
先说说没用的时候。首先，如果我是被管理者，就会很抵触这种做法。凭什么打我一巴掌？稀罕你这颗枣子呢？把爷当傻子耍？去你妈的！不要把别人都当傻子似的，利益面前谁都不傻。其次，这种行为会造成管理者和被管理者之间的复杂博弈。简单点说，就是勾心斗角阳奉阴违。你以为你在玩他，他其实悄悄在玩你，搞成了宫斗权谋，一片乌烟瘴气。
很多公司试图从“企业文化”这个角度来解决这个问题。试图把这些问题柔化掉，大家一起吃吃饭，沟通一下，喊两句口号，树立一致目标之类的，但以我的观察，都是缘木求鱼而已。上下级矛盾、部门扯皮，矛盾的根源没有解决，只是让大家谦恭忍让，忍得了一时忍得了一世？相反的，矛盾只会越积越深，直到崩盘。
公平
奖惩能够真正产生正面效力的基础是公平。这一巴掌该打多重，这颗枣该有多甜，标准是什么？这个标准是不是公平，才是问题的关键。
这一点，我觉得都没什么必要论述，但很多管理者往往遗忘甚至有意识的忽略它。受某D的影响，很多人还把劳动关系看成剥削关系，他们认为，“向管理要效益”就是多剥削一些员工的血汗钱。给你3000让你干5000的活就是我赚的，再搞个绩效考核，扣你200，晚上睡觉都乐醒。这种思路，不属于本文探讨范畴，我觉得这其实不是主流。更常见的情况是，管理者觉得自己被坑了，我发了这么多工资，你究竟有没有干这么多活？
这种顾虑的根源在于“计时”工资。这就和奴隶制时代很相似，你干一天的活，我给你一天的吃的。但问题在于，你是不是认真“干活”了呢？这就太难以衡量了。所以什么指纹打卡、装摄像头之类乱七八糟的管理方式就出台了。而且，从管理者的角度，还有一种潜意识，我给你8小时的工资，你就得干8小时的活，水都不喝一口这个要求过分了，但你躲在厕所抽烟我就接受不了。所以我看到新闻，某工厂每天上厕所次数不多于三次，每次不超过15分钟的奇葩规定就出来了。作为员工，尤其是现在的年轻一代，哪里还受得了？据我观察，一天8小时，能认认真真干4个小时的活就不错了；能干6小时的活，那绝对是优秀员工楷模了；干满8小时，那是绝对不可能的（加班除外）。
所以，在计时工资的框架内，管理就转变成了“如何在单位时间内提高员工工作效率”的问题。出于人性的贪得无厌（资方）和好逸恶劳（工方）考虑，这注定将是一场斗智斗勇难解难分的大混战。
计件
这里的计件，还包括内部承包、销售提成等一系列非“计时”支付方式。这几乎是解决上述问题的灵丹妙药。对于管理者来说，减少了一系列的管理成本；对于被管理者来说，摆脱了被监视督促的困境，可以自由的安排工作。更重要的是：公平！一旦达成协议，双方按约履行，多干多得少干少得大家心服口服。所以，其实看看周围，差不多能计件的，都计件了！
剩下的，就是一些确实不好计件的。软件开发，在很多人看来，恰好就是这种不好计件的工作。
难以计件，不是因为工作本身很复杂，需要特殊的难以掌握的知识技能等，而是工作本身能否简单的被计量。一般来说，工作越简单越容易计量，比如建筑工地上砌砖墙，工作简单，计量也简单，直接用面积/用砖数量计算就可以了。但一些看上去很复杂很高科技的工作，一样可以计量，比如医生动手术，够专业吧？一样可以用手术类型和时间计算，切胆结石手术一次用时3小时，就OK了，可以计件算报酬了。据我所知，挂多少号做多少床手术，这些都是和工资奖金直接挂钩的。但一些简单的工作，却没办法计件只能计时，比如餐馆迎宾服务员，怎么计件？鞠了多少个躬收了多少盘子？
那么回过头看程序员的工作呢？只能是“做一天和尚撞一天钟”？只能“吃大锅饭”，没办法多劳多得少劳少得？
切分
说任何复杂的事物，过于绝对，但大部分的软件开发工作，其中大部分的内容，其实是可以切分成一个一个简单任务的——简单到可以比较准确的计算其工作量。
切分的工作，其实我们都有意无意的在做着。一个项目，只要是多人合作，必然要进行切分，你做什么他做什么，都有个分工，不可能一拥而上吧？但有的切分是依据程序员的岗位或技能进行的，比如张三做前台、李四做后台；有的切分是按任务量来切分的，比如张三做甲功能，李四做乙功能。因为本文主要谈任务切分是否公平，所以我们着重讨论“按功能切分”，这种切分主要的问题是不够细，粒度太大。
假设两个功能点，核算都是14个人天的工作量，直接分给张三和李四，张三和李四会不会觉得公平，服不服？我估计最可能的情况是他们自己都不知道！里面可能出情况的地方太多了，所以他们其实是硬着头皮接下这个任务，因为他也不知道这任务的工作量是多少！大家都只有拼人品了。但总是这样做也不是个事儿，尤其是在任务重工期紧的时候（前期大家可能都悠哉乐哉的玩儿），矛盾很容易就爆发出来：
加班的先嘀咕了，“艹，他凭什么就下班了，我就要加班？”
项目经理解释了，“他的功能已经完成了呀！”
这时候不服了，“他的功能明显要简单得多，就看见他在玩游戏！我的功能多麻烦多复杂……”
然后摆事实讲道理，这里原以为怎么怎么，结果怎么怎么，要是里面还有点需求变更，就纯粹一堆烂帐了，谁说得清楚？
项目经理一般就只有投降了，“那张三，帮一下李四吧，特殊情况！”
一次两次就算了，但可能只是一次两次么？谁人品那么好？最终下去，两种情况：1、这次你帮我下次我帮你，帮来帮去帮成“大锅饭”；2、有人能力不行或偷奸耍滑，长期要人帮，老实人吃亏，怨气积累直到爆发。无论哪种情况，项目经理都是大眼瞪小眼无可奈何。
精细化
所以切分一定要切分到可控的粒度为止。任务太大，30个人天确实不好估计；但30分钟以内能完成的任务，应该心里有数没什么争议吧？根据我的实践经验，我一般会把任务切分到20分钟左右的粒度，最多不超过60分钟。在这个粒度范围内，任务已经相当的具体，可以说是胸有成竹十拿九稳。
按照这种模式，我们就有可能形成精细化的管理实践。而越精细化，就越有可能实现公平。就像买卖交割，一只羊43.78千克，每千克46元，合计2013.88元；其公平性肯定远高于以物易物式的谷子一堆。当然，你可能会说，只要双方你情我愿有何不可？但事实是，如前文说分析，基于人性的贪婪和计较，双方很难你情我愿，所以大而化之的以物易物现在几乎已经绝迹了。
成本
有同学感到疑惑，如果任务要切分到这么细，是不是项目经理一天到晚就划分任务去了，不用干别的？这个问题我们从两方面考虑：
第一，任务切分这个成本是必须的。比起切分任务，写设计文档才是“浪费”时间呢！我在实践中，至少发现了切分任务的以下这些好处：
- 能够真正的厘清功能和任务实现。在切这个任务的过程中，以前朦朦胧胧的概念，才一点点的清晰起来。
- 能够“纠错”。清晰过后，一些疏漏错误也就自然而然的暴露出来了。可能以前以为是2小时就能完成的工作，进行切分之后，才发现漏了一些功能点，把实现想得简单了一些之类的，自己就要适当的调整开发进度。
- 对开发人员有指导作用。我用的都不是高手大牛，但他们新人也可以顺着这个路子一步一步的做下去，至少其中一些简单的部分可以分给他，复杂的留给我自己做。
- 开发人员偷不了懒，但比较服气。不是每一个任务时间都估得那么准，如果你估多了，开发人员偷着乐就是了；估少了，他完全可以提出来。因为任务已经被切得很细很小了，他一提出来什么什么情况，你马上就能反应过来，任务量就相应的调整就是了。
总之，切分完任务，对这个项目，基本上就心中有数胸有成竹啦。作为管理人员，作为领导，威信就建立起来了。而不是稀里糊涂的把任务布置下去之后，下面一问三不知，错漏百出。一次两次问题不大，次数多了，下面的人不服，“聪明”点的就开始动心思糊弄了……
第二，可以采用“从下往上”垒的方式。如果开发人员值得信赖，你也可以让开发人员自己进行任务切分，你在任务验收时同时核查任务的工作量。因为代码都已经提交review了，这时候的工作量已经是挺好衡量的了。开发人员一般也不会乱来。但这里有一个小问题，就是开发人员开始可能会抵触这种做法。他们会认为切分任务和写文档、写注释、写日报周报一样，是无用的工作。
说说我是怎么处理的吧！我拗不过他，就随他的便，但只有一个要求， 你先把你要花多少时间告诉我。他说行，比如一个功能点，他信心满满的说，“120分钟够了”。结果够个屁！哈哈，他两天都搞不出来，想加时间，我不干了呀，你加时间的依据在哪里？我知道是因为任务在做的过程中变复杂了，但东一榔头西一棒，他怎么说得清楚？搞得他焦头烂额之后，他自己去体会。多尝试几次之后，同时随着他技术的逐步提高，最后他也养成了做之前，先切任务的习惯。其实切任务就是一个理思路的过程，做之前思路清晰了，事半功倍，“磨刀不误砍柴工”说的就是这个道理。其他作用
我们是由着“计件”这个话题谈到任务切分的，但实际上，即使任务切分，让程序员拿计件工资，我觉得现阶段还是不现实（鼓励大家多尝试，我有机会也试试）。当初我们公司开发人员入职，我给他们讲的都是计件，但实际上还是按月发大致固定的工资。但是，通过任务切分，我们可以做到以下几点：
第一、合理的安排人手。项目成员中水平有高有低，新人都有一个成长的过程。任务切分之后，像剔骨头一样，嫩肉给新人菜鸟，硬骨头给老人高手。这样，项目组才更具有效率和活力。你把简单的重复性工作给高手做，纯粹是让千里马犁地，浪费啊；把复杂的扔给菜鸟，他百度google，半天弄不出来也是浪费时间。但如果没有切分，难的简单的混在一起，区分不出来啊！
第二、有理有据的绩效考核。距今为止，我所见过的所有绩效考核，基本上都是扯淡。在无法量化的情况下，其唯一的作用就是无事生非，破坏安定团结的大好局面。你说他这个月绩效打80分，凭什么？他加了班？加班应该给加班费啊！代码出了bug？谁的代码没bug？都没bug要测试干什么？可能最大的原因是他和你顶了嘴？你看他不顺眼打击报复吧？所以最后基本上两种结局，要么弄得鸡飞狗跳，要么稀里糊涂一锅粥。
但我有了任务管理系统的记录和统计，每一周每一个月我把数据拉出来，明明白白的告诉他，为什么这个月多给，上个月少给，他基本上也认同。这里必须要说一下，工作量（时间）不是他实际完成工作的时间，而是我认为一个普通程序员（其实就是我啦）完成该工作的时间。比如我给这个任务20分钟，是指我能在20分钟完成，你哪怕花一天才搞出来，那是你的事！不然，你每天的工作量都是8小时，有什么意思？然后根据工作量，就可以统计出来你的绩效了。当然，任务是有难度划分的，还可 以包括很多其他因素，比如：验收不合格的比率、按时完成任务的比率等等，这些我们以后再谈。
第三、清晰准确的项目预算。我做开发七八年了，我从来没看到过一份清清爽爽的软件项目预算。都是做工程，比如建筑工程装饰工程，根据图纸，材料人工，一项一项的清单报价，不管多大的工程，价格算出来都是精确到分的，比如1080732.76元。但软件开发，合同能精确到百，都不错了，一般都是20万、3500，感觉在价格就是随口喊出来的一样。工期也是一样，建筑工程，误了工期，时间稍微长一点，违约金赔都赔不起。软件开发，延期延期再延期，才是常态，是吧？即使勉强交货，那都是蒙人的，里面bug一大堆，先交了货，再慢慢“维护”吧！
这个问题的根源在于，项目负责人对项目的细节没有切实的把控。只能凭着“经验”或者“想象”来大致的“估算”项目的工作量，而事实证明，这种估算是相当不靠谱的，由此而产生大量的纠纷。据我观察，一般只有小项目，才会采用按项目整体计价的方式发包；规模稍大的项目，如果双方都有一定的行业经验，通常是用外包人天事后核算的方式结算。按实际的人天结算，其实并没有真正的解决预算的问题，发包方一样需要预算啊！项目会花多少钱，该什么完工，心里一直没数。再说了，你外包过来的程序员究竟有没有认真干活，是不是在混日子，谁知道呢？
第四、应对需求变化。可能有这样一种想法：我花了大量的时间精力，事先把任务切分得清清楚楚，并据此做好了所有预算，但需求会随时改啊，最后还不是改得一塌糊涂？所谓“计划永远没有变化快”。其实不是这样的。如果你的计划是一个不可分割的整体，犬牙交错，牵一发而动全身的那种，那么当然，每一次改动都是一次伤筋动骨的大折腾。
但通过良好组织的任务切分，改动就可以被有效的对应到相应的计划部分。这时候，“有计划的变化远胜于无计划的变化”，因为每一次的改动就是一个局部的改动，是非常容易被重新计量评估的。比如，某次改动，会影响原任务3098-4012，原任务3876-3879，任务量共计480分钟；改动新增任务5678-5894，任务量共计300分钟；所以任务总量减少180分钟，非常清晰。
当然，我们还有一系列的措施应对需求变动。但良好的任务切分，具有基石般的重要作用！
之前发布了一篇，没上首页根本就没人看，所以就没脸没皮的上个首页吧！希望大家多拍砖。
