正确的理解和管理需求及其变更 
问题1: 从项目的需求搜集开始，业务专家搜集和提出基于整个业务的需求体系，但是在从初始的需求转化为软件特性和功能的过程中，由于业务专家和技术人员的沟通不充分或者需求描述不完善，导致技术人员对需求的理解产生曲解，从而影响该软件完成后不符合用户提出的真实需求。 问题2: 从初始的业务需求转化为软件特性的过程中，缺乏有效的跟踪和管理，导致软件功能特性与用户需求脱节。  做软件致电：010-52895342  
问题3: 在项目过程中，用户提出改进的需求或者增加软件功能和特性，项目组在了解需求后，对软件架构进行调整或者重构，但是如此频繁的重复下来，需求来源不清楚，软件规格书未反应需求变化，或者接受需求但未调整项目的整体进度，导致一些混乱情况的发生。    
上述1，2个问题其实都是对需求跟踪和管理机制的不完善引起的。在任何一个软件开发过程中，都充分地强调了需求管理的重要性。因此，在项目初期，相对花比较多的时间做需求的搜集和跟踪，完善业务人员和技术人员的沟通机制是很重要的。这会减少大量的由于曲解需求导致软件不符合用户需求从而返工造成的人力和物力的浪费。避免这种情况产生的一种方式是，在项目立项后，由专人或专门的团队(这些人必须是了解该项目业务领域的知识，并且有相关的技术经验)搜集该项目的原始需求，然后和技术专家(或团队)进行充分的沟通和讨论，保证技术专家对原始需求乃至一些用户要求的细节有完整而正确的理解，接着技术专家就会根据原始需求的文档，根据对需求的理解撰写软件规格书，在写的过程中，应该不断让业务专家一定程度的参与(例如审稿或一定程度的修订，并且参与评审)，这样的软件规格书才能为进一步正确地进行软件分析设计提供素材和指导。    
对第3个问题，用户提出的对软件进行改进可能是经常有的事情，遇到这种情况，有两种处理办法。一种办法是用户提出的改进建议在下一个发布版本中实现。但是用户往往要求能够在当前版本中进行实现。第二种办法就是认真考虑用户用户的建议，用各种方法来满足用户的需求，其中包括系统重构。在这些过程中，可能会造成一些混乱。其实归根结底还是需求的跟踪机制不完善引起的。建议采用需求和变更跟踪工具(比如rational clearquest)来对需求和变更进行全过程的跟踪，这样在形成需求文档的时候，每个需求来源和其状态都是非常清楚的。  

配置管理 

配置管理占据了越来越重要的角色，对文档，图形，代码和各种项目数据进行分类管理，并对不同的人拥有的权限进行控制，方便技术人员对其负责的配置项进行创建，提交和修改，提高项目整体的运作效率。但是在配置管理中也存在着一些问题：  

问题1: 没有制定好 文档 ，图形，代码应放的位置，配置项命名比较随意，无权限控制，造成各配置项存放混乱，寻找不易。    
问题2: 培训和支持不充分，对配置管理工具的用法不了解。目前配置管理工具很多，比如大家常用的vss，可能相对比较熟悉一些。但是诸如CVS和ClearCase等工具，由于软件功能非常复杂，并且对国内用户来说易用性比较差，虽然功能强大，但是没有真正派上用场。  

对第一个问题，在小型项目中可能尚不明显，但是在大型项目中，由于各种文档，代码等非常多，如果不能进行正确的配置管理，很有可能被弄得一团糟。因此，在项目启动后，经过技术人员之间的讨论，在配置项的命名规定，目录结构，存放位置等达成共识，因为这些在具体使用上还和开发工具，开发语言等是密切相关的，在讨论的时候也应充分考虑这些因素，给技术人员在使用它们的时候提供最大的便利。当然，为了安全起见，大型项目中，权限的控制也是很重要的。另外，在一些情况下，如果没有权限控制，项目成员可以随意修改其它文件，这样可能会导致一些混乱情况的发生。  

