个人学习

产品经理,超级奶爸

0%

最近买了一台 Windows 笔记本电脑,说到 Windows 笔记本电脑,上一次购买还是在六七年前,那会还在上学呢。

快要毕业的时候,加入苹果的阵营,最开始比较穷,买了一台 Mac mini 作为入门,再后来,又买了一台 MacBook Pro,从此在我的生活里,就与 Windows 渐行渐远了。

阅读全文 »

这是《我的产品技术之旅》的系列文章,每篇文章,我都尽量保证是一个完整的故事,但不可避免会有些前后关联,毕竟这是一个成长的过程。

这篇文章讲述,我在做运营工作期间,群发邮件的一个业务。

阅读全文 »

前段时间,终于把我学生时代使用的联通号资费套餐给换了,前后差不多也经历了 3 年多的时间。

当时在学校办理的一个校园合约套餐,可以绑定其他联通手机号码,相互通话有免费时长,也就是定向通话不收费的业务。

阅读全文 »

这是《我的产品技术之旅》的系列文章,每篇文章,我都尽量保证是一个完整的故事,但不可避免会有些前后关联,毕竟这是一个成长的过程。

在第一家公司的最后一年,我主动给自己调了个岗,进入了集团内的培训组织,做运营相关工作。

我去的时候,这个培训组织才成立不到 3 年的时间,刚刚完成了从 0 到 1 的过程,正在快速的发展。

随着快速的发展,就不得不面临着运营效率的问题,在以前,一个运营担当同一时间,可能只需要负责一个培训项目;而现在,一个运营担当,同一时间,可能对接 3 个乃至更多的项目。

即便他们能够响应,但是服务质量就不敢保证了,那问题怎么解决,最直接最快速的方法,就是增加人手。

但,这不是长久之计,当运营人员增加到比业务部门人员还多的时候,领导就开始有意见了:「你看人家那个 xx 部门,就 3 个人,一年就能创造 xxxxxxxx 营业额,而你们运营部门都已经 6 个人了,还在说对应不过来,是不是你们自己的运营流程没有梳理清楚,导致效率低下,先去把流程梳理一下」。

当然,在这里面,领导忽略了运营需要对接多个业务部门的情况,且每个业务部门都是不一样的工作流程,但是,说得也不无道理,梳理流程是有效提升效率的方法。

在以往的信息化经验中,我倾向于直接解决问题,针对某一个点就开始规划系统功能,我认为只要把线下的工作,搬到线上了,就能自然解决协作的问题。

这次却不像之前那么简单了,因为涉及的部门多了,且都是独立的利益体,协作不再像以前那么单纯,你说怎么干,就怎么干。

之前我一直忽略了一个很重要的问题,那就是「协作从来都是人的问题,而非系统」。人与人之间的协作,并不是单纯的 IT 技术能够解决的问题。

技术在这里面顶多是一种工具,而不是解决方案,人与人之间协作的问题,更加需要的是一套人人都遵循的流程制度以及管理规范,它的重要性远大于一套功能强大的系统平台。

如果深入去了解那些因为协作而效率低下的原因,你会发现,很多时候,并不是因为缺少信息系统,相反,信息系统反而成为一种累赘。

出现这种情况,大概率都是因为,连最基本的业务流程都没有搞清楚。

也就是说,线下的流程都没有跑通,就企图靠系统去解决问题,结果只会是越整越乱。

这话怎么理解呢?我记得之前写过一段话,应该能够很好的解释这个问题。

一项业务的从 0 到 1 没有什么套路可言,单纯的干就行了。

而想要实现从 1 到 N 的突破,单纯的依靠个人能力,可能就会遇到瓶颈,需要借助外力来实现突破。

什么是外力?

一方面指的是业务流程,从流程的角度,去梳理整个业务场景,从而优化整个业务执行路径。

这就好比:去往终点,有 A,B 两条距离差不多的路径,A 是乡间道路,而 B 是高速公路,这里的 B 代表有业务流程。

显然 B 要比 A 好些,如果同样是走路的话,其实也差不了多少,毕竟路程是一样的,大家都走路的话,在 B 路上或许因为好走,可能会让人轻松一些,快一些,但依然达不到质的飞跃。

那么,就需要借助另外一个外力:信息化。有了流程,那么将线下流程线上化,就形成了一整套的线上流程。

这就好比,你走在了 B 路上,现在又给了你一台车,可想而知,这就是质的飞跃了。

