Becomin' Charles

我在使用 Mac 的命令行管理自己的服务器的时候，我一直使用一个 goto 的命令，这个命令会列出所有的服务器列表，里面包含用户名，IP 地址，以及备注，我只要再键入一个序号，就可以自动发起对服务器的连接。这个脚本是我自己写的，是一个 Python 的命令行脚本。今年，这个脚本不能运行了，后来我打开 Cursor 寻求解决方法，AI 建议我将这个命令打包封装。

最近阅读完了《子弹笔记术》这本书，我觉得比起《麦肯锡笔记术》这种商业环境中使用的解决问题的笔记法，以及《康奈尔笔记法》这是学校里使用的提升学习效率的笔记法，子弹笔记术，本质上是帮助我们管理生活的，万用笔记法。

最近，感觉很苦恼，好久没有沉浸式工作过了。

哈佛幸福课里说，什么叫幸福呢？就是尽可能长时间在心流状态下工作，在心流状态下工作的时间越长，或者比例越高，人的整体幸福感就越高。

我觉得我已经很久没有在心流的状态下工作过了。

互联网，短视频，以及本身身处的管理岗位的工作模式，已经摧毁了我的耐心，注意力。大概就是，比如看一本小说，不能沉下心来去认真看，总是会分心，然后就中断了阅读，两个礼拜没有读完 100 页。如果沉下心来读书，就会觉得焦虑。

不能看内容比较深的电影，如果情节跌宕，感人肺腑，就没法沉下心来看，下意识就想关掉。但是那种爆米花，或者垃圾电影，没什么深刻的戏剧冲突的，浮躁的东西，反倒可以看完。

听小说也是，只想听那种垃圾快餐文，升级，打怪，装逼，如果有情节，有深度，感人的东西，无法看进去。

做事情就更明显了，如果沉下心来写代码，完成一个小功能，无法投入进去。更多做策略性，规划性的东西，就是很容易被批评的那种，画大饼，指点江山的工作。如果脚踏实地去写，一个个功能去完成，一行行代码去堆砌，就无法胜任。

我感觉这是一种病，不知道怎么了，可能需要去看看了。我总是在焦虑、急躁，进而痛苦，憎恨自己。然后是担忧、害怕，无法找到自己的价值和意义。

最近，真的很焦虑。

大语言模型的火爆，已经渐渐形成了一个洪流，显然不像是 AlphaGo 出现的时候那样，短暂出圈一下，就渐渐远离了日常生活。那个时候，还停留在特定应用的层面，没有形成什么足以撼动底层生活的杀手级应用。

最近，读了《麦肯锡笔记术》。介绍了麦肯锡管理顾问的一种工作方法：笔记术，他们是如何通过笔记进行思考，从而解决问题的。

前言

最近，公司因为国际化发展的需求，要从 TAPD 切换到 Jira。新平台的功能和 TAPD 不一样，团队不能直接把 TAPD 的经验照搬过去，所以得重新制定协作流程和标准。为了更好地制定这些新流程，我们得先回顾一下过去，看看我们为啥用 TAPD，又是怎么用它的。

TAPD 是啥

TAPD 是腾讯敏捷产品研发系统的英文缩写。网上关于它的介绍很多，我就不多说了。简单来说，TAPD 最初是为了敏捷项目管理协作而建的平台，后来还整合了 DevOps、CI/CD 等功能。不过，不管怎么变，它的核心还是敏捷项目管理。

我们为啥用 TAPD

公司从 2015 年创业开始就用 TAPD 了。当时研发团队有 10 人左右，CTO 和技术负责人都是从腾讯出来的，对 TAPD 很熟悉，而且当时它完全免费，我们就用上了。随着团队扩大，一直有相当比例的研发团队在用 TAPD。

创始人背景和免费是用 TAPD 的外因，那内因呢？为啥公司非得用项目管理工具呢？公司的研发工作到底是咋组织的，又是怎么借助 TAPD 的功能开展的呢？其实没表面上那么明显。

