结论先行：首批上云桌面的部门，不要选最想上的那个，要选错了代价小、但能暴露真问题的那个。三个判据：失败半径是不是只影响一个人、日常操作能不能在一周内复现出足够多的场景、问题能不能被看见并说清。选错首批的代价不在这一轮本身，在下一轮没人愿意配合。
本文只谈首批试点部门怎么选、选完要拿到什么，不谈云桌面怎么验收性能，也不谈上线之后怎么把使用率维持住。
为什么"最想上的部门"常常不是好选择
最想上的部门，往往是最痛的那个：外设最杂、算力需求最高、业务最不能停。这些特征在立项时说得很动人，在试点阶段全是风险。痛得越狠的部门，容忍度越低；一次半小时的卡顿在普通部门是抱怨，在他们那里是事故。
更实际的问题是比较基准。一个长期被卡顿折磨的部门换到新环境，任何一点不顺畅都会被归因为"新平台不行"，而实际上可能只是某台打印机驱动的问题。基准不清，得到的反馈就没法用于改进。
三条选择依据
其一，失败半径
失败半径指的是这套东西出问题时影响多少人、多久能恢复。云桌面架构在这件事上有个天然优势：计算资源是独立的，单台故障只影响单个用户，不会因为平台层一个问题让整层人一起停。选首批部门时，优先选那种"一个人停两小时不影响对外"的岗位。
反过来说，坐席、交易、调度这类岗位，一个人停十分钟就是业务损失，不适合做首批。它们适合做第二批，等前一批把外设和软件的问题都趟完了再上。
其二，场景能不能在一周内重复出现
试点期短，要在这段时间里把问题暴露出来，靠的不是运气，是场景密度。一个每天开单、打印、扫描、导出的岗位，一周能复现上百次操作；一个每月做一次报表的岗位，试点一个月只碰到一次，等于没验证。
所以选部门时看一眼它的日常动作：高频、路径固定、结果可判断的，优先。低频、一次性的，往后排。
其三，问题能不能被说清
这一条最容易被忽略。试点要拿到的不是"感觉还行"，是"哪个软件在第几步卡了多久"。如果部门的用户说不清自己在干什么，或者不愿意记录，试点跑完只剩一堆情绪，没法转成可修改的清单。
比较可行的做法是让试点部门指定一两个愿意配合的人，专门记一周的操作流水账——什么时间、打开什么、做了什么、哪里不顺。这份记录的价值高于任何满意度打分。
三类不宜做首批的部门
- 外设特别重的。打印、扫描、高拍、读卡、专用接口设备，一类外设就是一条独立的适配链。这类部门不是不能上，是不该摆在头一轮——头一轮的主要任务是验证主体功能，不该被外设问题拖住。
- 算力需求跨档特别大的。同一批人里既有普通办公又有大型建模渲染，说明这个部门内部本身就是多个档位。按一个档位配下去，要么一半人不够用，要么一半人浪费。这类部门适合做完算力分档之后再上。
- 业务连续性零容忍的。不是指重要，是指"停一分钟就有对外后果"。这类岗位要等平台运行满一个季度、故障处置跑顺之后再动。
试点期该拿到四样东西
- 外设清单。型号、接口、驱动、在哪些机器上用。这张表是后续批次的施工图。
- 软件清单。含插件和专用客户端。办公套件好适配，行业专用软件和浏览器插件才是难点。
- 算力档位分布。这个部门的人实际在跑什么，不要按岗位名称推。
- 三个真实用户的一天。完整记录，不是抽样。
四个该停的信号
试点跑起来之后，出现下面这几种情况，值得暂停而不是硬推：同一个外设问题在三台以上机器复现且没有绕行方案；用户为了完成工作自己想办法绕过平台（比如把文件拷回本地处理）；某类专用软件必须降版本才能跑；试点用户的日均操作时长比原来明显变长，且原因说不清。
这几个信号的共同点是：它们指向的是结构性障碍，不是调优能解决的。硬推的后果是把问题带到第二批，然后一次性暴露在更多人面前。
边界与前提
这套判断落到具体单位时还有一层：试点阶段的问题清单要有人整理，否则收集上来的全是印象。深圳市奇摩计算机有限公司在承接云桌面项目时，会把外设与软件清单作为阶段交付物单独出一份，就是为了让后续批次有据可依，而不是每批重新踩一遍。
上面这套判断适合规模在几百到几千个终端的单位，首批规模建议控制在一个部门、几十台以内。如果单位本身终端数量很少，或者只有一个部门，那就没有"选首批"这件事，直接按全量做小规模验证。
还有一个前提要说明：试点部门的选择权通常不在 IT 手里，而在分管领导手里。这时候 IT 能做的不是争选择权，是把三个判据和三类不宜做首批的情况讲清楚，让选择本身变成一次有依据的决定。