那么,也许你会问,我直接上平台不就行了,梳理什么流程啊,假如没有流程,上了平台也是一团糟。

你可以想象一下,你开着跑车,在乡间小路上,能跑得起来吗。

所以,要实现从 1 到 N 的飞跃,必须要先流程,后信息化。两者缺一不可,且顺序还不能颠倒。

道理很简单,但实际执行的过程中,却有很多的变数,就像上面的例子,给你车了,你却发现不会开车,再者,给了你一辆破车,开了几步就抛锚了,弃车而去又不合适,还得停下来修车。

写到这里,又想到刚入职了解 ERP 的时候,就听领导说过「在 ERP 刚开始引入国内的时候,制造行业中流传着这么一句话:上 ERP 找死,不上 ERP 等死」。

虽然信息化的工作没有这么严重吧,但道理是一样的。很多行业,随着市场竞争进入白热化,大家拼的不再是扩张领域,而是企业运营效率。

这是《我的产品技术之旅》的系列文章,每篇文章,我都尽量保证是一个完整的故事,但不可避免会有些前后关联,毕竟这是一个成长的过程。

这篇文章继续介绍学习 Node Web 的第二个阶段:解决问题,从单点实际问题出发,规划系统功能,提升效率。

第一阶段仅仅是对开发的练习,并没有去考虑做这个事情的价值,单纯是自己感兴趣,而去学习而已。

后来,接触了一些比较大的项目管理工作,我渐渐感受到,协同办公效率低下所带来的痛苦。于是,为了解决这个问题,我又做了一些尝试。起初是为了解决我自己的问题,后面也对他人产生了一些影响,感觉还是挺有意义的。

低效的项目管理

中间有一段时间,部门领导担任一个集团大项目的项目经理,而我为了协助部门领导,承担了一些项目资料收集整理,项目周报,项目文档的一些工作。

那时公司还没有项目管理系统,这些工作的协作,需要借助 office 和 email 等工具来处理,由于项目范围比较大,分为了 5 个小组同时开展工作,每周我都要处理 5 个小组发过来的周报相关内容,然后汇总到一块,交给部门领导审核,最后邮件发送到所有项目成员。

如果只是这样的话,似乎没多大的工作量,关键的问题是:

  1. 每个小组并不能够一次性准确的把周报内容提供给你,通常情况下,你的邮件列表是这样的:
    • xxx 小组 —— 周报 v1_20xx-xx-xx
    • yyy 小组 —— 周报 v1
    • aaa 小组 —— 周报 v1
    • yyy 小组 —— 周报 v1.1 更新
    • zzz 小组 —— 周报 v1
    • xxx 小组 —— 周报 v1.1_20xx-xx-xx 更新版
    • bbb 小组 —— 周报 v1
    • xxx 小组 —— 周报 v1.2_20xx-xx-xx 最终版
    • ccc 小组 —— 周报 v1
    • ……
  2. 即便你提供了统一的模板,你收到的内容格式依然是五花八门。例如:
    • 对于列表,有的人是这样写的:1、,有的人是这样写的:1.,甚至有的人这样写:1。
    • 对于重点内容,有的人加粗,有的人加大字体,有的人换字体颜色,有的人换底色

这还仅仅只是针对周报的汇总工作,另外,还有 Excel 类,例如:开发清单。更新汇总的时候,更是头疼,当开发团队那边更新了列表,发给你的时候,你却不知道到底哪行更新了什么。

这办公效率,这沟通成本,明明每天都忙得不要不要的,却感觉似乎什么也没干,不禁感叹,时间都去哪了?

这就是办公效率低下,最典型的例子,重复的干着这样的工作,确实有点头疼,所以,我做了一个项目周报系统。

由于自己当时技术且时间有限,它的页面很粗糙,功能也不完整,仅仅是满足了我上述工作中的部分痛点诉求,即便这样,也帮我省了很多事。

在基础功能开发完成后,就直接上线了,怀着忐忑的心情,给项目成员发了邮件,让大家将本周的周报,按照这个系统的方式,提交给我。

起初,我以为大家会觉得麻烦,毕竟习惯这东西是很难改变的,但是,用了几周之后,反馈还不错,偶尔还给我提个 Bug 啥的。

这个项目完结之后,我也调离了这个部门,这个系统也就下线了。

再后来,项目组里的一个同事,看到集团在举行 TopCoder 大赛,想要邀请我一块去参加这个活动,参赛作品就拿这个周报系统,我倒是受宠若惊。

但由于新部门的工作有点忙,也就放弃了,我把系统的源代码都给了她,她跟其它同事去参加比赛了。

虽然最后没拿到啥奖,但是,我做的这个系统,真的有人觉得有用,我还是很开心的。

开发这个系统,所使用的技术栈几乎和前一个没有多大的区别,很多功能模块都是直接 copy 的,因为要保证上线速度,早上线一周,就少一周的折磨。

虽然技术能力没有啥提升,但是,意义却是重大的,我开始尝试利用技术的手段,去改变身边的一些工作流程。

一次职业选择

来到新的部门,离产品技术更远了,虽然职级晋升了,但却是我职业生涯的至暗时刻。也是在那个时候,让我产生了对未来职业的思考。

在起初的部门里,虽然「内部产品经理」这个岗位没多少成就感,但是,与部门领导以及同事之间的相处,还是非常愉快的。毕竟是我的第一份岗位,从中学到了很多产品经理的基本功。

一晃 3 年过去了,在传统的大企业里,管理岗是唯一的晋升途径。虽然企业明面上说有多条晋升途径,然而,傻子都知道,在这种环境下,走向管理岗,才是最明智的选择。

我算是比较幸运的吧,算是比较早获得晋升资格的。管理职级晋升,谁又会不愿意呢,就算你对管理啥的提不起什么兴趣,但对薪资总在乎吧。

新的岗位不再直接处理一线的业务,更多的是收集信息,汇报以及管理。在这个层面上,很多工作就不再那么具体而单纯,对或错,全凭主观意识。

在新的岗位上,一下子让我接触了太多的「虚」,这个「虚」似乎与我的性格天生不合,一度让我很煎熬,我想做点实际的事情,能直接产生价值的那种,而这个工作,却是在不同部门间、上层下层间,不停的和稀泥。

与直属领导的冲突,点燃了这根导火索,即便被认为是不够成熟,意气用事,我也坚持要离开,下定决心的那种,上面磨磨叽叽,我就自己去争取,最后,我找到了接受我的岗位,直接脱离了原来的组织,甚至是换了行业。

当时,还写了一篇文章:关键时刻不怯场的勇气

虽然这段经历仅仅只是一次再普通不过的职业选择, 但是,对我后续的发展,还是起了很大的影响。至少能确定的有两点:

  1. 企业的管理岗,不是我的方向
  2. 产品和技术,是我一直想做的事情,产品范围可能是效率类

企业信息化道路

在担任项目管理的工作时,所要面对的是 5 个项目小组,协作起来已经是够麻烦了。

而这个岗位需要协作的范围更广了,我需要与集团内十几家公司的十几个部门协作,从他们那获取我想要的信息,也就是收集别人的数据(包括表格,报告等),然后汇总到一起,最终形成一份资料,提供给上层领导,必要的时候,还要做 PPT 汇报。

不仅需要协作的部门多了,而且所要处理的事项也多了,传统 office + email 的办公方式,带来的不再是麻烦,而是恶心。

当然,我从来都不是一个埋头苦干的人,不出意外,我又开发了一个系统。

这个系统的规划初期,是为了把我的所有的线下数据线上化,并提供协同功能,解决我收集汇总数据的繁琐环节。

由于上述「职业选择」的问题,这个系统只实现了一部分功能,我就离开了。

这个系统的开发,从技术成长的角度,有一些进步,如上图所示,我开始套用前端模版了,开发效率和界面视觉上,都有了很大的改善。

说到这,你可能有疑惑,那么多第三方的协作平台,你就不知道用一个?

还真不行,传统就传统在这里,企业内部网络是限制的,云端工具一个也用不了。说是为了保密,但很多时候,都是为了所谓的保密工作而保密。

当然,我并非指保密不重要,但至少需要区分对待,就因为没人去做「区分」这个脏活累活,那么,只能一棒子打死。可是,有些一棒子又打不死,就出现了各种「残废」状态。

有可能你又要问了,这么大的公司,难道不知道这个问题的严重吗,员工效率低下,自然会影响到公司的效益呀。既然不让用第三方,为什么自己不上线一套协作办公的软件平台?

这个问题嘛,得分几点来看:

  1. 这个活大多是基层员工干的,领导层根本感知不到,领导只知道什么时候要报告,至于你是加班加点整理出来的,还是系统一键导出的,跟他又有什么关系
  2. 领导也没有那么不堪,趋势还是能看到的,规划肯定是有了,至于实施嘛,就没那么着急了,毕竟不是战略性指标,你看现在那些互联网巨头,最开始还不是都用的第三方的,后面才自主研发的
  3. 自主研发基本没戏,主营业务不是这个方向,也没那个能力,采购回来的吧,又是各种水火不融,而我们又非要死守着那点固有习惯,一点不适应就嗷嗷叫,很多系统即便部署上了,使用频次也不高,我记得当时的 KM 系统就是这样的状态

所以,综上所述,传统大企业的信息化转型道路,走得非常的艰难。

我在公司的这段时期,刚好经历了转型的这个过程,有趣的是,我前面刚做了知识库的小站点,集团就上线了 KM 以及 3KS 系统;我刚做完项目周报收集的系统,我们组织就成立了一个 PM(项目管理)系统的项目,第二年就上线了。

当然,这只是巧合,我开发的这些小 demo,自然不能够跟市场中成熟的专业产品相提并论,但从中能看出来,传统行业信息化转型,企业内部协同办公是一个急需提升效率的方向。

这是《我的产品技术之旅》的系列文章,每篇文章,我都尽量保证是一个完整的故事,但不可避免会有些前后关联,毕竟这是一个成长的过程。

这篇文章开始介绍学习 Node Web 的过程。毕业之前学过 Java 和 Objective-C,但仅仅是学过,并没有产生实际的用处。

后来入职做了一名产品经理,学习了一个新的技术 —— Node,它不是一门新的语言,而只是 JavaScript 语言的运行环境,却帮我解决了很多实际问题。


岗位职责之外,给公司做的那个知识库站点,是第一个跟开发技术相关的项目。虽然不需要很高深的技术,但涉及到的知识点还是比较多的,从前台最基础的网页,到后台服务器的部署,都有涉及。例如:Markdown、Hexo、HTML/CSS/JavaScript、Nginx 以及 Linux 等。

如果完全没接触过这些零散的知识点,还是需要一些时间去了解的。而对于我来说,却比较轻松,因为我更擅长对整个概览的掌握,而不是精专某一个技术点。

做这个事情,让我尝到了一丝的甜头,在部门内,也渐渐有了「技术男」的标签,毕竟我那个岗位是几乎不需要啥技术的。

我在其中找到了「内在价值肯定,外在成就认可」的感觉,满足了我的「尊重需求」,于是,我开始寻求「自我实现」。

重新捡起开发

那段时间,我接触了一个新的开发技术 Node,它是 JavaScript 语言的后台运行环境。它诞生于 2009 年,创立之初,是为了获得一个高性能的 Web 服务器,并提供一套库。

前端由于它的诞生,大放异彩,逐渐发展出了大前端的概念。在我接触 Node 的时候,它就已经很火了。

像之前提到的 Hexo(静态博客框架),就是基于 Node 开发的,虽然 Node 很火,但是与 Java, PHP 等相比,还是显得小众了些。但我觉得很酷。

除了酷,它还有很多优点,例如简洁、开发效率高,使用 Node 开发一个 Web 站点,非常快,写一个 HTTP 服务,只需要短短几行代码就搞定了,简直是全栈开发必学的技能之一。

貌似,全栈开发这个词,就是在 Node 诞生之后,才慢慢火起来的,因为前端开发者常用的 JavaScript 语言,借助 Node 的环境,也可以做后台开发了。

前端工程师可以一个人解决前后端的开发,后来又渐渐出现「大前端」的概念,那个时候,前端真的是火得不行。

在选定 Node 之后,我开始做一些小的系统用来练手,什么需求都做,有时可能是别人的一句抱怨,也有可能是自己 YY 出来的需求,只要有机会,我都去尝试开发,毕竟是学习的过程,不能放过任何练习的机会。

当然,在一个传统的制造企业里,从来就不缺信息化的需求。有那么一段时间,我只要看到某些效率低下的工作方式或流程,我就在想,能不能通过线上协同的方式去提高效率。

练手的那些系统

姑且就叫「系统」吧,虽然大多都只是简单的「增删改查」,根本就称不上所谓的系统,但从这些项目的开发中,我学到了很多东西。

这样的「需求」真的是应接不暇,只是个人精力有限,毕竟还有一堆岗位职责的工作需要去处理。

