帮助IT团队快速构建符合jt808协议部标的基于java技术的GPS和视频平台(2379423771@qq.com)

什么算是大型项目经验(一)

     说老实话,我都不知道什么算是大型项目经验,我也不知道,那些所谓要求有大型项目经验的公司,在做多大的项目,有多NB,但我并不以做过大项目为荣,我这几年的项目经验告诉我,团队不在于大,在于精,我经历过20人的团队,也有60人的团队,我觉得这样的项目要做好以下的几点:
     1.项目团队构建前,组织架构要精细考量
       各个关键角色的能力有与角色职责相适应,越向上,能力要足够的全面,要足够的强势,这样才能层层推动。
       上至CTO,GM,下至PM,DBA,TM,要能够撑得住,靠一个NB的PM,是绝对撑不住的,俺经历过一个60人的项目,4个PM,一个GM,一个GM assistant,结果是GM,天天躲在自己的办公室里,发email, 以为自己是船长,吹个口哨,大家都齐心协力的向前划了,结果是今天向东,明天向西,每次开会,乱成一团,一帮SB PM,满口单元测试,闭口敏捷,开口迭代,谁也不服气谁。
     2. 避免跟着感觉走,
        其实国内很多软件公司都一样,越向上的领导,技术层面越来越薄弱,即使一些曾经是大N的技术人员走上了CTO的岗位,但也会逐渐丧失掉技术的敏感度,很多PM都很少写程序,何况CTO、GM?估计每天的时间都浪费在回复邮件,开会,评审,会客之类的所谓的很虚的管理之上。
       这样造成的结果,就是掌控力度,其实是越来越弱,在用人,更是做不到知人善任,对于不懂技术的上领导来说,一头猪和一个高手,是没有什么区别的,只能跟着感觉走,对下边的一些人会特别的依赖,当下面的PM发生争论时,也搞球不清楚,那个SB说的对,那个SB越的有道理。
       但做人要对得起良心,作为一线的PM,要相对虚心,自己没有经验的,从书上学来的,不要轻易乱用,不要拿别人当实验品,更不能现学现卖,欺骗不懂技术的上领导,有的时候,也是没有办法,会叫的孩子有奶吃,也要讲究策略。
    
     3. 沟通与协作
        作为PM向上的领导,有的时候,你感觉自己好像都在天天开会,但有的会,就开的很好,起到了事半功倍的效果,有的会,就开的很糟糕,不仅得罪人,还吃力不讨好,在沟通与协作能力方面,作为稍大的项目以上,PM是必须要把握尺寸的,我见很多嚣张的PM,说话节奏快,语气比较强势,经常批评其它的PM,结果在OP会上,很容易遭到攻击,大家的级别和能力都差不多,谁也不会卖你的账,更不会给你帮助和施以援手了。有的PM就比较圆滑,在会上很少发言,听的比较多,经常说的话就是:是的,对,OK,没问题,尽量吧,等等话语,这样的PM就很少被攻击,也更容易得到帮助。

       其实,大家经常解释时说的一句话:"我也是就事论事",但在OP这样比较高层面的会上,还是尽量不要这样搞,就事论事,可以在下面一对一的搞,不要动不动都拿到OP会上搞,得不到别人的协作,要尽量的沟通,不能动不动,就上报给CTO之类的领导,这样会更糟糕。因为CTO可能会不能罩你一辈子。也并不是每个CTO都是清明的领导。

        email有email的用处,但它不是command, 也不是communication, 从你的坐位上站起来,在公司内走一走,要比一个email强万倍。

     4.架构师
       
        架构设计是个很复杂的东东,但如何选择合适的架构师,如何进行最终的决策,很多公司做的并不好,很多领导在架构师的任命上,很容易草率,说你行,你就行,说你不行,你就不行。于是一些不负责的、半桶水的人,就在领导的指示下,走上前台,将项目推向死亡之谷。

        架构的设计依赖你全生命周期项目经验的积累,格局要大,依赖于你对技术的敏感度,技术上比较全面,就像参谋长一样,从军校毕业的,就容易纸上谈兵,比较激进,从士兵,一路杀过来的,就比较慎重,但如果不爱学习上进,则又属于野路子,做又不究其理,不善于抽象,不讲究方法论。

        总之,在这点上,能找一个NB的,又有理性的,不太容易。


     5. 文档
       
         项目组与项目组之间,项目组与客户,项目组与测试部门,项目组与评审组之间的交互,有很重要的部分就是文档。

         文档这个东东,说实在话,就是一个鸡肋,但不要又不行,客户要签字,领导要评审,测试组要拿它写测试用例,但对于项目组来说,天天在那咬文嚼字的,实在是没有意义的,俺在原型分析与用例驱动上探索了很长时间,虽然用例直接了当,且很容易转化成功能书、测试用例,但工作量,比之传统的需求文档说明书,有过之而无不及,在时间紧的时候,也很难保持实时一致。

        我目前的做法是原型必须与客户的需求保持一致,基于静态页面的原型,修改起来,速度很快,且更容易被客户、程度员、设计者所接收,长篇大论,动不动上百页的需求文档,你喊破喉咙,也没有人看。

       文档,有专人写,专人维护,但会比较滞后,只要能够保证在提交测试部门时,有一份完整的文档,这样测试部门,也更方便测试。培训的时间也少。

        在评审时,可以评审,但具体文档要拖一拖了。

        客户签字,就以原型为主了。文档,它也不看。如果动真格,要看,那就抽时间赶出来。

        当然对于接口等技术文档,还是必须要的。


         (未完待续)
      
    

    

 

posted on 2007-04-21 14:57 Speed 阅读(4171) 评论(6)  编辑  收藏 所属分类: 项目管理之道

评论

# re: 什么算是大型项目经验(一) 2007-04-21 16:56 junglesong

有點意思,整理好后是一篇好文章。  回复  更多评论   

# re: 什么算是大型项目经验(一) 2007-04-21 20:35 itspy

good  回复  更多评论   

# re: 什么算是大型项目经验(一) 2007-04-22 01:25 yufeng0681

对手册的理解还不是站在高层次的
既然是个产品,你就要推销,就要让大家了解,能学会使用,甚至二次开发。
没有一定的手册支撑,你这个项目的人只会被拖进去,累,半死不活的那种。  回复  更多评论   

# re: 什么算是大型项目经验(一) 2007-04-22 10:16 我为J狂

看来软件业中也存在着官僚主义。  回复  更多评论   

# re: 什么算是大型项目经验(一) 2007-04-23 08:43 freebird

不错,有一定的道理的  回复  更多评论   

# re: 什么算是大型项目经验(一) 2007-05-05 22:16 Welkin Hu

我觉得高层管理者,比如说PM以上,深厚的技术背景并不是必须条件,很多情况下也不可能。对于高层管理者来说,他们的确是把自己的命运交付给PM的。只不过通常不会把所有的鸡蛋放在同一个篮子里。  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

导航

留言簿(15)

随笔分类

值得一看的博客

积分与排名

最新评论

阅读排行榜