//本站点内容来自于 颠覆软件
纯粹意义上的项目经理是不用管技术的问题的，只负责管理，但是在一个中小公司可能出入就很大了，比如，在我所在的公司，项目经理=客户需求+项目管理+软件架构+程序编码+部署+测试+项目验收，如果需要的话也可以兼个DBA 
,还好，我以前的功底相对比较扎实，从linux到windows server到sqlserver 到oracle到jboss到websphere算不上精通也都基本能独立搞定，但要说效率有多高可能就不好说了.
我个人还是倾向于“分布式”，即各司其职，有人设计，有人实现，有人管理，有人维护，我还是欣赏我当初参加工作时在北京网通小灵通账务管理的项目中
的人员分配的方式，现在想来还是比较合理，在我们B/S组分配是：一名项目经理，主要负责总体和客户的沟通，一名需求管理人员兼DBA；一名技术经理带2
个
后台开发人员；后台开发人员各带一名前台开发人员；一名测试人员负责测试，同时负责用户平时的基本修改意见的汇总，如果有较大的变动则通过项目经理。而反
观我们现在的一些项目会发现，程序员居然和客户沟通起来了，真是不怕天下大乱，用户A提一个问题，程序员A修改了，过一段时间A又提一个问题给B，B也修
改了，有一天程序员A和程序员B都走了，客户觉得我的好多以前提的东西你们怎么现在的人都不知道啊？
双方都受伤害。其实，合理的架构才能保证有序的结果，一个小打小闹的团队怎么能应付日益变化的客户需求呢。
如果条件允许，我建议一个具有竞争力的团队应该是一名架构设计人员，一名DBA，3-5名中等水准的开发人员，一名美工，一名测试，其中DBA和美
工是共享人员，临时参与，测试放到一个更重要的位置，即，始终跟踪全部的客户需求，所有的修改变更都是通过测试人员，程序员和客户之间隔离开。其实这不就
是“面向对象”么？ 松耦合和紧耦合肯定不是一回事。现在很多的公司的高层人员普遍比较短视，所谓的理由就是“成本”，我的回答是：出来混迟早要还的！
现在不这么做，迟早要付出代价。