本文作者将以几十年的从业经验来告诉广大的汪们：当你跟程序猿提需求时，程序猿到底在想什么？

普通人跟程序猿的交流，往往会产生一些意想不到的结果：

程序猿之妻：「老公，下班回来买六个苹果，如果有卖西瓜的，买一个。」

程序猿：「好的，老婆大人。」

程序猿下班后，在超市里看到了卖西瓜的，然后买了一个苹果回家了。

这类奚落程序猿的小故事大家应该都看过，虽说有点夸张，但也反应了程序猿怕老婆思维严谨的本质。

然而，在现实生活中，由于程序猿「喜爱加班」的天性，导致与程序猿交流最多的并不是程序猿之妻，而是产品汪！而交流最多的主题，就是「产品需求」。

下面，果果就以几十年的从业经验来告诉广大的汪们：当你跟程序猿提需求时，程序猿到底在想什么？

是否违背逻辑？

这里说的逻辑并不是产品逻辑，而是「程序猿逻辑」。产品的逻辑往往是从用户的角度出发，提供高效便捷的使用体验，有时候也难免天马行空。但程序猿的逻辑则以「严谨」著称，一丝不苟。思维方式的不同，对同一个问题就难以达成共识。例如原来的产品中有根据搜索词的动植物属性作为类别展示结果的功能，现在如果你有一个需求，想在用户搜索「竹子」的同时也能把熊猫展示出来，在你提需求前，先做好跟程序猿大战三百回合的准备吧。

能实现吗？

当讨论需求点时，程序猿的脑子就会像翻字典一样快速遍历自己了解的所有技术，并逐一匹配需求中的对应功能。当需求中的所有关键功能都一一映射为技术点后，技术可行性基本上就没问题了。然而，如果有个别技术点超出程序猿的「技术字典」收纳范围，合格的程序猿会说「我先调查下这几个功能点」，但也有的程序猿会以「这几个功能点无法实现」为由而直接拒绝需求。针对这样的程序猿，一般的产品汪往往只能祭出竞品的对应功能予以反击，但长期关注果果公众号的产品汪则能提出完整的技术方案，给程序猿造成暴击伤害。

需求拆分和模块化

对于哪些可以在之前的功能上稍作调整就可以实现的新功能，往往都是程序猿喜闻乐见的，这种需求一般都会很容易落地。因为这种需求不会引入太大的工作量，维护的工作量也较低。产品汪在设计需求时，如果每个版本的需求都循序渐进，或者新需求是基于其他功能实现，则更容易营造这种开发体验。当然，这种需求「可遇而不可求」。所以，程序猿为了让自己在后面的开发过程中更轻松，往往会将需求按功能点进行拆解，并形成逻辑上相互独立的小功能模块。这些小模块就像「积木」，后期可以通过不同的复用和组合拼装成不同的形状。

性能是否可以接受？

程序猿在评估技术可行性的同时，还会对需求带来的性能损耗做评估。针对后台来说，可能会重点考虑网络请求的峰值、同时最大并发连接数、带宽和数据处理耗时等；针对终端来说，则考虑的是对CPU、内存等硬件资源的消耗，移动终端则还要考虑耗电等问题。如果你刚想到一个24小时用GPS监控用户位置的需求，我劝你还是只想想就好。

这肯定不是需求的真面目！

作为一个程序猿，这点觉悟还是要有的。面对产品汪的朝三暮四，程序猿在完成需求功能点的同时，在代码中如何设计良好可扩展性来应对需求变更，也是需要重点考虑的问题。总不能真的跑到天台上让你们立字据吧？！

#专栏作家#

给产品经理讲技术，微信公众号（pm_teacher），人人都是产品经理专栏作家。资深程序猿，专注客户端开发若干年，对前端、后台技术略懂，热衷于对新的科技领域的探索。

本文原创发布于人人都是产品经理。未经许可，禁止转载。