这个季度，一些产品经理已经进入生产代码开发：从需求到实现，再到测试上线，大家开始直接参与。以前遇到问题，通常先写需求、找研发、等排期；现在至少一部分事情可以自己往前推进。能打开仓库、查日志、看懂数据流转，和只看页面完全不同。

以下内容，来自团队季度复盘会议摘要：

今天复盘，我想多花一点时间，聊聊大家这个季度写代码的事。

这个Q，我们的一些产品经理已经进入生产代码开发了。从需求到实现，再到测试和上线，大家开始直接参与。这件事我会继续鼓励，因为它给了我们更多实践机会，也让很多过去只能讨论的问题，终于可以动手验证。

以前，我们遇到问题，通常先写需求、找研发、等排期，再跟进验收。资源充足的时候，这样分工没有问题。但一旦资源紧张，很多事情就停在那里。我们知道用户着急，也知道应该改，却只能不断问进度。

现在，至少一部分事情，我们可以自己往前推进了。

能打开仓库，能查日志，能看懂数据怎么流转，和只看页面，感受是不一样的。以前觉得很复杂的问题，可能只是某个环节没有对齐；以前觉得很简单的修改，进去才发现牵涉好几个地方。

所以，我鼓励大家写代码，也希望大家借这个机会，把产品理解得更完整。

这个过程中，协作方式也在变。我们开始往GitHub式的协同靠近：大家进入同一个仓库，通过分支、提交和PR，也就是合并请求，共同讨论一项修改。

过去，我们各自维护PRD和代码，中间靠会议、消息和口头解释连接。信息来回传，容易漏，也容易出现“我以为你知道”。

围绕具体改动协作之后，很多讨论可以直接展开：为什么这样做，改了哪里，影响哪些场景，还有哪些问题没有处理。产品和研发都能看到，后面接手的人也能看到。

我觉得这是很好的一面。我们不用反复从头解释，判断也更容易被检查。一个需求考虑得够不够完整，在实现和评审的时候就会暴露出来。

但大家也要看到，这种方式对人的要求更高了。

以前，方案讲完了，可以等下一环节的反馈。现在，你提交的东西，别人要能看懂、能审查，还要能接着做。你不能丢过去一大段代码，只说“AI写的，我这里能运行”。

这次解决了什么，哪些地方会受影响，验证了哪些情况，没验证的是什么，都要交代清楚。提交尽量小一点，问题说具体一点，别人才能有效地给你反馈。

多人同时修改时，也不能各写各的。接口变了要同步，评审意见要回应，遇到冲突要主动找人讨论。仓库把记录留下来了，沟通还是要靠我们自己完成。

这个季度，我也反复提醒大家，测试要留出时间。

写出来之后，还有异常情况、权限、历史数据和不同端的体验要检查。AI帮我们加快了开发，后面的验证也得跟上。不能把时间全部用在写功能上，最后才发现来不及测试。

对我来说，也有要补的功课。哪些需求适合大家自己做，哪些需要研发一起参与，评审由谁负责，都应该更清楚。鼓励大家动手，也要给大家提供能协作、能求助的条件。

还有一个问题，今天我想提醒我们所有人，包括我自己。

写代码很容易让人忙得踏实。功能做出来了，问题修好了，当天就能看到结果。用户为什么没用起来，这个方向值不值得继续，却没有这么快的答案。

我们已经看到这种倾向了：功能不断增加，发布不断推进，真正该想的产品问题，反而往后放。

所以，能写之后，时间怎么分配更重要了。用户的一天是怎么过的，我们替他省了什么，他为什么愿意换一种工作方式，这些问题仍然要花时间去聊、去观察。

我也希望大家多看看自己的日常工作。哪些问题每天都在重复分类，哪些信息总要由我们转述？如果能把规则和上下文整理好，让团队直接处理，就应该把这个机制建起来。我们可以从那些重复劳动里退出，去做更需要判断的事情。

下次复盘，我希望我们多讲讲：一个问题从发现到验证用了多久，协作有没有更顺畅，上线之后用户有没有真正用起来。