2_lr软件企业常见问题的系统化解决方法

软件企业常见问题和系统性解决方法林锐博士://@[e-mail]@[e-mail]上海漫索计算机科技有限公司Page2目录1.1.1.1.软件企业常见问题u1.1软件挣钱难的问题u1.2组织结构和人力资源问题u1.3跨部门协作问题u1.4流程改进问题u1.5需求问题u1.6设计和开发问题u1.7软件项目管理问题u1.8管理工具问题2.2.2.2.集成化管理模型3.3.3.3.软件企业战略管理十项措施u3.1企业问题分析u3.2优化盈利模式u3.3领域需求研究u3.4成果标准化与复用u3.5反省过错不二过u3.6优化组织结构u3.7优化人力资源u3.8优化并推行流程制度u3.9建设并推行管理平台u3.10提升全员技能4.4.4.4.集成化流程介绍5.5.5.5.集成化研发管理平台MainSoftMainSoftMainSoftMainSoft介绍详见《如何管理软件企业》第2版Page31.11.11.11.1软件挣钱难的问题u一、承接合同项目，为甲方开发软件系统。–市场上能够承接到的合同项目，利润很小。而高利润的项目则被有权势的人或机构掌控。–项目需求和验收受制于客户。开发过程中，客户会不断变更需求，导致开发方不断修改软件，项目验收被不断地延后，开发方成本（包括机会成本）越来越高。–缺乏规模复制效益。由于合同项目都是针对特定客户（甲方）的特定需求而签订的，即使做成功了一个合同项目，也很难“复制这个项目”直接卖给下一个客户。u二、开发并销售通用软件产品–凡是面向个人的通用软件产品，由于盗版原因，几乎无法靠卖软件来挣钱。–只有企业级软件产品不容易被大量盗版，可以走“通用软件产品盈利模式”，难度非常高。开发方必须把自己打造成为“企业级应用的领导者”，否则客户不信任你的方法和产品，产品就无法通用。于是客户提出的个性化需求越来越多，回到了“合同项目盈利模式”。u三、运营模式–互联网公司的业务太容易被模仿，同质化竞争严重。每个领域都死掉了成千上万的相同业务的互联网公司，最终只有少数几家可以活下来，极大地浪费社会财富。–互联网公司的另一个大缺点是太浮躁，过分追求快而导致根基不扎实，国内绝大多数互联网公司的软件研发管理，要比传统软件公司混乱得多。u软件企业要想多挣钱，靠“开源节流”。“开源”主要靠优化盈利模式，使得现有的技术和资源产生更高的效益。“节流”主要靠改进管理，使企业的所有经营环节更加合理，减少不必要的成本，省下来的钱也就成了利润。Page41.21.21.21.2组织结构和人力资源问题u组织结构常见问题：–组织结构臃肿，工作效率低下。–岗位和职责不清晰，而且经常变动，好多人不清楚自己的岗位和主要职责。责、权、利不明。–项目矩阵关系比较复杂，项目成员不知道听“职能经理”还是“项目经理”指挥。u人力资源的常见问题：–无法发挥团队中每个人的价值，老抱怨员工素质低。–重要岗位用错人，例如把技术水平很高，但是情商低的人提拔到领导职位。不仅荒废了这个技术高手，而且带乱了队伍。–优秀人才难招到，也难以留住。–难以准确地评价研发人员的业绩，缺乏有效激励措施。Page51.31.31.31.3跨部门协作问题u企业重要的部门如“研发、营销、服务”普遍存在跨部门协作问题：–跨部门人员相互不熟悉对方的工作流程和规范，沟通费劲。–上游传达给下游的需求不够清楚，各方理解有偏差，上游不断变更需求，导致下游不断修改工作成果，频繁浪费。–上游不能及时了解下游的工作进展情况和负荷，不断传达新的任务，下游忙不过来。–由于各部门的目标和利益不同，导致跨部门合作产生矛盾。例如营销部门为了使客户满意、增大销售额，答应了客户太多的需求，或者承接了过多低效益的项目，致使研发部门耗尽有限资源，疲于奔命，哪个项目都做不好。u要求：–企业不仅要让每个部门制定内部工作流程，还要把各部门的流程整合起来，形成整个企业的集成化流程。–下游一定要有制约上游的机制，否则上游没有做好工作，将使苦难堆积到下游。–跨部门协作的接口人，不仅要熟知本部门的流程，而且还要了解对方部门的流程，才能够主动灵活地处理比较复杂的跨部门问题。Page61.41.41.41.4流程改进问题u大多数软件公司成立最初几年，几乎没有流程，基本靠人治。等公司规模稍大后，就基于CMMI搞流程改进，不知不觉把软件流程搞得很复杂，貌似完善却难以推行，走向了另一个极端。u软件公司既希望有完善的流程来指导重大项目的研发，规避风险，又希望有快捷的流程适用于“短平快”的项目。软件公司需结合CMMI理论和敏捷开发思想来优化流程。Page71.51.51.51.5需求问题u客户方的问题：客户说不清楚需求，双方误解需求，客户经常变更需求。u开发方的问题：–没有熟练掌握需求工程的各项技能，如需求调研、需求分析、需求定义、需求评审、需求跟踪、需求变更控制等。–公司没有在战略高度上重视“领域需求研究”，仅仅把需求分析当做项目中的一个环节看待。每个项目都从零开始做需求分析，被动地等待客户提出需求、变更需求。而没有主动研究领域需求，提炼出领域需求知识财富，从而引导客户消费。Page81.61.61.61.6设计和开发问题u技术架构和平台策略问题：–同一系列的产品、甚至一个产品之内，采用了多种编程语言，和多种差异较大的技术。受制于原有的落后技术，先进技术难以无缝引入。若放弃老技术，用新技术重做，风险太大，不敢。若放弃新技术，延后老技术开发新功能，又不甘心。–在很多项目中重复地开发相似的功能，互不通用，浪费生产力。没有提炼标准件，没有建设公共技术平台，就无法取得软件复用带来的高效率和高质量。u软件设计问题：–软件用户界面设计是大多数软件公司的弱项，人们不知道怎样才能设计出易用、美观的用户界面，凭着个人的经验与感觉设计软件的用户界面，这样产生的界面往往得不到大众用户的认可。–只关心功能设计，却不会综合考虑产品的性能、可扩展性、可复用性等。–软件设计应当“细到什么程度”很难把握。太粗了的话，对后续开发工作的指导价值不高；反之倘若太细的话，耗费时间就比较多，如果后面不断改进设计的话，前面的设计浪费太多。u软件实现问题：–程序员的编程风格差异较大，代码质量有高有低。大多数软件机构没有编程规范，即使有的话，程序员也没有很好地按规范编程。–相当多的程序员没有养成自我测试的习惯，尤其是对自己代码进行“单步跟踪调试”的习惯。等到测试人员发现Bug之后自己再去改错，此时改错的代价已经增加了很多倍。Page91.71.71.71.7软件项目管理问题u软件项目管理的独特之处是，它是建立在软件工程基础之上的专业化项目管理。一个没有软件工程经验的人，即使他通读PMBOK，哪怕是MBA毕业，也管不好软件项目。u软件项目管理的范围主要包括：立项管理，结项管理，任务进度管理，项目评审，变更控制，软件质量管理，软件配置管理和文档管理等。每个领域都存在若干常见问题。u大多数软件企业的项目管理可以用“三拍”来概括：领导拍脑袋做决定；项目经理拍胸脯作保证；员工拍屁股后走人。u一、项目经理的问题：–大多数项目经理是搞技术出身的，没有系统性地学习过软件项目管理。他们不知道究竟要管什么，更谈不上有好的管理方法，基本上靠自己的威望和感觉来管理项目。这种情况下，项目的进度和质量都难以预测。–国内大部分软件企业的项目经理有带头干活的权利和义务，他们对项目的进度和质量负最大责任，但是没有财务权。他们不会关心成本也不懂得如何控制成本。因管理混乱、工作效率低下、进度延误等问题导致“隐性成本”不断增加，钱在不知不觉地流失。u二、立项管理问题：–自主产品的立项问题：没有“立项调研、可行性分析、立项评审”活动，主要靠公司领导独断；项目团队只知道干活，却不了解产品的开发背景和目标，不清楚用户期望的产品应该是什么样的；在开发过程中经常迷失方向，导致进度延误、费用超支等问题。–合同项目的立项问题：客户需求不清晰、合同内容空洞；开发方在签订合同时给出了一些空头承诺，在实际执行时却难以兑现这些承诺。Page101.71.71.71.7软件项目管理问题u三、结项管理问题：–项目结束时，都记得要吃顿饭，却忘记了总结知识财富、经验教训，用于下个项目。–开发人员干完活后，不知道自己的工作成果产生多大的效益，缺乏成就感。不能对员工的业绩进行公正考核，不能很好地激励员工。–项目团队解散后，原项目遗留的问题没有人处理了，把毛病留给客户。u四、任务进度问题：–许多项目经理肩负重要的开发工作，他们往往把注意力集中在自己的开发工作上，却不知给组员们分配合适的任务。–项目成员汇报工作时，记流水帐，应付了事。懒得动脑筋分析项目遇到的一些问题，例如某些任务的进度延误了，不分析为什么延误了，就顺延。导致问题越积越多。–项目实际执行情况与原定的项目计划严重脱节，领导、客户、营销人员、开发团队都不了解项目真正的状况，项目计划形同虚设。u五、项目评审问题：–没有界定哪些是“决策评审”哪些是“技术评审”，没有清晰的评审准则和评审人员要求。每次评审会议都请来很多人，大家七嘴八舌，无法形成结论，浪费很多人的精力。Page111.71.71.71.7软件项目管理问题u六、软件配置管理问题：–有些软件公司竟然不使用软件配置管理工具（如SVN、CVS等），用最原始的“复制文件或覆盖文件”方式来保存代码和文档，经常出现“版本混乱、文件无法追溯历史”等低级问题。–不少软件公司已经按照CMMI要求制定了软件配置管理规范，该规范在理论上比较完善，面面俱到，但是实际操作比较麻烦，没有突出重点。久而久之，人们厌烦后就逐渐放弃了规范，按自己的习惯来操作，留下了隐患。u七、软件质量管理问题：–有些软件公司没有软件质量管理的流程制度，开发人员把完成功能当成终极目标。用户在使用软件的过程中发现许多Bug，导致开发方的纠错性维护代价很高。–有些软件公司虽然很重视软件质量，按照CMMI的要求建立了流程制度，但是效果不明显。人们搞不清楚软件测试、技术评审、质量保证的作用和关系。不懂得内建高质量，却靠修补Bug的方式来提升质量，代价比较高。–很多人误以为提高软件质量是质量部门的责任，没有意识到任何开发人员、管理人员都会对质量产生影响，都要对质量负责。另外，质量管理人员的权力比较小，很难推动质量改进措施。–没有及时反省过错、预防犯相似的过错。例如在软件研发过程中不断地产生大量相似的缺陷，然后花费大量时间、精力找出缺陷，再消除缺陷，是巨大的浪费。Page121.71.71.71.7软件项目管理问题u八、变更控制问题：–难以拒绝客户和上级领导的不合理变更要求，项目内部亦随意变更设计和代码等，严重影响项目的开发进度和质量。u九、管理工具问题–大部分软件公司没有对管理工具进行规划和统一部署。各部门、各项目采用自己熟悉的管理工具，分别用于管理客户问题需求、项目信息、任务进度、代码库、文档库、测试与缺陷跟踪等等，管理工具之间各不兼容，形成信息孤岛。有些工具很老旧了、不好用，但是有数据存在，既不能淘汰，又不能更新。结果这么多杂乱的工具非但成不了财富，反倒成了包袱，十分头痛。–企业需建设与流程配套的集成化管理平台，监控所有项目和人员的工作情况，不断积累知识财富，而且提供更高级的统计分析和决策依据。u软件企业常见问题总结：–本节所述问题在软件行业普遍存在，我们不要等到出了问题之后，再头痛医头、脚痛医脚。软件行业需要系统性的企业管理方法，避免常见问题一而再、再而三地发生。Page132.2.2.2.软件企业集成化管理模型u集成化管理模型自顶而下划分三层：思想理念，战略管理，集成化流程和工具。u第一层：思想理念–主要论述：企业根本目标，企业道德，管理目标（正确决策和正确执行），管理基本方法（法治和人治），企业管理的经济学原理，如何赢得客户。目的是让企业全员对