最近做的东西比较纯粹、直接，比如写爬虫抓数据，写程序脚本等等。但是突然接需求和与需求人沟通的时候，发现存在各种问题，导致需求延期、沟通扯皮等等问题。其中也有自身原因，也有需求人的不足。现在分析下情况，记下来，且当教训来鞭策自己吧。
需求设计缺陷
从需求人手中拿到原型，接下来肯定是技术与需求人过一下，如果有问题，尽早提出并解决。当时犯的毛病就是，没有仔细分析原型，认为到了开发时遇到问题，再沟通解决也不晚，其实不然，秉着问题越早提出越好的原则，认真分析原型，发现问题，反馈需求人是很有必要的。否则到开发时，后果小则加功能项目延期，大则项目夭折都是非常痛苦的。分析如下：
1、原型代表着需求人直接想要得到的东西；
2、原型直接关系到技术实现方面可能会遇到的问题；
3、在前两者来看，一方面是需求，一方面是实现，如果沟通不好，很容易扯皮；
4、技术角度来看，可能开发人员更熟悉其细节，要权衡利弊，提前说明可能会遇到的问题；开发人员对需求了解不充分
很多技术人员犯的一个毛病就是，自己开发的功能，不知道用户什么时候会用，什么情况下会去用，甚至有的开发人员都不知道自己开发的功能具体是干嘛的，提高了什么，改变了什么，只是一味的为了开发而开发，殊不知开发人员对需求的了解，注定整个需求的成败。分析如下：
1、开发人员必须了解该需求是什么情景下会用，频率如何，发生异常要如何处理；
2、开发人员在了解该需求的情况下，权衡整体项目可能会影响到的业务点提出疑问；
3、站在技术角度分析需求，如果有更优的可行方案，及时提出并沟通；
4、以上直接影响开发人员对需求的开发时间、结果以及产生的价值；需求完成后及时求反馈
需求做完了，任务交工了，是不是以为就完事了？这么想的结果肯定是悲剧的。很多技术人员犯的一个问题就是：需求提交后，不问需求人做的如何，用的如何等等问题。如果你做的需求花费了你十成的精力，但反馈只有一成，你是否会觉得自己做了太多的无用功？谁都想自己的贡献与回报成正比，这样才证明你做的东西有价值，很多时候我们想想，我们做需求是为了什么，初衷和结果是否和自己期盼的一样？做需求得到的结果不亚于这几种：1、完善流程；2、提升效率；3、提升用户体验等等，我们应该思考，做完这个需求，得到的是什么？如果是完善了业务流程，那就要分析之前的业务流程和完成后的对比，用户用的是否方便、顺手了？如果是提升了效率，那就要比较前后的数字比例。如果是提升了用户体验，可能最大的反馈就是：不错，用的真爽！这些情况我们都应该在心里有个谱，否则不管对自己还是对于需求都是不利的。
1、完成需求后，及时向业务人员寻求反馈；
2、思考需求前与完成后达到的效果，最好出数据做比较，更优说服力；
3、如果完成后的与完成前相差无几，权衡人力与时间，类似的需求慎重考虑；写了这么多，算是对自己犯过的错做一下分析与总结，以免以后再犯类似的问题，其实，做每件事，多分析、思考，选取最优的解决方案，才能事半功倍！
