软件企业管理改革方案

《软件企业管理改革方案》由会员分享，可在线阅读，更多相关《软件企业管理改革方案（8页珍藏版）》请在装配图网上搜索。

1、滴入式公司管理改革方案2015年3月16日个人觉得目前公司的问题解决方案就是：扩大研发部，强化项目管理部，整合开发测试部！市场迫切要求我们考虑发展问题，可我们却习惯了原有的管理模式， 两者的矛盾凸显了管理不足，其核心就是开发部这锅温水煮熟了研发 部和项目管理部这两只青蛙！由于软件企业常见的发展路子，开发部在成立之初，其实就承担了研 发部和项目管理部的部分工作，一路沿袭下来，大家已经习惯了这种 格局，也习惯了开发人员集编程、研发、项目管理多项技能于一身的 现状。比如开发人员的业务知识，本身是理解需求的一种能力，却也成了研 发人员对需求质量要求不高的一种资源，在公司初期，这其实是个好 事，研发和开

2、发的沟通效率会比较高，简单一说，大家就明白活该怎 么干了，但是现在，这却成了大问题，因为两者之间的默契造成了工 作量模糊，无法量化。而且开发人员的自由度过高，也对产品质量造 成了不小的挑战，出了问题更是难查！究竟一个任务单要多久可以完 成，成了一个迷，进而造成公司管理无法高效运行的连锁困局。目前的情况下，我觉得，大刀阔斧的改革易乱，火力全开式的全线招 人也有些过于盲目！应该是在现有管理模式下，有针对性的，渐进式 的解决问题！首先，招人确实是解决目前“产能不足”的一个好手段，但科技企业 不同传统企业，大量的招人看似是个解决思路，但我们也要注意其弊 端。IT企业，每个人相当于传统企业的“设备、操作

3、工、原材料、半成品 质检”对我们的培训机制、大量进入新人，对于个人素质要求较高！ 等多种资源的组合，其它相关管理制度都是一个考验！比如说代码规范，目前我们几乎是空白，技术框架也不完善，进来的 人员各有各的代码特色，产能大了，增加的代码维护量就是一个难题！ 势必会影响正常工作开展，形成更大的积累！而且考核仓促，也很容 易造成招到的员工良莠不齐。何况现在看似需要人，但实际上，我们真的需要这么多人吗？谁能回 答？哪个部门不是拍脑袋提出的招聘需求？有什么数据支撑？而且 也要考虑进人容易出人难，未来对公司的社保、薪酬负担也将是个沉 重的话题。所以必须理性、有序、有针对性的安排人员入职。如周总所讲，改革就

4、是解决“干什么，怎么干，谁来干”这几个问题，目前反映比较集中的就是研发部没有做好“干什么”的引导工作，无 论是新产品的研发，还是现有项目的需求研发，各部门都有不少意见。 这里我们要明白研发的苦，也要正视这确实是我们的短板。另外，后 两个问题其实是个“怎么管”的问题，这里面涉及到的主要是项目管 理部！综合而言，我觉得目前最主要的问题就是“头太小”，研发部、项目 管理部的人员配置的确是严重不足，很多应有的作用没有发挥，很多 事情没人做，或者做不到位，才导致了目前这样的情况。就说研发部，相关的同事确实是相当辛苦，一个人应付数十家市场， 业务沟通、进度跟进、界面原型、业务公式等等，每天的工作确实是 很

5、大！但是从本质上来讲，我们的产品研发还是浮于表面，跟着客户 跑还是常态，一个项目下来，初始需求弄完，没有一两次大改，数次 小改不算完，比如深圳电子的系统，我们加班加点做的两种交易模块， 客户根本就没有用！引导客户谈不上，走不到客户前面，那我们想 象中的产品化，那就只能是镜中花，水中月！.2014年，我们尝试着把研发下放到开发部，包括现在让客服部负责 的维护性研发工作，其实是个不错的思路，让研发部的工作压力小一 些，可以腾出手做点其它的事情。但是对初管研发工作的人（包括原 来开发部的一部分同事，以及现在的客服部）没有引导，因为业务上 不熟，与客户沟通的经验缺乏等各种原因，导致需求质量参差不齐！

6、并且没有章程，研发人员全员对客户贴身服务，看似是提高服务质量， 每个客户的问题都有人跟，有人处理，但其本质是让需求变更的更加 严重，研发能力不足造成的问题并没有解决，反而是恶化了！因为对 外口径太多，项目管理部其实对于哪家客户谁在跟，出了什么问题， 怎么解决的，很难得到准确的信息！而对于腾出来的研发人力资源，目标引导也不够，新产品研发稍有点 阻力，就感觉他们没事做了，就又开始弄些项目压到他们身上，久而 久之，研发部又回到了原来的状况，而其它辅助研发的人员也在一起 忙，研发出来的需求只是量增，却并没有实现质升，导致开发更加忙， 却更加忙的没有效率，没有质量，所以2014年我们的开发团队显得 有些

7、乱了章法！再者，兼职做研发的人员和开发人员本身就是一个团队，人际关系本 身就离的太近，原来还有研发部、测试部等形成掣肘，现在变了，一 个团队，什么人员都配齐了，都在这个小圈子里，很容易形成小作坊 式的生产模式，各自为政，每个团队都觉得自己负责的那个客户是上 帝！自已的事情是最重要的！某人干一件事的优先级，更多在乎交待 这个事的人和他的关系好坏，而不是公司实际的项目需要，以致于不 是高层出面，人力资源几乎调动不了，项目优先级完全失控！长鞭效 应进而导致下游的测试、客服全部跟着陷入恶性循环！其实这也凸显了我们目前的一个用人方式的误区，就是信任你，就把 你们扔.到相应的岗位，自力更生，且看谁能笑傲江

8、湖！过度强化独挡一面的 价值观，让很多人学会了 “死顶”，这样的方法虽然是使个人能力最 大化的发挥，但是没有一个综合的管理部门，没有信息搜集、汇总、 分析的渠道，一个人一个打法，不成章法！无法形成合力！项目管理部就不多说了，优先级失控，其实就是项目管理部失控，项 目管理部本身应该管理很多东西，比如项目的优先级安排，开发进度 管控，开发成本管控等等，可是现在做到了什么？能做到什么？ 我们的症结重点所在就是研发部和项目管理部，这两个部门确实该补 充一些优质的人力资源！但是要建立在合理的部门改革的基础上！比如研发部，行业类软件的业务研发究竟要干什么？个人觉得大致分 为四个层次四件事：改进：从我们现有

9、的项目、售后中吸取营养，改进产品的易用性，稳 定性等，这里我建议应该把我们数百万装机量的客户端，网站等的“意 见反馈”功能完善起来，这里我们浪费了太多量化数据的收集机会， 对于我们产品的兼容性、稳定性、易用性等改进而言，我们简直是每 天在扔钱！引导：从我们的客户那里吸引营养，结合我们的经验，吃透其业务需 求，给出超出客户预期的产品解决方案。前瞻：关注行业动态，吸取行业经验，做到快速跟进，人有我有，人 有我优；未来：关注各种渠道提供的舆情，掌握国家、各地的相关法律法规动 态，分析其中的市场信号，比如为什么天津能出来一个渤海交易所， 是不是国务院给了天津海滨区一个“先行先试”的制度。能读懂这其 中

10、的信号，我们就可以走在同！人无我有行的前面，不仅仅是做到 人有我有，人有我优，而是我们目前只做了改进，引导中的一小部分，其它两种几乎没有，而且 关于未来，个人觉得研发团队至少应该有一至两个人做好其它本职工 作的同时，倾向于这个方向，并且最终形成专职人员！比如，下面几幅关于“大宗商品交易平台”的百度指数图，我们能从 中解读到什么信息？业务研发是方向盘！还有更重要的，就是发动机！技术研发！现在的汽车发动机都有个人驾驶习惯学习技术，这是一种自我调整与 改良！一样的，我们的技术应用也应该有其自我调整与改良的机制， 并且技术研发应该是一个垂直深入研发，开发、测试各个环节的部门， 不仅仅是框架研发，新技术

11、引进，而应该是在不同环节，有不同的关 注点，不同的关注频度，比如：在研发部，技术研发人员不仅要做框架的研发，新技术的引进，还可 以改良研发人员的信息搜集、需求、原型文档的制作工具，甚至可以 提供更多的新技术Demo供研发人员脑洞大开；在开发部，技术研发人员要制定技术标准，开发规范，并通过走审， 抽检等保证代码质量等；在测试部，技术研发人员要协助制定压力测试用例，压力测试工具开 发等。滴入式改革！讲了问题，说了思路，可最终如何改进？漏斗状 的业业架新 基务务产构研础研品研 研发部发发发 新技开术 引发进规项目管理部 范业务、技术管问题开发部量化数据理B/S反馈 C/S移动测试部客服部如图，其实就

12、是扩大研发部，强化项目管理部，整合开发部！方向把握，由研发部产生的任务单不再仅仅是客户的项目需求，也包 括新产品的开发任务，甚至是技术框架、新技术的应用任务，需求文 档中不仅包含业务、原型，还应该包括UI交互、技术要求、所用框 架等技术细节，由技术研发部相关人员利用代码走审，抽查复检等机 制保证技术流程推进的正常开展。资源管理，项目管理部根据公司的综合情况，调整产品研发单和项目 需求单进入开发阶段的比例，安排所有任务单的优先级，调整内外部 需求单的人力资源比例，可控可调节的，逐步的修正目前的恶性循环， 并且保证新产品的研发。产能优化，开发部、测试部则把B/S、C/S、移动产品部整合成一个大 部

13、门，不再分立太多的产品线，给每个小团队重复的设置相同职位， 造成不必要的人力资源浪费。由项目管理部根据人力资源情况，确认处理某张任务单的合适团队， 安排项目经理接单，再由项目经理管理和调配人力资源，开发人员则 对所有任务单一视同仁，根据任务单的交期和优先级处理工作。而且 开发内部也不用对于人力资源使用再发生矛盾，只要按项目部的优化 级排序，考虑如何锁定、释放相关人员实现人力资源最大化利用即可。 在这种体制下，项目管理部可以把控了解所有任务单的安排、完成情 况，进而可以搜集到相应的人力资源不足的量化数据，从而形成有数 据支撑的岗位补充需求，而不是全员觉得缺人，就大跃进式的招聘！ 整合之后，可能会感觉开发测试人员群体太过庞大，项目管理部是否 可以管控的了，其实这里面不用担心，这种管理模式并不排斥短期的 小型开发团队，而且可以结合开发人员的技术、专长排序，最大的变 化其实就是事后管理变成事前管理，要把计划落实到人力资源的使用；系统安全，安全是没有绝对的，而收缩全面知识了解人群，减少“高 危”人群，其实是降低安全风险的一个最佳性价比方案。开发人员只 了解其负责的具体模块开发任务。电子交易开发中心.