我们知道，产品是为提供用户价值服务的，
它解决了用户问题，从而创造了商业价值，
因此，用户才肯花钱购买产品，企业有了利润才能活下去。
虽然如此，但是在产品生产过程中的每一个环节，
都能保持客户第一的清醒认识，也是不容易的。
例如，在安排任务的时候，我们会考虑事情的优先级，
也会考虑投入产出比，甚至会优先选择容易实现的功能点，
在局部上，我们可能难以断言，所做的事情，能带来多大的用户价值。
因此，这就带来了几方面的问题，
本文来探讨一下这些场景。
1. 完整的需求规格
完整的需求规格，事实上，远比产品经理所表述的那些还要多。
例如，系统的异常流，简直随着系统规模呈指数级的增长。
大家可能有过这样的感受，
我们用了20%的时间，就能看似完成系统的大部分功能，
而剩下的那些细节，越经常会消耗掉80%以上的时间。
我认为这是帕累托法则（二八定律），
在软件开发实践中的体现。
此外，我们对正常业务逻辑的理解，
也会随着工作的进展，逐渐变得透彻起来，
交付阶段我们认识到的逻辑复杂度，与刚开始时简直不可同日而语。
因此，为了交付完整的用户价值，
就必须尽快理解清需求的所有细节，
尽快投入到后80%的开发时间中去。
在前20%的开发阶段，对需求的全貌过于乐观，是项目延期的主要原因之一。
2. 简化需求
先实现出一版功能的轮廓，然后再持续不断的进行完善，
这也是软件开发过程中的一种常见手法。
这样做其实没什么问题。
无非会稍微增加一些返工的成本，
如果一开始就对问题有了透彻理解，再选择这样的开发方式来迭代，
那就更没有什么问题了。
可是，这样的开发方式，却经常伴随着一种不良的习惯，
那就是有意在交付阶段对需求进行简化。
开发者不愿意交付完整的功能点。
这样其实是危害极大的。
实际上，实现一个简化版的功能，比实现完整的功能点，要容易太多了。
某个简单的定制化需求，可能会产生复杂好几倍的软件。
当然我们也知道业务架构不清的情况下，代码结构也不会清晰，
不过我们现在暂时不准备讨论这些。
所以，如果关心用户价值，那就不要故意简化需求，
即使实现起来很麻烦，
这正是开发者要做的事情，麻烦才有价值。
3. 容易实现
在职业生涯的前几年，我经常会为了某个功能容不容易实现，而跟别人争论，
这件事到现在来看，让我感到非常羞愧。
因为，如果简单的实现满足不了用户的需要，
那么这种实现，对最终产品来说就没有任何意义，
创造不了用户价值。
虽然我们有时会考虑到投入产出比，
优先实现更重要，回报率更高的功能点。
但是，这和容易不容易其实没有什么关系。
用户要的是功能，其实不关心我们是怎么实现的。
实现难以实现的功能点，正是开发者的本职工作。
容易实现和不容易实现的功能，一起给用户提供了软件服务。
所以，如果关心用户价值，那么在讨论实现难度时，就应该保持警惕，
是我们本能的避重就轻，
还是站在了用户和项目按时交付的角度在考虑问题。
结语
我们常说客户第一，实际上真正执行起来是很难的，
开发者也很难跳出自己的舒适区，全局性的看待软件的整个交付过程。
大多数开发者都是接到了需求，就去实现它，
在遇到困难时，就去质疑需求的合理性。
其实这样有违软件系统被研发的初衷。
我们应该从需求的描述中，试图捕捉那些遗漏的用户需要，
认识到完整需求的真实复杂度，
然后耐心去应对困难。
我觉得这才是开发者，能为用户价值所做的应有贡献。
用户也不会关心我们遇到了哪些麻烦。