顾承安第二天上午。
把两份分线记录重新打开。
左边是主校区需求线。
右边是新校区技术线。
他没看论坛。
也没翻学生私人账号。
桌上只有项目组正常留存的东西：
本人提交的贡献说明。
经过授权保存的面谈摘要。
阶段任务记录。
以及两边在规定节点交换的结论。
——
需求侧第一轮结果。
最初假设是：
校园机会信息不够清楚。
林辰以“苏晚晴”的身份做完访谈以后。
没有急着证明这个假设。
反而把问题拆成了几层。
入口依赖熟人。
实际时间投入不透明。
退出有心理成本。
同辈比较会放大“怕错过”和“怕选错”。
价值型推荐又存在明显分歧。
最后甚至主动写：
【目前不建议直接做活动推荐。】
——
技术侧更有意思。
最初只是做一张最小信息卡。
苏晚晴以“林辰”的身份跑原型时。
遇到“免费”这种非规范费用字段。
她没有为了让程序继续跑。
直接把它转成0。
也没有把空白退出规则解释成“可以随时退出”。
而是统一标：
【需确认】
【未说明】
从技术角度看。
这是输入校验。
从需求角度看。
却也是一种明确的判断：
不知道的信息。
不能被系统替用户补成确定答案。
——
顾承安把两边记录并排。
看了很久。
如果只是普通互补。
应该是一个越来越会做需求。
另一个越来越会写程序。
各自更强。
接口更清楚。
这很正常。
可眼前这两个人。
不完全是这样。
——
“苏晚晴”的需求笔记里。
开始频繁出现技术边界。
【不能确认实现成本时，标待核。】
【不把展示原型当可交付系统。】
【数据字段含义需由来源方确认。】
而“林辰”的技术记录里。
又不断冒出需求意识。
【空值不代表否。】
【异常输入不得被默认值掩盖。】
【字段不存在时，不替主办方形成承诺。】
这已经不是简单的：
你负责前端。
我负责后端。
——
工作人员进来送材料。
看见顾承安还在对两份记录。
“有问题？”
“暂时没有。”
“那你看这么久？”
顾承安把其中两句圈出来。
“你看这两个。”
工作人员看完。
“挺像。”
“对。”
“情侣合作久了互相影响？”
“可能。”
顾承安没有往私人关系上深挖。
那不属于项目审查范围。
他只在观察表里写：
【工作方法存在明显交叉。】
停一下。
又补：
【不是单向补位。】
——
工作人员问：
“什么意思？”
“如果只是互补。”
顾承安道。
“林辰技术强。”
“苏晚晴需求强。”
“合作以后。”
“应该是两个人各自在自己那边更顺。”
“但现在。”
“苏晚晴开始主动给技术判断留接口。”
“林辰开始在代码里防止系统替用户做决定。”
“像是两边的方法都进了对方那边。”
——
“那不是挺好吗？”
“可能是好事。”
顾承安说。
“也可能带来新的问题。”
“什么？”
“贡献越来越难拆。”
“还有。”
他往后翻到两份面谈摘要。
“他们对彼此的工作方式。”
“太熟。”
——
这种熟悉。
现在还完全可以解释。
高中同学。
恋爱关系。
长期互教。
公开合作。
一个教另一个表达。
一个教另一个程序。
都说得通。
顾承安没有理由怀疑别的。
可项目管理上。
熟到一定程度。
就会出现另一个风险。
两个人不用把话说完。
对方就知道下一步。
短期效率极高。
长期却可能没人知道：
到底哪些判断属于谁。
如果后来换队友。
流程还能不能复制。
——
顾承安在白板上写两个词。
【匹配】
【塑形】
匹配是：
这个人原本有A能力。
另一个人有b能力。
放在一起。
效率提高。
塑形则是：
合作以后。
A开始长出一部分b的判断方式。
b也开始长出A的做事习惯。
最后。
两个人本身都变了。
——
这不是坏事。
甚至可能比单纯互补更有价值。
可要证明。
不能靠感觉。
顾承安把两份表关掉。
新建一项任务。
【交叉答辩】
规则很简单。
每组成员。
必须解释搭档模块。
但不允许把搭档贡献说成自己的。
——
通知下午发到所有项目成员。
不是只针对林辰和苏晚晴。
有人负责数据。
就要讲明需求为什么要这个数据。
有人负责访谈。
也得理解技术为什么拒绝某个功能。
目的写得很清楚：
【验证团队成员是否真正理解接口与上下游约束。】
【理解不等于贡献归属。】
【答辩时需明确区分：本人完成、本人参与、仅理解。】
——
林辰看到最后一句。
头皮都麻了一下。
苏晚晴在视频里问：
“怎么了？”
“这个规则。”
“挺狠。”
“哪里狠？”
“懂也不行。”
“还得说清为什么懂。”
“本来就应该。”
“我知道。”
林辰把椅子往后挪。
“问题是。”
“我真懂你的技术模块。”
——
苏晚晴安静两秒。
“我也真懂你的需求模块。”
两个人隔着屏幕。
同时意识到这才是麻烦。
按现在的身体和公开分工。
主校区的“苏晚晴”。
实际里面是林辰。
让他解释“林辰”的技术模块。
他不是一般意义上的了解。
那些程序方法本来就是他的强项。
另一边。
新校区的“林辰”。
让她解释“苏晚晴”的需求逻辑。
她同样不只是听过。
很多选择权、访谈、信息边界的思路。
本来就是她长期坚持的。
——
如果答得太浅。
不真实。
如果答得太深。
又会让贡献边界更奇怪。
“所以不能演不会。”
苏晚晴说。
“嗯。”
“也不能说是自己做的。”
“嗯。”
“那就照事实。”
“能解释设计原因。”
林辰接道。
“但实现是谁做的。”
“明确说谁。”
“访谈也是。”
“我能讲结论怎么来的。”
苏晚晴道。
“但不能说那些主校区访谈是我做的。”
——
两个人把现有共享材料重新过一遍。
不是交换未授权原始记录。
需求侧只给技术侧已经允许共享的去标识化结论。
技术侧只给需求侧接口说明、异常处理原则和当前原型状态。
各自原始访谈。
个人工作笔记。
不因为要答辩就全部打开。
——
林辰先问：
“技术模块最容易问什么？”
苏晚晴道：
“费用字段。”
“空值。”
“异常输入。”
“你都知道。”
“我知道实现思路。”
“但具体哪一行不是我写的。”
“那就这么说。”
——
苏晚晴问：
“需求模块呢？”
“为什么删推荐指数。”
“为什么不把‘有人怕选错’总结成所有人都需要推荐。”
“为什么不把退出心理压力直接做成功能。”
苏晚晴点头。
这些她也懂。
但她只看过阶段结论。
没有看完整原始访谈。
所以如果问：
哪个受访者说了哪句话。
她就应该答：
不知道。
那属于需求线记录。
——
两个人准备到最后。
反而比以前更轻松一点。
因为真正需要守的。
不是：
装成彼此。
而是：
知道多少。
就说多少。
做过什么。
就认什么。
——
第二天上午。
创新中心通知再次更新。
【交叉答辩采用双负责人席。】
【正式过程中不得使用外部即时通讯。】
【可查看项目组已授权共享材料。】
【回答必须标明贡献归属。】
林辰看完。
关掉蓝牙耳机盒。
“行。”
“明天。”
“公开拆。”