Make Quality a Requirements Issue.
使质量成为需求问题.
这些是次品 有一个比较老的笑话,说一家美国公司向一家日本制造商订购100,000片集成电路.规定说明中有次品率,10,000片只能有1片.几周过后订货到了:一个大盒子,里面装有数千片IC,还有一个小盒子有一个标签,里面有10片IC.上面写着:"这些是次品".图:《日出·印象》法国印象派画家克劳德·莫奈于1872年
不知道你看到这个故事会怎么想? 不过对于做软件开发的我们,如果能在一开始就严格地控制好软件的设计和交付就好了.不过现实总是事与愿违.而或说我们需要换个角度来思考.
上篇文章我们类比软件工程需要像建筑一样来设计和扩展.但是如果您准备做一款产品或者开源一个项目的话.我们更希望你能从生命的角度开看待要开发的软件.
软件是有生命的,他不仅仅需要最初设定的架构目标,还需要后期各部门实现来他成长.从这个角度来出来,我们可能不需要把软件做得按自己设想的足够好后在推到市场,而是让他慢慢地使用起来,通过用户的交流和反馈来更加明确软件的最好的方向.
同样的故事也是在一个朋友公众号中看到.说如果是做开源的软件项目的话,先期不要把软件设计的太完美,要让大家参与进来,有写bug的,有改bug的.让大家都互动起来.先有氛围.感觉这个思路的出发点是对的.
以下两点建议供参考:
1. 让用户尽早参与进来
如果软件是产品,让你用户尽早参与进来,或许是可行的方式.用户在使用中在反馈常常会带来更好的思路和意想不到的灵感.不妨参考下小米的MUI.
2. 知道何时止步
在某些时候,编程就是绘画.在完成一幅绘画的时候,需要让自己停下来,确定好一个时间段的软件的边界是一个智慧.而不是在无休止的细节上去修饰.这样或许会让软件变得复杂.
相关阅读:
