Becomin' Charles

缘起

说到保险，你会想到什么？大多数人对保险中介的印象可能停留在两个词——骚扰和欺骗。

是的，保险中介就像信贷员、房产中介一样，常常因为推销的方式不当，给大家带来负面印象。这些职业有一个共同点：所销售的产品很有价值，需求量大，然而，很多人对产品了解不足。

我认识很多 Web 后端开发程序员，他们多多少少会写一些前端的代码，但是很少例外，大都 不擅长写 CSS 样式，我自己也不例外。

后端开发程序员为什么都不擅长写 CSS？我想，因为 CSS 不是一门编程语言，而是一门设计语言。而 Sass 的发明，使得写 CSS 变得更像一般的面向对象编程，从而大幅度缩小了后端程序员编写 CSS 的难度。

为了提升网站性能，或者为了更好的模块化开发，我们可能用 AJAX 技术，载入部分页面内容（HTML），里面也可能包含新的 JS 逻辑代码或者外部 JS 文件。

为了讨论方便，我在这里把一个普通的网页称为 “主页面” 或者 “父页面”，用以区分 AJAX 加载的部分，那部分我称为 “子页面”。

我在使用 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）上，你可以学习到这个笔记记录方法。