标签归档:管理

2020 年这一年

随着时间的奔逝,2020 年翻过了最后一页,来到了 2021 年的第一天。在过去的这一年,听到的和从网上看到的是大家过的都不容易,与我而言,我仿佛经历了许多,又好像时间在某一刻就停在了那里。

疫情是过去一年的关键字,是绕不开的话题,也牵动着每一个人的心,早期当铺天盖地的消息涌来的时候,我第一时间感到的是迷茫和不解,然后是沮丧,这些迷茫不解和沮丧仿佛让我回到了 2002 年底开始的那段糟糕的日子,对于一些事情,我们好像总是很擅长遗忘。所幸的是一年下来,我们都还在,所以我们有必要对那些各行各业的奉献者致以最高的敬意,当然也包括我们这些安静宅在家不添乱的人。

从我的日常来看,过去的一年跟上一年并没有什么太大的不同,我依旧在家做着项目,读着书,看着剧,听着歌,痛并享受着孩子们的「骚扰」,提醒孩子的网课,检查孩子的作业……

— 项目 —

既定的几个项目的开展整体上还是比较顺利的,其中一个项目随着项目的启动,按照既定的需求在年中基本完成,但在年底的时候需求有些变更和增加一些新项,这就顺延到今年了。

年初的时候尝试接触了一个新行业,并找了几个朋友「当然都是线上」,准备在这个新行业的一些项目上进行尝试,后因时间和一些客观因素最终没有继续下去。中间有朋友给介绍的几个项目因为疫情搁浅后目前都没有下文。我本来想给一个技术大牛牵线的项目,经过简短的评估后也没有下文了,这一年因为疫情很多项目都取消了,有些甚至企业都不存在了。

年底的时候开始入坑 Java ,准备截止到今年上半年完成一个软件产品的初始版本,产品面向企业用户,按照目前的情况,进展比计划慢不少,好在顺延的项目进度不错,接下来可以给这个产品分配更多的时间,另一方面除了继续看项目实战课程,也要要跟一直在这个领域中耕耘的朋友唠唠嗑,在学中做,做中学。

做项目得以让我在家也略微能有一些收入,这是一个选择和取舍,其实做项目并不是一个好的方式,它多数情况是把自己一段时间的产出出售一次,理想中应该是找到一段时间的产出能卖出去很多次的机会,在没有发现这样的机会前,做力所能及的项目既可以获得经济上的回报,又可以在做的过程中尝试寻找机会。年底准备做的产品就是今年的一个尝试。做项目还能让自己保持一定的一线战斗力,毕竟还是喜欢这个,虽然比不上现在的年轻人,但自娱自乐也是蛮不错的。

— 阅读 —

读书基本上是一种习惯了,除了特殊的事,每天在固定的时间都会读一会,一般是早晨送完孩子后、午饭后和睡觉前这三个时间段,差不多都会读 1 小时这个样子。读电子书多一些,主要用「微信读书」阅读,纸质书也读,数量上要少一些,去年一年一共读了 112 本书,其中在「微信读书」中看了 88 本,纸质书 22 本,在 Kindle 中看了 2 本。

其他方面的阅读花的时间非常少,我经常一个星期都不看一次朋友圈,付费的社区也会集中时间刷一下「扫视的方式」,到期的也就不续费了,朋友们推荐的文章会收藏分类后,一般会在周末集中时间仔细阅读一番,这样操作下来,感觉不错,今年继续保持。

阅读中我会用钢笔在笔记本上写写画画,纸质书会在书上写写画画,这种方式现在看来有些问题,一是让信息太分散,二是随着年龄增长可能需要更多的重复次数加深记忆,今年要在此基础上把这些写写画画的内容数字化,然后与在电子书中的标记内容整合在一起,录入电脑,统一在「Notion」中管理起来。

过去的这一年读到了不少好书,有开阔视野的,有引发思考的,有解决问题的,有纯硬核知识的,有让人感动的,也有看不太懂的,收获自然有一些,不懂的也更多了起来,让我比较欣喜的是能感到各个拼板在慢慢的填充着。

