柔性项目管理

终于熬到了周末，我觉得这周过得特别的难，更加讽刺的是这周其实一个task都没有。害的我发慌的在想，我到底做过什么。项目组的开发模式是比较古老的多项目并行开发，项目间的版本交叠是最头疼的问题，而这古老的基于Unix和4gl的语言开发使得版本控制如火上加油。UAT服务器只有两个，同时进行UAT的项目有5个，这5个项目版本预计分三批移植到生产线。涉及到两个项目以上的程序大概有10来个，这10来个文件堆，绝对是个顽主。

 

屋漏兼逢连夜雨，这个时期Vender来搞个系统升级，引进基于角色的权限管理，虽说Vender是系统原来的开发者，但经过多年的演变和甲方的“专业”维护，Vender也不知道水深水浅，一发布就覆盖了生产线上上800个程序，引出一个巨大的版本问题，甲方头破额裂通宵复原版本。为此，甲方也对Vender失去了信心，于是接手一部分的升级工作，这些升级工作自然并行中的项目也要承担起来。

 

我带着两个项目，其中一个是5个UAT项目之一，另外一个刚入SIT。月中回珠海的时候，和一位朋友谈起项目管理，她说项目管理最重要的是计划和人员管理。我说，最重要的是做好心理准备承担责任，包括项目组成员犯下的错误。

 

管理的技术希望将项目中的活动度量化，其本质和法律的精神有点像，基本观点是“人性本恶”，它规定一些既定的规则防止项目组中的成员做出对项目进度不利的事情，如规定每个项目活动的输入和产出，极端的说，只要项目成员按照既定的流程走完，项目也就完成。可是现实中出现的情况往往比设想中的要多要琐碎。

 

我的管理方式比较柔。读高中的时候当班委，教室的清洁同学做不好，我就拿个扫把跟他们一起扫，自然就有同学跟着我加劲。这种好的劲头在团队中散发，整个团队就会向好的方向发展。偶然间接触另外一个项目组的一位同事，我看了看其中的一个设计，觉得有些不妥当，我就问了一些问题。他说他不知道，只要他按照既定的编码指导完成编码和单元测试，就“不关他的事”了。我当时就想起另外一件事情，有一次和IT部门经理讨论一个设计，BA的需求写的有点简单，我觉得设计的操作方式比较别扭，但是实现起来很方便。我就说，既然BA要求也就这样，我们也好节省些功夫。经理说，“We have to do the right thing mah”。经理的人格和职业道德的确是很让人敬佩的。我也是基于这种“正确的解决方案”才过问一下另外项目组的设计。（最后证明他们的设计也正确）

 

至于“不关我事”的想法，这并不是个人素质的问题，事实上这个同事工作很负责。问题是项目组有好多次为了需求的问题去请教客户，和客户的沟通过程似乎不太愉快，客户投诉了几次，IT部门于是三申五令不准随意跟客户交流，客户不能确认，那漫天盖地的需求确认找谁谈去？只能找项目组中较为资深的人员，要是资深的人员也不清楚，就再通过指定的协调者和客户沟通。可是资深人员也是开发人员啊，也要搞活，这个规定自然加重他们的担子，于是又像分猪肉一样分开，有了”1帮1“，”1帮2“类的组合。资深人员也有了微词。慢慢的，大家见到需求有问题，也尽量少去深究，因为大家都承担不起当中的沟通成本。着希望设计做到伪代码级别，做到烧锅炉的也能写出来那样仔细。做设计的资深人员很痛苦，编代码的也很痛苦，因为天天工作重复，其实自己没有什么进步的空间。

 

这种具有深严规定的项目管理，我总想起一个词——军事化。读大学的时候，有个同学带一个Web项目，项目是他班主任接过来的，参与人员是班级里边的同学，内容是帮某旅游区开发一个介绍性网站。后来项目失败了，他也祸及自身，四年大学生活，他一直被认为”人品“有问题，自大，目中无人，如此种种。大三那年我跟他聊天，他说，他觉得项目组就应该像一个军队一样，严格的命令执行。我当时说，“那真是军队么？真能用军队的方式管理么？他们有质的不一样，要是真的是军队，首长就有生杀大权。而项目组，更像是一个利益团队，领头者比法号司令更重要的，就是协调各方关系，使得项目组向既定的目标进发。“自然，我找到他祸及自身的原因了。作为一个大学生项目，一伙同学兴致勃勃，不为金钱，为的是实现自身的价值，也希望在当中学习到实践经验。这是个多么单纯的团队。可是没有的报酬，自然也少了责任，搞什么军事化？老子不爽拍屁股走人。

 

我不喜欢军事化的管理，但当然，可度量和可控的项目管理还是需要的。我希望项目组成员会思考，有自己发挥的空间。项目组中的一位新成员，就一些改动和我讨论，最后他忍不住说，”你怎么知道这就不是客户需要的呢？“从业务逻辑的角度看，那当然不是客户要的。可惜这成员不熟悉，而解释这业务逻辑，得耗费甚多。我没有喝斥也没有说任何打压积极性的话，因为我觉得他做的很好，将来他会知道他问的问题比较幼稚，但是这种质问会帮助他成长，业务就是这样积累起来的。有些问题需要和BA沟通，我就让他开个IM聊天，拖我进去，但是基本他进行沟通。沟通的技巧是这样积累起来的。IT 人走出代码的逻辑去看业务，这才是成熟的标志。

 

给人发展的空间，管理和被管理是一种博弈，重要的是相互之间的信任，而信任的建立，需要双方都作出尝试，试着将一些有挑战性的任务给某些少有突出表现的成员，往往发现结果比自己想像的要好。我曾让一个女孩子帮我做代码复查，这涉及10多个程序，系统保费收取的各个环节，对于以往都只是做具体任务的她当然比较挑战。过了一天，她找出了几个严重的设计错误，其中包括BA更改了BR的一些内容而没有反映到开发文档当中。她跟我讲，虽然是代码复查，对她来讲倒像是一次学习的过程。这不是我要的效果么？

 

只要你带着项目，就会有成员来问你意见，”这个事情我们这样做好不好？”其实大部分都应经有自己的仔细度量，我笑笑，按照你的想法做，不害怕。

 

那项目管理者做什么？承担风险，承担错误，项目下的人不会一直犯错误，而他们却会一直成长，团队会变得强壮。