昨天学习吴军老师的"数学通识"(其实听点数学更容易入睡)，听到以下四点，有了些触动
1、不要怕提出傻问题，符合逻辑的傻问题常常是认知升级的开始 2、如果之前的认知解决不了那些看似傻问题的悖论，我们可能就要跳出圈子了,因为在圈子里转永远解决不了问题 3、当我们扩大认知体系的时候，之前的傻问题可能有了答案 4、但是不要指望一次就能完美解决所有问题。我们的解决方案可能有漏洞，不要怕被别人指出来。当我们进一步弥补漏洞后，我们的认知就再次升级。
对于问题和圈子，即囿于我们的认知,有些问题是在我们原有的认识体系里解决不了的,需要我们扩大认识,突然串到了IT领域的DDD(Domain-Driven Design 领域驱动设计)、敏捷开发和Togaf的企业架构知识了。
敏捷宣言的第一条就是"个体和互动 重于过程和工具"，首先从人员层面强调沟通和互动。敏捷开发的十二条准则：“强调业务人员与开发人员必须在一起工作”。那么我们为什么需要互动呢，为什么不同知识背景的群体需要在一起工作呢。这或许是因为业务人员需要研发人员用IT知识开发一些工具、系统、平台来帮助他们更好完成任务，完成他们价值的交互;而研发需要业务人员提出的需求必须是“准确”的，需要他们确认双方对一个需求的理解是一致的;需要一起对进度和优先级进行梳理; 这样才能保证开发的成果是符合预期的，才能完成才能形成价值流的交付。
那么多个知识背景(至少涉及:业务、产品、研发、测评等角色)的人如何在一起工作呢,如何基于统一的视角看待问题，如何用统一的语言描述、定位问题，如何把业务人员的业务问题域映射到研发可以理解的IT领域？这个问题是DDD尝试解决的。在研发过程中,敏捷提供了许多工具如看板、用户故事敏捷站会等。
但是随着企业、市场复杂度的提高，有些事情或问题已经突破了业务人员可以掌握的边界了，如组织形态演进的问题、自研或外包等问题。那就需要一个框架把更多的角色和视角管理起来，尝试解决如何组织这些人员、如何协作，协作周期、如何输入、输出(对于togaf可能是价值流和流程)。如何用一套语言描述问题，这个是togaf之类的企业架构尝试解决的问题。
其实这些方法论、框架本质上是用来解决问题的，这一点我们需要有明确的认识，避免为了追求完美、符合标准忘记我们的目的是什么。
提到这个突然想起郭德刚的一个段子。
孙老师骨折去医院。 医生指着CT说：“伤的挺严重。这也骨折了，那也骨折了...” 但是孙老师着急出院，怎么办？医生想了一会儿，把片子拿走了。 过了一会儿过来说："这也好了，那也好了，全都好了!"。 孙老师很意外问为什么？ 医生说：“看你确实很着急出去，我把你的片子ps了一下。”
段子归段子，我们有时候ppt上有一套系统,实际跑着的是另外一套。虽然有各种各样的工具可用，我们需要关注我们遇到的问题,不要在工具中迷失。