微信读书 — 我的年度之书

微信读书 — 这本小众的书还是不错的

— 影音 —

偶尔听歌,比较大的变化是去年又开始看剧了,上一次这样看剧可能要追溯到 08 年了,这之间的十二年很少看剧,主要是去电影院看电影。那这过去的一年就补回了很多精彩的剧集,也翻出老旧的片子怀了一把旧。

一共看了 99 部影视,阿凡达和指环王三部是补录的,阿凡达是跟家里领导一起看的第一部 3D 电影。

今年还是要继续看剧的,但要控制一下量,今年要开始上 B 站看看,这两年从年轻的朋友们日常言谈举止中学到了很多东西,所以他们关注的东西一定要看看,一定会发现不一样的东西,而 B 站是他们经常谈论的,有不少已然在 B 站下场实践了,这些年轻的朋友非常可爱,视野非常开阔,行动力也是杠杠滴。

— 家庭 —

家庭主要就是日常的生活,大体上就是柴米油盐酱醋茶,嗯,还得加上让人焦虑的教育。今年没有带孩子们远行,能出门后也是只去近郊空旷的地方转了转。倒是我自己在去年 11 月份的时候出了趟差,到甲方现场碰了一下需求,出差的地方比较特殊,一个小县城也是我的家乡,得益于疫情我能够在出差的期间有一定的时间观察一下我家乡的现在,回来后我也断断续续的在记录观察到的情况,目前还没完成。

孩子们还是挺给力的,在秋季开学后,随着体育运动的开展,在校排球队的老大与他们的团队一起代表学校参赛,拿到了金水区的第一名,对于二年级下学期自己选择并进入排球队,老大基本上一路保持着良好的热情和刻苦的行动已经有两年了。老大另一个自己的选择是围棋,也在下半年考级后晋级为业余一段。

小的在缺少一学期幼儿园小班生活后,秋季直接开始了幼儿园中班的生活,开学不久后被选中代表幼儿园参加河南省幼儿基本体操乙组的比赛,她们这些小朋友们在老师的指导下,通过加班加点的训练,在比赛中获得了一等奖。

两个孩子都通过自己的努力取得了成绩,我在为他们高兴的同时,也想了很多,教育是有孩子后家长关注的重点领域之一,它也给很多家长带来了焦虑,尤其是在当下的这个环境里,好像可供选择的并不是很多,而现在的这一套方式应该是目前最优的体系,能够保证绝大多数人受到教育,获得平均水平的知识,然后还有那么窄窄的一条缝隙,供优秀的人穿过。对于目前家里的两个孩子,今年大多采用放养的方式为主,一方面以各自的自己选择为主,然后给予鼓励和支持,另一方面多以身作则的给孩子们做一些榜样,试图让他们养成一些习惯,但一年下来并不太可行,潜移默化是很难的,文化课的成绩也随着老大年龄增长,周围可玩的增多而有所下降。

文化课的成绩下降其实并不使我焦虑,有些着急的是思维方式并没有同步提高或改变,学习方法也主要以记忆为主,日常以完成任务「作业」为目标。对于老大我通过他排球取得的成绩和日常的刻苦训练,如何把自己玩的游戏玩的出类拔萃等角度引到文化课的知识掌握上,但多次引导不甚理想。

坦白讲目前并没有太好的方法,我的应对办法就是密切关注这个领域,不断的尝试,多与朋友们交流请教,我想更多的是要相信孩子,给他们时间,他们自然会找到办法,咱们不都是这么长大的吗?

最后,今天是元旦,是新年的第一天,这一天也是我和我家领导结婚的纪念日。不知不觉 11 年过去了,感谢共同的陪伴,我们会继续一路携手前行。去年很糟糕,今年会变好吗?我不知道,可是好与不好那又如何?我们不都得面对?我想应该坦然的面的生活,在柴米油盐酱醋茶的同时,我们也不妨偶尔探寻一下琴棋书画诗酒花。

