公众号1周年纪念,以及我的管理实践文章预告

我从2019年7月21日开始,正式写作公众号「古老湿」,迄今已经超过1年了。

今天分享一下自己的收获——

粉丝数从200上升到了15000;

在这一年中,写过10w+爆款文,也写过仅几百个阅读的文章;

文章被删过几次,还有一篇被百度告了、索赔50万,还在等开庭;

认识了不少同行朋友,结交了大量「媒介」,被放过鸽子,也有忠实的甲方;

公众号产生了基本稳定的收入,生存可以保障,广告一般提前3个月就被预订光了(可能是我价格太便宜了吧)……

也有很多遗憾:

最大的遗憾,是至今没能撺起来一个自己的队伍,刚开始时仅有的一个团队成员也很快离职去网易哒哒写公众号了;

视频内容还是没有做起来,因为自己懒惰,没啥特殊原因;

一年来虽然粉丝数上涨了不少,但距离自己早先的设想,还有很大差距;

下面说点生活中其他的事情:

虽然脱离软件工程行业 1 年,但自己的代码能力还没有大幅度下降。前两天做了一个技术面试题,写一个3D 图像数据压缩算法,写出来了,但因为不会线性代数,也不懂如何用 numpy 进行矩阵运算,所以只能用暴力循环的方式实现。逻辑都没有错,但性能太差了——在这方面,我对自己要求不高,这已经是我的极限了,在3天时间内学习了线性代数、图像学、深度相机的基础知识,尽管距离实际生产还差距颇远。

老读者应该有印象,我非常喜欢做管理工作,从大学毕业后开始,就出于兴趣阅读了大量工商管理图书,自己也产生了一些发乎性格和直觉的见解。这些见解,在我几年管理工作中,经过实践,逐步成型,杂糅了一些管理学家的思路,产生了独到的发酵反应。尤其经过了在米筐的技术管理经历,对工业化管理有了新的认识,针对「流程管理」「人力优化」和「目标管理」做了很多创新性的工作。我的团队,即便在高手林立的米筐,也算是工作效率最顶尖的团队之一了。

而且,通过这两年对教培行业的深度观察,我还发现了一些中国企业普遍存在的严重问题,例如高层视野过窄、中层发育不良、基层看不到未来,例如各大行业普遍缺乏对本行业商业史的理解,例如一些管理基本概念搞不清楚(OKR 和 KPI 傻傻分不清楚),等等。这些在旁观者看起来匪夷所思的现象,其实就是中国企业经营的最大现状。

所以,后面我会把自己的管理思路、对经营的理解,逐渐落实为一篇篇文章,一方面,为其他管理者提供一些新思路,另一方面,也能让白领们找到向上晋升的捷径——毕竟,管理的目标之一,就是「自我提升」,做不到这一点,就不算做到卓越的管理。

德鲁克是现代管理学大师,但很多观点过于模糊,虽然正确,但实践性较弱

你在阅读我的管理学文章时,很可能会看到稻盛和夫、迈克尔波特、彼得德鲁克等人的影子。没错,就是这样,这些管理学大师,都是我的老师,我从他们身上学习了很多。我之所学,最终融合到一起,和我的性格、我的偏好融合到一起,并对这些大师的理论进行自己的再解读。例如我觉得德鲁克的目标管理,毫无疑问的过时了,对于组织的目标,不仅要使用新工具,更要有新视角。我的类似观点,在管理学界是比较激进的,但在企业经营实践中,并不算前沿。如硅谷 Netflix 中彻底忽略员工成长的经营哲学,比我激进得多,但最终依然总结为一本广受好评的《Netflix文化管理集》。

我记得我刚上浙大的第一堂课,就是管理学。当时的老师还问那个经典问题——管理到底是科学,还是艺术。现在,我可以非常坚定的回答,管理就是一门科学,可以重复、可以证伪。也正因为此,管理学作为一门学科才有存在和学习的意义。

最后,以上仅仅是一个预告。我的管理实践文章,会在博客陆续发出来,如果你是管理者、或是有意从事管理工作的基层员工,那么强烈建议看一看我的实践方法,这些方法,远比国内「大师」们的屠龙之术,更具体、更有可操作性、更有效。

敬请期待。

Tagged :

技术部门团队管理的一点心得

最近半年公司一直在对整体业务后端数据存储做大修改,由我负责开发核心的数据存储、拉取组件,这个组件以 gRPC 为协议,完全重构了早先的 Java 业务,即将部署到公司线上产品以及机构产品。除了数据存储拉取以外,其他组件之间也统一使用 gRPC 协议,这种情况下,需要一个简单易用的 gRPC 接口测试框架对各个接口进行压力测试。
而此时,我刚开始管理公司的测试开发团队,团队的常规任务是完成开发团队的测试需求,但最重要的任务是为开发团队提供简单易用的测试工具。总的来说,更偏重于开发而非测试。因此近期测试开发团队的最重要任务就是搭建一个上述框架出来,保障即将上线的新产品顺利交付。
目前团队只有我和另一个新入职的测试工程师(正在招聘手工测试员一名)共二人,由于测试工程师并无开发经验,刚开始上手开发有一些障碍,因此对稍微复杂的开发任务表现出无力感。
在这种情况下,团队管理出现几个挑战:

1. 新入职员工对工作内容不熟悉、以及技术上有欠缺,无法独力完成项目
2. 团队人数较少时,人事关系容易出现扭曲,表现为团队负责人与成员过于亲密或过于疏远,这两种情况都会伤害团队未来的发展。
3. 新成立的部门往往被委以重任,甫一成立就会面对攻坚战类型的技术难题,而此时恰恰是作为新生儿的团队最脆弱的时候。

针对挑战一,我的解决方式是,结伴编程快速提升工程师的基础开发能力,并使之在短时间内熟悉公司的技术栈和代码规范。这段时间压力会很大,学习内容也会很多,但是要求并不能放松,需要管理者持续关注工程师的进度和心态,对成员烦躁、失落的情绪及时进行安慰和疏导,同时在某些环节进行必要的技术辅助。
针对挑战二,首先避免过分亲密的关系,保持普通的社交距离,同时也在处理「挑战一」的时候让对方感受到你的关心。张弛有度,会使双方关系有序的发展下去,也为团队的长远发展打下基础。
针对挑战三,要和部门的上级主管进行沟通,确定部门的目标方向,然后主动将目标按优先级一一列出,根据实际情况向上级索要资源(要么给人,要么给时间,要么降低任务量)。以我的经验,能够主动索要资源的团队,往往是资源最充沛、进度最快的团队;对于管理者来说,一个能够合理索要资源的下属,也大概率是一个有思考深度和执行力的团队成员。
在数年前做运营的时候,团队管理就是一个我很重视的问题,每个工种对人有不同的影响。例如运营部门的基础运营成员往往看不到职业发展的前景,进而转行到其他行业;一线工程师则埋头于技术,疏于梳理工作内容和工作前瞻。这样其实给团队管理提出了很大挑战:作为管理者,到底能在多大程度上纾解这些职业对成员的负面影响、并提高团队运行效率?
在前些天给 CTO 提交的一份测试开发团队工作计划书中,我提到了进行人才梯度建设。虽然测试开发团队人数不多,以后最多也不会超过5人,但是由于分工不同,必然产生事业层次的高低。在团队内部明确人才梯度,告知每个人未来的上升渠道,指明上升的途径,不仅成员会主动成长,人员流失率也会得到降低(软件测试行业的流失率非常高)。一旦形成稳定的循环,那么这个部门将能够实现「无人驾驶」,几乎自动化的在公司内部高效运转。这也是我未来的工作目标。


最近买了一款 CMON 出品的卡牌构筑类的塔防主题游戏《XenoShyft: Onslaughter》,感觉比领土好玩很多,无论美术或游戏机制都远远超过其先辈们。先贴几张图以飨读者,后面会写一篇文章,来介绍和评论一下这款游戏(前两张图是我拍的,图中还乱入了我的猫「三十」。最后一张游戏图是 Google 来的,仅供示范)。
WechatIMG55
WechatIMG56
Xenoshyft-Board

Tagged : / / / / / /