每日一得

不求多得,只求一得 about java,hibernate,spring,design,database,Ror,ruby,快速开发
最近关心的内容:SSH,seam,flex,敏捷,TDD
本站的官方站点是:颠覆软件

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  220 随笔 :: 9 文章 :: 421 评论 :: 0 Trackbacks

//本站点内容来自于 颠覆软件


纯粹意义上的项目经理是不用管技术的问题的,只负责管理,但是在一个中小公司可能出入就很大了,比如,在我所在的公司,项目经理=客户需求+项目管理+软件架构+程序编码+部署+测试+项目验收,如果需要的话也可以兼个DBA  :) ,还好,我以前的功底相对比较扎实,从linux到windows server到sqlserver 到oracle到jboss到websphere算不上精通也都基本能独立搞定,但要说效率有多高可能就不好说了.

我个人还是倾向于“分布式”,即各司其职,有人设计,有人实现,有人管理,有人维护,我还是欣赏我当初参加工作时在北京网通小灵通账务管理的项目中 的人员分配的方式,现在想来还是比较合理,在我们B/S组分配是:一名项目经理,主要负责总体和客户的沟通,一名需求管理人员兼DBA;一名技术经理带2 个 后台开发人员;后台开发人员各带一名前台开发人员;一名测试人员负责测试,同时负责用户平时的基本修改意见的汇总,如果有较大的变动则通过项目经理。而反 观我们现在的一些项目会发现,程序员居然和客户沟通起来了,真是不怕天下大乱,用户A提一个问题,程序员A修改了,过一段时间A又提一个问题给B,B也修 改了,有一天程序员A和程序员B都走了,客户觉得我的好多以前提的东西你们怎么现在的人都不知道啊? 双方都受伤害。其实,合理的架构才能保证有序的结果,一个小打小闹的团队怎么能应付日益变化的客户需求呢。

如果条件允许,我建议一个具有竞争力的团队应该是一名架构设计人员,一名DBA,3-5名中等水准的开发人员,一名美工,一名测试,其中DBA和美 工是共享人员,临时参与,测试放到一个更重要的位置,即,始终跟踪全部的客户需求,所有的修改变更都是通过测试人员,程序员和客户之间隔离开。其实这不就 是“面向对象”么? 松耦合和紧耦合肯定不是一回事。现在很多的公司的高层人员普遍比较短视,所谓的理由就是“成本”,我的回答是:出来混迟早要还的! 现在不这么做,迟早要付出代价。

posted on 2008-07-03 14:12 Alex 阅读(2930) 评论(1)  编辑  收藏 所属分类: 项目管理与软件杂谈

评论

# re: 项目经理的职责[未登录] 2008-07-03 17:33 石头
讲的不错,我觉得一个项目里面还应有一个系统分析人员不可却少。一个合格的系统分析人员能让你的项目开发过程处于一个比较主动的地位(可以引导客户用合适的方法解决客户提出来的问题,可以回绝客户不合理的要求等)。同时需求的管理也是非常重要。对于一个可持续的项目来说,知识和文档的沉淀是非常重要的。但是国内软件公司能做到的确定不多。  回复  更多评论
  


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


网站导航: