软件企业管理改革专项方案.doc

滴入式企业管理改革方案
3月16日
个人认为现在企业问题处理方案就是：
扩大研发部，强化项目管理部，整合开发测试部！
市场迫切要求我们考虑发展问题，可我们却习惯了原有管理模式，二者矛盾凸显了管理不足，其关键就是开发部这锅温水煮熟了研发部和项目管理部这两只青蛙！
因为软件企业常见发展路子，开发部在成立之初，其实就负担了研发部和项目管理部部分工作，一路沿袭下来，大家已经习惯了这种格局，也习惯了开发人员集编程、研发、项目管理多项技能于一身现实状况。
比如开发人员业务知识，本身是了解需求一个能力，却也成了研发人员对需求质量要求不高一个资源，在企业早期，这其实是个好事，研发和开发沟通效率会比较高，简单一说，大家就明白活该怎么干了，不过现在，这却成了大问题，因为二者之间默契造成了工作量模糊，无法量化。而且开发人员自由度过高，也对产品质量造成了不小挑战，出了问题更是难查！到底一个任务单要多久能够完成，成了一个迷，进而造成企业管理无法高效运行连锁困局。
现在情况下，我认为，大刀阔斧改革易乱，火力全开式全线招人也有些过于盲目！应该是在现有管理模式下，有针对性，渐进式处理问题！
首先，招人确实是处理现在“产能不足”一个好手段，但科技企业不一样传统企业，大量招人看似是个处理思绪，但我们也要注意其弊端。
IT企业，每个人相当于传统企业“设备、操作工、原材料、半成品质检”等多个资源组合，对于个人素质要求较高！大量进入新人，对我们培训机制、其它相关管理制度全部是一个考验！
比如说代码规范，现在我们几乎是空白，技术框架也不完善，进来人员各有各代码特色，产能大了，增加代码维护量就是一个难题！势必会影响正常工作开展，形成更大积累！而且考评仓促，也很轻易造成招到职员良莠不齐。
何况现在看似需要人，但实际上，我们真需要这么多人吗？谁能回复？哪个部门不是拍脑袋提出招聘需求？有什么数据支撑？而且也要考虑进人轻易出人难，未来对企业社保、薪酬负担也将是个沉重话题。所以必需理性、有序、有针对性安排人员入职。
如周总所讲，改革就是处理“干什么，怎么干，谁来干”这多个问题，现在反应比较集中就是研发部没有做好“干什么”引导工作，不管是新产品研发，还是现有项目标需求研发，各部门全部有不少意见。这里我们要明白研发苦，也要正视这确实是我们短板。另外，后两个问题其实是个“怎么管”问题，这里面包含到关键是项目管理部！
综合而言，我认为现在最关键问题就是“头太小”，研发部、项目管理部人员配置确实是严重不足，很多应有作用没有发挥，很多事情没人做，或做不到位，才造成了现在这么情况。
就说研发部，相关同事确实是相当辛劳，一个人应付数十家市场，业务沟通、进度跟进、界面原型、业务公式等等，天天工作确实是很大！不过从本质上来讲，我们产品研发还是浮于表面，跟着用户跑还是常态，一个项目下来，初始需求弄完，没有一两次大改，数次小改不算完，比如深圳电子系统，我们加班加点做两种交易模块，用户根本就没有用！引导用户谈不上，走不到用户前面，那我们想象中产品化，那就只能是镜中花，水中月！
，我们尝试着把研发下放到开发部，包含现在让客服部负责维护性研发工作，其实是个不错思绪，让研发部工作压力小部分，能够腾出手做点其它事情。不过对初管研发工作人（包含原来开发部一部分同事，和现在客服部）没有引导，因为业务上不熟，和用户沟通经验缺乏等多种原因，造成需求质量参差不齐！
而且没有章程，研发人员全员对用户贴身服务，看似是提升服务质量，每个用户问题全部有些人跟，有些人处理，但其本质是让需求变更愈加严重，研发能力不足造成问题并没有处理，反而是恶化了！因为对外口径太多，项目管理部其实对于哪家用户谁在跟，出了什么问题，怎么处理，极难得到正确信息！
而对于腾出来研发人力资源，目标引导也不够，新产品研发稍有点阻力，就感觉她们没事做了，就又开始弄些项目压到她们身上，久而久之，研发部又回到了原来情况，而其它辅助研发人员也在一起忙，研发出来需求只是量增，却并没有实现质升，造成开发愈加忙，却愈加忙没有效率，没有质量，所以我们开发团体显得有些乱了章法！
再者，兼职做研发人员和开发人员本身就是一个团体，人际关系本身就离太近，原来还有研发部、测试部等形成掣肘，现在变了，一个团体，什么人员全部配齐了，全部在这个小圈子里，很轻易形成小作坊式生产模式，各自为政，每个团体全部认为自己负责那个用户是上帝！自已事情是最关键！某人干一件事优先级，更多在意交待这个事人和她关系好坏，而不是企业实际项目需要，以致于不是高层出面，人力资源几乎调动不了，项目优先级完全失控！长鞭效应进而造成下游测试、客服全部跟着陷入恶性循环！
其实这也凸显了我们现在一个用人方法误区，就是信任你，就把你们扔到对应岗位，自力更生，且看谁能笑傲江湖！过分强化独挡一面价值观，让大家学会了“死顶”，这么方法即使是使个人能力最大化发挥，不过没有一个综合管理部门，没有信息搜集、汇总、分析渠道，一个人一个打法，不成章法！无法形成协力！
项目管理部就不多说了，优先级失控，其实就是项目管理部失控，项目管理部本身应该管理很多东西，比如项目标优先级安排，开发进度管控，开发成本管控等等，可是现在做到了什么？能做到什么？
我们症结关键所在就是研发部和项目管理部，这两个部门确实该补充部分优质人力资源！不过要建立在合理部门改革基础上！
比如研发部，行业类软件业务研发到底要干什么？个人认为大致分为四个层次四件事：
改善：从我们现有项目、售后中吸收营养，改善产品易用性，稳定性等，这里我提议应该把我们数百万装机量用户端，网站等“意见反馈”功效完善起来，这里我们浪费了太多量化数据搜集机会，对于我们产品兼容性、稳定性、易用性等改善而言，我们简直是天天在扔钱！
引导：从我们用户那里吸引营养，结合我们经验，吃透其业务需求，给出超出用户预期产品处理方案。
前瞻：关注行业动态，吸收行业经验，做到快速跟进，人有我有，人有我优；
未来：关注多种渠道提供舆情，掌握国家、各地相关法律法规动态，分析其中市场信号，比如为何天津能出来一个渤海交易所，是不是国务院给了天津海滨区一个“先行先试”制度。能读懂这其中信号，我们就能够走在同行前面，不仅仅是做到人有我有，人有我优，而是人无我有！
我们现在只做了改善，引导中一小部分，其它两种几乎没有，而且相关未来，个人认为研发团体最少应该有一至两个人做好其它本职员作同时，倾向于这个方向，而且最终形成专职人员！
比如，下面几幅相关“大宗商品交易平台”baidu指数图，我们能从中解读到什么信息？

