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