从一名开发者的角度看待产品需求的“烦恼”

 

    想来，工作已经2年有余了，从进入公司的第一天开始，“产品需求”这个名字就一直萦绕在耳边，这也难怪，做产品开发这个行当，就注定要与“产品需求”打好交道，否则，只能给自己增加无尽的烦恼和忧愁，下面简单说下自己与“产品需求”之间的这点经历。

 

    自己首先从修复产品的功能缺陷开始切入我们的产品，此时对需求的理解无外乎“正确”与“不正确”，因为既有的需求已经确定，但产品没有按照确定的需求工作，我的工作呢，就是修正这些“不正确”的代码，让他们按照“正确”的方式执行。

 

    紧接着，可以从事一些简单需求的实现，所谓简单，指的是主体功能之外的一些小的细节功能，此时尚不知“产品需求”的真正厉害，总之，按照给定的细节实现方案进行代码编写，工作便可顺利完成。当然，其中也不乏出现一些需要与产品经理讨论的需求，这主要仍旧局限于自己个人技术能力的有限或者技术实现的难度等，一般情况下，前者会在直属上级的指导帮助下顺利解决，而后者往往通过略微变更需求的方式解决，最差劲的情况就是没有伸缩的余地，那就只能硬着头皮将功能实现。

 

    说着说着，已经工作了半年时间，前面点的日子相对轻松，接下来就要转入新产品的开发工作了，从此开始，如同带上紧箍咒一般……

 

    经过几轮的需求讨论，需求文档终于有了雏形，经过需求评审、设计评审后，新产品开始开发，其实对于主体功能来说，与需求并无太大的出入，问题最多的当属数量庞大的偏之细节，但有趣的是，在我们开发人员的眼中，对这两种需求的态度，与产品经理、实施人员存在很大程度上的不同，你道为什么？用句客户的常用语，便是“总感觉操作起来不是太方便……”，你道是怎么个不方便法？极有可能是因为页面的一个操作按钮的位置摆放问题，或者又是某个输入框的长度大小感觉不合适等等……

 

    一开始，自己真的有一股比较大的压抑感，因为自己编写代码，设计界面，往往带有很强的自我主观感，可能是自己的某种喜好，于是就反应到了功能的实现细节中，而就是这种出于自然的流露，却给自己一而再再而三地带来麻烦，于是自己陷入到此起彼落的需求反馈和需求讨论中，不但让自己信心受挫，更增加了自己工作的任务量……或许大家也会有同感吧。

 

    再难熬的工作，也会有完工的一天，经过近一年的开发，新产品顺利结项了，伴随一路的烦恼而来的却是一起争吵、讨论的朋友，还是有很大收获的。

 

    新产品发布，接下来需要面对的就是针对不同用户进行的个性化修改，相对通用版本来说，个性化版本的随意性更强，客户反应度更高，而且对于一个开发者来说，可能挑战更大，有的时候，可能连客户都不太确定自己所表达的意思是否是自己心仪的需求，这就给开发带来了非常大的压力，刚刚实现的需求，往往因为产品经理的意见而重新返工，过了产品经理这道坎，又可能会因为客户的意见而重新再次开发，紧赶慢赶如期完成，二期需求又接踵而至，有的时候只能苦笑对之……

 

    可能感觉上面都是一肚子牢骚，其实，下面要说的才是重点，重点绝非是抱怨需求的缠人，相反，恰恰正是客户的感受才是需求真正含义，也应该是我们作为一名开发者应该追求的方向，说到这里，我们不难想到一个人，对，那就是比尔.盖茨……

 

    我也是经过最近的几个个性化项目的开发才能进一步有所领悟的，通过和客户进一步的交流和沟通，通过前面2年来的“反面教育”，终于对客户的方便易用性在需求中的反应的重要性有了进一步的理解，再深入的道理我也不想过多阐述，只想表达一个观点：我们为客户做应用，不是为自己做开发……

 

    最后，补上一个小故事，一个大拿曾经提到自己再为邮政局做一个应用的时候，涉及到一个地址查询的小功能，他们做的应用是要输入地址的拼音全拼，而实际的录入员反应，希望能够修改为同样支持汉字首字母的查询，事后经过实际调查，仅这一个改动就使该录入员的工作效率提高了4倍……