按照时间顺序,大概分为 3 个阶段:

  • 第一个阶段:练习开发。学会把一些零散的知识点,拼成相对完整的项目;
  • 第二个阶段:解决问题。从单点实际问题出发,规划系统功能,提升效率;
  • 第三个阶段:产品化。从业务流程出发,做信息化平台;

下面介绍第一个阶段:练习阶段。这个阶段开发了 3 个系统,每个系统较之前一个都有很大的进步,这个过程要学习的东西实在太多了。

1. 评分系统

这应该是我使用 Node 开发的第一个 Web 站点,它甚至连最基本的用户管理都没有,但它让我学会了很多基础的概念。例如:

  • 了解了页面模版的概念
  • 学会使用 bootstrap 样式库去搭建页面
  • 学会使用 express 框架作为后台服务
  • 学会使用 Node 访问 MySQL 数据库

这个在部门内用了几周,就没再用了,非常简陋的一个站点,仅仅满足了投票打分的核心需求。

专门找到了当时写的几篇介绍文章:标签: 评分系统 | 个人学习,读完后,还挺有感触,这就是那时的自己。把时间维度拉长,觉得写作是件非常有意思的事情。

2. 需求收集系统

这是个半成品,甚至都没有部署到线上,只是存在于我的电脑里,在这个项目里,我开始学会使用一些开源的前端组件,例如常用的有:

  • bootstrap-fileupload 上传插件
  • bootstrap-table 表格插件

随着后面系统的开发,使用的第三方库也越来越多,后来,我还专门创建了一个开源项目,用来收集以及总结这些开源组件的使用方法。

GitHub 地址:https://github.com/pengloo53/js-plugin-example

在这个项目的练习上,除了学习组件的使用之外,开始逐渐学习模块化的开发,例如将数据库相关配置独立,再抽象出业务调用数据的模块。

当时也写了几篇介绍文章,只是不完整,就写了 3 篇,标签: 需求收集系统 | 个人学习,这里,大多数精力都花在了前端组件的使用上了。

3. 考核系统

这是我第一个完成程度较高的系统,这个系统的需求不是我自己 YY 的,是我们做客户拜访的时候,领导接回来的。

这原本也不是我们的岗位职责,接这个任务,是因为客户有非常明确的需求,而我们部门恰好又有能力去做这个事情,另一方面,部门领导也想给部门的工作找些亮点。

和前面不一样,这个项目,我只是负责开发,前期的需求沟通是部门另外一个同事做的,还有一个同事帮忙写 SQL,所以,这个项目中,我的角色只是程序员。

经过前面几个系统的练手,做这个项目的时候,还算得心应手,况且我只负责开发,所以,我记得差不多两周的时间,我就完成了所有的开发工作,功能并不复杂,花时间最多的是前端页面布局和样式。

做完这个项目,发现了两个问题,也就是改善点吧。

  • 一个是前端页面太费时间了,如果有现成的页面模板的话,就省事多了
  • 数据库的调用太 Low 了,这个项目的数据库调用都是采用字符串拼接 SQL 的方式

当然也有很大的收获:

  • 了解了完整的项目结构搭建
  • 各种前端第三方组件的学习和使用

不出意外的话,这个项目应该还跑在公司的内网服务器上,相关的业务参数是动态配置的,所以,如果没有大的调整,应该还能跑上一阵子。

学习 Node Web 的过程,就是在这样的状态下,不断的迭代,每开发一个新的系统,都会针对性的解决前面一个系统的问题。

所以,感觉这个过程,还是比较扎实的,我相信,每一个技术的学习都应该是这样的过程,就是不断的练习,练习,再练习。

这是《我的产品技术之旅》的系列文章,每篇文章,我都尽量保证是一个完整的故事,但不可避免会有些前后关联,毕竟这是一个成长的过程。

这篇介绍我那不堪的学业生涯,回忆过去,发现很多事情有因必有果,即便再来一次,也许我依然会走向同样的道路。

计算机专业不就是玩电脑吗

我是计算机硕士毕业的,但我并非科班出身(本科不是计算机专业),在上研究生之前,我对计算机的认识,只是停留在 —— 这专业不就是玩电脑嘛。别笑,真是这样。

