作为程序猿的我们总是被提醒,要从商业角度去考虑需求,要交付价值。商业?价值?这应该是每个公司的大腕们应该关心的问题吧,商业是什么?价值如何衡量?我们没有接触过,也够不到,这虚无缥缈的两个词,如何去理解?
请众位看官们阅读此文,细细品味,如何去开发出一个好软件。
对于什么是好软件,见仁见智。传统软件制作团队中,开发人员认为好软件最重要是有好代码保证可维护性和扩展性。产品经理总是在寻思怎样能比竞争对手提交更多价值。测试者努力使软件在发布的时候没有bug……。
这几个人可能都错了——即便这几点都实现了,你仍有可能提交的是一个过于复杂,不好使或者很难学会使用的软件
如果你真想知道自己做的软件好不好,最好去接触用户,有多少人在用,使用频率如何?如果很多人都在用,说明:“恩,这个软件还不错”,反之……好吧, 失败的软件各有各的失败原因。
超越bugs
对于用户来说,bug显然会造成困扰。但是谁都不可能在发布前扫除所有的bug,尤其正在给一个正在用的产品频繁增加新功能时。如果我们能接受这一点,再尝试从不同的视角来评判——比bug更重要的是软件能否解决问题?能否为用户提供清晰的指导?能否告诉用户现在什么情况,下一步该怎么做?这一类的帮助和支持应该是好软件能够提供的。
好软件三要素
有效性:我们考虑到人们真正想要的功能了吗?可用性无关复杂度,而是为最终用户提供正确的功能,使他的效率迈向更高的台阶。
可用性:好用的软件必须“快”、“高效”、“容易理解和学会使用”。用户可没有太多的耐心去学习冗长复杂的用户手册。
持续性:好的软件会使用户很快看到价值,并且用过之后还想继续使用,每天,而不是一年用一次或者两次。这种情况下,他会很乐意向她的朋友或同事推荐使用这个软件。
但是如何能做到呢?
最简单的方法就是直接和用户接触。有些项目中,团队和用户的讨论沟通过程和敏捷开发过程可以结合在一起,从而使反馈回路能够更早建立,用户的意见能够更全面,更快的传达到开发团队。
当产品经理组织和“用户期望……”相关的会议时,请各位程序猿们尽量融入其中,参与讨论。越早参与能越好的了解用户,也就能更好的完成自己的开发工作。
以用户为核心
对于任何一个新老开发团队来说,在整理需求或者写每行代码前考虑考虑以上三点要素,并且在接下来的整个产品开发周期都保持这样的话,好软件就离的不远了。
让最终用户告诉我们应该开发什么样的软件。想做出有用的软件就得花时间去了解他们的需求,观察他们如何用软件,持续进行用户调查,因为用户是评判这个产品好坏的唯一因素。