产品指出:选人不是一次动作,要**从主管的运营意图出发**拆开讲 —— 而且叙述该
「先列出要回答的问题,再说谁答、凭什么答」,这才是产品思维。按这个重写 §1。
**召回策略(在选人之前的一环)= 一批召回要回答的四个问题**
1 做哪一类还没启动的治疗 → 主管答,凭这季度的经营重点
2 找多久没来的人 → 主管答,凭经验
3 要不要只挑高价值的 → 主管定,但**助手先摆数据**
4 团队还吃得下多少 → 主管定,但**助手先摆数据**
⇒ 1、2 是运营意图,他张口就来;**3、4 他答不了** —— 不把全景摆在面前,
「要不要只挑高价值的」根本没法回答:他不知道这批里有多少是高价值的,
也不知道切完还剩几个。所以:
**选人 = 主管初选(1、2)+ 助手精选(3、4,并顺手给出一版已经分好的方案)**
助手在这一步⛔ 不是"等下一个指令",而是先把该看的摆出来、把方案做出来。
🔴 **补上「多久没来」的真正分量**(产品点出,此前整篇都没写):
它不只是筛选条件 —— **有经验的主管能从它估出这批大概能回来多少**
(一两年没来的和三年以上的,回头率不是一个量级),而这个估算往下游一步
就是**诊所的排班**:预计回来多少人、多少要做种植,医生和科室要不要提前留位。
⇒ 这一项必须由主管拍,⛔ 系统不代劳也不推荐。
决策树相应改成 召回策略 → 主管初选 → 助手精选 → 分人 → 确认 → 确认之后;
重跑那条环回到「主管初选」。mermaid 节点引用与 style 目标已校验无悬空。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
| Name |
Last commit
|
Last update |
|---|---|---|
| .claude | Loading commit data... | |
| .design-sync | Loading commit data... | |
| apps | Loading commit data... | |
| clickhouse/config.d | Loading commit data... | |
| deploy | Loading commit data... | |
| docs | Loading commit data... | |
| packages | Loading commit data... | |
| scripts | Loading commit data... | |
| .gitignore | Loading commit data... | |
| .gitlab-ci.yml | Loading commit data... | |
| .npmrc | Loading commit data... | |
| .prettierrc | Loading commit data... | |
| README.md | Loading commit data... | |
| docker-compose.expose.yml | Loading commit data... | |
| docker-compose.managed.yml | Loading commit data... | |
| docker-compose.prod.yml | Loading commit data... | |
| docker-compose.yml | Loading commit data... | |
| eslint.config.mjs | Loading commit data... | |
| liu.cjs | Loading commit data... | |
| package.json | Loading commit data... | |
| pnpm-lock.yaml | Loading commit data... | |
| pnpm-workspace.yaml | Loading commit data... | |
| tsconfig.base.json | Loading commit data... | |
| turbo.json | Loading commit data... |