大二的时候,才拥有自己的电脑,那是一台联想笔记本,当时预装的是 Windows Vista 操作系统,然而,用了几个月,在还不清楚「操作系统」是个什么概念的时候,我就把它换成了 Windows XP,从此一发不可收拾。

在这台笔记本上,我几乎把所有的系统装了个遍,除了 Windows 的各个版本,还包括 Linux 的各种发行版,从 Ubuntu 到 Federo 到 Debain 到……,这还不算完,后面还整了各种双系统,XP + Ubuntu,Windows 7 + Federo 等等。

这台电脑也因为不堪重负,在上研一的时候,终于被我搞挂掉了,硬盘整出坏道了,后来换了块硬盘,目前扔家里,竟然还能用。

第一台电脑虽然挂了,但是鼓捣系统之心一直没灭,借写论文之由,又买了一台新的笔记本,HP 的超级本(好像当时很火的一个概念),在这台笔记本上,除了联想电脑经历过的那些,还包括:黑苹果,安装上了 xcode,甚至还写了一个 iOS 的 App demo,这个单独再说。

说到这里,关于计算机最初的印象,就是在安装各种版本的操作系统,现在看来,认知不够是多么可怕的事情,浪费了多少美好时光,当时做的那些事情,对现在似乎没有半点实际用处,除了能作为调侃自己的谈资。

我也说不清楚,当时的自己,为什么就是想要去折腾,也许觉得这样很酷,或许是因为对新产品的好奇心,每次发布新版的系统或是软件更新,总是忍不住想要去试一试。

这个经历对于现在来说,没有实际的价值,但是在当时,倒是帮助我做了一个重要的决定,那就是要考计算机专业的研究生,考研的过程虽然辛苦,但不算太难,反正就是看书做题嘛。

即便我有丰富的装系统经历,但是面对那些真正的计算机专业课,也是一脸蒙逼。因为本科是物理专业,考研专业课要考的那 4 本书(计算机组成原理,操作系统,数据结构,计算机网络)都没有正经学过,简直就跟天书一般。

自学这些专业课,跟帖子里教你如何安装系统,完全不是一码事。不过,好在凭着一丝的兴趣,也是硬着头皮看了下去,最后的考试成绩,不算理想,但也没有特别拖后腿,如愿考上了计算机专业的研究生。

终归还是当不了程序员

说来惭愧,上研究生之前,我几乎都没有接触过软件开发,唯一沾点边的是,本科物理专业学过单片机,使用的是汇编语言,这门课是我大学学习生涯里,唯一一个得满分的课程,一度让我觉得「诶,难不成我在编程领域有点天赋,要不深入一下」。

后来倒是自学过 C 语言以及数据库一些知识,兴趣使然,还是很轻松的考过了计算机二级以及三级证书,不过那种程度的编程,完全只是停留在考试层面,都不能算作是软件开发。

真正让我开始接触软件开发,是我的一个研究生同学 LC,他当时给我演示了,他用 Java ME 给自己的功能机写的那个工具软件。那个瞬间,似乎打开了我的一道门,居然还可以给自己手机写软件,这都是我之前想都没有去想过的事情。

于是,我也开始学习 Java,当时,并不是觉得 Java 厉害或真的对编程感兴趣,完全是盲目的学习,觉得能够给自己写软件,是一件很酷的事情,就像之前无数遍安装操作系统一样。

研究生的课程几乎跟写代码没有任何的关系,学的都是基础理论知识,但那时的自己意识不到孰轻孰重,花了大量的时间去学习应用层面的东西,而忽略了基础理论(算法相关)的学习。

现在看来,其实是舍本逐末,就目前来看(已经毕业 6 年了),Java 几乎忘得一干二净,而当时学习的数据挖掘相关算法理论,却是越来越有用,即使对一名产品经理来说,这些基础知识也是异常的重要,因为目前的互联网产品,几乎都离不开诸如聚类、分类以及关联分析的相关算法理论。

这些都是后话了。即便是学习 Java,我也没能深入的扎下去,其中有一个主要的原因:我似乎更倾向于整体概览的了解,而不是某个技术点的深入。这也有可能是我做不了程序员的主要原因吧。

快毕业那会,还学了一段时间的 iOS 开发,而那时没有 Mac 电脑,还整过黑苹果,都不知道我是为了整黑苹果而学习的 iOS 开发呀,还是为了学习 iOS 开发,而整的黑苹果。

在这样的状态下,一不小心就毕业了。毕业之后,成为了一名产品经理,一直至今。