在决定要写「知行周报」之后，我和娄娄对要分享的内容进行了沟通和规划。在这个过程中，她跟我提到一个问题：因为工作上和技术组的直接合作比较少，技术伙伴们又大都少言寡语，所以她很好奇技术组的工作日常及状态，因为似乎和她经常在媒体文章上看到的 996 程序员不太一样。

确实，技术组一直隐于幕后，能直接面对用户沟通交流的机会不多，作为技术组第一个写周报的人，我想我有必要借这个机会向大家介绍一下有知有行的技术组以及我在这里工作的体会和观察，希望能增进大家对技术组的了解。

技术组大合照（文字版本的）

先给大家总体概括一下技术组的工作内容：

我们需要针对 iOS 和 Android 系统分别进行有知有行 App 的开发工作，还要开发一些基于网页的内容，比如大家经常使用的市场温度页、文章阅读页，这样大家在 App 和网页上都能看到这些内容。我们也需要开发运行在服务器上的程序来实现各种功能，比如更新账户资产、发表想法、修改昵称等。此外，还需要保证服务器、数据库这些基础设施正常运行，保证大家在 App 和网页上发起的所有操作能够被快速响应。

技术组伙伴们的日常工作就围绕上面这些内容展开，只是每个人负责不同的部分。

我们经常说，用户不是业务图表上的数字，而是真实生活场景里的人。有知有行 App 的背后也不是冷冰冰的代码，而是技术组的每一位伙伴：

• 米老师是我们的 CTO，拥有丰富的工程经验，博览群书，风趣幽默。偶尔在深夜喝啤酒，经常在公众号上发一些我有时看得懂，有时看不懂的文章。

• Louie 是我们的后端工程师，从「财帮子」那会儿就和孟岩一起创业。喜欢网球，是孟岩多年的球友，你可能看过他的小破车的故事。

• 振民是另一位后端工程师，工作之一是负责后台运营系统功能的开发和维护，解决了编辑和运营伙伴们的痛点无数，常被他们唤为「振民男神」。目测经济实力雄厚，拥有 BenQ ScreenBar、Herman Miller 人体工学椅、搭载M1芯片的 MacBook Pro 等各种先进设备，就差把「工欲善其事，必先利其器」这句话刻在桌上了。

• zed 也是一位后端工程师，负责记账功能对应的后端服务。在遥远的佛山远程办公，由于疫情影响，我们已经很久没有见过面了，听说他最近晚上等娃睡觉以后，会举铁减肚腩。

• 振凯是我们的 Web 前端工程师，有时也会负责后端服务的开发，明明可以靠颜值出道，却还是选择来有知有行展现实力，他之前就上过知行小酒馆。

• iOS 工程师凯爷是运动达人，熟练掌握篮球、羽毛球、足球、网球、乒乓球、跑步等运动，前段时间饱受牙病困扰，后来久病成医，前不久还在 TGIF 上分享了牙科护理知识。

• 华伟哥之前是 Android 工程师，自从我接手他的工作后，已经转型为后端工程师了。他是一位长跑健将，虽然身处 40~59 年龄组，有氧适能却达到了 59。作为参考，20~29 年龄段有氧适能水平及格线是 48。

• 大勇哥是我们的运维工程师，常年穿拖鞋上班，每天下午 3 点准时去跳绳，当然，也是穿着拖鞋跳。很多人不知道，大勇哥在知识库中有一篇名为「Something on Tue」的文档，记录着每周二黑板报发布文章时，服务器的流量访问情况。

• 而我，则是个普普通通的年轻人，大学专业是电子科学与技术，饱受折磨后决定半路出家，自学编程，身处上述这些神人之中，时常感觉自己平平无奇......

有知有行的技术组由上述九人组成，是我加入的第三个团队。在此之前，我过着标准的 996 大厂程序员生活，即便是在夏天，也从未能在结束一天工作时见到过夕阳。

