Younix's Studio.

2017年总结

字数统计: 2.4k阅读时长: 8 min
2017/12/31 Share

今年应该算是目标更加专注安安心心沉淀技术的一年。
自从三月跳槽后,朝九晚十,大半年一眨眼就过了。
还是惯例在新年伊始,总结一下去年的收获,制定一下明年的计划。

关于工作

今年在 CSDN 上发表了 28 篇技术文档,翻译了 0 篇外文,创作了 0 篇个人文章。
实际上还有二十余篇技术文档 因为公司产品的保密性原因无法释放。
但是总共加起来也仅有 50 篇 左右,相比去年的 67 篇技术文档、翻译 2 篇外文、12篇 个人文章,从数量上来看是有大幅的下降的。

分析原因来看,一方面个人时间被项目占据是个人文章产量为 0 的一个借口,另一方面是今年相较去年参加的展会、沙龙屈指可数。
缺少了思维的碰撞与视野的拓展。可以说是有舍有得吧。

CSDN 的博客访问从 16年年底的 5万,到 17年年的 17万。增长了 12万:http://blog.csdn.net/dearsq。
同时也有很多行业内的小伙伴联系到我咨询技术问题,这个成就感满满。尤其是当看到自己的所作的一些工作成果能为其他人提供方便时,还是相当开心的。

另外创办了一个微信公众号,不过实在精力有限疏于打理,写了几篇文章后就放弃了。比起 CSDN 可以直接支持 Markdown 的语法,使写者可以更专注于文章内容,微信公众号需要大量的时间进行排版。
也许在以后微信公众号支持 Markdown 语法,或者是有大牛开发出一个直接将 Markdown 转微信公众号的编辑器后,可能再考虑回归吧。

所做的项目也不像去年涉及到 Android 的很多层面。
准确的说从三月底跳槽后今年只做了一个项目 ———— RK3399 的开发板。包含部分的工作,即开发其 Android 系统与 Linux 系统。

首先,从公司的角度来看,项目成功量产,老板虽然挺开心(因为利润比较高,卖一块顶其他产品十块),但是个人认为这个项目是相当失败的:

  1. 软件工程师(我)/硬件工程师个人能力不足,软件上移植调试过程中涉及到的很多部分没有了解过。从学习到实践耗费周期太长。在项目初期大大高估了人员能力和预计开发时间。
  2. 整个项目开展过程中没有用到任何项目管理的思维。部分需求纯靠拍脑门,想到啥做啥,在项目后期很多需求还在添加或删除。
  3. 项目干系人管理混乱。可能因为工作强度比较大、硬件需求不断变更、和老板产生隔阂,相继离职了两位负责的硬件,硬件前后交接了两次,涉及到三位硬件工程师,硬件文档资料都没有很好的管理,BOM表以及相关资料版本管理混乱,硬件上甚至出现第一个版本的问题,第二个版本解决,第三个版本继续出现的情况。

现在尝试复盘来看:

首先,在项目初期应该由老板或者产品经理确定需求,利用 WBS 将调试模块分解为最底层的 Leaf。将每个任务的耗时至少拆分到以周为单位。最后产出甘特图或是网络图以跟踪项目进度。

实际情况是,在项目初期仅仅用了不到一个小时遍历硬件模块列出了大致需要调试的模块,便埋头投入项目的开发。缺乏深入评估的后果就是很多功能的冲突问题在后期会爆发式的出现,比如 RK3399 只有两组 Mipi CSI,有一组已经被 HDMI-IN 功能占用,但是硬件上另外接出了两组 Camera。老板知道 RK3399 支持 HDMI-IN,支持双摄像头,但是由于缺少评估,不知道这些不能同时使用。结果就是软件兼容性问题耗费的时间没有被预算到开发周期中。

而且因为没有 WBS,导致时常跑偏,比如调试 DC 与 TypeC 充电的时候,在完成调试后发现了应用层的显示缺陷,又投入大量时间了解应用层相关的知识修改 UI。诚然了解更多的知识对工程师个人是有好处的,不过牺牲的是项目的开发时间,而且这种问题在整个项目中的优先级中应该是相当靠后的。不能任由工程师天马星空的埋头死做,要时常回头看是否和 WBS 上的主线任务相契合。

