24 Years Old!

发布于 think

对自己说

先祝自己 24 岁生快!

今年确实成长了很多,还是要被各种现实推着走才能有所进步,自己活在舒适区太久了。

去年好像单身,去年身边单身的兄弟今年似乎也还是单身,为了逼自己改变现状,还是决定向大二投稿(公开处刑)看看有没有合适的对象能聊得来,积攒点经验值早点脱单。

从国庆之后也尝试固定每周两个晚上的跑步+骑行计划,国庆前试水了两天效果还不错:)

对公司说

这半年做了什么?

  • 内部基建
    • Blueprint 项目(用于快速构建项目后台视图用,目前迭代到了第二个版本)
    • 生产环境的分布式+容器化
  • 无线计费项目
  • 一个合作运作项目
  • 若干外包

中间遇到的问题

问题真的蛮多,总结下主要的问题:

  • 多项目并行的时候,时间间隙期问题
  • 实习时间的不确定性问题
  • 人员自觉性问题、适应性问题
  • 团队沟通问题
  • 项目选择上的问题

在团队内部半年度总结里也扩充了一下具体细节以及目前理想的解决方案,供自己参考。

总结

从实习主动 7 月因学业等因素离职开始,9 月底又因为一些考虑主动裁员 2 人

在缩人后,项目开发并发从2降至1,专注将自己觉得应该完成的项目给完善好,而不是并行 2 个项目难以管控的局面。

不裁员前(不含自己)总共 7 人(含实习 1 人),裁员后 4 人(不含实习)

人员配比从

  • 前端 3(实习1)
  • 后端 3
  • 客户端 1(Android)

调整至

  • 前端 2(客户端纳入FE范畴)
  • 后端 2

调整后,前端和客户端以及自己去学习 Flutter,将客户端纳入前端范畴。
先试水将目前的一个项目的用户端的客户端改写,从 Android 原生视图迁移至基于 Flutter 的视图,然后实现对 iOS 的支持。

自己作为机动去辅助 FE/BE 栈在人手不够的时候充数加入战斗。

  • 开销缩减 40%
  • 人员利用效率提升
  • 对目前人员的相关能力要求增高
  • 从奉行两组人两组项目并行,到合适人数高效率单项目多栈并行开发
  • 从大而全转向小而精,不过分注重规模,让团队成员都能适应和发展

算是对自己管理能力的一次打脸和反思吧。

下一步

年前再搞定完2-3个短平快的项目,然后思考下一年要做什么项目才能有所发展。

继续以技术入股的方式试水新的合作项目,同时思考自己感兴趣且投入没那么大的项目。

年初给自己定的计划虽然不顺利,但是也执行了一半多了,年底前争取全部兑现吧。

评论

是时候给自己做一个一年份的总结了,公司正式化,始于去年七月,也是自己离校的时候,到现在,刚好一年,遇到了很多事情,也学到了很多东西。

带一个团队,要让团队内所有人认同你的想法,并和你以同样的拼劲去努力做一件事情,说实话,这是非常困难的。

这一年,我犯了两个致命的错误:

  1. 招了不合适团队的人(暂时用不上、对工作技能不熟练)
  2. 以外包 + 自己团队的新项目作为团队的收入核心

第一点,是以付出人员工资为代价学到的。
作为老板,需要明白以下几点。

  • 你需要招什么样的人
  • 他能为你做什么事情
  • 他的能力是否足够满足你的预期
  • 他为团队带来的产出能否大于给他的工资

切忌招人后,以养活团队为目的来找项目,而是以项目为核心去招人,否则作为老板会活的很累,而且整个团队也在做毫无意义(赚不到钱、也没有任何技术学习价值)的工作。

招了不合适的人,公司的收入会被空耗,而且安排无意义的工作也是在消耗他们的青春,实在不合适。

创业团队,想找高单值的外包项目,除非有一定门路,否则接到的外包价格都不一定能养得活自己。对于有一定技术能力的团队来讲,做外包也是屈才。

作为老板,没有能力和精力安排好手下的工作,没有足够的经验管好他们,是作为一个老板的失职,也是对他们的不负责任。

这几天,内心做了一个重要的决定,宣布让部分兄弟转岗,如果不接受转岗,也没有合适职位的情况下就使之主动离职,以团队的情况无法为他们安排适合的工作,没必要禁锢他们在这里,早点找下家比较合适,这才是一个比较负责任的做法,天下没有不散的宴席,好聚好散吧!

接下来一年,先完善现有的产品线,在保持团队小而精的情况下,再开始做一些自己既定想做的东西,在人少的情况下也更好沟通。

与其慢慢沉没,不如减轻负荷,重新轻装上阵。

你好,我的正式创业第二年!

评论

引子

貌似是一年半前上映的电影了,现在才注意到。

