艾伟也谈项目管理，我也发软件开发团队的思考（侧重点是人员）

　　//上个月给我们老板的mail.洋洋洒洒6000多字．
　　//为了方便公开，改了一下．以致可能有些地方前言不搭后语．
　　//不管他同意不同意，先在我们组实行了再说．
　　//请多大家多提提意见，日后看有没有机会找老板当面交流

　　经历的几个项目,项目的进度老是不尽如人意。更重要的是市场的开拓因为这些项目拖住了后退而无所作为。
　　我们现有的情况是：项目期限和最开始的保守估计都相去甚远，最后提交给客户的产品60％都是最后一个多月开发出来的，还有20％左右是以前就固有的固定模块。这几个项目我参与了编码，我对整个系统还是很了解的，但是就我的了解,我是不能让自己满意的。
　　也和其他同事聊了一下，探讨了一下原因。原因林林总总，因为我最近在看《人月神话》和《人件》也是深有感触，结合自己这些项目上的体会。谈一些自己的意见和建议，从好的方面说是活学活用，学以致用，从坏了方面说是班门弄斧，贻笑大方。
　　就如总监所说，项目出了这些问题，不是我们编程技术上的问题（很多项目的失败都不是技术上的问题），那就应该是我们项目管理上的问题。
　　我最近一直在思考这个问题：怎么才能很好的控制项目。显然以我的能力是只能发现问题，不能分析问题，解决问题的。这个业界的通病，我认为在我们公司同样解决不好。我们在技术上是成熟的，系统的构架能很好的适应项目，使用的技术也是成熟的，没有什么真正意义上的技术攻关。其他的项目也是这样，但是我们的项目却都是一样的问题。问题不在技术上，在管理上。最近看《人月》给我的第一感觉就是我们的文档太少。虽然我也是很排斥那些对人约束的文档的。需求分析文档，系统设计文档，用户需求变更文档......还有就是人员的问题。“我们在人上面遇到的难题比在技术上遇到的难题更多，但是我们在项目过程中用在技术上的时间比在人员上的时间显然少很多”，这个是《人件》上的话。
 对于这些问题，在我看来，员工心态上我们还能作得更好。 