业务研发是方向盘！还有更关键，就是发动机！技术研发！
现在汽车发动机全部有个人驾驶习惯学习技术，这是一个自我调整和改良！一样，我们技术应用也应该有其自我调整和改良机制，而且技术研发应该是一个垂直深入研发，开发、测试各个步骤部门，不仅仅是框架研发，新技术引进，而应该是在不一样步骤，有不一样关注点，不一样关注频度，比如:
在研发部，技术研发人员不仅要做框架研发，新技术引进，还能够改良研发人员信息搜集、需求、原型文档制作工具，甚至能够提供更多新技术Demo供研发人员脑洞大开；
在开发部，技术研发人员要制订技术标准，开发规范，并经过走审，抽检等确保代码质量等；
在测试部，技术研发人员要帮助制订压力测试用例，压力测试工具开发等。
讲了问题，说了思绪，可最终怎样改善？漏斗状滴入式改革！
项目管理部
研发部
开发部
B/S
C/S
移动
基础
业务研发
新产品
业务研发
架构研发

测试部
客服部
新技术引进

开 发 规 范 管 理

业务、技术
问题
量化数据
反馈

图，其实就是扩大研发部，强化项目管理部，整合开发部！
方向把握，由研发部产生任务单不再仅仅是用户项目需求，也包含新产品开发任务，甚至是技术框架、新技术应用任务，需求文档中不仅包含业务、原型，还应该包含UI交互、技术要求、所用框架等技术细节，由技术研发部相关人员利用代码走审，抽查复检等机制确保技术步骤推进正常开展。
资源管理，项目管理部依据企业综合情况，调整产品研发单和项目需求单进入开发阶段百分比，安排全部任务单优先级，调整内外部需求单人力资源百分比，可控可调整，逐步修正现在恶性循环，而且确保新产品研发。
产能优化，开发部、测试部则把B/S、C/S、移动产品部整合成一个大部门，不再分立太多产品线，给每个小团体反复设置相同职位，造成无须要人力资源浪费。
由项目管理部依据人力资源情况，确定处理某张任务单适宜团体，安排项目经理接单，再由项目经理管理和调配人力资源，开发人员则对全部任务单一视同仁，依据任务单交期和优先级处理工作。而且开发内部也不用对于人力资源使用再发生矛盾，只要按项目部优化级排序，考虑怎样锁定、释放相关人员实现人力资源最大化利用即可。
在这种体制下，项目管理部能够把控了解全部任务单安排、完成情况，进而能够搜集到对应人力资源不足量化数据，从而形成有数据支撑岗位补充需求，而不是全员认为缺人，就大跃进式招聘！
整合以后，可能会感觉开发测试人员群体太过庞大，项目管理部是否能够管控了，其实这里面不用担心，这种管理模式并不排斥短期小型开发团体，而且能够结合开发人员技术、专长排序，最大改变其实就是事后管理变成事前管理，要把计划落实到人力资源使用；
系统安全，安全是没有绝正确，而收缩全方面知识了解人群，降低“高危”人群，其实是降低安全风险一个最好性价比方案。开发人员只了解其负责具体模块开发任务。

电子交易开发中心