软件企业管理改革方案.docx

软件企业管理改革方案

软件企业管理改革

1

2020年4月19日

文档仅供参考，不当之处，请联系改正。

文档仅供参考，不当之处，请联系改正。

PAGE2

PAGE2

2020年4月19日

滴入式公司管理改革方案

3月16日

个人觉得当前公司的问题解决方案就是：

扩大研发部，强化项目管理部，整合开发测试部！

市场迫切要求我们考虑发展问题，可我们却习惯了原有的管理模式，两者的矛盾凸显了管理不足，其核心就是开发部这锅温水煮熟了研发部和项目管理部这两只青蛙！

由于软件企业常见的发展路子，开发部在成立之初，其实就承担了研发部和项目管理部的部分工作，一路沿袭下来，大家已经习惯了这种格局，也习惯了开发人员集编程、研发、项目管理多项技能于一身的现状。

比如开发人员的业务知识，本身是理解需求的一种能力，却也成了研发人员对需求质量要求不高的一种资源，在公司初期，这其实是个好事，研发和开发的沟通效率会比较高，简单一说，大家就明白活该怎么干了，可是现在，这却成了大问题，因为两者之间的默契造成了工作量模糊，无法量化。而且开发人员的自由度过高，也对产品质量造成了不小的挑战，出了问题更是难查！究竟一个任务单要多久能够完成，成了一个迷，进而造成公司管理无法高效运行的连锁困局。

当前的情况下，我觉得，大刀阔斧的改革易乱，火力全开式的全线招人也有些过于盲目！应该是在现有管理模式下，有针对性的，渐进式的解决问题！

首先，招人确实是解决当前“产能不足”的一个好手段，但科技企业不同传统企业，大量的招人看似是个解决思路，但我们也要注意其弊端。

IT企业，每个人相当于传统企业的“设备、操作工、原材料、半成品质检”等多种资源的组合，对于个人素质要求较高！大量进入新人，对我们的培训机制、其它相关管理制度都是一个考验！

比如说代码规范，当前我们几乎是空白，技术框架也不完善，进来的人员各有各的代码特色，产能大了，增加的代码维护量就是一个难题！势必会影响正常工作开展，形成更大的积累！而且考核仓促，也很容易造成招到的员工良莠不齐。

何况现在看似需要人，但实际上，我们真的需要这么多人吗？谁能回答？哪个部门不是拍脑袋提出的招聘需求？有什么数据支撑？而且也要考虑

进人容易出人难，未来对公司的社保、薪酬负担也将是个沉重的话题。因此必须理性、有序、有针对性的安排人员入职。

如周总所讲，改革就是解决“干什么，怎么干，谁来干”这几个问题，当前反映比较集中的就是研发部没有做好“干什么”的引导工作，无论是新产品的研发，还是现有项目的需求研发，各部门都有不少意见。这里我们要明白研发的苦，也要正视这确实是我们的短板。另外，后两个问题其实是个“怎么管”的问题，这里面涉及到的主要是项目管理部！

综合而言，我觉得当前最主要的问题就是“头太小”，研发部、项目管理部的人员配置的确是严重不足，很多应有的作用没有发挥，很多事情没人做，或者做不到位，才导致了当前这样的情况。

就说研发部，相关的同事确实是相当辛苦，一个人应付数十家市场，业务沟通、进度跟进、界面原型、业务公式等等，每天的工作确实是很大！可是从本质上来讲，我们的产品研发还是浮于表面，跟着客户跑还是常态，一

个项目下来，初始需求弄完，没有一两次大改，数次小改不算完，比如深圳电子的系统，我们加班加点做的两种交易模块，客户根本就没有用！引导客户谈不上，走不到客户前面，那我们想象中的产品化，那就只能是镜中花，水中月！

，我们尝试着把研发下放到开发部，包括现在让客服部负责的维护性研发工作，其实是个不错的思路，让研发部的工作压力小一些，能够腾出手做点其它的事情。可是对初管研发工作的人（包括原来开发部的一部分同事，以及现在的客服部）没有引导，因为业务上不熟，与客户沟通的经验缺乏等各种原因，导致需求质量参差不齐！

而且没有章程，研发人员全员对客户贴身服务，看似是提高服务质量，每个客户的问题都有人跟，有人处理，但其本质是让需求变更的更加严重，研发能力不足造成的问题并没有解决，反而是恶化了！因为对外口径太多，项目管理部其实对于哪家客户谁在跟，出了什么问题，怎么解决的，很难得到准确的信息！

而对于腾出来的研发人力资源，目标引导也不够，新产品研发稍有点阻力，就感觉她们没事做了，就又开始弄些项目压到她们身上，久而久之，研发部又回到了原来的状况，而其它辅助研发的人员也在一起忙，研发出来的需求只是量增，却并没有实现质升，导致开发更加忙，却更加忙的没有效率，没有质量，因此我们的开发团队显得有些乱了章法！

再者，兼职做研发的人员和开发人员本身就是一个团队，人际关系本身就离的太近，原来还有研发部、测试部等形成掣肘，现在变了，一个团队，什么人员都配齐了，都在这个小圈子里，很容易形成小作坊式的生产模式，

各自为政，每个团队都觉得自