2021,我们来了!

本文首发于我的微信公众账号「时间易逝」,欢迎订阅我的微信公众账号
在微信中搜索「doevents」或用微信扫描页面右上方二维码可订阅我的微信公众账号

2018 个人总结

今天是 2018 年最后一天,时光匆匆忙忙就又跑了一年,在过去的这一年中,看到的,听说的,经历的好像都不怎么如意,这是一个凛冬之年。想想这一年好像没有什么值得总结的,思来想去之后觉得还是应该给自己一点点的仪式感,所幸就叨叨几句。

这一年总体来讲比较简单,大部分时间围绕着孩子在做几点几线的一些事情,上学放学的正常接送与跆拳道、围棋两个课外班接送,外加检查检查作业。在这个过程中其实能看到很多的挺有意思的事情,比如围绕接送与辅导学生的小生态中就存在很多的产品。

接与送中间的间隔时间主要用来读读书,这样一来书倒是没少读,前前后后差不多读了 135 本书,与去年基本相同,但远超去年的计划。

去年还做了一些计划,比如预计做的产品和尝试一些小的事情,今年均未按计划完成,预计做的产品在一季度后就撤离了,小的事情也未曾尝试。

年中与家人一起回了趟青海,短短 7 天意犹未尽,毕竟是故乡而又风景如画。在每个人都忙忙碌碌的现在,能够见见朋友们,感受一下夏都的凉爽无疑是极美的。

基本上 2018 年就干了这些事,比较简单,在简单中给我带来了很大的不适应,我花了相当长的时间来进行调整,但直到如今仍未达到理想状况。

这种不适应主要是自己的习惯与时间的分配造成的,白天能用的块时间是孩子上学时候的时间,这部分时间大概上午会有 2.5 小时,下午会有 2 小时,这中间还有小的随时过来互动一下,在开始时尝试了一下做产品相关的工作之后,发现根本不行,就主要以看书来使用这些时间,然后尝试调整,效果不是太好,放到晚上倒是效果还行,就是身体不太允许了,毕竟年龄不小了,可能随着小的也上学后会好一些。

大概要叨叨的就这些了,2019 年准备做些什么呢?现在来看也比较简单。

两件重要的事:继续完成孩子上学的接送与作业的检查;尝试寻找在家赚钱的方式「毕竟曾做过共享软件」。

其他要做的事:继续读书;继续保持完成每日多邻国学习;继续间断性的写写东西;在线上社区多一些互动,看是否能提供力所能及的帮助。

最后,感谢家人在 2018 年给我的帮助,感谢各位兄弟朋友给我的帮助,感谢 2018 年遇到的每个人、每本书,是你们使我得以能够继续成长,看到希望。

本文首发于我的微信公众账号「时间易逝」,欢迎订阅我的微信公众账号
在微信中搜索「doevents」或用微信扫描页面右上方二维码可订阅我的微信公众账号

2017 个人总结

时间的脚步总是很快,转眼间一年就又过去了,在懒惰和拖延症加持下有些日子没写东西了,这不太好,趁着新年的开始,有必要回顾一下过去的 2017 年,同时展望一下新的一年。

总体上,2017 年略显平淡,并没有太大的突破性成长。年初定的目标完成了一些,并没有完全达到预期。

工作上,在 8 月份正式告别了这段职业生涯,选择了主动性失业,跟 2017 年初的计划有所出入。年初的计划是工作完这一年,按照投资股东们的设定带来一定的现金流,告别全部由投资款运营公司的状况,但设定往往并不能按照预期,在年中的时候产品环境有所改变,家里又有些事,身体也略感不适,最后选择提前离开。虽然是客观存在的情况,但终归根据任命公司是由我负责在管理,所以这责任我得认。总体上来说这段职业生涯是蛮有趣的,有趣的人,有趣的事,有趣的公司,感谢你们。

