当前我们承接的软件项目中不少项目出现的延期交付的情况，分析原因不外乎以下几种情况： 1、需求不清楚，需求边界没有界定好，需求交付物质量不高——对需求的描述不细致，不清晰； 2、技术架构不合理，系统稳定性，扩展性不强，应付不了客户的需求变动； 3、质量保障和控制措施没有真正实行——单元测试，功能符合性检查，代码规范性检查，功能测试、集成测试没有做； 4、试运作的保障工作没有到位，无法及时响应和解决试用过程中出现的问题； 而上述问题最重要就是需求问题，需求问题其实包括以下内容的： 1、用户需求；2、业务用例；3、IT需求（需求规格说明书，含原型） 当前我们的项目经理或需求分析师与需求的思维都是定位在编写IT需求，没有仔细去分析与思考用户需求，业务用例，而当前的情况下大多数客户的对接人都不能系统的提出用户需求，更不能要说业务用例了，所以我们项目经理或需求人员总是要求去现场调研，最后调研过程是没有沟通和确认点，人云亦云，有价值的信息很少，最后把责任推给客户，导致项目延期或项目失败，最后公司来承担后果。项目经理、需求人员、售前方案和销售人员要工作和思想都要前移，适应当前软件项目的市场环境，其实用户需求，业务用例都是有一系列的法律和法规、规章制度做支撑的，我们可以从招标网下载同类型的项目的招标需求来加快业务的熟悉和理解。

所以，当拿到需求时，不要先调入纠结控件布局，按钮位置这种细节中，可以先将设计思路上升一个维度，思考以下几个问题：

1. 这个需求解决了用户什么问题（问题导向）

2. 这个需求给产品带来什么好处，例如收入，用户增长，行业方向推动（目的导向）

3. 这个需求是否围绕着现有用户画像制定的（不脱离用户群，减少对未知领域的不可掌控度）从这几个思路入手，不要去试图寻找一种通用的解决方案，一期先搭好框架，收集用户反馈，试水后，根据反馈进行第二阶段的调整，细化。可以节省在纠结上耗费的时间。

今天先写这么多，有点晚了。后续思考一下，需求应该怎么样入手？用什么样的人？在什么时间跟客户沟通？沟通过程中要注意哪些问题？如何确认需求点？