第二个问题，对ClearCase等大型的配置管理工具，如果不作充分的研究和大量的培训，对软件配置和使用不当，缺乏对组织内人员的统一培训，因为配置管理工具是几乎每个人都会用到的，这样造成的问题会相当多。在ClearCase中，比如基线的概念，可能很多人都不甚了解，还有动态视图，静态视图，集成视图，流等，这些如果不能做充分而细致的培训，技术人员会感到相当的困惑，如果支持不到位或在使用中的问题无法解决，会造成项目进度的延迟乃至停滞。所以，在对待此类问题上，培训和支持的工作是必不可少的，虽然可能会在初期浪费一些资源，但是磨刀不误砍柴功，组织内人员都掌握了强大工具的使用方法，将会极大地提高开发效率和节省时间。  。  
文档 

国内进行软件开发从最初的完全不重视文档，到后来吸取无数的经验教训后，对文档的重视又被提高到前所未有的地步。但是不少公司对应该写多少文档，怎么写文档不能把握好，因为技术人员往往对文档方面的任务是抵触的，认为不如多抽点时间专注在技术方面，写文档纯粹是浪费时间。但是文档却是必不可少的，应该怎样处理好这种矛盾呢? 事实上，这种矛盾天生就是难以化解的，因为技术人员对技术和相关情况最了解，其它人很难撰写这些文档，项目经理所需要做的是，通过斟密的项目进度安排，给技术人员留出一些时间来书写文档(在工作时间而不是在加班时间里完成，否则难免会有怨言的)，并在规定的进度下进行评审。在Rup和Xp中，对文档的看法有些不一样。在RUP中，对文档非常的重视，每个阶段都有一些工件是必须要评审和交付的，其中除了代码外，绝大部分都是文档，写起来相当费时费力。而在XP流程中，强调的是通过代码和面对面的沟通，来加强团队的协作性，文档除了一些设计性和需要保留的资源需要撰写外，只是起到一些辅助性的作用。但不管怎样，重要和必要的文档总是要写的。让每个技术人员了解文档的重要性，合理的分配和预留写文档的时间，都是可以一定程度上化解矛盾的做法。   如何保持工件的一致性(同步)   在软件开发过程中，不断有新的工件产生，而且有些工件随着一些变更的发生，就需要进行更新，但工件数量太多，一则维护更新不容易，另外有些工件只是项目结束后参考性的资源，立即更新也不必要，求大求全则会一定程度上占用项目资源，耽误进度。因此，一个建设性的建议就是，对必要的工件，如 需求规格书，产品定义书，概要设计书，详细设计书.....等工件是一定要根据项目和评审情况立即进行修订和更新的，但是，对另外一些衍生的工件，如用户指南等工件，虽然在开发流程中，可能是在每个阶段都必要写的，但是却可以在评审进行前集中进行更新一些，避免频繁修订造成的资源占用和进度延迟。  
重视风险管理 

建立风险管理体系，让风险意识贯穿整个流程体系，对不断出现的可能的风险进行预测，分析和讨论对策，划分风险级别，采用各种方法来降低风险变成现实后对整个项目所造成的损失。 

风险管理体系是一个项目预防可能潜在风险的一个很好的保障方式，在项目初期，根据项目情况如资金，人员和可能的进度对整个项目的风险作一个预先的评估，采用的方式可以是以项目经理为中心，集体讨论的形式来进行。在讨论结束后形成一份risk list，
项目经理 

由此整理出一份文档，即风险管理文档。在项目进行当中，随着情况不断变化，项目经理应该不断组织一些专题会议，对风险进行讨论，并统一对策。这样在风险变成现实后，整个项目组不至于束手无策，而是可以采取一些补救的措施来把风险可能造成的损失降到最低。   关于周报和月报 

在很多公司中，都要求开发人员填写周报和月报，以便在项目周会，月总结上了解每个人任务的进展情况和对人员进行考核。但是技术人员总是对此类工作不胜其烦，往往敷衍了事，填几个比较大的任务(如开发XX系统等)，而且一连几周都是如此，这样对了解项目进展和对人员考核的参考作用就失去了意义。 虽然技术人员比较反感写这类东西，但是还是必须要写的。应该怎样化解此类矛盾呢？实际上，这类任务主要是人的因素在发挥作用。要想达到有效性的目的，对项目成员进行一定程度的指导和培训是必要的。例如，一种比较好的方法就是，可以推荐项目成员进行daily plan一类每日计划的编写，每个人对每日工作任务进行划分和规划时间，然后在每日工作结束后对预先计划和完成情况进行对比，并在下一个工作日进行改进。坚持下去，项目成员必然在工作计划和完成情况间越来越接近，养成良好的习惯，这样不仅在保障进度上人的正面因素可以被大大增强，而且在编写周报和月报时就有所依据而不是匆匆了事，能够发挥应有的效果。 

