软件系统设计过程中，最重要的就是对用户需求的把握，只有清楚了解用户到底想要的是什么，才有可能开发出用户满意的系统，用户需求如果没有把握对，就像客户找你建一座房子，你以为是A这样子的，客户实际想要的可能是B这样子的，自然做不出用户满意的系统。
为了准确把握用户的需求，根据不同的实际情况有不同的方法，比如访谈，调查问卷，实地观察、查阅历史资料，开会讨论，原型确认等。
项目背景
我们公司是一家电子元器件贸易商，主要业务模式为将国外品牌的电子元器件通过项目协同设计的方式分销给国内的制造企业及设计公司。两年前，我们公司自主开发了一套内部使用的销售过程管理系统（内部名称为COP系统），我作为IT部程序组经理，担任了这个项目的系统分析师角色，负责系统需求收集、分析及系统设计工作。
COP系统定位于公司内部客户服务人员的协同作业平台，主要用户为销售和技术人员。系统为销售人员提供项目机会的创建、项目机会跟进、项目机会转化功能。而对于技术人员，如何鼓励他们更多更好地服务有价值项目，同时避免资源过度集中，以实现公司整体价值最大化正是本系统着重要解决的问题。在此之前，我们的销售人员有在另外一套系统上（内部名称为DIT系统）上管理机会，新开发的COP系统是需要取代DIT系统的。
我们采用过的方法
为了把握用户的真实需求，开发出用户真正满意的系统，我们采用了如下几个方法：
01用户问卷调查
系统用户是全公司所有销售人员，人员众多，且人员分布在全国各地，不便直接访谈。为了收集大家对旧系统的改良建议及对新系统的期望，我们设计了一套调查问卷，透过OA系统发布到每个人的待办任务中。问卷回收后，我们将所有改善建议分类统计，将用户反馈最多的问题，加入到了新系统的开发需求中，比如速度，是用户普遍反馈的需要改善的问题。
02关键用户访谈
对于核心的业务流程，比如提交原厂注册时的具体要求，我们采用了关键用户访谈的方式。我们首先透过高层领导出面，指定了几个关键用户，然后我们直接找关键用户当面了解具体需求。
03高层领导汇报
我们有了初步想法后，找高层管理汇报了我们的系统设想，同时也了解到高层领导对系统的管理需求，比如在什么场景中需要审批，审批的层级都是由高层领导确定的。
04旧系统反向工程
对于旧系统，我们查看了历史文档及源代码，了解到旧系统中对于机会阶段的定义及机会属性字段，这些都沿用到新系统中，以方便迁移历史数据，及减少用户的学习成本。
05开会讨论
对于涉及到多个部门之间衔接的流程，我们采用召集各部门领导开会讨论的方式来确认需求。比如DR流程（有些厂商为了避免各个代理商之间恶性竞争，针对每个最终客户的业务机会要求做备案登记，专门用语为申请DR，一家代理已经做了DR，其他代理商就不能再做了）。
原先我们采用的是各销售自己到原厂注册的方式，为了提高效率我们将这个注册工作集中到一个客服人员身上，对于如何提交资料，如何审批，如何反馈结果这个流程我们找销售经理及客服经理最终确认了下来。
经验教训总结
有效的方法
上面我们采用的方法中，效果最好的是关键用户访谈，从关键用户身上，我们了解到系统的核心业务流程，及用户最急迫希望改进的功能，比如机会要汇总到项目层管理。同时，在与用户沟通的过程中，用户也加强了对我们的理解与支持，后面正式上线前，都是关键用户帮我们做的培训，效果比我们IT部门自己培训效果还要好。
无效的方法
高层领导汇报方式是需要改善的，第一次汇报时，我们是用PPT文字的方式，将我们打算开发怎样的功能，我们需要改善的地方向领导做了汇报，领导给出了一些指示。在临近上线前，我们再次给领导作了一次汇报，这一次我们系统已经开发完成，所以直接做了系统演示，领导看到系统界面后，提出需要增加一个客户活跃度字段，这个字段需要我们根据该客户活动内容自动计算。我们只好重新设计开发此功能，系统延后了一个月才上线。
对于给领导汇报，我们觉得可以做如下改善：
- 开发中期需要定期给领导汇报项目进展情况，对于开发时间比较长的项目不能只在开发前汇报一次，开发后汇报一次
- 给领导汇报系统，最好是有形象化，图形化的界面，在系统开发出来前，最好是用系统原型，给领导一个直观的，可交互的界面，有利于领导理解系统并提出需求。
