文章目录需求中经常遇到的问题需求不合理解决方案需求不明确挖掘客户的真实需求我好累给我找把椅子。我要一匹跑得更快的马需求如何更优业务必须闭环数据流向需求、设计、代码不一致把需求弄明确细节明确没有需求文档就敢开发梳理需求也是工作而且是很重要的工作需求的拆解评估人天时一定要考虑周全交付期限一定要顶住项目做的很不顺手可以考虑下需求的合理性BRD、PRD、详设、SRS、SOP坑到无可救药就是跑路时其他忌讳点需求对于一个项目来说太重要了。它是项目的源动力是开发过程中方向的校准线是项目是否成功的重要判断依据。需求如此重要却又有无数的坑能够驾驭的一定是高手。需求中经常遇到的问题需求不合理客户 我想上月球?猿你该找国家航天局。。。很明显上月球的需求不合理因为程序员完不成。客户对5人项目组说 我们要做出个全国第一流的电商平台。猿。。。。。。客户我想根据用户的生日获取到用户的唯一身份信息。猿生日不能作为用户的唯一身份信息标志因为同一天有无数个人。解决方案需求不合理的情况是非常常见的这种没什么好说的鼓起勇气说明理由坚决怼回。需求不明确相对需求不合理来说更常见的是需求不明确这也是较复杂的一种情况。客户自己都不知道想做什么。客户自己都不知道想做什么太正常了你可以把客户想成白痴基本也差不多少。这时要多沟通了解需求的场景用户群里等。客户我们要做个飞天项目。飞天是个啥 阿里飞天还是挖掘客户的真实需求做项目必须要学会透过现象看本质。下面随便举几个例子。我好累给我找把椅子。一个客人跑到一家饭店发现没位置。他跟老板说“我好累给我找把椅子。”椅子不是客户的需求休息才是客户的需求。 这时候你如果给客户弄张沙发那必须赞一个。我要一匹跑得更快的马我要一匹跑得更快的马这是被所有产品经理奉为圣经的案例。马不是客户的需求快才是。所以福特造出了汽车。需求如何更优只会开发代码还是太低级一定要参与并主导方案既可以提高自己的能力同时也少挖坑。因为从技术的实现角度来说研发一定比客户想的周到完全按照客户的思路不可取很有可能跑偏了费劲不讨好后期也不好维护所以一定要主导有好的建议果断提利人利己。业务必须闭环例如我想要陆地快速运输那么火车快我们造火车吧但是造完火车发现没有铁轨是不是就费了所以业务必须闭环。数据流向数据流向也属于业务的一环既有助于理解业务也方便排查问题。为什么提这个呢?是因为有这个概念才知道重点关注这块。加油吧。需求、设计、代码不一致把需求弄明确细节明确没有需求文档就敢开发这是程序员的原则之一无论如何要把住了。要开发一定要给我需求文档否则到时候死无葬身之地。如果产品实在忙没工夫写需求文档。 最起码程序员要梳理出需求的文字描述聊天工具里面发出要产品点头确认不然背锅的一定是自己。梳理需求也是工作而且是很重要的工作拿到一份任务功能点就十几个而工期也就十几天。赶紧写代码吧否则完不成。错。要先梳理需求一条一条都列出来而且描述清楚。 用2天的时间出个清晰的文档就很可以了。然后火速开发吗还是错。然后要找领导说十几个功能十几天根本完不成。给安排2个人吧。一人4、5个功能是不是就可以完成了。这里就体现出功能列表及文档的重要性了可以直接分功能给其他人。如果一团浆糊别人帮都没法帮你。需求的拆解客户有个想法就会提出需求。可能他自己都不知道要什么你要帮他想。弄明白需求是什么之后还有可能很复杂要一步一步的拆解为多个功能点然后才能开发。这中间要多沟通。注需求文档落地后先写实现方案吗?实际也这么试过实际有点问题而且显的比较乱。正确的方法应该是先根据需求确定效果因为效果是唯一的倒着推反而简单。有时效果明确了实现方案自然就确定了甚至都不用写方案。评估人天时一定要考虑周全交付期限一定要顶住做项目可不是闹着玩定下了期限到时候交不出来东西可就死无葬身之地了。评估人天要适当的宽限一是对给公司创收二是手下的弟兄不用太紧张。人天评估当然不能太夸张因为客户绝不是傻子管理项目的都是经验丰富的老油条根本蒙不了人家。有的时候客户比较着急不断的催前交付期限。夹在中间非常难受但是无论如何难受一定要顶住这是无数次血的教训换来的经验。 如果松了口到时只能更难做。最好的办法就是沉默显示自己很为难然后商量的口吻说这个日期确实做不出来做不出来额。。。但是口一定不能松。项目做的很不顺手可以考虑下需求的合理性如果对自己开发能力比较有信心但是开发某个任务的时候困难重重怎么写都不顺手各种悖论。那么可以重新审视下需求看是否有不合理的地方导致逻辑本身就要矛盾。BRD、PRD、详设、SRS、SOP1、BRD(business requirement document)(商业需求文档)2、PRD(product requirement document)(产品需求文档)3、详设(detailed design)(详细设计)4、SRS(software requirements specification)(软件需求规格说明书)5、SOP(standard operating procedure)(标准操作步骤)对比图文档简称核心侧重点核心内容主要受众核心用途BRD评估项目能不能赚钱市场分析、投资回报率、成本收益评估投资人、高管说服投资人掏钱立项PRD提供画界面的依据业务流程、功能清单、原型图、交互逻辑设计师、开发团队给开发团队提供界面和交互依据SRS明确系统的死标准功能性需求、性能指标、安全与并发要求甲乙双方、测试团队作为项目验收和测试的唯一法定依据详设指导代码怎么写数据库表结构、API接口定义、核心算法后端开发、架构师指导开发人员具体怎么敲代码SOP规范日常怎么操作傻瓜式操作步骤、量化指标、异常处理预案一线业务人员、客服规范员工日常怎么使用系统或执行业务坑到无可救药就是跑路时一个项目坑死一个团队的事一点都不新鲜。 需求不合理需求不明确需求不细致工期紧交付要求高频繁改需求等让项目后来简直无法维护最后以失败告终。一个需求坑死个把程序员那都不是事。一个看似能做实际不合理的需求简直愁死程序员活没法干到了工期万箭齐发直指程序员只能跑路咯。其他忌讳点调研一定要细致该提的点提该明确的不明确。如果某点没弄清楚后来又叼出来了客户不会说他没提到而是会说你需求调研不明确所以一定要避过这个坑。