了解培训的重要性 

在各类组织中，都会对员工进行一定程度的培训。在项目立项过程中，就应该考虑人员配备情况。比较理想的情况当然是项目组每个成员都对该项目的技术了如指掌，对软件开发流程比较了解，相互之间能够进行充分的沟通，能充分理解沟通对象的意图等等。但是理想情况往往不是经常存在的。由于IT行业的人员具有一定的流动性，而且项目组的人员配备往往不是非常固定的。因此，项目经理应该充分考虑到这些因素，在项目成员比较确定后，如果有一些新手，就必然要进行一些技术，业务，开发流程等方面进行有计划的正式培训，当然，还应该指定每个老资历的项目成员带1-3个新手，这样，新手在各方面都能够迅速提高，也能促进整个项目按照预先计划高质量地完成。

两年前政府提出“互联网+”的行动计划后，传统企业纷纷踏入这波浪潮，插上了互联网的翅膀。在今年，政府的工作报告上出现了“人工智能”，“智能制造”，“大数据”等科技名词，又一波高科技将推动了传统产业的转型升级。无论是早前的电商、APP，还是当下被炒的火热的物联网、人工智能，企业都需要对其技术领域有所了解，避免盲目走弯路。
编今天主要跟大家分享企业选择软件外包公司时需要避免踩的坑！
网上有很多的外包平台，发布需求，全国各地的服务商都会来竞标抢单。但是建议大家选择本地的开发公司，一来是方便考察，二来是节约沟通成本，很多需求通过面对面的沟通才能节约时间。
那么，在这个过程中，选择靠谱的外包公司合作很重要，我列举几个方面说明靠谱的外包公司的特点，以供大家判断：
首先、谨慎分析需求，再给报价
很多客户在初次简单的沟通后就询价，比如：“我想要做一个类似滴滴打车的APP，开发费用需要多少”，如果乙方在初次见面就能给你一个报价，比如20多万。八成是不靠谱的，也是不负责任的。报价并不是凭感觉，而是要通过剖析开发的周期来计算的。
靠谱的团队不会乱承诺什么都能做，而会先让产品经理与客户沟通，理顺开发需求。而这个过程，来来回回，至少会持续三五次的当面沟通。最后才是给出合理的报价方案。
其次、有明确的开发时间节点
合同备注清楚明确的开发时间节点很重要。比如，原型设计周期、UI设计周期、开发文档以及数据库设计周期、平台框架搭建周期、平台各个功能模块开发周期等等，只有做到细化，才对开发进度能有全局把控。
第三、原型确认再动工
靠谱的团队，会告诉你，原型确认后再进入研发。因为在原型确认的过程中，往往是很耗时的，不靠谱的团队很可能为了缩短工期，隐瞒某些不明确的需求点，往往就是这样的敷衍带过，导致后面需求不封闭，出现扯皮的事情。
第四、交付开发文档
编写开发文档是标准的开发过程，这是技术人员必备的技能，文档简洁与否倒是其次，最重要的目的就是让后续开发人员可以读懂。关于这一点我们也建议在合同里就写好。
第五、合理的付款方式
选择合理的付款分期比例很重要，我们建议采用分期，按照开发过程中的不同阶段付款，
比如：
①在启动原型设计前，先付定金10%，完成产品原型，基本就确定需求了。
②启动UI设计时，再付20%，完成UI设计基本上客户知道做完成什么样了。
③开发完成并通过测试后付40%。
④交付正常运行一周后付20%。
⑤三个月维保期结束后付10%。
切忌甲方首次付款比例不要超过50%，如果遇到乙方不责任，后面沟通很被动。
北京软件开发公司华盛恒辉专注于软件行业的外包资源开发、整合及服务。面向行业客户，我们提供高度个性化的行业解决方案，帮助客户实现信息化管理最佳实践，以满足客户需求。行业解决方案涵盖的领域包括：软件定制、软件开发、航天、军队、政府、铁路、大型企业、文物考古等领域在产品工程解决方案领域，北京华盛恒辉科技有限公司的开发理念是以“满足客户需求”为根本出发点，开发出“最满意”的软件产品。