在那段 996 的日子里，时间过得很快，但当我试图回想起每一个具体的项目，却又总显得面目模糊。有一天，我在 Xmind 官网看到了他们创始人孙方的演讲，他说在 Xmind 有一个「奇怪的现象」是员工可以按时下班，「在南山科技园，找一家按时下班的公司恐怕比找北极熊还难。」

他说，那些加班的公司，做事逻辑是别人有什么，他们就要有什么。一定要比别人做得快、做得早、做得多。如果是这样的思路，就一定要加班，基本上什么都是要争的要抢的，在这样的公司，工作是做不完的。而 Xmind 能按时下班的原因是，他们不和别人比做得快和做得多，而是精心打磨自己产品的功能，他们的工作是做得完的。

与竞争对手互相攀比着做功能，和同公司的不同部门、项目抢资源，浪费大量的人力、物力，最后做出很多没什么人用的功能……跳出来再看有些恍惚，但身处其中，这就是互联网行业每天都在发生的事情。当时埋头 996 的我记住了孙方的这段话，虽然非常羡慕孙方所描绘的工作状态，但我不知道他所描绘的是不是真的以及是否真的有公司按照这种方式开展工作。

直到我来到了有知有行。

在有知有行，我们相信可以为用户提供独特的价值，所以不会整天瞄着别人在做什么，而是通过一步步的探索、假设、验证，找到用户的真问题，然后再努力把它们解决好。在这个过程中，我们当然需要快速地试错和迭代产品，但绝不会匆忙上线很多莫名其妙的功能。这让我们能把精力放在对我们而言最重要的事情上，而不是通过 996 去追赶竞争对手。

这一套一开始我就相信吗？我当然是充满怀疑的。但日复一日，看到身边所有的同事自然而然地站在用户一边思考问题，每一个功能、每一个版本迭代都站在用户具体的使用体验上考虑，重视和珍视每一条用户反馈，我才意识到，原来我真的来到了一家，像孙方演讲中描绘一般的公司。

当然，就像没有必要为了 996 而 996 一样，「按时下班」本身也不应该作为工作的根本目标。它作为 996 的对立面，似乎非常政治正确，但是，健康的工作状态，我想其实应该是「保持弹性」的。

有时，产品经理的需求遭受了一些挑战，需要多花一些时间思考和完善；有时，设计师为了追求完美的交互和视觉效果，在设计阶段多花了一点时间；有时需求发生了比较大的变更.....这些情况下如果还想要保持版本发布时间不变，那么压力就来到了程序员这边，这时我们就会加班赶赶进度，尽量保证版本能按时发布。身处这个阶段的我们，就算人已经不在公司，但晚上还是会在家里默默写代码。

在刚从事程序员这份工作时，我对上面这些情况颇有微词，觉得这对程序员也太不友善了，就像处在接力赛的最后一棒，总是扛起追赶进度的大旗。但工作时间久了我又慢慢理解了这种情况。在产品设计阶段，产品经理和设计师通常会尝试不同的方案最后确定最合适的一个，他们其实也经常需要加班赶进度；他们在体验到我们真正做出来的软件后，可能会发现在设计稿上看不到的问题或者产生新的灵感，需要在软件发布前做一些调整；我们自己也可能因为一些超出预期的技术难题导致进度受阻......虽然我们都想打造完善的功能，也都希望用户能早点使用上它们，但我们又都是人，不是精密运转的机器，我们所处的外部环境也可能随时发生变化，所以发生意外其实是很正常的，重要的是如何应对它。

及时沟通，确保大家能及时跟进每一个变化，在讨论和决策的过程中不要掉队；问题发生了，不要埋怨、扯皮，互相理解，推进接下来的工作，因为我们的目标始终是一致的，那就是解决好用户的问题、打造用户喜爱的产品。

本文章所载内容仅供参考，不构成投资建议。市场有风险，投资需谨慎，投资者应保持独立思考。详见《文章免责声明》。如转载使用，请参考《文章转载规范》。