简约清爽和粗枝大叶……
他们还信奉权谋之道，用人嘛，“打个巴掌，给个枣吃”。你在用驴呢？稍微有点想法的就会不服，凭什么打我一巴掌？稀罕你这颗枣子呢？把爷当傻子耍？去你妈的！
利益面前谁都不傻，靠阴谋算计小心思，只会造成管理者和被管理者之间的复杂博弈。简单点说，就是勾心斗角阳奉阴违。你以为你在玩他，他其实悄悄在玩你，搞成了宫斗权谋，一片乌烟瘴气。
我们从一个最简单的例子说起。一件功能，交给张三去完成，给他三天时间。提前完成了有奖，超时罚钱扣工资。任务布置得清晰明了，而且赏罚分明，是不是？管理就这么简单。
凡是这么想的人，一定是没有搞过管理工作的。
中间可能出现的突发情况太多了。三天过后，任务还没有完成。你火了，问为什么？一堆的理由：任务难度太大，工作量太多，李四不配合，理解错了你的意思，中间出现了什么突发情况……反正都不是他的责任。他说得这么有道理，你处罚试试看？没过几天你就孤家寡人光杆司令一个。所以，最可能的情况是，问一下原因，埋怨两句，给他擦干净屁股，然后照样稀里糊涂的过日子吧！
胸有成竹
上述管理者困境的一个重要原因，就是管理者自己都不清楚：分配下去的任务，难度有多大，工作量有多少，可能出现的情况有哪些……自己都是一本糊涂账，怎么可能管好别人？
我们常常说管理人员要有威信。威信是怎么建立起来的？工作起来要胸有成竹，而不是稀里糊涂的把任务布置下去之后，遇到问题一问三不知，瞎指挥穷折腾。这样次数多了，下面的人自然不服，“聪明”点的就开始动心思糊弄了……
话是这么说，但具体到我们软件开发中的项目管理，胸有成竹就不那么容易了。
以项目预算为例，我从来没看到过一份清清爽爽的软件项目预算表。
先看报价。都是做工程，比如建筑工程，根据图纸，材料人工，一项一项的清单报价，不管多大的工程，价格算出来都是精确到分的，比如1080732.76元；但软件开发，合同能精确到百，都不错了，一般都是20万、 3500之类的，感觉在价格就是随口喊出来的一样。
再说工期。建筑工程，误了工期，时间稍微长一点，违约金都赔不起。软件开发，延期延期再延期，才是常态，是吧？即使勉强交货，那都是蒙人的，里面bug一大堆，先交了货，再慢慢“维护”吧！
想来主要有两点原因：
开发工作本身是一种创造性劳动。不像流水线上的工人拧螺丝钉，或者建筑工地上的工人砌墙搬砖，都是重复性劳动。虽然我们很多同学自嘲其工作为搬砖，但我们搬砖过来之后还是要砌成不同形状花样的，而不是千遍一律的一堵墙。所以，很多问题，只能在开发过程中才会暴露出来，解决的难度工作量都是一个未知数。
不断的需求变更。这个就不多说了，大家都懂的。
所以项目负责人对项目的细节没有切实的把控，只能凭着“经验”或者“想象”来大致的“估算”项目的工作量。而事实证明，这种估算是相当不靠谱的。
切分
处理一个复杂的事物，最常用的手段，就是把他切分成一个一个简单的部分。针对项目管理而言，我们推荐的，就是做任务切分。
也得有个数吧？
只是很少有人专门花时间和精力，有意识的来做这件事。因为我们对于项目管理中“计划安排”的理解还不够深刻。
根据我的项目实践经验，深入细致的任务切分，能够帮助我们：
真正的厘清需求。在“切”任务的过程中，以前朦朦胧胧的概念，才会一点点的清晰起来。
能够“纠错”。清晰过后，一些疏漏错误也就自然而然的暴露出来了。就应该相应的调整进度计划等。
合理的安排人手。团队中每个人的水平都是参差不齐的。任务切分之后，简单的重复性工作分配给新手，复杂的有挑战性的给大神，大家都满意，开发成本也能随之降低。但如果没有有效切分，难的和简单的混在一起，是区分不出来的。
对开发人员有指导作用。我用的都不是高手大牛，但他们新人也可以顺着这个路子一步一步的做下去，至少其中一些简单的部分可以做起来，复杂的帮帮忙就行了。
游刃有余，这才能给人一种愉快的艺术享受！
精细化
担心这样做的成本太高，是不是项目经理一天到晚就切任务去了，不用干别的了？
这是一个值得讨论的问题。粒度越细，可控性越高；但是也要考虑成本，过犹不及。这个应该是根据项目具体情况，灵活掌握。
这里我只分享一下我的一个变通处理实践：你也可以让开发人员自己进行任务切分，你在任务验收时同时核查任务的难度、工作量等。（如果你需要考核的话，因为这时候代码都已经提交review了，算是水落石出，做复核工作量其实很少了，所以开发人员一般也不会乱来）
但这里有一个小问题，就是开发人员开始可能会抵触这种做法。他们会认为切 分任务和写文档、写注释、写日报周报一样，是无用的工作。
道理当然要讲，但最好还是事实说话。
我随你的便，但只有一个要求， 你先把你要花多少时间告诉我。他说行，比如一个功能点，他信心满满的说，“2小时够了”。结果够个屁！哈哈，他两天都搞不出来。我就要找他说为什么了呀？东一榔头西一棒，他怎么说得清楚？焦头烂额之后，他自己去体会。多尝试几次之后，外加他技术水平的逐步提高（切任务不是个简单活，很考功力的），最后他也养成了习惯：敲代码之前，先切任务。其实这就是一个理思路的过程，哪怕是纯coding，做之前思路清晰了，也能事半功倍。“磨刀不误砍柴工”，说的就是这个道理。
应对变化
有人觉得这样做不值得。你辛辛苦苦的分任务，做计划，需求变了呢？或者出现了其他情况呢？计划是不是就白费了？越完善详尽的计划越不可能实现……
“计划永远没有变化快”！但是不是就可以证明，我们不需要计划了呢？让我们静下心来仔细分析一下。
首先，无论如何，首先肯定要有一个计划。公司要签合同要有金额工期，项目经理要报项目安排，程序员也要在deadline之前完成手头的工作……无论你愿不愿意，这是一个客观要求，很难逃避的东西，是不是？
那么，为什么我们很多人提起计划就头痛，特别因为：计划被滥用。
月计划，写的时候就不情愿，感觉多此一举；更何况要是没能按计划完成，还要被要求说为什么！太多为什么了，怎么说得完？真要说呢，又会被批评“为失败找借口”，烦死啦！所以就做个假计划大计划空计划之类的东西敷衍一下完事……
这种做法有几个问题：
僵化的看待计划。管理者认为计划一旦指定，就一成不变的、必须丝丝入扣的完成；甚至把计划当成了监督鞭策员工努力工作的东西。这肯定是行不通的，其实，既然是计划，就意味着它还没有被实现；需要制定计划，就说明实现是有不确定性的。很确定性的东西，比如明天早上8点钟我要到公司上班，这种事情根本不需要计划；下周我要去海南岛环岛游，从来没去过，可能有很多突发情况，这才需要计划！这个计划就可能受天气、自己的身体状况等一系列的因素影响而无法百分百实现；但无论有无突发情况，我有机会肯定比没计划强。为什么就大家自己想一想吧？
计划制定者指定不当。让能力一般的底层工作者指定计划，实在是有 些强人所难。计划不是那么好制定的，让你制定一个攀登珠穆朗玛峰的计划靠谱么？虽然说coding是程序员的工作，但他们很多时候，编码还是在摸着石头过 河，走一步看一步而已。所以，制定计划这种走一步看三步的工作，还是项目经理，或者经验丰富的程序员来做更贴切一些。
所以，我们必须明白：计划制定出来，就是被破坏的。计划没能按预期执行，并不说明他们没有用。实际情况发生了变化，计划就应该相应的调整；但这种调整应该是有序的可控的，而不是胡乱的调整。有序的调整能够最终保证大任务的顺利完成；而无序的调整，只会把事情搞得一团糟。怎么样才能够有序？还是要有计划！一份计划，就像一张图纸一样，出了情况，铺开图纸，圈出出相应的部分，结合周围的情况，考虑一个妥善的解决的办法……而不是一堆人你一句我一句，天马行空，公说公有理婆说婆有理，乱哄哄的不可开交。
。
如果你的计划是一个不可分割的整体，犬牙交错，牵一发而动全身的那种，那么当然，每一次改动必然都是一次伤筋动骨的大折腾。
但通过良好组织的任务切分，改动就可以被有效的对应到相应的计划部分。这时候，每一次的改动就是一个局部的改动， 是非常容易被重新计量评估的。比如，某次改动，会影响原任务3098-4012，原任务3876-3879，任务量共计480分钟；改动新增任务 5678-5894，任务量共计300分钟；所以任务总量减少180分钟，非常清晰。
共同学习，写下你的评论
评论加载中...
作者其他优质文章
