一家公司发展的胡言乱语

精彩

后面咋办，我们这也是安全第一，每次都是等重大版本变更才来个底朝天的改。但是每次业务前瞻性又做得不够，导致后续需求的跟进使代码，结构变得相当UGLY，支撑困难

有的公司会将开发的管理跟项目经理拆分下来。我之前待过个公司就是这样的

项目经理完全负责项目的需求和需求拓展，但是不负责管理开发人员，项目经理可以带个组，这个组人不用多，几个人就好，只负责跟客户接洽需求和谈需求的工作量，维护项目运转，包括售前和售后。

开发单独存在个开发经理全权负责开发人员，根据技术栈的不同，分为java大组和c++大组，存在个大组长。每个技术大组下按模块划分技术小组，存在小组长，小组长跟大组长直接负责，大组长对开发经理负责，大组长的职务为开发控制，和管辖下的小组沟通配合提供协助，并且负责技术架构重构和技术难题的领导攻关。

项目经理接到需求或项目，跟客户谈判成功后发回完整的项目规划书和需求规格书，并责成自己的一个组员为需求接口人，负责开发人员和客户之间的业务疑点沟通。每个需求的工作量的谈判，有技术大组长组织具体开发人员和开发小组长进行评估。 技术大组长总体跟项目经理趋近于平级，但是项目经理更有话语权。

项目经理和开发经理问题归你调控

测试部拿到测试任务进行功能测试，出了BUG反馈给开发人员，一轮测试后，开发人员修改后提交新的版本，知道版本在测试部通过，BUG数对2个边都加点要求，要求开发人员需要一个月最多只能出几个，测试部一个月至少要测出几个。

测试部测试通过后，项目经理结合自己的维护人员开发人员选择具体时间对新版本进行上线和割接，也可以在现场加个测试服务器，现场需求接口人负责将新版本代码升级部署后进行部分验证，然后没有问题后，割接上线到正式的生产机。

感觉你们公司发展还是挺快的呢

我认为在质量方面的度量可以引入发布后或者上线后的某级别以上的Bug率作为对QC和开发的共同评测指标。

楼主可以写小说去了。

团队大了,管理的问题凸显.


有意思哦,期待楼主的继续!

针对一个需要重构的项目.
建议:
成立一个新的项目组.保留原有项目组成员中既懂业务又懂技术的
其他成员按情况安排.

旧项目组:只保留1-2个人进行维护.

感觉按bug数发奖金不太靠谱。

是不太靠谱，哈哈。我们公司以前搞多，但是容易造成对立矛盾，反而进一步降低了生产力

楼主这个过程起码要10年。