这几天偶尔补《世界奇妙物语》的其中一季,听到中间一话插的 BGM 超赞(嗯,就是这部电影的主题曲,来自 Back Number 的 Happy End),然后就顺路搜到了这部电影,看了下题材对胃,果断补了。

剧情简介

(存在剧透风险,可能会影响观看体验)

这是一部交错时间线的日式纯爱片(嗯,定语很多)

男女主位于时空互相交错的两个世界,每五年会相遇一次,每次相遇30天。

不同的是,在两者的时空观里,对方的未来都等同于自己的过去。

且每一个0点都是一个重置点,自己走向新一天的时刻,对方的昨日记忆会消失。

故事叙述的开始始于男主20岁节点的第一天,女主20岁节点的最后一天。

在电车上,男主高寿“偶”遇了女主爱美,并主动在电车到站时追上搭讪。

开始的几天男主和女主交往发展的速度如火箭般,当然,内心也有疑点

  • 为什么女主那么爱哭
  • 为什么女主偶尔能够准确道出未来的事情

随着剧情发展,这些谜底也被一一揭开。

(嗯,先皮到这里,不剧透啦,各位自己去看看)

评价

亮点

  • 男女主颜值在线,两者人设好评
  • 故事设定和剧情新颖(只是对我来说,或许大家见过类似的故事)
  • 主题曲很好听(歌词真的很应景,加两百分)

故事后半段以女主的视角从男主的未来到男主的过去,从亲密到逐步陌生的过程,更是加重了故事的虐。

最后结尾收幕的时候,选择以铁轨为画面,也和故事的时空观(相互交错)贴合,很应景。

可能这个交错时空的设定有一些情理上说不通的 Bug,不过么,毕竟这不是科幻片,而是爱情片,咱不能强求逻辑缜密吧。

个人评分: 9 / 10,值得后面再补。

感想

去爱一个注定会分开的人,是一个错误的决定么?

理性上来讲,是的。但是从感性上来讲,不是的。

有时候,人就是这么矛盾的一个存在,但是如果只靠理性活着,又会十分无趣。

男主知道真相的时候也痛苦过,但是想起更加痛苦的女主,也坚持继续给女主留下珍贵的回忆,并在最后一天,给女主画像,作为今后的自己和将来遇到的15岁的女主的留念。

如果是我的话,大概会和男主做同样的选择,现在留下的记忆,哪怕过程和结局很虐,都不重要,虽然很遗憾,但是这个决定,以后的自己绝对不会后悔。

(快单身两轮了,得抓紧马力全开开拓交际圈啦!)

评论

引子

以前没有就这个问题深入思考过,最近忙碌的时候偶尔脑袋会闪过这个念头,但是没有深入作整理,趁这个机会理一理自己的想法吧。

这阵子一直在思考如何做一个合格的项目,感觉自己欠缺的东西太多了。

想起前几年做的一些蠢事,都是因为对产品经理所做的事情理解不深,还是有一些后悔浪费了太多机会,还好现在醒悟也不算太晚。

正文

合格的产品经理需要具备很多的特质,应该说任何职业都需要下面三个特点。

  • 思考
  • 执行力
  • 管理力

有这三点,基本上离成功不远了(自己还有很长的路要走)

应该思考些什么?

  • 项目解决了用户的哪些需求/痛点
  • 整体市场价值预估有多大
  • 是否已经有同类的产品,如果有,还需要思考下面的问题
    • 竞品的市场份额
    • 市场所处发展阶段(初、中、后期)
    • 和竞品横向对比,自身的项目具备哪些竞品所不具备的特点
  • 目前的大环境下,是否合适去推这个产品
    • 政策
    • 理念是否过于超前(典型:盛大盒子)
  • 资金相关(这点似乎超脱了产品的范畴,是公司层面需要考虑的问题了)
    • 能否拉到合适的投资方(最好先有一个原型/初版)
    • 推广需要多少成本,能否扛得住

产品应该做些什么?

  • 思考需求
  • 做用户和市场调研
  • 根据实际情况去定基本的功能大纲(不要自己脑补去搞空中楼阁)
  • 每个功能用具体的语言去落实想法,完善需求分析书
  • 基于上面的点去画原型图
  • 和C(B)/S端负责人,沟通具体的需求,确定对方在理解了需求的情况下动手
  • (可选)产品如果懂技术的情况下,最好能出一个接口大纲(方便前后端在开发进度上实现异步)
  • 定期去跟进双方进度,必要的时候做中间协调人

产品进阶:如何成为合格的项目经理?

能否快速在短时间内,运用现有资源做出一个还算过得去(不要过度注重面子)的产品,就看执行力和管理力了。

执行力不是项目经理一个人的事情,需要有能力调动整个团队一起爆肝出货。

管理力则体现在妥善安排项目功能的优先级,适当做加减法取舍一些东西。

