职业病
我的大学是在北京师范大学读的，当时读的一个叫做「励耘实验班」的专业（现在已经取消了），美其名曰第一年进行通识教育，第二年选专业。我最终选择了计算机专业，并且有幸和一群不同专业的室友一起生活了四年。
其中一个室友选了「数字媒体」专业，他在专业学习过程中，需要每天看各种电影，分析各种电影片段的拍摄手法。那个时候（03 年）网络还不发达，他有一个大书架，上面全是他买的各种电影光盘。有一次和他聊天，他说道：「我现在看电影已经无法融入剧情中了，因为我一看见电影，脑海里面想的就是当前的摄像机机位在哪里，用了什么拍摄手法，为什么导演要用这样的手法」。
有人把这种现场取一个名词，叫「职业病」，就像警察一样，不管有没有上班，都会下意识地观察有没有行为异常的路人。而我做为一个 iOS 开发者，每每试用一款新的 App，看到一些交互效果，第一想到的不是这个效果多酷，而是想这个效果是用什么技术方案做到的。
我以前觉得这就是「职业病」，但是突然有一天，我发现这还不是「职业病」这么简单的事情。
脑洞
事情的转折发生在我开始转型，从一个 iOS 开发，转变为一个团队管理者。我开始参与产品和 UI 的讨论。这个时候，我发现我开始关注技术实现之外的东西，拿到一款 App，我不但会考虑它的技术实现，也会考虑产品经理这么设计的意图，也会考虑用户使用这个功能的场景，还会考虑视觉设计的特点。
于是，我觉得这不是职业病，而是打开了另一个思考问题角度的脑洞。
就像我的室友打开了「艺术创业」的脑洞一样，他可以从各种电影中吸取到电影拍摄的专业知识，而我却对此完全不会有感受。同样，我使用一个 App 可以带来技术实现上的思考和提升，而我的室友却完全不可能有这方面的感受。
每一个脑洞的打开，都代表着一种新的观察世界的视角，以及这个视角下的思考、学习和积累。iOS 开发者由于需要大量地接触到终端用户，产品原型以及 UI 设计，本来可以学习和积累出大量的产品设计、交互设计 和 UI 设计的知识，但大部分 iOS 开发者在面对产品稿的时候，却只知道思考这个功能应该如何实现。这些 iOS 开发者只打开了技术实现的脑洞，无论他们做多少个 App，他们也无法得到产品设计上的提升。
另外有一些 iOS 开发者，他们喜欢和产品经理聊天，了解产品稿背后的设计意图，他们还会反馈给 UI 设计师一些 iOS 下的视觉规范。在一些产品设计非常难以实现的时候，他们会站在产品经理的立场上，提出不损害产品意图，又有更容易实现的技术折中方案。这些 iOS 开发者，不但打开了技术实现的脑洞，也打开了产品设计，视觉设计的脑洞。每一次 App 的开发过程，他们除了能够提升开发能力，还能提升产品设计和视觉设计能力。
服务器端的同学在这一点上，会吃亏很多，因为服务器端的同学大多数不需要接触 UI 稿，产品稿方面，他们的工作因为不涉及交互细节，所以也很容易忽视产品实现的细节。相对来说，他们更难以打开产品设计，视觉设计的脑洞。
感受
每一个脑洞都代表着一种新的思考问题的角度。我现在管理小猿搜题产品技术团队，我开始越来越关注大家的工作流程，沟通方式是否顺畅，希望让每一个人都能舒服地工作，高效地产出。这个时候，我打开了管理的脑洞，我开始注意到大家的协作方式，注意到非正式领导的组织过程，注意到跨组协作的效率问题，注意到细节问题的处理过程。我会观察和思考这些事情，甚至会尝试给组织加入一些规则或增加一些沟通来改善一些问题，这想在这个团队中，很少有人会像我一样关注这些问题，所以他们也很难像我一样积累出团队管理经验。
当你理解了这件事情之后，你就可以打开更多的脑洞了，因为很多经验的积累，并不真正需要你全职去做，而只要你仔细观察就可以了。比如你可以打开 CTO 的脑洞，看看公司的 CTO 是如何管理整个技术团队的，你还可以打开 CEO 的脑洞，看看 CEO 在哪些问题上会向员工沟通，前几天，《李大学：CTO，应该像 CEO 一样思考》 其实讲的也是这个道理。你甚至可以打开餐馆老板的脑洞，观察公司楼下的各种餐馆的经营模式，哪些最后死掉了，哪些最后成功了。
作为一个普通 iOS 开发者，我们更应该打开的是自己上司的脑洞，看看你的老大（他或许是一个 iOS 团队负责人）是如何负责一个团队的。这样，你也可以学习到他需要哪些信息，他会怎么决策，从而有效地和他进行沟通，让他对你的工作满意。
结语
打开脑洞这个叫法是我自己发明出来的，你喜欢这个思考方式吗？
一旦你被我打开了「打开脑洞」的脑洞，你就停不下来了，好好享受从新视角观察世界的乐趣吧！
祝大家玩得开心！
如果你感兴趣，这儿还有我的另一个脑洞：《软件开发中的上帝模式与农民模式》