文章目录
  1. 1. 职业病
  2. 2. 脑洞
  3. 3. 感受
  4. 4. 结语

职业病

我的大学是在北京师范大学读的,当时读的一个叫做「励耘实验班」的专业(现在已经取消了),美其名曰第一年进行通识教育,第二年选专业。我最终选择了计算机专业,并且有幸和一群不同专业的室友一起生活了四年。

其中一个室友选了「数字媒体」专业,他在专业学习过程中,需要每天看各种电影,分析各种电影片段的拍摄手法。那个时候(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 团队负责人)是如何负责一个团队的。这样,你也可以学习到他需要哪些信息,他会怎么决策,从而有效地和他进行沟通,让他对你的工作满意。

结语

打开脑洞这个叫法是我自己发明出来的,你喜欢这个思考方式吗?

一旦你被我打开了「打开脑洞」的脑洞,你就停不下来了,好好享受从新视角观察世界的乐趣吧!

祝大家玩得开心!

如果你感兴趣,这儿还有我的另一个脑洞:《软件开发中的上帝模式与农民模式》