我们知道，时间、预算、范围是项目管理的三个关键要素。项目研发的主要目标就是在合理的时间和预算范围内，尽可能多地满足需求。项目经理得带领团队克服困难，达成项目成功。但我们公司不一样，研发活动一直是模糊的项目化运作。为啥说模糊呢？因为不是每项研发活动都有明确的项目，没有明确的立项和截止日期。这些条件都是公司当时的环境和人力资源隐性约束的，项目需求也有很大弹性。因为我们用的是敏捷研发流程，一般完成一个需求的最小闭包就能发布，然后马上开始下一个功能需求。从项目管理角度看，这延长了项目研发时间，但需求范围随时变化，整个研发活动就像一个永不结束、没有边界的项目研发过程。

这种松散的项目管理机制，也决定了项目经理的作用有限，没啥协调和权衡的工作可做，这大概是中小型团队的共性。公司有经营目标，研发只要大体符合这个方向就能持续开展。

我们怎么用 TAPD

那团队为啥还要坚持用项目管理工具呢？真正依赖它的地方又在哪呢？

在我看来，团队本质上是把 TAPD 当成协作的基本工具。

产品经理

产品经理在平台上记录和管理需求。每个项目都有需求池，产品经理可以把成熟或不成熟的想法都记下来，然后把规划好、确认的需求分派给开发。需求就成了任务，能进行状态流转。

研发

研发主要通过需求单记录工作。打开平台，看到自己名下的需求单，就知道当天要干啥了。完成需求描述的功能点，就是每天的工作。

质量管理

质量同事通过跟踪需求内容和状态，了解研发进度。他们还能利用研发时间编写用例。平台上专门有工具记录用例、制定测试计划。除了需求，质量同事用得最多的单据是缺陷单，能关联到需求。

除了这些基本功能，还有迭代功能，用于组织相对封闭的研发工作，但我们用得很少。现在基本单个或几个需求就能直接上线，借助平台提交提测邮件、发送测试报告和上线通知就行。

从某种角度看，质量管理团队是 TAPD 平台的重点使用用户。在项目经理缺位的情况下，质量团队保障研发成果的质量，成了最关注整个协作过程的人。产品经理也会一定程度关注需求的整体成功，部分扮演项目经理的角色。

必要的功能

从前面的分析来看，我们用 TAPD 是因为产品经理、研发、质量管理这几个角色需要通过平台进行异步协作，偶尔还会跨团队合作。更多时候，它是代替线下文档传递，提高效率。不过，各个团队有各自的风格和特点。比如我所在的团队，对需求编写和归档要求很高，因为我们做的是企业软件的持续迭代研发，涉及公司政策和规则，得时刻保障功能合规。所以，我特别注重需求的可追溯性，确保研发团队的每一步都合规。这在其他团队可能不是必须的。

没用到的功能

前面提到的迭代功能，我们没用。在客户端软件开发中，这个功能比较常见。我们也不需要基线管理等功能。TAPD 在 DevOps 和流水线方面不断加强，但我们也没用到。所有单据上都有很多时间记录功能，比如创建时间、工作量估算、工作量消耗、完成时间等，这些功能我们几乎完全没用。

结语

回顾了这些，我们对 TAPD 的使用情况有了更清晰的认识。现在要切换到 Jira，我们也能更好地分析出哪些功能是我们真正需要的，从而制定出更合适的协作流程和标准。

康奈尔笔记法，是一种记录笔记的方法，或者，你也可以认为是一种学习方法。

在康奈尔大学的官方网站，LSC（Learning Strategies Center）上，你可以学习到这个笔记记录方法。

上周，冯少说要来香港，公司给他办理的高才通计划，他来激活签证，申领身份证，顺便在香港玩玩。不过香港着实没什么好玩的，因为香港很小，很容易就转遍了，但是如果你走马观花看一圈，也不会有什么很深的印象。

我已经不知道有多少年没有写过年度总结了，这些年都是奔波且动荡的，在这种不稳定中，有一些间歇性平衡的生活，动荡是主旋律，而规律只是暂时的。

2018 年，为了追求更好的工作机会，以及去外面看看，老婆申请了北京的工作机会，成为一个北漂，到 2019 年，女儿随着她也去到北京，我一个人在上海工作，过上了两地奔波的双城生活。平均每两周去一次北京，我积累了厚厚的一沓飞机火车票。

老板了解到，我们同行的很多公司，都使用 Confluence 作为公司级的知识库，于是，要求也为我们公司部署一个。尝试在公司使用和推广。