在英语的学习中基本上每天都会在某 App 上完成 20 分的经验值,基本上完成了 2017 年初订的目标,初步养成了习惯,今年保持这个习惯的基础上每天增加完成 10 分的经验值。就目前来看收获不是非常明显,感觉到对单词和一些句子熟悉了一点点,读起来也略微顺畅了一点点,可能需要更多的时间积累和沉淀。

在阅读这方面完成的还不错,2017 年一共读了 134 本书,超出计划 34 本,阅读的书中电子书占绝大多数。经过几年的延续,阅读已是习惯自然的事,今年计划减少阅读数量到 50 本,增加重复阅读量。阅读的收获还是不少的,不仅仅能够开阔视野,更有了进一步了解自己的可能,同时它很有趣。稍晚些时间我会单独整理一个书单,把我看着不错的书分享给大家。

练习钢笔字也是 2017 年初制定的一个计划,这个执行的不好,断断续续有一出没一出的,以失败告终,今年索性不再纳入计划。

在写字上,2017 年在公众号上共写了 20 篇文章,坦白讲并没有制定明确的数字目标,仅仅作为自己尝试锻炼写作和内容输出的一种方式,虽然写的不多,也写的并不好,但还是很有收获,这个今年还得继续进行,同样没有明确的数字目标,怎么着也得跟 2017 年持平吧。

基本上过去的 2017 年就干了这些事,在离职后的 4 个月中我远距离走动了一下,到了不同的几个城市,以不同的角色在各个场景体验了一番,算是对接下来准备做的事情做了个调研,调研其实并不理想,当然很大程度上我的判断可能是错的,不管怎么说,2018 年还是先把产品做出来,说多了没用,先干再说,这可能是今年上半年最主要的事情。

作为一个油腻的中年大叔,上有老下有小,但陪伴家人的时间太少了,今年要开始改善起来,同时也应该开始锻炼身体了,以前的运动在身体中积攒的能量经过这么多年的支出,是时候该补充一点收入了,就从做俯卧撑和仰卧起坐开始。

在朋友圈中大家告别 2017 的方式很多,来自莎士比亚《暴风雨》中的「凡是过往,皆为序章」这句话我比较喜欢, 无论前方有多大的暴风雨,2018 我来了,从先干出来一个产品开始,验证需要验证的,从下半年开始,做一些有趣的小尝试。

本文首发于我的微信公众账号「时间易逝」,欢迎订阅我的微信公众账号
在微信中搜索「doevents」或用微信扫描页面右上方二维码可订阅我的微信公众账号

怎样提高开发速度

软件产品想在市场上获得竞争力,开发速度是克敌制胜的重要因素之一。基于此,在产品开发的过程中,速度是每个团队都会重点关注的指标之一,每个团队都在极力想办法提升产品开发的速度,以便在市场的赛道上奔跑中领先那么一半个身位。从我自己的角度来看,我会尝试关注以下 6 方面的工作,这可能会对团队提高开发速度带来一些帮助。

及时清理技术债务,技术债务对团队生产率的影响是非常大的。技术债务很容易产生,产生后往往又不是一个能够快速修正的工作,当技术债务积累过多时,常常会花费数月乃至数年来偿还。避免产生技术债务需要优先考虑代码质量,实际中很多团队为追求开发速度往往并不注重代码的质量,或许开始能够在赛道上领先,但在整个赛程中,随着积累的技术债务,开发速度会越来越慢,直到花费巨大的成本偿还这些债务,这个阶段往往也是模仿者/追随者弯道超车的好时机。一开始就保持时时清理技术债务从整体是会提高开发速度的,毕竟开发是伴随着整个产品的生命周期而时刻在进行的一项工作。

技术债务并不是那么容易清理,依赖于技能水平与经验,但总可以从最简单的开始。比如,当发现有重复性代码的时候,可能就产生了技术债务,对这些重复的代码进行重构,既避免了技术债务的生成,又提高了自己的技能。伴随着勤快处理问题和系统演进中的即时重构除了能够降低技术债务的累积,也是提高个人竞争力的一条道路。