　　员工心态上，为什么越是到最后期限，工作效率越是高？
　　无论项目时间是多长，都是最后时间最忙的问题。目前的这几个项目，项目的进度完全取决于客户定下的最后期限，我们都是被动的在项目启动和客户确认结束项目这段时间忙。但是实际上有一半时间是在白忙。一直作的都是，随时都基本上完成了，但任何时候都是今天作的比昨天作的好。这不是我们的惰性，而是人的共性。不是我们懒惰，我们组的员工在工作热情上还是很优秀的。公司想很快完成项目，想我们赶进度，节约时间作下一个项目，我们员工又何尝不是呢？但是前提是最好不要牺牲我们个人的时间。但是事实远非如此，作为员工最坏的想法是，我为什么要牺牲自己的利益来赶进度，进度上去了，工作量多了但是时间没有变，计时工资没有变。为什么我要参与压迫自己的活动？虽然不会这么极端但是潜意识里面是不喜欢赶进度的，至少不会主动赶进度。怎样才能让公司的意志和员工的意志统一起来呢？项目奖金。项目奖金我们是实行了的。但是因为老是滞后很久，所以给人感觉远水解不了近渴体会不到是“奖”的。说白了无论忠诚也好，敬业也好，大家工作的第一目的是为了钱，最基本的都是为了追求金钱而工作的。如果前面有钱的诱惑，我相信大家会争先恐后的。项目奖金的钱迟早是要发的，但是为什么不能发得及时一点，让员工觉得那是因为他工作的努力奖励的，来激发员工的激情呢?回头一想：说来惭愧，如果项目初验就发项目奖金的话，我已经加班加点的组织大家改完BUG，然后催促客户验收了。我相信哪怕是组织他们通宵，大家也会乐意的。
　　加班是比赛中的冲刺，但是因为里程碑太多，所以需要冲刺的也太多，于是就达不到冲刺的效果了，如果中间休息得多，真正能冲刺的时候也就多了。
　　一个越是时间紧迫的项目，越是需要频繁的召开头脑风暴会议，还有就是聚会（《人件》上的大意）。虽然开会占用了时间，但是能节约思考的时间少走弯路（对于我们还起到了督促进度的作用）。聚会可能会耽误一天，但是他能提高士气，和帮助个人融入团队中，接下来的几天工作效率的提高应该是可以抵消那一天的工作时间的。这点我觉得会我们开的会还是够的，但是聚会太少了。
当然我作为项目经理我很希望大家把所有的时间都投入到工作中来，前提是不牺牲个人的休息时间。现在我们组的人员都是有激情和精力的，如果以牺牲自己的一些利益为代价的，很快就会耗尽自己激情和精力的。当疲惫不勘的时候就是选择离开的时候。然而工作时间的延长也并没有见得工作量就提高了很多，相反是效率降低了。前几个月，周末一直在加班，主要是自己给自己设置的里程碑多了（问题是没有这些又不能保证项目进度）。至少有3个周末两天都加班，导致连上了半个月的班。一来疲惫，二来觉得没有劲头。可想而知，后面那个星期的效率。我想如果不是为了赶星期一的进度，最好不要加班，如果非要加一天班的话，星期一能休息半天，加两天班的话能休息一天，我猜测从效率上来说这天的时间是能补回来的，休息一天显然能提高效率。再者从心理上来说，觉得加班值得，这样加班的积极性会提高（虽然我们都不存在积极性不高的问题），同时能体现出我们公司对员工的关爱，施以小惠，得到的是什么呢？员工对公司的认同，工作积极性的保持，和对自己加班的认可。而休息一天又失去了什么呢？对公司来说，失去了一人一天的工作量，一人一天的工作量是多少？除了当事人，没有人确切知道。至少这个量是小于想象中的一人天工作量的。虽然一周的工作安排下来了，但是作为程序员不能控制工作的多少，却能控制工作的质量好坏。质量×数量＝工作量。所以说工作量确切上只有自己清楚。让员工怀这一个工作环境优越（有调休）的心，和得到休息的身体工作，工作的量和工作的质量的乘积显然是大于前者的。
　　关于员工生日的问题，公司也提过，不过口惠而实不至．在我看来完全可以按组来操作。项目组有人过生日，组里面给买一个蛋糕，买点点心，happy个20分钟左右，如果大家不尽兴完全可以自己去自由发挥，公司需要的是把这种气氛调动起来。上周同事的生日，效果很好，至少给大家了一个在一起融洽的借口。不需要人太多，需要的就是平时大家在一起工作的那几个人就可以了。
　　公司的讲座一定要坚持，如果每天面对的都是作同样的技术，人是会麻木的，但是如果不时有新的东西注入的话，能激发人的热情，同时能给人感觉公司很有活力，公司的人很有活力，觉得自己能学到很多从来没有听过的新技术，值得留下来继续学习。而我们的现状是不怎么对员工（特别是新员工）进行培训。新进的毕业生，好些没有真正接触过编程，只有一句话，你去学编程吧，没有任何培训。这就像游泳教练对想学游泳的人来说，你们自己跳到河里去学习，然后就走开了。结果呢，一部分被淹死了（放弃了编程），另一部分虽然学会了，但姿势上完全不对（形成了不良的编码风格，我就是这样，编码风格很差）。这样我觉得会导致后期的维护费用增加，虽然这些东西暂时看不出来，但这种隐性成本肯定是存在的。虽然培养的人部分会走，但有没有培养是99%都会走的，留下1%的庸才（“庸才沉淀”文化）。专业的队伍需要专业的培养，不能因为自己付出的让员工得到的多公司得到的少就不付出。结果是公司有很高的员工流动率，公司员工总是处于一种低水平的状态。
　　给员工一个触手可及的诱惑，感恩的心，舒适的心情，被大家接纳的环境，还有就是能提升自己的机会我觉得是激发员工工作动力和潜力的方法。
　　换休我觉得能给员工感恩的心（虽然加班不是天经地义的，但是业界无偿加班好像是天经地义的），因为至少他们朋友在的公司不是这样，比较之下有一种自己所处优越的感觉。适当的休息，和必要的活动能给大家一个好心情，活动没有必要整个公司，试想一下，公司这么多人，出去玩的时候作什么不可能大家一伙，势必分成几伙，而这个因个人关系自然而分的伙显然不大会同项目组的分配一样。这样是不能促进项目组和谐的，反之，一个项目组出去，10人左右，这时候大家都在一块玩不大可能分伙，更能促进大家的交流，形成以后互相照应的习惯，能体现出自己是组的一员，被这个组接纳。能体会到是组的一员自然是公司的一员，然而公司一大群人出去呢？是体会不到自己是组一员的。没有组这个集体的概念在里面，不方便以后开展组的工作。员工生日虽然是一个很好的机会，但是就是时间短了点，能发挥的空间也没有一个组出去玩的空间大。公司的讲座一定要坚持，而且弄得规律、正式一些。
 我想实行了这些，公司为此付出的应该能大于得到的。
　　回头来看这文，发现中间提到的都是自己私心想得到的。而我却冒昧揣摩大家的想法也是如此。但是转念一想，我其实也是一个底层的技术开发人员，只是比别人多了敢于说话的勇气，和不计后果的傻气。如果我都不能向上表达自己的意思，上面对我们的理解就可想而知了。写此文的目的，最初是想提高项目管理的可控程度，在我这个项目经理（作不了技术的主，也没有能力作主）的角度越写越觉得项目的可控程度很大部分取决于对开发人员的可控程度，而对开发人员的控制，不是通过工作安排来控制，的而是动之以情，诱之以利，让其自己控制自己。动之以情，需要公司给营造气氛，诱之以利需要公司牺牲眼前利益。我很想尝试一下，改变能改变的，接受不能改变的，把我们组打造为一支团结稳定的队伍。不知道老板有没有兴趣？