需求延误，程序员该背锅吗？

根据大众的需要去设计产品其实是非常难的。因为在很多情况下，人们并不知道自己想要什么，所以需要你去展示给他看。

 

——乔布斯

 

01

 

需求延误，不仅发生在技术和产品之间，产品和业务方也时常面临这个困扰。但产品无法按时交付，最终都会归因为开发的延期。

 

可能有人会说：产品有时候会出很急的需求、很难实现的需求，这些情况一般都是加班加点才勉强按时交付的，更别说出bug很难解决的情况下，开发延期是常有的事。

 

这话没错，除了程序员要学会对需求较准确预估外，做业务的人也要对需求有全面的了解，尽量确保每个环节的交付能少一点不确定性。

 

其实这中间涉及到的一个问题就是：过早精细化。

 

需求方还没想明白，就要精确知道最后能带来多少收益；程序员还没有完全了解整个项目，就想量化最终要交付什么。

 

为了追求这种不确定的、不完整的精确，双方都需要花费大量精力和时间。

 

02

 

举个例子，之前有产品提过一个需求，要开发一个特别复杂的新功能，涉及的内容和类型非常多，当时只给一周时间开发，2天时间测试，时间非常赶！

 

当时评审说得很好，说产品上线后转化率起码提升一倍。我们团队当时连周末都没休，紧赶慢赶总算交付了，结果上线后发现人家运营根本用不着后台配置，页面也用不着那么多类型，可算是把我们坑了一把！

 

当然，这样的情况是很多程序员的日常，但这并不代表这就是正常的。

 

程序员其实是非常容易掉进精细化陷阱的，因为大部分开发人员都知道要评估整个系统，大部分情况下会精确评估，但事实常常不按我们所想的发展。

 

03

 

每个团队接收到的信息完整度是不一样的，需求文档代表的或许不是原始需求方的原始需求，甚至，就算是代表了原始需求，产品上线后他们的需求可能又会马上变化。

 

就像乔布斯说的：“根据大众的需要去设计产品其实是非常难的。因为在很多情况下，人们并不知道自己想要什么，所以需要你去展示给他看。”

 

所以直到产品上线的前一秒，或许需求都不会变化，反而产品上线后，需求可能会完全变了个样。这时候很多程序员和产品才晃过神来：之前的各种精细化设想和评估，某种程度上都是在浪费时间...

 

如果每次开发都精细化评估，你会一直delay，为了不延期，你就要付出更多工作之外的时间，这是一个恶性循环！

 

而且需求变化本是常态，一昧地追求精细化大可不必。

 

那么如何做才能不增加工作强度又减少需求延误呢？下次再给大家详细讲讲，也算是我工作多年来总结的几个经验吧。

 

-The end-

 

你好，我是中年码农飞哥，

我会从CTO视角讲述程序员职场/技术/学习/创业等，

分享从码农到CTO的职场和技术经验

 

扫 码 | 围 观 飞 哥 朋 友 圈