文章目录
- 需求中经常遇到的问题
- 需求不合理
- 解决方案
- 需求不明确
- 挖掘客户的真实需求
- 我好累，给我找把椅子。
- 我要一匹跑得更快的马！
- 需求、设计、代码不一致
- 把需求弄明确
- 细节明确
- 没有需求文档就敢开发
- 梳理需求也是工作，而且是很重要的工作
- 需求的拆解
- 评估人天时一定要考虑周全，交付期限一定要顶住
- 项目做的很不顺手，可以考虑下需求的合理性
- 坑到无可救药，就是跑路时
需求对于一个项目来说太重要了。
它是项目的源动力，是开发过程中方向的校准线，是项目是否成功的重要判断依据。
需求如此重要，却又有无数的坑，能够驾驭的一定是高手。
需求中经常遇到的问题
需求不合理
客户： 我想上月球?
猿：你该找国家航天局。。。
很明显上月球的需求不合理，因为程序员完不成。
客户对5人项目组说： 我们要做出个全国第一流的电商平台。
猿：。。。。。。
客户：我想根据用户的生日，获取到用户的唯一身份信息。
猿：生日不能作为用户的唯一身份信息标志，因为同一天，有无数个人。
解决方案
需求不合理的情况是非常常见的，这种没什么好说的，鼓起勇气，说明理由，坚决怼回。
需求不明确
相对需求不合理来说，更常见的是需求不明确，这也是较复杂的一种情况。
客户自己都不知道想做什么。
客户自己都不知道想做什么太正常了，你可以把客户想成白痴基本也差不多少。
这时要多沟通，了解需求的场景，用户群里等。
客户：我们要做个飞天项目。
飞天是个啥？ 阿里飞天，还是？
挖掘客户的真实需求
做项目必须要学会透过现象看本质。下面随便举几个例子。
我好累，给我找把椅子。
一个客人跑到一家饭店，发现没位置。他跟老板说，“我好累，给我找把椅子。”
椅子不是客户的需求，休息才是客户的需求。 这时候你如果给客户弄张沙发，那必须赞一个。
我要一匹跑得更快的马！
我要一匹跑得更快的马！
这是被所有产品经理奉为圣经的案例。
马不是客户的需求，快才是。所以福特造出了汽车。
需求、设计、代码不一致
把需求弄明确
细节明确
没有需求文档就敢开发
这是程序员的原则之一，无论如何要把住了。
要开发一定要给我需求文档，否则到时候死无葬身之地。
如果产品实在忙，没工夫写需求文档。 最起码程序员要梳理出需求的文字描述，聊天工具里面发出，要产品点头确认，不然背锅的一定是自己。
梳理需求也是工作，而且是很重要的工作
拿到一份任务，功能点就十几个，而工期也就十几天。
赶紧写代码吧，否则完不成。
错。要先梳理需求，一条一条都列出来，而且描述清楚。 用2天的时间出个清晰的文档就很可以了。
然后火速开发吗？
还是错。然后要找领导，说十几个功能十几天根本完不成。给安排2个人吧。一人4、5个功能，是不是就可以完成了。
这里就体现出功能列表及文档的重要性了，可以直接分功能给其他人。如果一团浆糊，别人帮都没法帮你。
需求的拆解
客户有个想法，就会提出需求。可能他自己都不知道要什么，你要帮他想。弄明白需求是什么之后，还有可能很复杂，要一步一步的拆解为多个功能点，然后才能开发。
这中间要多沟通。
评估人天时一定要考虑周全，交付期限一定要顶住
做项目可不是闹着玩，定下了期限到时候交不出来东西可就死无葬身之地了。
评估人天要适当的宽限，一是对给公司创收，二是手下的弟兄不用太紧张。
人天评估当然不能太夸张，因为客户绝不是傻子，管理项目的都是经验丰富的老油条，根本蒙不了人家。
有的时候客户比较着急，不断的催前交付期限。夹在中间非常难受，但是无论如何难受，一定要顶住，这是无数次血的教训换来的经验。 如果松了口，到时只能更难做。
最好的办法就是沉默，显示自己很为难，然后商量的口吻说，这个日期确实做不出来，做不出来额。。。但是口一定不能松。
项目做的很不顺手，可以考虑下需求的合理性
如果对自己开发能力比较有信心，但是开发某个任务的时候困难重重，怎么写都不顺手，各种悖论。
那么可以重新审视下需求，看是否有不合理的地方，导致逻辑本身就要矛盾。
坑到无可救药，就是跑路时
一个项目坑死一个团队的事一点都不新鲜。 需求不合理，需求不明确，需求不细致，工期紧，交付要求高，频繁改需求等，让项目后来简直无法维护，最后以失败告终。
一个需求坑死个把程序员那都不是事。
一个看似能做，实际不合理的需求，简直愁死程序员，活没法干，到了工期，万箭齐发，直指程序员，只能跑路咯。
