项目管理(一)任务分配

  1. 云栖社区>
  2. 博客>
  3. 正文

项目管理(一)任务分配

17bang自由飞 2015-11-16 22:34:00 浏览426
展开阅读全文

之前写过一篇,不满意,重写如下:

 

管理一般说来,就三件事:管人,管事,还有管钱。而这三者其实又是联系起来的,比如,我们可以说:让合适的人做合适的事,并给他合适的钱。那么,问题就转化为:怎么才算“合适”呢?

 

困境

 

有一些人的管理工作随意散漫,但他们振振有词,“管理是一门艺术”。我觉得,他们应该仔细区别一下,错落有致和杂乱无章,简约清爽和粗枝大叶……

 

或许他们还信奉权谋之道,用人嘛,“打个巴掌,给个枣吃”。你在用驴呢?稍微有点想法的就会不服,凭什么打我一巴掌?稀罕你这颗枣子呢?把爷当傻子耍?去你妈的!

利益面前谁都不傻,靠阴谋算计小心思,只会造成管理者和被管理者之间的复杂博弈。简单点说,就是勾心斗角阳奉阴违。你以为你在玩他,他其实悄悄在玩你,搞成了宫斗权谋,一片乌烟瘴气。

 

我们从一个最简单的例子说起。一件功能,交给张三去完成,给他三天时间。提前完成了有奖,超时罚钱扣工资。任务布置得清晰明了,而且赏罚分明,是不是?管理就这么简单。

凡是这么想的人,一定是没有搞过管理工作的。

中间可能出现的突发情况太多了。三天过后,任务还没有完成。你火了,问为什么?一堆的理由:任务难度太大,工作量太多,李四不配合,理解错了你的意思,中间出现了什么突发情况……反正都不是他的责任。他说得这么有道理,你处罚试试看?没过几天你就孤家寡人光杆司令一个。所以,最可能的情况是,问一下原因,埋怨两句,给他擦干净屁股,然后照样稀里糊涂的过日子吧!

 

胸有成竹

 

上述管理者困境的一个重要原因,就是管理者自己都不清楚:分配下去的任务,难度有多大,工作量有多少,可能出现的情况有哪些……自己都是一本糊涂账,怎么可能管好别人?

我们常常说管理人员要有威信。威信是怎么建立起来的?工作起来要胸有成竹,而不是稀里糊涂的把任务布置下去之后,遇到问题一问三不知,瞎指挥穷折腾。这样次数多了,下面的人自然不服,“聪明”点的就开始动心思糊弄了……

 

话是这么说,但具体到我们软件开发中的项目管理,胸有成竹就不那么容易了。

 

以项目预算为例,我从来没看到过一份清清爽爽的软件项目预算表。

先看报价。都是做工程,比如建筑工程,根据图纸,材料人工,一项一项的清单报价,不管多大的工程,价格算出来都是精确到分的,比如1080732.76元;但软件开发,合同能精确到百,都不错了,一般都是20万、 3500之类的,感觉在价格就是随口喊出来的一样。

再说工期。建筑工程,误了工期,时间稍微长一点,违约金都赔不起。软件开发,延期延期再延期,才是常态,是吧?即使勉强交货,那都是蒙人的,里面bug一大堆,先交了货,再慢慢“维护”吧!

 

想来主要有两点原因:
  1. 开发工作本身是一种创造性劳动。不像流水线上的工人拧螺丝钉,或者建筑工地上的工人砌墙搬砖,都是重复性劳动。虽然我们很多同学自嘲其工作为搬砖,但我们搬砖过来之后还是要砌成不同形状花样的,而不是千遍一律的一堵墙。所以,很多问题,只能在开发过程中才会暴露出来,解决的难度工作量都是一个未知数。
  2. 不断的需求变更。这个就不多说了,大家都懂的。

所以项目负责人对项目的细节没有切实的把控,只能凭着“经验”或者“想象”来大致的“估算”项目的工作量。而事实证明,这种估算是相当不靠谱的。


切分

 

处理一个复杂的事物,最常用的手段,就是把他切分成一个一个简单的部分。针对项目管理而言,我们推荐的,就是做任务切分。

 

这其实是一个必须得做的工作!区别只在于你是主动还是被动,是认认真真还是敷衍了事的在做。别说是一个团队,必须得分工配合;就算是你一个开发,先做什么再做什么,你心里也得有个数吧?

只是很少有人专门花时间和精力,有意识的来做这件事。因为我们对于项目管理中“计划安排”的理解还不够深刻。

 

根据我的项目实践经验,深入细致的任务切分,能够帮助我们:

  1. 真正的厘清需求。在“切”任务的过程中,以前朦朦胧胧的概念,才会一点点的清晰起来。
  2. 能够“纠错”。清晰过后,一些疏漏错误也就自然而然的暴露出来了。就应该相应的调整进度计划等。
  3. 合理的安排人手。团队中每个人的水平都是参差不齐的。任务切分之后,简单的重复性工作分配给新手,复杂的有挑战性的给大神,大家都满意,开发成本也能随之降低。但如果没有有效切分,难的和简单的混在一起,是区分不出来的。
  4. 对开发人员有指导作用。我用的都不是高手大牛,但他们新人也可以顺着这个路子一步一步的做下去,至少其中一些简单的部分可以做起来,复杂的帮帮忙就行了。

总之,切分完任务,对这个项目,基本上就心中有数啦。如果说“管理艺术”,游刃有余的分配安排任务,像庖丁解牛一样,“以无厚入有间”游刃有余,这才能给人一种愉快的艺术享受!

 

