项目是个电信类的项目(其实是一个产品),30来个人做了13个月,前后经历了不少人员变动,包括PM和技术总监。我在该team里担任一个开发小组的组长。下面就以自己的认识总结一下这个项目吧:
        1
、首先说一下人员构成情况。
        team
里,一个PM,两个副的(其中一个是技术总监,另外一个是分析设计人员),PM在项目做了几个月的时候离职,后上来的PM是上层领导捧上来的,两个PM的共同点是熟悉相关的业务不懂技术,管理水平不好评价;技术总监(架构师)在原来的 PM离开后离职(估计是因为职场斗争),后来的技术总监是从设计人员提拔上来的。原来是PM对项目总体把握,开发工作一般由技术总监部署,后来的PM总揽 全局,以铁腕控制所有工作。我个人观点,第一个PM那种工作划分更合理,他懂业务懂管理,就多负责内外沟通、协调管理上;技术总监技术功底深厚,有很好的 架构设计能力,同时开发管理经验丰富,理应担任一个开发经理角色。

       PM下面,有几个分析设计人员和开发小组组长(按功能模块划分)。分析设计人员只熟悉业务技术只懂一些皮毛,遗憾的是设计成果有时让详设人员和开发人员头疼,但他们掌控着各个模块的需求分析与概要设计。开发小组组长做详细设计同时写少量代码,下面的开发人员由本公司的新员工和外包人员构成,负责编码。我比 较认同分析、设计职责分开的做法,懂业务的不一定懂设计,设计是技术描述业务的过程,不懂技术做出的设计很难让开发人员开展工作。分析人员可以不懂技术,他们只负责把需求整理出来提交给设计人员。
       2
、开发过程。
       
原来的技术总监在时,搞敏捷开发 ,按模块划分的各小组按迭代计划开发。个人观点:其实这个项目是个很大的项目,用RUP结合XP会更好,对项目整体用RUP,同时采用迭代和测试驱动,这 样难度虽然大些,但对以后的开发很有利。该技术总监离开后,敏捷开发不了了之,后面的开发基本采用领导分任务模式,做完拉倒,后来还用CC实施了 daily build。项目开发中期,一部分人到另外一个地方做开发,但还是同一个项目,这样便有了异地集成(用的版本管理是VSS),两边的team里便要单独找出人来负责两边代码的同步,因为代码同步出来不少问题,中后期两边的测试人员开始工作,常会出现代码同步问题产生的BUG。我暂时想不出有什么好的办法解决异地开发的合代码问题,只能总结些教训,如果没有其他办法解决异地开发的代码同步,就在两边的team里各找出一人合代码与文档(类似一个Facade吧),VSS管理员更好,该人直接对team的最高领导负责,其他人员不能插手该工作。在项目中出现过两边多接口的情况,相互扯皮,影响了team member的团结与工作效率。没有使用过CVS异地开发,不敢妄加评论。
      
对于daily build,没什么可说的,对于有N多个模块的系统,daily build是好事,不过build的周期却不一定是daily,它的决定因素应该考虑项目组的开发能力、系统开发进展等。daily build是双刃剑,用不好会死人的,不过team里有不怕死的,daily build在这个项目的使用是成功的还是失败的,我很难做出评价,它对开发过程起了一定的作用。
       team
中原来有几个专门的技术人员人做技术研究与验证(me也在其内),主要解决开发过程中普遍存在的技术问题、研究新的技术或写出公用代码来提高整个team的开发效率。对于大的project,这些人的存在有一定的意义。
       3
、内部的管理。
      
首先说一下公司的发展倾向,原来公司是产品+项目,有专门的部门做研发,现在公司对人员整合,不再有研发部门,按项目划分人员。公司采取什么样的管理模 式,我说话没有作用,暂且说说自己的看法。我所在的公司说大不大说小不小,带有点国企性质,近年来业绩较差(我就不明白,每年签好多单子,怎么就盈利那么 点钱),按项目划分也有不少好处,起码员工要可以靠干活吃饭啊,不过从长远考虑,对于要求有技术要求的公司,专门的研发部门不可少。按项目划分同时使一种现象强化,即重业务轻技术,公司搞电信软件开发与系统集成,对于懂电信业务的人员很重视,项目经理都是搞业务出身的,而且team的中级管理人员也是搞业务的,这样形成了一种业务人员带着一帮技术熟练工工作的现状,这样一来,搞技术的看不到自己的发展前景,心灰意冷,加之公司的工资水平低,亦没有调薪的习惯,公司每个月都有N个员工离职。我们项目组也走了几个,新来的大都是刚毕业的学生,因为他们会得到户口。没有走的技术人员不知道以后发展会如何,过的也很不爽:搞技术,公司不重视,没前途;搞业务,没有机会。也曾有不少项目经理提出过人员流失的问题,但公司发展如此,改变的可能性不大,起码这几年内不会有变化。
      
管理有一种情况也许跟不少其他公司很相似,现在的teamPM一人负责制(我更希望公司采用矩阵式管理,这样管理成本虽大些,但其更具稳定性、更有效率),team中用人与其他管理以项目经理的个人判断而定,这对PM的要求太高了,我想这种管理模式下的PM能让下面的同事心服口服的不应该在多数。对于一个不大懂技术的PM,如何衡量技术人员的水平是一个不太容易得出答案的问题。
      
“你们公司的管理是很混乱”,这是一个与我们合作的一个公司的PM的评价。从team里人员的职责划分与执行可见一斑,人员职责划分要明确的道理都懂,人们大都知道自己做什么,但不作什么同样需要Manager明确。对于一个大的team,管理需要严谨,需要层次,member之间的沟通应遵循一定的原则。看到现在作坊式的team,便怀念以前的那家日本公司(不要鄙视我),那家公司的管理很让人佩服,尽管他们用的技术并不先进。
       
还有一点,也算是一种经验吧。team里总有一些人技术业务能力一般,但“沟通”能力强,很会表现自己,当面一套背后一套的本事很强,呵呵,这类人在我们公司会受上上下下的领导赏识,很有发展前途,因为公司的PM培训文档里规定的PM的能力中,最重要的便是沟通能力。这些人被PM以及上层领导视为人才。
     
至于member之间的竞争,甚至相护踩踏,在team里也有体现,如何避免跟公司的企业文化、PM的管理、人员素质都有关系。
     
写的有些累了,以上便是自己在这个项目过程中的一写体会吧。尽管自己是个技术人员,但有一点现在自己不得不接受:不要沉迷于技术,比技术重要的东西很多,这是中国国情,不是技术人员所能改变的。

评论
发表评论

您还没有登录,请登录后发表评论

banner
搜索本博客
博客分类
最近加入圈子
存档
最新评论