为什么不能合到一起？

1、对于我第一个 关于“日历和任务能不能合并”的“幼稚”问题。支付宝有个即将上线的产品我做了这样的决定，Google用行动给出了回答 ：Yes！

2、对于我第二个 关于“收藏夹和购物车能不能合并”的“幼稚”问题。迟早大家会看到有人这么干，而且还会感觉挺好。

3、对于前两个问题，暂时还没有看到和我在同一个思路考虑问题的回复者。当然，这并非是说我的思路就是真理，只是这类问题如果思路不一样就算结论一样，都很难讨论的起来。大家在各说各的话。

4、我的思路其实很简单：先分析需求，再分析功能，再想实现；先想基础的大需求，再想细节的小需求。这个顺序只要一颠倒，多半不会同意我的做法。

5、做架构的人，必须非常极致非常认真的尽最大可能来控制“熵 ”。某种程度上，我认为控制“熵”的能力，才是一个架构师真正的能力。无论是技术架构，还是业务架构，还是我现在作的产品体验架构。

6、不要一直想着“我要怎么用”，不要指望“去问问用户想怎么用”。只能去分析，站在用户的角度从架构上分析。90%的产品架构是靠分析得来的，不是靠用户问来的。

7、上面的话，写的很乱，有点像在咬文拽字。每个人的语境不同，理解的也肯定不一样。我权当自己写工作日记，你如果看着烦，就当没看见。
要写下来完整的思路，实在需要太多文字，回头我再在《Design IT.》 里详细来写。

8、今天，我要说一个好像是“反面”的例子，搅浑更多人的思路。这是一位我最敬佩的CEO，给我讲了一个故事：
当 年，变压器市场三分天下，三家始终难分高低；其中某家突然做了一个事情，做上了老大的位置。大家的变压器都可以在“-20度 至 +80度”的温度下正常运行，这家公司在现有的产品基础上什么都没做，只加了两个外包装后推出了两款产品，一个号称“高温地区专用”、一个号称“寒冬地区 专用”，一年之内拿到了60%的市场份额，改变了市场格局。

9、
做产品架构设计的兄弟们如何看待这个例子？，做产品运营的又如何看待这个例子？
这个例子有影响你的思路吗， 是不是在帮助你反驳我这两个关于“合并”的想法？