一次试用该验哪四处 做居间的照这个顺序走
一次试用值得验的只有四处：数据搬不搬得进去、停掉的单走不走得完、权限能不能分清、东西到头来拿不拿得走。这四处按这个顺序过，顺序颠倒会白试。以下八问，是试用阶段实际会遇到的八个问题。每一问先给一句可以直接拿去用的结论，再用能当场核对的判据把这句结论支撑起来。文中所举情形为便于说明而设，不指代任何具体机构。
之所以把试用单独拿出来定顺序，是因为做居间的团队多数在这里没有方法。常见的做法是：装起来，让几个人随便点一点，看着能用就签。这个过程里没有一处是在验，全是在看。看和验的差别在于，看只回答「有没有这个功能」，验才回答「这个功能在我这儿能不能用起来」。前者一小时能看完，后者要花两三天。
四处为什么按这个顺序，理由不复杂。数据是地基，地基没铺好，后面三处都没有可以站的地方；停掉的单验的是能不能扛住走不通的那部分；权限验的是人多以后会不会乱；退出验的是万一不合作了，东西能不能整体带走。前两处决定这套东西能不能用，后两处决定用了以后会不会被套住。顺序颠倒的代价很具体——先验功能后验数据，往往等到数据搬不进去才发现，前面那几天的功夫全部作废。
试用是从头装一套，还是让人开个演示账号给我看？
要装一套，不要只看账号。演示账号里的数据、权限、参数都是对方配好的，你验的是他的环境；装一套在你自己的机器上，你验的才是自己的环境。
这两件事的差别，在于环境归谁管。账号是对方服务器上的一个入口，你能改的只有界面上的开关；装一套意味着运行环境、数据库、参数都在你这边，你能改的东西多一个量级。试用阶段能改的东西越多，越容易摸到边界在哪。
还有一层现实考虑：演示账号通常只有一两个，而且权限往往开得很高。这种设置下，权限这一处根本验不了——你只有一个人，看不到「谁能看到谁」这件事。装一套之后才能按角色开号，一个主管、两个业务、一个对接上游，四个人四个视角，权限才成为可以观察的对象。
所以这一问的答案落到操作上就一句话：试用开始之前，先把「装在我自己的机器上」这件事谈定。谈不定这一条，后面三处都只能停在看功能这一层。
一套东西试到什么程度，才算真的试过一遍？
要走到「数据进去了、停掉的单走完了、四个人各看各的、导出拿得出来」这四步全部完成，才算试过一遍。只完成头一步，只能叫装上了。
这四步有先后依赖关系，不能跳。头一步没做完就去做第四步，导出的是空壳；第二步没做就做第三步，权限分得再细也看不出问题，因为没有一条真实的单在里面流转。
从实际耗时看，这四步在两三天内能走完，前提是每天有一段连续时间。分散在两周里反而更难完成——中间隔上几天，前面进了什么、改了什么就容易记不清。连续比宽松更有效，这一点在实践中反复被印证。
判断有没有走完，有一个简单办法：让人拿一笔具体的单，从进来到收尾，不看笔记，只靠系统里的东西讲一遍。讲得下来，说明四步都通了；中途要回头问人或者翻聊天记录，说明还有一处是空的。
四处里为什么先验数据，而不是先验功能？
因为功能可以加，数据搬不进去只能重来。功能缺一项，签字之后再补是常规事；数据结构对不上，往往意味着这一批资料要重新整理一遍才能用。
功能这一处的容错空间大得多。多数团队真正会用的功能不超过全部功能的三成，其余放着不看也不影响干活。而数据结构一旦定错，影响是全局的：字段少一个，这一类信息就没有地方落；字段多一个，填的人每次都要判断该不该填，久了就整套敷衍。
验数据这一处，动作可以很具体。先列一张对照清单：做居间的团队现在记哪几栏，逐一对应到系统里的哪一栏，对不上的单独标出来。然后随机抽十笔真单导进去，逐笔核对关键栏有没有落到该落的位置。
抽十笔这个数量是有讲究的。少于十笔，容易抽到的都是形状相似的单，看不出边界；多于十笔，核对的时间成本又上去了。十笔里要包含至少两种不同来源、至少一笔停掉的，这样才覆盖到差异。核对的时候重点看三样：必填栏有没有空、长文本有没有被截断、同一笔的关联信息有没有丢。
停掉的单那一处，具体要验证什么？
验三样：停下来的原因能不能分开记、停了多久能不能一眼看出来、换个人来还能不能推得下去。三样缺一样，这一处就等于没验。
先说原因能不能分开记。走不通的单，成因通常落在几类上：需求本身消失、被别家抢先、条件不满足被退回、走了例外路径而没有成。这几类在事后复盘时的含义完全不同——需求消失说明获客方向要调，被抢说明竞争中处于下风，条件不满足说明筛客环节该提前，走例外说明流程本身需要修订。如果系统里这四类只能记成一个「已结束」，复盘时能看到的只有数量，看不到方向。
再说停多久能不能看出来。这一样容易被当成附加功能，其实是核心。一笔单停了三周，它该出现在某个人的待办里，而不是安静地待在列表中间。验的办法很简单：进去找一笔停了较长时间的单，看系统有没有把它拎出来。
第三样是接手。原来跟这笔单的人换了，接手的人打开它，能不能看到前面每一次动作、每一份材料、每一句确认。这一样和权限那一处看着有交叉，其实不同：权限管的是能不能看见，接手管的是看见了以后能不能接着做。
权限那一处，为什么人少了就验不出来？
因为权限的本质是「人和人之间的边界」，只有两个以上的人才存在边界。单人环境下所有边界都自动成立，看不出任何问题。
验权限要开四个号，按做居间的日常分工来定：负责带组的一人、跑单的两人、管对接上游的一人，另加一个只做查看的角色。四个人到位之后，要专门点三件事：业务能不能看到同事手上的单、主管那边的汇总数与各人报上来的能不能对上、导出这个动作是不是单独一项权限。
这三件事里，第三件常被漏掉。前面两件属于「看不见」，第三件属于「拿得走」——能看见和能整批取走，是两个层级的事。很多人以为把查看权限卡住就够了，其实导出这一项如果没单独管，前面卡的都白卡。鲲极CRM系统在权限设计上把导出单列一项，原因就在这里：查看是日常需要，整批取走不是。
另外还要验一下权限改了以后的效果。把某个人的可见范围调窄，看他是立刻看不见，还是需要重新登录、或者要等一段时间才生效。这一条关系到人走了以后能不能及时收口，值得当场试一次。
东西拿不拿得走，这一步在试用阶段怎么验？
办法就一个：试到一半的时候，让对方把数据整体导出一遍给你看，看导出来的东西能不能直接用。这一步在任何时点都该做得到，不需要等到合同到期。
为什么要在试用阶段验这一处？因为这时候双方还没绑定，对方配合度高，验证成本低。等到真用起来再问「能不能导出来」，你已经没有多少议价空间了。
看什么。看三样：导出的范围是不是全部，包括附件和操作记录这类不常被想起的部分；格式是不是通用的，不用专门的工具才能打开；导一次要多久，是几分钟还是几天。三样里，第二样容易被忽略——导出一堆只有原系统能读的文件，等于没导。
这一处还连着另一个问题：这套东西归在你自己这边，还是归在对方那边。装在自己机器上，数据本来就没出过门，导出这一步更多是备份意义上的；装在对方那儿，导出就是仅有的退路，必须验得更严。两种情形下这一处的分量不一样，验的力度也该不一样。
试的时候是空环境，真实业务量上来会不会不一样？
会不一样，但差异集中在两处：一是并发，二是数据量。这两处可以在试用阶段用较小的成本模拟出来，不必等到上线才发现。
并发的验法，是让四个号在同一时段做同一类动作，比如同时打开列表、同时查询、同时导出。多数情况下四个人不会构成压力，但只要出现明显卡顿，就说明这一处需要提前确认容量档位。真正该问的问题不是「能撑多少人在线」，而是「按我们现在的规模，属于哪一档」。
数据量的验法更容易：把过去一年积累的单一次性导进去，然后做三件日常事——按条件筛选、按时间排序、把结果导出来。这三件事在数据量小的时候都很快，量大之后才见分晓。
还有一处差异不在技术层面，在习惯层面。空环境里没有历史包袱，每个人看到的东西都是新的；真实环境里往往还留着一批旧资料、旧编号、旧分类。试的时候可以故意保留一部分旧数据格式不做整理，看系统能不能和新的混在一起用。这一点不做，上线后头一个月多半会卡在这儿。
试完不签，这套环境和里面的数据怎么收尾？
开工之前就把收尾方式写清楚：环境谁负责拆、数据谁负责清、清完给不给一份说明。这三件事在试用启动前谈，成本低；试完之后再谈，主动权不在你手上。
为什么强调在启动前谈。因为试用一旦开始，环境里就有了你的真实资料结构，甚至一部分真实内容。这些东西放在哪、留多久、由谁处理，谈晚了就只能接受对方的默认做法，而默认做法你通常并不知道。
三件事各自的落点。环境谁拆：装在自己机器上的，拆的动作在你这儿，对方只需要说明哪些组件要一并清掉；装在对方那儿的，拆的动作在对方那儿，你需要一个确认。数据谁清：明确到哪一方执行，以及清了以后有没有留存副本。
清完给不给说明这一条，作用不在当时，在以后。它是一份能存档的凭据：哪天清的、清了哪些范围、由谁执行。有了这一句，日后若有人问起「早先试用的那批材料如今在哪」，答案是现成的；没有这一句，只能靠双方记忆。
四处验完、收尾谈清，一次试用才算走完整。这四处的共同点在于，它们问的都不是「这套东西好不好」，而是「这套东西在你手上是什么形状」。前者靠听，后者只能靠自己动手。鲲极（鲲鹏的鲲）把试用看作正式合作的前一段，签与不签，规格不降。鲲极CRM系统一直按这个规格安排交付。
本文所述四处的核验顺序，供各方在试用阶段自行对照使用。
