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

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

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

时间: 2024-09-16 12:44:53

艾伟也谈项目管理,我也发软件开发团队的思考(侧重点是人员)的相关文章

艾伟也谈项目管理,给敏捷软件开发的26条建议

我经常收集各种各样的至理名言,最近我重温敏捷软件开发:真正的问题是什么?下面是一份26条关键原则的清单,以指引敏捷软件开发团队. 1.完整地干完一件事后在开始另一件事:用厨房比喻来说就是:"先上这道菜,再开始做下一道".软件开发的最大问题就是同时开始几件事情,这将不可避免的造成某些工作被废弃,从而造成浪费.专注于一件事:完整地实现其功能:运行测试:编写文档:签入所有,把这当做一项工作完成,然后再开始下一件事. 2.不要破坏构建:非常明显,但必须被包含在任何软件开发建议清单中.程序员在签

艾伟也谈项目管理,找出软件开发过程中的BUG,你需要火眼金睛

1)Bug大都出现在程序员的编码过程中.测试人员工作之一就是找出Bug,面对那些难以被人发现的Bug,测试人员通常会采取哪些手段?以您的经验,对广大测试人员有什么好的建议?对于开发人员,您有什么建议让他们减少Bug的产生? 之所以难以发现,大多是测试案例不够完整,检查测试案例是否全面覆盖了需求,等价类划得是不是够细有助于发现更多的问题. 如果已经发现的问题大多是猜测法发现的,那么惨了,这是一个天马行空的测试,所有的BUG都将是难以发现的BUG,碰运气吧.如果你真的是在这个不幸的团队,别伤心,你有

艾伟也谈项目管理,如何评估软件进度

这是一个评估项目完成和剩余百分比的指导说明. 我还没看到了这个问题. 完成:0%, 剩余时间:2周左右. 我看到了这个问题. 完成:50%, 剩余时间: 还要2周左右. 我差不多都完成了.剩下的是一些很麻烦的东西,我真的不知道该怎么处理. 完成:90%, 剩余时间: 还要2周左右. 所有的都做完了.只剩下文档.代码复查.测试和异常处理工作. 完成:99%, 剩余时间: 还要2周左右. 文档.代码复查.测试.异常处理工作还是没有完成.实际上我是在已经完成的事情上精益求精.可是我刚刚发现了另外一个问

艾伟也谈项目管理,打造高效的技术团队,我会关注的7个点

1:使用分布式的版本管理系统 如果你觉得不需要使用版本管理系统,那我们沟通会有代沟,如果你是cvs.svn的粉丝,或者由于某种原因没有使用过分布式版本管理系统,比如git,那强烈建议你去看一下"why git is better than x". 2:一键式发布 这里发布的目标位置,既可以是开发机,做本地测试:也可以是测试机,为QA准备好捉虫游戏的森林:还可以是生产环境(或者beta环境),供用户直接访问. 如深度xp一键恢复系统一样,一键式发布需要自动完成很多工作:代码自动化测试(开

艾伟也谈项目管理,软件公司的两种管理方式

这篇文章是我的一个外国的同事Gareth推荐给我的,我和他一起工作过一段时间.他之所以觉得非常不错,是因为这篇文章让他身有体会,他觉得我也一定会有体会,并让我考虑一下翻译到我的blog上来.我看完后觉得很有代表性,而且觉得说得太对了,所以翻译过来,希望大家都读一读,最好转给你的公司老板. 这篇文章来源于 StakeExchange 上的一个问题--"为什么BA和PM的薪水要比程序员要高?",顶在一楼的回复分析了这个原因,并指出了两种管理文化. -------------------正文

艾伟也谈项目管理,克服在企业中应用敏捷方法的技术挑战

在企业中应用敏捷方法是一项具有挑战性的任务.实现敏捷不像安装软件那样能在一天内完成.而是需要适应企业环境,其中包括:文化.技术和组织方面.本文将探讨面临的一些挑战,这些挑战与建立开发环境.自动化测试.持续集成相关,并且同在企业环境中明确完成的定义(DoD)相关. 建立开发环境 每位技术负责人和开发经理都想缩减团队成员建立开发环境的时间.然而,为了在项目中获得较高的产出,开发人员要持续投入许多精力,让事情变得有条不紊.缺乏文档,是建立开发环境时间过长的关键原因.第二个关键原因是建立过程中包含多少手

艾伟也谈项目管理,项目管理利刃之MSF

MSF,MicrosoftSolutionFramework,微软解决方案框架是一个在预算范围内按期创建一个业务解决方案需要一种经过检验的方法. 本文将结合MSF在项目管理中的实际应用进行讲解,如果您是软件项目的参与者,如项目经理.开发工程师.系统架构师.顾问.质量管理人员等,想找到项目管理中遇到问题的解决方案,相信本文会给您一定的帮助. MSF为成功地规划.设计.开发和部署IT解决方案提供了一套成熟的方法论.与具有固定框架的方法相反,MSF提供了一个可以伸缩的灵活框架,以满足任何规模的组织或者

Google 极客谈软件开发团队的不良行为

开发团队是一个整体,稳定的.沟通无碍的团队文化非常重要.好的文化氛围应该包括基于共识决策的开发模式.高质量的代码.代码审查,以及能让人放心尝试新事物或者快速失败的环境.Brian和Ben是Google的两位开发主管,他们在"极客与团队"中列举了软件开发团队的典型不良行为,提醒开发者时刻保持警惕,并提出了一些实际的解决办法. Brian和Ben指出,团队的注意力和专注力是最容易受到威胁的.团队规模越大,编写软件和解决有趣问题的能力就越强-不过这种能力毕竟是有极限 的.要是你不去主动保护它

MBTI在软件开发团队中的应用

人绝不是一种资源.一方面我们不可能因人设岗,另一方面也不能忽略人性的差异.面对问题时,不要总是单纯地从人的态度或品德上查找问题,而是要反思人事安排和流程建设上的不足.奢望一个人改掉他的缺点,还不足充分发挥他的优点. 前言 MBTI将人区分为16类人格特质,我无法断言是否真得能表达出人的真实一面,毕竟只是统计性的结果.我的思考并不在于它归类的结果,而在于它的归类方法.   在团队合作中,各种各样的情绪.喜好.偏见一直在影响着我们对于人和事的判断.我们强调第一印象的重要性,正是因为一旦被贴上标签,就