这一章的内容是，如何运用探索式编程技术，为产品创意构思出有意义的验证方案。
首先，你需要尽快理解客户的需求。【这点肯定是要做的，毕竟你是要为客户服务。】
在整体性的问题都弄清楚后，就要准备开发了。在开始阶段，可以先用线框图展示应用的基本结构，弄清楚需要完成的工作都有哪些，但是不要太关注细节。【这一部分的重点我觉得就是简化，比如线框图就是用最简单的线条来展示应用的大概样子，有哪些组件。如果在这一阶段反复纠缠细节就会让进度推进变得困难。】
新的应用不能只停留在线框图上，应当尽快建立一个测试系统，让大家都可以使用，并收集反馈。这样能迅速拉近每个参与者之间的距离，之后的工作可以围绕这个测试系统进行交流。同样，不要在这个阶段纠缠细节，能尽快搭建好一个能够使用的系统才是关键。【这个时候做出的产品可能很丑陋，让人忍不住想要去优化。但是这个时候优化半天的功能可能根本不是客户想要的。所以不如先听听用户的意见。】
测试系统搭建好后，肯定有很多不足，客户会给你提很多意见。这个时候应该权衡这些缺陷带来的损失和修复需要的成本。【我觉得在这里，如何权衡才是难点，而且有时候你觉得可以延迟修复的问题客户却会觉得很关键。我个人的观点是，应当尽快推进功能的完善，先不要纠结界面美观和性能问题。】
如果对客户的目标有不明白的地方，尽早去问一问，避免做无用功。
找到一些具体的问题，尝试去解决它们，并选择最简单的解决方案。
对于原型系统，不应该要求它能够达到生产系统的健壮程度，能够尽快解决问题展示成果才是关键。如果发现一些未来的生产系统需要注意的问题，可以先标注出来，让后续的开发人员知道。【在这里，我跟着作者的节奏，就掉到了坑里。主角在一个设计上，可以使用热链接引用（不保证可用），或者选择开发者API。我一想就觉得肯定要用开发者API，要不然哪天热链接就失效了。但其实在原型系统里可以先用热链接，毕竟API的使用成本高不少，不如留给后续的优化。】
另外，可以设计一些特性便于收集反馈，这些特性不一定需要保留到正式的系统，只要现阶段有用就行。
网友评论