一个技术人的知行笔记
这个系列写到这里，该聊点未来的事情了。
前三篇文章分别是：FreeInk 的全栈解析、硬件路线与软件路线的对比、各个项目的技术栈全景。这一篇我不打算再拉清单了——我想聊聊我看到的几个信号，以及它们可能会怎么改变我们读书这件事。
先说一个暴论：今天的电子书阅读器，在上手体验上，还没有超越十年前初代 Kindle Paperwhite 的水平。 无论是开源还是商业，市面上的阅读器本质上还是在做同一件事——把电子墨水屏换成分辨率更高的、加了前光、调了刷新率——但你在阅读器上能做的事情，和 2012 年没有本质区别。
翻页。标注。查词典。调字体。
就这些。
但这几年出现了一些有意思的信号，让我觉得这个局面可能快要被打破了。
你有没有遇到过这种情况：一个项目干到一半，两个同事开始互相推诿——“这事不该我干”“我以为你负责呢”，最后锅甩到你这儿，你还得去擦屁股。或者更糟：所有人都觉得“这事有人管吧”，结果没人动，deadline到了才发现根本没开始。
这种混乱的根源只有一个：分工不明确。
你以为你说了，以为大家理解了，以为会议纪要写清楚了。但“以为”是职场最大的坑。人只相信自己看到的、写下来的、签字确认的东西。
这时候，RACI矩阵就是你的救命稻草。但别急着去百度它的定义，我知道你看过那张四个字母的表格无数次了。今天咱们聊的不是课本，而是真实战场上怎么用它杀敌。
先破个认知：RACI矩阵最大的价值，不是帮你“安排工作”，而是帮你避免事后扯皮。
四个字母，老生常谈：
但绝大多数人用RACI翻车，是因为犯了三个致命错误：
❌ 错误1：一个任务写N个R
比如“需求确认”写了5个Responsible，结果就是5个人都觉得“我不干别人也会干”。每个任务只能有1个R和1个A，其他全是C和I。这是铁律。
❌ 错误2：A和R是同一个人
常见于项目经理自己干活又自己拍板。这意味着没人给你兜底，你也得不到横向制约。A最好是比你高半级或者跨部门的负责人，这样出了问题有人真能扛。
❌ 错误3：只画矩阵，不签字确认
你Excel画得再漂亮，不跟所有人过一遍、不签字，就是废纸。RACI必须变成“契约”，不是“参考文档”。
“我推不动其他部门的人。”
这句话，是我在项目复盘会上听到的最高频的抱怨。你明明有项目章程，有高层授权，甚至KPI都挂在了墙上，可一开会，研发说需求不清晰，市场说优先级要调整，运营说时间太赶——所有人都坐在一张桌上，但每个人都觉得自己在“帮你的忙”。
跨职能协作的真相是：权力不统一，责任又交叉。
你在项目管理岗上待得越久，就越会发现，90%的项目延期不是因为技术难，而是因为“人”没对齐。今天我们就拆一下，跨职能协作的障碍到底卡在哪，以及怎么真的把它拆开。
先别急着怪别人不配合。我们来看三个藏在表面下的核心原因：
① 目标不对齐，各玩各的算盘
每个职能部门的KPI是独立的。市场部看线索量，技术部看上线时间，财务部看预算执行率。你的项目目标在他们眼里，只是“额外的工作量”。
② 没有共同的“痛点”
如果这个项目黄了，对研发主管的季度奖金有影响吗？如果没影响，他凭什么加班帮你赶工期？
③ 沟通陷入了“汇报模式”
你把周报写得再详细，也不如一次15分钟的电话。跨职能协作最怕“通过邮件打仗”，你以为说清楚了，人家压根没看。
你有没有遇到过这种情况？
早上9点开站会，有人摄像头黑着、麦静音，说了句“昨天做完了，今天继续”，然后就消失了。你打开Jira一看，他的任务状态三天没变过。你私信问他进度，半小时后回了个“在等后端接口”。你再追问“接口什么时候好”，又没动静了。
项目经理老张跟我说：“以前坐在一起，走过去问一句就行。现在呢？每个进度都要追，每次沟通都要发消息、等回复，一天下来光催人就把我搞废了。团队绩效反而比坐班时还差。”
这不是个例。疫情后很多公司“强制回办公室”，不是因为老板保守，而是因为虚拟团队的管理难度，被严重低估了。
今天这一问，我们直击痛点：远程协作的挑战到底在哪，以及项目经理该怎么破局。
你有没有接过这样的项目：老板笑眯眯地把一沓资料推到你面前，说“这个项目你能力强，交给你我放心”。你热血沸腾，拍胸脯接下，结果两周后才发现——需求是老板拍脑袋定的，资源只配了半个人，客户那边已经换了三波对接人。你像掉进沼泽，越挣扎陷得越深。
为什么踩坑的总是你？ 因为你把“接手”当成了“接受”，而不是“审查”。
在我十年的项目管理生涯里，见过太多项目经理因接手了一个“垃圾项目”而毁了自己的口碑。但真正的高手，在点头之前，一定会问自己三个直击灵魂的问题。这三个问题，不是问老板、不是问客户——是问你自己。
你有没有遇到过这种场景：你熬夜做完了项目，数据漂亮，功劳却没人认？或者你推动的流程优化明明省了50万，老板听完只轻飘飘说了句“辛苦了”？
别急着怪老板不懂。真相很可能是——你做的东西，跟公司眼下要解决的问题，根本不在一张地图上。
这是很多项目经理最大的盲区：我们太擅长“把事做对”，却很少想“做对的事”。而“做对的事”的核心，就是价值对齐：你的项目到底在帮公司解决什么具体问题？这个问题的答案，才是你真正的KPI。
前两篇文章聊了 FreeInk 的全栈设计和开源阅读器的硬件/软件路线之争。今天换个角度，从技术栈切入，看看这些项目的开发者们分别选择了什么工具来造轮子。
作为一个写了十几年代码的人，我有个习惯：看到一个开源项目，第一反应不是「这玩意儿能干啥」，而是「它怎么写的」。技术栈的选择往往暴露了一个项目的核心哲学——你选什么语言、什么框架、什么构建工具，背后都藏着你在乎什么、不在乎什么。
这篇就带你在开源阅读器的技术栈里走一圈。