提高客户参与度,开发人员往往不具备客户领域内的知识,碰到需要客户解答的领域内问题时,要么等待,要么猜测,这么一来一往之中,会拖延开发的速度。提高客户参与度,有能够随时回答开发人员问题的客户,无疑会提高开发速度。

让客户参与进来往往并不那么容易,在这方面往常中采取的措施是引入行业领域内的专家,或者把整个团队进驻到客户所在的场地,通过这种方式来提高客户参与度往往会增加一定的成本,但相比缺乏领域知识造成的开发效率低下和不专业性无疑是值得的。另外一种做法是用专人往复于客户与团队之间传递这些领域内的知识,效果取决于这个专人横向的认知广度和纵向认知的深度,在以前可能由项目经理承担这个角色,现在更多会设置产品经理岗位。

精力充沛的工作,疲倦会带来成本高昂的错误,同时疲倦也会让人难以全力以赴地工作,长时间的加班是极不可取的。短暂的透支一下精力是可能的,长期透支则代表应该寻找问题的根源了。试试在单位时间的使用上投入更多的关注,这样或许会更好一些。加班普遍的现象有一部分原因是实际上投入工作的时间并没有那么长,拉长的时间线在补充了实际工作时间的同时很容易让人精力不济。

减少对开发人员的干扰,尽量将非开发的工作交给其他能完成的人来完成,减少不必要的会议,在产品开发进行中时,跟产品开发无关的事交由另外的人处理,比如行政事务类的事由专门的人负责。另一方面的干扰来自自我,面对众多的干扰源,要求我们自律一些是重要的,这方面一方面需要团队的文化制度塑造个人,另一方面选择合适的人可能是更合适的。

尽量提供优质的资源,一台电脑在手,天下我有。很大程度上开发人员的主要资源需求就是设备,不要让开发人员抱怨电脑慢、内存不足…,给他们提供优质的资源。在这些资源上省钱是毫无意义的。这方面我们可以简单的算笔账,如果每天因为设备耗去每个开发人员半小时,算算一年损耗的时间和因损耗减少的产出。

尽量谨慎地增加开发人员,除非团队人员严重不足,而且有经验的丰富员工可随时拿来用,否则开发人员的增加并不会带来速度的提升,项目往往还会进一步延期。假如开发一个产品需要 10 人月,那么并不能增加到 20 个人就能半月完成,这应该是产品开发中的常识。

将这些方法应用于开发过程中,随着时间推进,开发速度应该会有显著提高,从而使团队具有「小步快跑,试错迭代」的能力。当然有一个清晰的要达成的目标是最根本的,这就好比打仗,当团队知道为什么战斗时,具备这种能力的团队,往往每次迭代都会交付一个好结果。

本文首发于我的微信公众账号「时间易逝」,欢迎订阅我的微信公众账号
在微信中搜索「doevents」或用微信扫描页面右上方二维码可订阅我的微信公众账号

我眼中的传统软件企业和互联网企业

在传统软件企业工作 15 年后,转换阵地进入一家互联网企业,转眼快 3 年了,说说在这两种类型企业工作的一些感触。

先说说这家互联网企业,是做数据中心的,主要为中小企业提供互联网的基础服务,属于B2B模式。我对数据中心的理解是它主要解决数据在两个方面的问题:

  1. 数据在空间维度的传递「通信」;
  2. 数据在时间维度的传递「存储」。

围绕这两个要解决的主要问题构建一系列基于软硬件的产品,在构建产品过程中和传统软件企业的工作方式还是有很大不同的,具体体现在组织结构和产品开发方式有不小的差异。

组织结构

组织结构的不同在我看来最终会反应到对资源使用的效率与整体的协作力。

