后要能够总结归类然后反馈。我在实施过程中会先将客户的问题给记录下来并且分析难以程度以及紧急程度再反馈给技术开发人员。
(2) 过滤伪需求排除不再范围内的需求，有些客户提出的要求并不是一个可行性的需求，也有一些不是在我们范围内的需求。我们这个需要明确把握，在项目实施的过程中我有几次充当烂好人，结果也没有得到什么好处，反而适得其反。先做好本职工作再在有能力的情况下去帮助客户解决问题。
(3) 技术人员要能虚心的接受实施反馈的问题，在某种情况下技术人员认为不太可能的事情但是对于客户来说是非常重要的。比如在一个表格中第一列和队列显示的内容问题，你认为第一列和第二列位置无所谓，但是对于客户来说却是非常重要，为什么这样你体会不出来，或许是习惯问题!所以技术人员要能够接受莫名的问题。
三. 表和里的问题
可能是因为我没有大局观，也可能是我没有考虑问题的本质。以前我一直做互联网方面的开发，但是个人认为这对于自己来说不是一个什么太好的事情，所以现在退居一步做一些传统行业方面的软件。我公司现在的软件方面主要是以条码,二维码,RFID 为基础的仓库管理系统和生产管理系统。但是在做互联网和传统软件上我觉得有很大的区别，这个区别不知道我自己是否理解的正确，可能也是因为我站的角度不一样。
讲一个真实的事情: 同事A和我在探讨一个项目问题的时候，我们发生了一些问题的偏岐。我们给客户实施一套仓库管理系统，难度较大。我们定好某一天去客户现场部分实施，但是项目从整体上是没有成型的，只是部分功能可以使用完全算不上一个软件。同事A却希望能够多开发一些功能界面，即使功能不好也可以，只要能够看到是那么一回事就好了,他是想让客户知道我们做了很多事情。而我认为这是一种虚假的做法，从开发多个"仿制"界面来说，本身就是一个耗费时间的过程，而且开发了对后期的真实需求的完成没有太大的作用，反而有时候会让给自己埋下很多坑。
这是一个公说公有理婆说婆有理的事情，我暂且不讨论谁对谁错。从根本上来说这是给项目推进自己挖坑，后面自己好跳下去，这是对项目的推进极为不利的。一直到目前为止我仍然认为自己的想法没有错，在多次的实施过程中客户关心的是你所有的东西完成没有，你画了很多仿制的界面对于整个项目来说仍然没有完成，不仅浪费了时间而且给自己挖了一个很大的坑。当然也不是说同事的想法错了，这个只是出发点的问题。
(1) 从公司的角度来出发我们要考虑表的问题，这个时候我们可以对客户做适当的事实隐瞒，因为这是一种策略，当然你有足够的能力就不需要这些。
(2) 项目已经开始实施，还是暴露所有的问题比较好，这个问题暴露可以不让客户知道，但是自己一定要明白这个问题的存在性和严重性。
(3) 个人觉得不要让客户产生我们快完成了的这种错觉，最好是实事求是，千万不要打肿脸充胖子，欠的总是要还的。
(4) 这是大部分人都会犯的错，这个问题小问题下次再解决，往往到了后面就忘记了这个问题，又为自己埋下了一颗地雷。暂时搁浅问题下次解决，问题也是逐步积累出来的，到了一定程度就会集中爆发。
四. 计划性
我们在发开软件的时候有这样一个功能，做生产排产计划，做过相关工作的人应该都知道：工厂在加工某个产品的时候，会先做一个排产计划，比如这周要排产什么产品，排产数量是多少，所需要领料是多少，产品的先后顺序是什么。做排产计划的目的是为了让工作更加有序的进行，在规定的期限达到相应的目的，软件开发这个功能方面我们都非常擅长。但是你真的会做计划吗?
任何事情都要有计划，这样才能保证自己的事情按照既定的目标和轨迹推进，虽然不能完全一致，但是至少让你有一个目标感!在开发和项目实施的过程中，我们往往缺少这样的计划任务，事情想到哪里做到哪里，导致所做的的事情毫无章法头绪。先做这个发现问题做不下去然后又走另外一个，最终一个都没有做成。个人做计划应该达到如下几个要求:
(1) 针对目的：做这个计划是针对什么，也就是我们的目标，我们要达到什么目标
(2) 明确任务: 这个计划是要做具体什么事情，甚至包括具体的实施推进步骤
(3) 时间限制：做计划一定要有时间限制，这个计划实施要在什么时间范围内完成