作为程序猿的我们总是被提醒，要从商业角度去考虑需求，要交付价值。商业？价值？这应该是每个公司的大腕们应该关心的问题吧，商业是什么？价值如何衡量？我们没有接触过，也够不到，这虚无缥缈的两个词，如何去理解？

请众位看官们阅读此文，细细品味，如何去开发出一个好软件。

对于什么是好软件，见仁见智。传统软件制作团队中，开发人员认为好软件最重要是有好代码保证可维护性和扩展性。产品经理总是在寻思怎样能比竞争对手提交更多价值。测试者努力使软件在发布的时候没有bug……。

这几个人可能都错了——即便这几点都实现了，你仍有可能提交的是一个过于复杂，不好使或者很难学会使用的软件

如果你真想知道自己做的软件好不好，最好去接触用户，有多少人在用，使用频率如何？如果很多人都在用，说明：“恩，这个软件还不错”，反之……好吧, 失败的软件各有各的失败原因。

超越bugs

对于用户来说，bug显然会造成困扰。但是谁都不可能在发布前扫除所有的bug，尤其正在给一个正在用的产品频繁增加新功能时。如果我们能接受这一点，再尝试从不同的视角来评判——比bug更重要的是软件能否解决问题？能否为用户提供清晰的指导？能否告诉用户现在什么情况，下一步该怎么做？这一类的帮助和支持应该是好软件能够提供的。

好软件三要素

有效性：我们考虑到人们真正想要的功能了吗？可用性无关复杂度，而是为最终用户提供正确的功能，使他的效率迈向更高的台阶。

可用性：好用的软件必须“快”、“高效”、“容易理解和学会使用”。用户可没有太多的耐心去学习冗长复杂的用户手册。

持续性：好的软件会使用户很快看到价值，并且用过之后还想继续使用，每天，而不是一年用一次或者两次。这种情况下，他会很乐意向她的朋友或同事推荐使用这个软件。

但是如何能做到呢？

最简单的方法就是直接和用户接触。有些项目中，团队和用户的讨论沟通过程和敏捷开发过程可以结合在一起，从而使反馈回路能够更早建立，用户的意见能够更全面，更快的传达到开发团队。

当产品经理组织和“用户期望……”相关的会议时，请各位程序猿们尽量融入其中，参与讨论。越早参与能越好的了解用户，也就能更好的完成自己的开发工作。

以用户为核心

对于任何一个新老开发团队来说，在整理需求或者写每行代码前考虑考虑以上三点要素，并且在接下来的整个产品开发周期都保持这样的话，好软件就离的不远了。

让最终用户告诉我们应该开发什么样的软件。想做出有用的软件就得花时间去了解他们的需求，观察他们如何用软件，持续进行用户调查，因为用户是评判这个产品好坏的唯一因素。