传统的软件企业对于组织结构的设定就是一棵树,从上到下逐渐扩展层级,高度取决于团队的规模,宽度取决于职能部门的规模。

这种组织结构比较好的一方面是每个组织成员对于所处的位置比较清晰,从职能内部来讲分工也比较明晰,有利于工作任务的分工,其由于职能部门的分割自带分组特性,可以把每个职能部门看成一条流水生产线。

不好的一面是跨职能部门的协作型缺乏灵活,沟通成本随着层级递增成指数增长,在多职能部门间涉及到客户时多有扯皮,就职能部门内部来讲往往资源过剩,最大的直接体现是你工作几年后发现每天都很轻松。

我所经历的工作企业大多采用这种组织结构,从搜索引擎中搜一下「组织结构」,能够看到的搜索结果中的图片也大都是这样的组织结构。

我所在的互联网企业采用矩阵式组织结构,在传统的树形组织结构上,职能部门在垂直上是由很多小团队组成的,有直接隶属于职能部门的团队,主要负责完成公用性的任务,其他的小团队则为各个产品团队人员,这种产品小团队在横向和纵向受到双重管理,具体来说,涉及到产品相关的产品经理会从横向综合调配各个职能部门中隶属于产品团队的人员,完成目标。涉及到职能部门行政管理则由职能部门统一管理,大概如下图这个样子。

OrganizationalStructure

这种组织结构好的一面是能够最大化利用资源,打通了横向的隔离,协作效率极高,比较灵活,会大大降低沟通成本。如果要开设新的产品线,从横向纵向组建相互隔离的团队即可,而这种纵横隔离也最大程度上降低了互相扯皮的发生。

比较不好的一面是对每个团队的领头人要求极高,针对每一个点要确立明确的目标并能正确的理解目标,执行目标。

这种组织结构也跟互联网产品的开发有很大的关系,每个组织都是独一无二的,还应当以自身的特点出发,其他的仅能借鉴不能套用。

产品开发方式

传统软件企业在产品开发方式上,比较依附软件工程的理论,无论是瀑布式还是RUP(统一软件开发过程)迭代式,都讲求产品的大而全的规划和论证,重文档,重流程,重测试,所以动不动一个软件产品开发好几年,每更新一次再来个半年一年的,不能说这样的产品开发方式不好,针对特殊领域的产品开发,这种方式还是很有优势的,比如在航空航天、金融等领域这样的产品开发方式还是挺有优势的。

互联网企业在产品的开发方式上跟传统软件企业略有不同,当要开发一款产品时,首先要围绕总体的目标找到假设的最核心的,最小化的可执行「产品」,快速实现后上线验证是否为用户带来了价值,根据验证的结果再做接下来的动作。

比如验证失败了(这是常态,所以互联网企业大多允许一定程度的试错),再寻找另一个假设的最小化可执行「产品」,直至找到或者承认失败。假如幸运的验证成功了,也就是找到用户了,那接下来用户自然会倒逼驱动产品的迭代发展,在这个过程中用户甚至还会帮助企业建立服务流程,考核体系,这也就是平常讲的「以用户为导向」。

这两种产品开发方式跟面对的用户类型也有不小的关系,如果用户是企业,一般企业用户追求大而全,这几年传统企业都在积极+互联网,但思考的出发点还是从大而全,从局域网向广域网,或许在这方面可以针对互联网的产品开发方式进行借鉴,在+互联网的时候先确立一个最小化的目标进行验证,毕竟这种产品开发方式的思路很大一部分就来自传统生产企业「丰田的精益生产」。

这里说的是软件产品开发相关的企业,其实传统企业都是可以借鉴一下,如果把每项业务看做一个产品,业务负责人看做一个产品经理,不论从组织结构上,还是在业务开展上都可以结合自己的特点进行尝试。

本文首发于我的微信公众账号「时间易逝」,欢迎订阅我的微信公众账号
在微信中搜索「doevents」或用微信扫描页面右上方二维码可订阅我的微信公众账号