蚂蚁金服上市后取消了周报，为什么我说不合理？

听说蚂蚁金服上市后，不用再写周报了。全公司上下奔走相告，每个人好像比财务自由还开心。

听到这个消息，我低头思忖，蚂蚁恐药丸。这种体量的公司一旦上市后，掉以轻心，盲目自大，恐怕是要步史玉柱的“巨人网络”后尘，活成马老大曾说过的那个预言，“多数人死在明天的晚上”。

不计较上市“既得利益”，保持饥饿，继续追逐辉煌，才能守得住江山，持续创造价值。仔细盘一盘，国内上市后不套现的大佬没几个，而且国内也不常有 Goldman Sachs 一样的合伙人制度规约，反而因合伙人意见不同而频频造出丑闻的公司不少，好比某当的夫妻合伙档。

但，马上查阅内部人士流出的截图，似乎我这一波担心，是多余的。

周报虽然取消，TL(Tech Lead)的月报还要继续。这当然是好事，蚂蚁的那颗炽热的红心还在。

有人可能会说，周报，月报是奋斗比的表现，卑微地讨好上级，不值得一提。还有同学会认为，革命成功了，财富自由了，应该好好享受生活。写周报就是虐待自己，该抛弃。

作为一名爱好写点豆腐块文章的小作者，写周报这事，我赞同蚂蚁的做法。应该积极鼓励周报制度，最好写日报。

前排的同学，板砖可以先放下。
后排的同学，F字可以先咽下。

我这么说，当然有足够的理由。不会写日报，周报，月报，惩罚会绵绵不绝地找上你。不错，就是惩罚。

我就是个典型的例子。

老读者都知道，刚工作那会，我是在电子厂写 MIS 软件的，也就是信息系统管理软件。当时的老板，主抓生产，没有从 MIS 看数据的习惯，需要什么数据，开个大会，把各个口子的负责人拉到一起，挨个汇报下，他就清楚了。

每个负责人都非常有规矩，一人一本，上面写着今天的日产，库存还有人工等等。那场面，就像美国人这次的安全部门开会一样，对答如流：

引自：https://weibo.com/6479869715/IvYljlfNV?type=comment

如果你认为这一切，都是理所应当，那么回头找找黄冈卫健委的回答。

话说回来，每次开会，我是最紧张的一个。我既不懂生产，又不懂管理，写的软件，数据也没有获得老板重视，每次老板叫到，“ 小黄，你那边情况咋样，有什么要补充的么？” 我都只能耸耸肩，回答没有。顶多汇报下，报表打开慢，操作系统有病毒，或者新加功能什么时候能上线。

就这样过了两年后才发现，原来自己说不出来，真的是自己水平问题。我总想在当场就能口吐连珠，才思如喷涌，可平时没有积累素材，没有经过训练构思成文，没有真正自己演练过如何演讲，还要想着诸葛舌战群儒那份慷慨激昂，太天真！一口气怎么可能吃成胖子呢？这不是痴心妄想，是什么。

意识到这个问题后，我就开始写东西，写日报，写周报，写月报，写年终总结，还在博客写文章。

有时候在本子上用笔写，特别费劲。思维特别快的时候，码字儿速度跟不上，就写得特别丑，看着看着就没心情写，因为个人对美观还是挺看重，排版不好就能逼死我这个强迫症。于是换到电脑上写。那时候也没有云笔记，换电脑时，就经常丢笔记。换过至少5,6个本子，丢过的笔记不少。后来 有了云笔记，就一直没丢过了。

以下是我个人云笔记，大概3-4天会有一篇。如果有发表的必要，我就发布在公众号。

甚至在代码里写注释也成为了我的爱好。和我工作过的朋友，可能对我代码印象不深，觉得晦涩，但往往都会觉得我的注释，非常舒服。就算有时候代码重构的太过风骚，但一步步的推进，用法，都会标有详细的注释。写代码要考虑到简洁，性能，还要考虑到后续维护的成本，万一别人看不懂怎么办。我记得半佛有句话，戏称 “ 我看众人兼 SB，我料众人看我亦如是 ”。这特么太写实了。

接下来的两年，老读者也清楚了，我把各类报表升级成了 BI 软件产品，嵌入到公司的 MES 里面。写了长长的介绍与操作指南，发给 MES 的各个用户（这里的用户大都是各个分公司分厂的厂长，制造经理，甚至是党委书记等等），几乎是一夜间，用户需求纷沓前来。

只见过文字，表格形式报表的老派用户，哪受得了可视化对他们的诱惑，各种图表制作都提了出来，这一仗算是打开了公司数据的 BI 化。平时瞅都不瞅我一眼的 IT 部经理，开会都点名安排我坐在他身边。自那开始我知道，该找个更大的平台了。

虽说这是微不足道的小事，但至少给了几个启发：

1） 平时注意收集项目中的素材，包括风险，进度，技术难点，行业动态和故障克服方法，对此多做总结，等到有机会汇报给老板时，才更有底气。自己贡献了多少，怎么做的努力，形成什么样的理论和实践方法，都可以分享给老板。有时候老板未必知道我们做了多少工作，尤其在人多的情况下，我们贡献了什么样的价值，老板并不能清晰的知道。这时会叫的孩子有奶喝就成了常态，与其让老板去回忆，去思考你的价值，那不如我们写出来，直接跟老板沟通。

2）我观察，周报的时效性远小于日报。程序员在接收工作任务时，往往以小时为单位。比如 4 小时解决一个 bug, 32 小时完成一个中等量级的任务。64 小时完成一个 sprint. 如果一周做一个 sprint,可能你还知道这周干了什么，用到了什么技术，哪些方面自己不熟悉。假如一周尽在修 bug，修了 10 来个,痛苦的要命， 但在复盘的时候，什么都想不起来。自己先想下，是不是这样。你还能记得上一个 bug 产生的原因，以及修复的方法吗，知道怎么去防止这类bug再次产生，有没有一个清晰的路线？这其实都需要记录。

3）编程是个多元化的工作。如果任由自己整天处在救火之中，不给自己留时间放空，我们就无法开启下一段的旅程。整天在处理 CRUD 的工作，而没办法去深入研究各类数据模型，数据库内部原理，那么我们积累的那点小知识，小技巧，早晚会被年轻而聪明的后浪给超越。而日报，周报留给我们的，就是很清晰的一个复盘资料。哪怕那天没记录，也至少知道一周中是不是无效时间拉长了，接下来怎么去弥补。当回头审视自己的任务时，发现这段时间一直在处理 sql 的事情，而对 big data, BI, AI 都没有更好的扩充积累，那么很快就会提醒自己，该看点别的什么了。

4）团队的协作更高效。团队之间协作高效的方式有很多，最杀时间，最无效的便是毫无意义的多人大会。往往老板没想好主题，团队也没对事情有充分的预热，就硬凑着一帮人开会，结果张三李四都插一句，事情没啥进展，还浪费一拨人 2-3 小时的生命。如果采用异步的文字分享和预热，比如分享周报，绝对是特别有意义的事情。当年很多工作的同事，看了我的分享邮件，知道有个 BI 的东西正在流行起来，于是尝试在各自的分管部门推一推，做一做，最终才促进了整个公司的 BI 进程。你看，就是不经意同事或朋友们的一封邮件，一个总结，就能有一个创意，打开自己的思路。所以我建议，积极地靠近有想法，会创造的同事，朋友，他们往往都是灵感之泉。

在写周报这方面，尤其对于程序员，我觉得大家还是尽量逃离舒适区，好好写，不搞形式主义，不讨好谁谁谁。我也在努力，你看公众号大部分文章都是我的个人总结，都是原创，如果不写，怎么培养自己思考，说话和演讲的能力？

通过写文章，不断迭代修正自己的思维产品，这产品的好坏，直接决定自己的价值。

谁都不愿意成为第二个张飞吧：

--完--

往期精彩：

本号精华合集（二）

如何写好 5000 行的 SQL 代码

如何提高阅读 SQL 源代码的快感

我在面试数据库工程师候选人时，常问的一些题

零基础 SQL 数据库小白，从入门到精通的学习路线与书单