永远不要想着出一个绝对完美的东西,可以先期出来之后试试水看看市场反应,后期逐步进行迭代和改进。

在这过程中,也需要不断推翻自己的想法,使自己的想法更加成熟。

管理上的门道也比较多

  • 如何安排合适的人去做合适的事情
  • 如何协调各个部门的工作
  • 如何妥善排程,不在非必要的地方造成单点block
  • 脸皮要厚,不要过分顾忌他人颜面

后记

写的挺乱的,也只是给自己做一个思考范本,可能对他人不适用。

其实一个人做东西也是做,几个人做东西也是做,很多的角色如果能一个人兼任(全才),能节省很多沟通成本,且更不容易做歪。

现实则是,一个人精力有限,能分清主次,优先做重要的事情,是很有必要的。

首先,还是要做一个正常人,保证正常作息的基础上,最大化自己的工作效率!

一些参考

评论

总评

这本书是 Joel 的博客中的一些文章的摘录,文章简单按一些要点进行了一些分类,这次看的是卷一,里面主要讲了 Joel 对于软件公司运营以及软件开发的一些看法。

这本书中的很多文章观点鲜明,充满了个人特色,从中可以看出作者是一个忠实的软粉,毕竟也在微软干了几年,哈哈,抛去一些有偏见性的文章以及一些放到现在应该老早算过时的观点(毕竟这本书中文初版发行是在10年前了,最初写文章可能有接近20年了吧?),很多内容还是值得借鉴的。

中心思想:人和时间就是一切,不要做一些大量浪费时间且收效甚微的举动,优化日常开发流程,以节约时间,使收益最大化。

主要内容

  • 合格的软件公司应该具备的特征
  • 如何进行软件设计
  • (大型)软件的错误反馈机制设计(似乎已经都是按书上说的来弄了)
  • 开发者面试和管理知识

一些不错的观点的提炼

  • 先做必要的设计,充分理解设计后,再进行开发,避免后续高成本的弥补设计时的过错
  • (对于小公司而言)招人时一定要一步到位,确定招的人能够胜任工作(聪明、能干),能省却很多后续麻烦
  • (小公司可能无法实现,但是有必要)测试很重要,且有必要请足够的专职测试来分担开发的工作
  • 有必要引入合适的项目进度管理机制
  • 分配任务时尽量避免把多种不同的工作同时分配给一个人,人需要时间去转换思维
  • 不要随意抛弃旧代码并且完全重写,时间成本过大且还得重新考虑不少实际应用场景下的问题
  • (以麦当劳举例)作为一个小的实体,更容易有自己的特色并快速产出产品,大的实体为了向外界输出统一的价值观,总会定制繁杂的规则,而出来的东西却趋于平庸(可以用成语尾大不掉概况?)
  • (以本杰瑞和亚马逊举例)如果一个市场还是蓝海,可以考虑快速引入投资,进行激进发展来占领市场,如果是红海,则需要稳扎稳打,稳步发展
  • 利用扶持配套软件(环境)的发展,来给自身带来盈利
  • 不过分追求新技术,采用整个团队现有能适应的技术栈,避免在研究新技术上浪费大量时间
  • 不要排斥别人的代码,每次都自己造轮子,但是,和自己业务直接相关的部分,不要去用别人的轮子,请务必自己去实现,这是公司的立命之本
  • 每个人都应该带头去主动优化开发流程,然后以自己的实际行动去影响别人,哪怕现在没人这么做
  • 可以接纳客户的意见,去调整一些细枝末节的地方,但是主要结构不能去动
  • 以接纳与开放态度设计产品,解决客户使用产品的障碍,从而逐步从竞争对手手里吸纳用户
  • 自己去使用自己开发的产品,找出不足,并改之

一些不足

一些内容放到现在已经过时,不过毕竟距离作者写这些东西也有接近20年了呢。

作者作为一个曾在微软工作的人,写了很多微软的优秀品质,但不免带上了一些对其他同类产商的不屑的话语,有些过于随意。(不过后面也抱怨微软一些产品的做法)

作者强烈抵触绩效考核制度,弱化制度管理,倾向于招进来的人各个都是天才,各个都有主观自觉,能够发挥主观能动性,但是,现实往往和理想差异甚大。。。

作者在非连续的多处地方对一些只说大话不干实事的行为表示了嘲讽,能够理解作者的想法,但应该精简这部分的篇幅。

不过这些不足也能体现出作者个人的个性 - 语不惊人死不休,立场鲜明啊!

就算有种种不足,这本书仍然值得一看吧!

评论

BranchZero

一只向全栈不断努力的 Web 开发者、运维、与眼镜娘控,面向 Google 和爆栈编程,继承了大部分理科宅的特性(除了审美),可惜是个 Acer


Web Developer


HangZhou