Becomin' Charles

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

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

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

互联网，短视频，以及本身身处的管理岗位的工作模式，已经摧毁了我的耐心，注意力。大概就是，比如看一本小说，不能沉下心来去认真看，总是会分心，然后就中断了阅读，两个礼拜没有读完 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 作为公司级的知识库，于是，要求也为我们公司部署一个。尝试在公司使用和推广。

此前，我写过一篇文章，抱怨 Flutter 的 WillPopScope 的一些问题《Flutter 在 iOS 下 WillPopScope 导致右滑返回（Swipe Back）失效》，当时，我就提出过，在 iOS 上，Swipe Back 这个手势，要播放个动画的，这个交互动作的观感是，像翻书一样的，好像翻起了一页纸，你会看到纸下面是什么内容的。而 Android 系统，完全不是这个交互动画效果，是直接返回的。而 WillPopScope 就是拦截在 Android 上的返回动作，所以出现了一个问题，就是如果你用 WillPopScope，你发现，在 iOS 上牺牲了 Swipe Back 的交互手势。

最近，公司开始大幅扩张，各个团队都在招人，而且都是招那种比较高级的人才。我也不例外。

说实在的，在 2024 年 8 月这个时节，市场上被释放出来没有找到归宿的研发工程师还是很多的，既然有这么的候选人，就不免贪心，想找到一些真正好的候选人。这反倒成了我的困境，因为这样就势必招人的速度非常慢。

而另一个困境是，我所研发的系统，专业性非常强，虽然说，通用的研发技能，可以胜任我部门的工作，但是如果游刃有余地完成工作，那是不可能的，必须把领域知识给补起来，才可能。这就造成了，虽然我的人入职了，也不能快速形成强大的战斗力，还需要很长的时间去适应和积累。

于是，我想到了另一条路。