精细化

 

我极力主张:把任务要切分到尽量小的的粒度,比如一个任务20分钟左右,最多不超过60分钟。当然,很多同学担心这样做的成本太高,是不是项目经理一天到晚就切任务去了,不用干别的了?

这是一个值得讨论的问题。粒度越细,可控性越高;但是也要考虑成本,过犹不及。这个应该是根据项目具体情况,灵活掌握。

 

这里我只分享一下我的一个变通处理实践:你也可以让开发人员自己进行任务切分,你在任务验收时同时核查任务的难度、工作量等。(如果你需要考核的话,因为这时候代码都已经提交review了,算是水落石出,做复核工作量其实很少了,所以开发人员一般也不会乱来

但这里有一个小问题,就是开发人员开始可能会抵触这种做法。他们会认为切 分任务和写文档、写注释、写日报周报一样,是无用的工作。

道理当然要讲,但最好还是事实说话。

我随你的便,但只有一个要求, 你先把你要花多少时间告诉我。他说行,比如一个功能点,他信心满满的说,“2小时够了”。结果够个屁!哈哈,他两天都搞不出来。我就要找他说为什么了呀?东一榔头西一棒,他怎么说得清楚?焦头烂额之后,他自己去体会。多尝试几次之后,外加他技术水平的逐步提高(切任务不是个简单活,很考功力的),最后他也养成了习惯:敲代码之前,先切任务。其实这就是一个理思路的过程,哪怕是纯coding,做之前思路清晰了,也能事半功倍。“磨刀不误砍柴工”,说的就是这个道理。


应对变化

 

有人觉得这样做不值得。你辛辛苦苦的分任务,做计划,需求变了呢?或者出现了其他情况呢?计划是不是就白费了?越完善详尽的计划越不可能实现……

 

这些倒都是经验之谈。现实确实如此,“计划永远没有变化快”!但是不是就可以证明,我们不需要计划了呢?让我们静下心来仔细分析一下。

 

首先,无论如何,首先肯定要有一个计划。公司要签合同要有金额工期,项目经理要报项目安排,程序员也要在deadline之前完成手头的工作……无论你愿不愿意,这是一个客观要求,很难逃避的东西,是不是?

 

那么,为什么我们很多人提起计划就头痛,特别反感计划呢?我觉得,很大一个原因是因为:计划被滥用。

比如被要求写这些日计划周计划月计划,写的时候就不情愿,感觉多此一举;更何况要是没能按计划完成,还要被要求说为什么!太多为什么了,怎么说得完?真要说呢,又会被批评“为失败找借口”,烦死啦!所以就做个假计划大计划空计划之类的东西敷衍一下完事……

这种做法有几个问题:

  1. 僵化的看待计划。管理者认为计划一旦指定,就一成不变的、必须丝丝入扣的完成;甚至把计划当成了监督鞭策员工努力工作的东西。这肯定是行不通的,其实,既然是计划,就意味着它还没有被实现;需要制定计划,就说明实现是有不确定性的。很确定性的东西,比如明天早上8点钟我要到公司上班,这种事情根本不需要计划;下周我要去海南岛环岛游,从来没去过,可能有很多突发情况,这才需要计划!这个计划就可能受天气、自己的身体状况等一系列的因素影响而无法百分百实现;但无论有无突发情况,我有机会肯定比没计划强。为什么就大家自己想一想吧?
  2. 计划制定者指定不当。让能力一般的底层工作者指定计划,实在是有 些强人所难。计划不是那么好制定的,让你制定一个攀登珠穆朗玛峰的计划靠谱么?虽然说coding是程序员的工作,但他们很多时候,编码还是在摸着石头过 河,走一步看一步而已。所以,制定计划这种走一步看三步的工作,还是项目经理,或者经验丰富的程序员来做更贴切一些。

 

所以,我们必须明白:计划制定出来,就是被破坏的。计划没能按预期执行,并不说明他们没有用。实际情况发生了变化,计划就应该相应的调整;但这种调整应该是有序的可控的,而不是胡乱的调整。有序的调整能够最终保证大任务的顺利完成;而无序的调整,只会把事情搞得一团糟。怎么样才能够有序?还是要有计划!一份计划,就像一张图纸一样,出了情况,铺开图纸,圈出出相应的部分,结合周围的情况,考虑一个妥善的解决的办法……而不是一堆人你一句我一句,天马行空,公说公有理婆说婆有理,乱哄哄的不可开交。

 

任务管理系统就能够帮助我们及时迅速的应对各种变化。除了可以提供自动化的统计分析以外,更因为项目已经被有效的切分

如果你的计划是一个不可分割的整体,犬牙交错,牵一发而动全身的那种,那么当然,每一次改动必然都是一次伤筋动骨的大折腾。

但通过良好组织的任务切分,改动就可以被有效的对应到相应的计划部分。这时候,每一次的改动就是一个局部的改动, 是非常容易被重新计量评估的。比如,某次改动,会影响原任务3098-4012,原任务3876-3879,任务量共计480分钟;改动新增任务 5678-5894,任务量共计300分钟;所以任务总量减少180分钟,非常清晰。

 

结论

 

总之,任务的切分/分配能帮助项目管理人员深入的了解项目,并在此基础上合理的计划安排开发工作,应对项目实施中的各种变化,是任务管理系统的基石。

 

++++++++++++++++++++

哇塞,写得好苦啊!最难产的一篇博客!

网友评论

登录后评论
0/500
评论
17bang自由飞
+ 关注