本文讨论了产品开发中需求延误的问题，指出需求方和开发方过早精细化可能导致资源浪费和延期。以一个实际案例说明，即使在紧急需求下，过于详尽的预估也可能导致不必要的工作量。文章引用乔布斯的观点，强调人们往往不知道自己真正需要什么，直到产品展示出来。最后提出，需求变化是常态，避免精细化陷阱对于减少延误至关重要。
根据大众的需要去设计产品其实是非常难的。因为在很多情况下，人们并不知道自己想要什么，所以需要你去展示给他看。
——乔布斯
01
需求延误，不仅发生在技术和产品之间，产品和业务方也时常面临这个困扰。但产品无法按时交付，最终都会归因为开发的延期。
可能有人会说：产品有时候会出很急的需求、很难实现的需求，这些情况一般都是加班加点才勉强按时交付的，更别说出bug很难解决的情况下，开发延期是常有的事。
这话没错，除了程序员要学会对需求较准确预估外，做业务的人也要对需求有全面的了解，尽量确保每个环节的交付能少一点不确定性。
其实这中间涉及到的一个问题就是：过早精细化。
需求方还没想明白，就要精确知道最后能带来多少收益；程序员还没有完全了解整个项目，就想量化最终要交付什么。
为了追求这种不确定的、不完整的精确，双方都需要花费大量精力和时间。
02
举个例子，之前有产品提过一个需求，要开发一个特别复杂的新功能，涉及的内容和类型非常多，当时只给一周时间开发，2天时间测试，时间非常赶！
当时评审说得很好，说产品上线后转化率起码提升一倍。我们团队当时连周末都没休，紧赶慢赶总算交付了，结果上线后发现人家运营根本用不着后台配置，页面也用不着那么多类型，可算是把我们坑了一把！
当然，这样的情况是很多程序员的日常，但这并不代表这就是正常的。
程序员其实是非常容易掉进精细化陷阱的，因为大部分开发人员都知道要评估整个系统，大部分情况下会精确评估，但事实常常不按我们所想的发展。
03
每个团队接收到的信息完整度是不一样的，需求文档代表的或许不是原始需求方的原始需求，甚至，就算是代表了原始需求，产品上线后他们的需求可能又会马上变化。
就像乔布斯说的：“根据大众的需要去设计产品其实是非常难的。因为在很多情况下，人们并不知道自己想要什么，所以需要你去展示给他看。”
所以直到产品上线的前一秒，或许需求都不会变化，反而产品上线后，需求可能会完全变了个样。这时候很多程序员和产品才晃过神来：之前的各种精细化设想和评估，某种程度上都是在浪费时间...
如果每次开发都精细化评估，你会一直delay，为了不延期，你就要付出更多工作之外的时间，这是一个恶性循环！
而且需求变化本是常态，一昧地追求精细化大可不必。
那么如何做才能不增加工作强度又减少需求延误呢？下次再给大家详细讲讲，也算是我工作多年来总结的几个经验吧。
-The end-
你好，我是中年码农飞哥，
我会从CTO视角讲述程序员职场/技术/学习/创业等，
分享从码农到CTO的职场和技术经验
扫 码 | 围 观 飞 哥 朋 友 圈
扫一扫
371
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