其次,项目责任分工不明确,软件开发没有话语权,HR 负责担任兼职项目经理。应该由老板放权,指明第一项目负责人是谁,他将拥有资源调度的权利。

比如在本次项目的干系人中,话语权最大的是老板,同时会承担项目前期产品经理的工作,话语权第二大的是 HR,兼职担任项目经理的工作,软件开发和硬件开发话语权最小。HR 因为对技术知之甚少,在项目中期会传达错老板的需求。从而影响项目开发的进度。
同时项目资源调度也不够及时,比如有的 IC 原厂提供的代码过于老旧,会产生一些顽固的 Bug 可能耗时一周都停滞不前,老板便会勒令 Pending,从其他的模块开始调试,完成其他模块调试后又回头来调这些 Bug,需要重新恢复现场,回顾代码,这种做法相当浪费时间。
我认为当遇到某颗 IC 调试有问题的时候,正确的做法应该是由项目经理立即协调 IC 厂的 FAE 或者 SoC 原厂的 FAE,及时提供支持。将难题解决,而不是不停搁置。

对于一个拥有健全完好的分工的嵌入式项目,一定可以跑得更快。

项目范围管理很糟糕。需求时常变更,变更时也没有深入调研分析这种变更是否是值得的。正确的做法前面也有说道,应该在项目初始阶段做好各个模块功能的评估工作。有规划的进行移植工作。

项目没有时间管理的概念。应该利用甘特图等工具,定好项目主干、明确以哪些功能为节点。

复盘后思路确实更加清晰了一些。
在 2018 的工作中,一方面要多补充自己项目管理的知识点,一方面要将这些知识点运用到开发工作中。相信后面会越来越好的。

关于生活

今年一共读了 4 本人文书,相较去年的 18 本,确实有大幅下降。可能是因为获取知识的渠道发生改变了。
因为项目上的工作比较紧,静下心来读书的时间确实难得,现在碎片化获取知识的渠道变成了 微信听书 以及 得到App。
他们的共同作用都是会有人负责提炼一些书中的核心观点,然后进行分享。对于快速获取信息而言着实很方便。
不过说这种方法很好,也不尽然。一则,确实太急功近利了; 二则,别人咀嚼的东西即使吃进去也是别人咀嚼的,和自己咀嚼后吞下的是完全不一样的。
暂时打算明年也还是通过这种方式,在得到上订阅至少两个专栏,利用碎片时间尽量高效的扩展自己的知识面吧。另外,除了输入,最好也能输出一些,这样可能才是更加高效的。

今年 Keep 上一共锻炼了 600 分钟,和去年相比,相形见绌。体脂不断的增加,实在是无可奈何。虽说时间是压榨出来的,但是周日早上的懒觉真的是很难割舍啊。
也许有效的方法是平常早上起早一点,适当锻炼,体质增强后睡眠质量也应该也会增加,也就不那么依赖睡眠时间了。达到一种良性循环。

去年制定的计划,开始理财,算是完成了。一共拿了两万五,趁着行情还不错,一年赚了 5000。这么算年化收益达到了 20%,真的是人不理财,财不理人啊。
缺点是太累了太浪费时间了,每天上班电梯、下班电梯、中午吃饭,都会情不自禁的掏出手机看看行情。
明年也许可以在代办事项上划掉理财这一栏,把更多的精力放在对自己的提升上,因为对自己能力的投资,才是真正年化收益率最高的理财方式。

总结

一转眼毕业两年半,感觉时间越走越快。
回头看看,自己对不对得起 2017 的自己呢,说不上来。
总之 2018, 继续加油。一切都会更好的。

CATALOG
  1. 1. 关于工作
    1. 1.1.
    2. 1.2.
  2. 2. 关于生活
    1. 2.1.
    2. 2.2.
    3. 2.3.
  3. 3. 总结