关于产品定义、架构和设计实现的一些想法

碎碎念，自己总结一下。

一、怎么定义产品？

好的产品自然是“设计”出来的，而不是树上长出来的。“设计”这个词很虚，我试着分解成定义、架构和设计实现三个过程。产品的定义就先从产品的使用来看吧：无论什么样的产品都有I（输入）-P（处理）-O（输出）这三大坑，好产品的功能很强大，性能很优越，输入输出方便、直观、容易理解。

但是，一般而言，越是功能强大、性能优越的产品，它的P坑是非常复杂的，因为强大的功能需要复杂的交互来梳理。所以，相应的，I坑和O坑也会非常复杂。

然后说I坑。录入/编辑/建模的过程非常复杂——产品的输入，或者说产品的使用方法，体现了产品的建模方法论。比如3DS Max、PS、一些MDA工具，等等。如果缺乏方法论的支撑，就不能清晰的定义基本概念、不能梳理使用流程，内部模型不可靠不完备不一致，产品在定义阶段就卡死了。

大家的对策几乎都是山寨同类型其他产品的做法，或者说参考啊~向前辈致敬等等，总之是为了反推出方法论、UI和UX。这也无可厚非，因为用户都已经习惯了这些优秀产品的用法，如果你非要独树一帜反而增加学习成本。但是如果没有别家产品参考，你是先驱，那就一定要慎重了。这种复杂产品的设计，一定是先有理论再有实现，如果有专门研究这个理论的牛人发表论文专利，那可以跟随这条路走下去。否则这意味着点错科技树，是很令人沮丧的事情。

最后说O坑。和输入差不多，复杂的输出信息难理解、难判读。不一样的地方是有时要抽象、隔离O和I的信息。不过，好消息是O坑紧挨着I坑，填完I坑，O坑几乎也就填平了。

IPO每个坑里面的概念、功能、性能、流程、交互、并发、部署等等等等都需要考虑需要选择，或者通过设立指标去分配权重去打分或者干脆拍脑袋，总之要做选择，说好听点叫做权衡，这是第一个权衡。完事以后，就证明了这个产品的理念是可以落地的。产品的落地有很多种做法，需要通过权衡之后我们选定一种做法。这第二个权衡阶段就是在讨论架构。

二、怎么架构？                                                      

软件是个实践性的行业，在你定义过产品之后，你才会定义；在你架构过之后，你才会架构；在你设计实现过之后，你才会设计实现。饶是如此也应该看一些架构的书，这个阶段有很多前人踩的路可供参考，没有复杂的道理全是经验。定义产品的时候我们就知道，用户总是希望产品功能强大，并且要傻瓜式操作，不然他会觉得“不好用”。也就是P强大，IO强大。这样强大的产品，它的复杂度怎么控制？

我的经验是从服务对象的角度去考虑。

产品的定义是为用户服务的，从用户角度考虑，用户希望产品的使用（体现为交互体验）简单易用、功能强大；

架构是为产品定义服务的，所以同样的，从产品定义的角度考虑，产品也希望架构的使用（体现为支撑作用）简单易用、功能强大。

架构一定要简单，越简单的架构产出的产品“能用”的概率越大，参照常见的架构模式和经验，也可以从设计模式中找灵感但是不要直接使用设计模式，设计模式不是架构阶段考虑的问题，在架构的阶段不要讨论设计实现，尽量把复杂度压给低层的设计去处理。

三、设计实现

设计实现是为架构服务的（承接架构），同样，架构希望设计实现简单易用、功能强大。设计的问题比较单一，需要考虑的不确定因素比较少，常见的设计模式、经验都可以用的上。因为讲设计模式的材料比架构模式多得多，造成很多人在架构阶段错用设计模式，所以首先要注意不要用设计模式破坏架构。

可以设计复杂的框架/库，实现功能强大的子系统/模块，但是不要泄露给其他子系统/模块。用设计模式解决了自己内部任务就行了，不要反过来破坏架构影响整体的复杂度。

其次，现代开发工作越来越像搭积木房子，很多时候需要找到合适的积木/组件，拼到现有的作品中。有时候一个好的架构并不一定产生最“漂亮”的设计，也就是说，经过权衡后选中的那个架构，单纯从设计角度考虑并不一定是最美最精巧的，而是最“合适”的。比如由于计算性能的提高令我们可以选择很多中间件，使得很多看似“愚蠢”的设计都能满足需求，因此就不再需要昂贵精巧的设计了。这么做很丑，但是可以帮我们控制复杂度，使我们能专注于更宏大的故事。

所以要理性看待，不能有洁癖、不能单纯追求美感。

四、总结

每个阶段的任务都要找到不同的解法，这样经过迭代、优化、权衡，才能做出合适的选择。