Shopee店群管理工具怎么选：先看管理没理顺的是哪里

选型之前先列管理缺口

有一个几乎人人都会踩的开头。打开几家工具的页面，把功能一栏一栏抄下来放进同一张表，抄完发现每家的表都很长，只能在长短和价格上分高下。抄下来的过程通常很顺利，因为功能栏本来就是为了被抄而写的，每一栏都写得清楚，一行一行往下拉，半小时就能填满一整张表。

这个开头之所以常见，是因为功能清单是唯一可以直接横着比的东西。它看得见、数得清、能对齐，比完还能得出一个看起来客观的结论。相比之下，自己的缺口是一团模糊的感受，说不清几项，也没法写进表格里。

于是比较的重心不知不觉从「我缺什么」滑到了「它有什么」。滑过去之后，判断标准就变成了功能条数、界面美观、价格档位，而这三样跟你每天的实际处境没有直接关系。于是一张看起来很客观的对照表就成型了，拿给谁看都不容易挑出毛病。

还有一个加剧的因素是销售介绍。介绍总是从能力最全的地方讲起，听得多了，人会以为那些能力自己都用得上。实际用起来才会发现，日常在那套系统里点的还是那几个按钮，其余部分几个月都不会打开一次。

反过来看那些用得比较顺的团队，共同点是先写了一份东西。这份东西不长，通常就是一页纸，上面写着最近一两个月里最让人头疼的七八件事。写完之后彼此一看，很多人的头疼是同一件事。

这份纸的作用不是马上得出买哪个的结论，它做的是一件更基础的事：把模糊的难受变成可以排序的条目。有了条目，后面每一步判断才有落点，也才知道试用的时候到底要验什么。它是给自己看的，所以不必写得好听，宁可写得难看一点，也要写得具体。

具体做法可以分三步走。第一步是把最近一个月里被打断、被催、被临时叫去处理的事情回忆一遍，只记事情本身，不记感受。第二步是把同类的事情合并成一条，比如改价格被催了五次，合并成「改价格」一条。

第三步是给每条标一个频率，用每天、每周、每月去标，尽量不写感觉上的形容词。频率是这里唯一需要的量化，不必精确到分钟，只要能把每天发生的和每月发生的分开就行。频率标错一条，排序就会整体往后挪，所以标的时候宁可保守一点，不要往高了写。

标完之后按频率排下来，最上面那几条就是主要的缺口。这时候往往会出现一个让人意外的情况：排在最上面的那件事，之前从来没被当成问题提出来过，因为它太日常了，日常到大家已经不觉得它是问题。

写的时候有一个要点，只写自己做过的动作，不写希望工具能做到什么。这两者听起来接近，其实差得远。「希望它能一键改价」是一句对工具的期待，「每天要改三十次价格」是一句事实。事实能排序，期待不能。

写完之后找另外一个每天动手的人看一遍，问他有没有漏的。两个人各自写出来的清单常常不完全重合，合起来才接近全貌。这一步花的代价很低，但能避免整张清单只有一半。两个人写的时候各自独立写，先不要互相看，合的时候才会有互补的效果。

这份清单要留着，不要用完就丢。过半年再看一次，哪些条已经不在了、哪些条还在、有哪些新出现，这三个答案会告诉你上一轮的调整究竟动到了什么，比凭记忆回顾可靠得多。它也是唯一一份能证明上一轮调整确实起了作用的凭据，比事后回想靠得住。

最后要说明一点。列缺口这件事不需要工具在场，也不需要花钱，一页纸加半小时就够。它做的不是决策，而是把决策的依据摆到桌面上，让后面每一句关于买不买的讨论都有地方落脚。这句话可以在讨论跑偏的时候拿出来用，它能把话题拉回到自己身上。

有一个具体的边界情况值得说清楚。清单上出现「不知道该不该再开一家店」这种条目时，不要把它往三类里塞。它不是缺口，它是决策，属于另外一栏，单独放在纸的边上。这一栏的条目也值得留着，因为它们往往比清单本身更能说明店群现在走到了哪一步。

把它分开处理的原因是它会污染排序。这类条目听起来很重，容易排到最前面，一旦排上去，整张清单的重点就被带偏了，因为工具解决不了它，讨论到后面会无疾而终。把它单独放一栏，既不占用清单的排序位，也不会被当成缺口买来买去。

清单的篇幅也有讲究。写七八条比较合适，超过十五条会失去排序的意义，因为条目太多的时候，人对顺序的感受会变得模糊，最后还是回到凭印象挑。合并不掉的条目可以先放到附页。条目太多的时候，读的人会先看后面的，因为它们看起来更新鲜。

合并同类条目的办法是看它们的动作是否相同。改价格和改标题看着是两件事，但都是「一处改动铺到多家店」，动作相同，可以合成一条。合的时候把两种情形都写在括号里，细节不丢。合成一条的好处是付一次代价解决两种情形，比分开处理更省事。

清单写好之后放在哪里也有影响。放在某个人的文档里，过两周就没人看了；放在每天都会打开的地方，它就一直是活的。有的团队把它贴在排期表旁边，每解决一条划掉一条，这个动作本身就有推动力。

还要防止一件事，就是清单被当成工具采购的需求单直接发出去。清单的作用是给自己排序，不是给别人报价。带着清单去找答案，得到的会是比较，而不是判断。这一步要留给团队内部先走完。

它站在第四步，前三步没做完，买到的东西通常对不上自己的缺口

缺口分成操作类数据类协作类

有一类现象能说明分类的必要。让几个人各自写下自己觉得最麻烦的事，收上来会发现内容很杂：有人写改价格要一家一家改，有人写看不到别的店卖得怎么样，有人写不知道这事该谁做。这三句话如果分开听，是三件不同的事，放在一起看，其实是同一批动作在不同环节上的重复。

这些句子放在一起看起来是一堆抱怨，其实它们属于三种完全不同的问题。改价格一家一家改，麻烦出在动作被重复了太多次；看不到别家的数据，麻烦出在信息没有汇到一处；不知道这事该谁做，麻烦出在人和人之间的边界没划清。

三种麻烦的差别很关键，因为它们能被解决的方式不一样。第一种可以靠把动作合并来减少次数，第二种可以靠把信息收拢到一处来缩短寻找时间，第三种只能靠把边界写清楚，任何工具都替不了这一步。

操作类缺口最容易被看见，因为它直接消耗时间。多改几次价格、多传几遍图，这些动作是实打实落在手上的，做得多了谁都能感觉到。它也最容易被当成全部的问题，因为它是用手摸得到的那一类。

数据类缺口没那么显眼，它的代价是判断质量的下降。看不到别家的情况，分配资源的时候就只能凭印象，印象往往来自最近一次被提起的事。这类缺口不会让人觉得累，它让人觉得事情老是没做对。

协作类缺口最不容易被发现，因为它的表现形式是内耗而不是忙碌。同一件事两个人都在做，或者一件该做的事谁都没做，这两种情况下每个人都觉得自己很忙，问题却出在没人负责的交叉处。它往往要等到出了事，才被发现原来这里一直是空的。

一个实用的提问方式是问「这件事如果不做会怎样」。操作类缺口不做，页面就会停在那里不动，后果是外显的、能被买家看到的，所以这类缺口通常最先被察觉。这一类缺口也最容易被回应，因为它能立刻指出是哪一步慢了，反驳的空间很小。

数据类缺口不做，门店照样在运转，只是判断质量慢慢下降。它的后果是内隐的，需要过一段时间才能从数据高低上看出来，所以在清单里常常排在中间靠后的位置，容易被操作类压下去。它的存在感通常要等到某次分配明显不合理，或者某类商品长期没有做起来，才被人回过头来发现。

协作类缺口不做，短期内也不会有明显异常，因为大家还在各自的岗位上忙着。它的后果是资源被重复消耗，或者某一块一直没人管，往往要等到某一件事彻底断了才被察觉。等它被察觉的时候，前面已经消耗掉的时间是收不回来的，只能从当下开始补。

这个提问方式有一个好处，就是它不依赖人的感受。感受会随着最近发生的事波动，让人把刚吵过的那件事排到最前面。问后果则是往后再推一段时间看，受当下情绪的影响小得多。这个差别在情绪起伏比较多的团队里体现得更明显，稳的判断往往能筛出更真的缺口。

还有一个提问方式可以配合使用：这件事出问题的时候，第一反应是找工具还是找人。第一反应是找工具，多半属于操作类或数据类；第一反应是找某个人问一下，多半属于协作类。两个提问方式的结果如果一致，归类的把握就大一些；不一致的时候先记下来，过几天再看一遍。

两个提问方式交叉用，归类的准确度会明显提高。一件事既不做会有外显后果、出问题第一反应又是找工具，那它基本可以确定属于操作类，往上排没有问题。两种判断不一致的，单独拉出来再看一遍。

有一种归类容易出错的情形，是同一件事被不同的人归到不同的类里。比如「上新的商品资料要填很多遍」，一个人归到操作类，另一个人归到协作类，理由是他不知道谁该填。两个人对这个例子的分歧不在事实，而在他们看到的是同一件事的不同截面。

判断的办法是往前追一步，问第一次填是什么时候、为什么后面还要填。如果是因为资料没有统一格式，每次要照着不同的要求再整理一遍，那它属于操作类，问题出在格式上。如果是同一份资料要给好几个人，谁都不清楚该谁交，那属于协作类。

还有一类条目会被重复归到两个类里，比如「几个人同时在改同一批商品的价格」。它既有操作层面的重复，也有协作层面的边界不清。这种情况可以拆成两条，一条写动作重复，一条写边界不清，各归一类。

拆开之后，两条的解决方式也分开了。动作重复那一条靠合并动作，边界不清那一条靠指定谁来改。两件事各自解决，比混在一起当成一条更有可操作性，也不会出现改了一半还剩一半的情况。

归类完成后，可以数一下三类各有几条。这个分布本身有信息。操作类占绝大多数的，说明这家店群还处在动作压过判断的阶段；协作类占多数的，说明规模已经上来了，人比事多。分布只能说明阶段，不能说明好坏，规模不同的人看同一份分布会得出完全不同的结论。

分布只是参考，不要拿它下结论。数完再看一遍清单，确认没有被情绪抬高的条目。最近刚被批评过的那件事往往会被归到最难的那一类，实际再想一遍，它可能需要的就是一张更清楚的表格。

越靠近执行层的缺口越靠工具，越靠近取舍的缺口越靠人自己

三类缺口各对应什么能力

有一个场景把三类的差别体现得很清楚。一批商品要调整价格，涉及几家店。做的时候发现有两件麻烦：改的时候要一家一家进去改，改完之后不知道别家改成了什么价。这两件麻烦是两类不同的缺口，用同一种方式解决不了。

前一件属于操作类，靠的是把改动一次性铺开到多家，让动作发生一次。后一件属于数据类，靠的是把各家的价格收拢到一处显示出来，让你能一眼看到位置关系。少了任何一样，这件事都做不干净。

还有第三件麻烦容易被漏掉，就是改完之后谁都没记住这次改动是为什么。等到数据变化的时候，几个人一起回想，谁也说不清当时是基于什么判断改的。这一件属于协作类，靠的是把每次改动记下来，并且记到人。

三类缺口混着报的时候，最容易出现的结果是买来的能力只覆盖其中一类。买了合并动作的能力，操作是快了，但数据还是看不到一起，协作还是说不清。于是人的感受是「工具装了，事情还是不顺」，进而想换一个功能更多的。

混着报的另一个后果是排序失准。操作类的缺口最吵，喊得最大声，所以通常排在第一位；数据类和协作类不吵，就一直往后放。等到操作类补上之后，前面那两类才露出来，才觉得当初的优先顺序定得不对。

所以把三类分开写下来这一步很值。分开之后能看清哪些缺口是同一类，同一类缺口用同一种方式解决，不必买三套东西。也能看清哪一类是自己最该先动的，哪一类虽然吵但其实可以往后放一放。

分成三类还有一个附带的好处，就是它让讨论有了共同的词。以前争论的时候，一方在说动作太多，一方在说数据看不到，各说各的，谁也说服不了谁。用了同一套分类之后，大家先确认这是哪一类，再讨论怎么处理，会快很多。

面对操作类缺口，能起作用的能力有明显的共同特征：把多次动作并成一次。一次改动铺到多家、一次导入带上多个字段、一次提交覆盖一批商品，这些都属于同一类，它们减少的是动作发生的次数。

面对数据类缺口，起作用的能力分两层。下面一层是把信息收拢到一处，让原本要跳几个地方才能看到的东西出现在同一屏；上面一层是让这些信息彼此可比，也就是口径一致。多数时候，下面那一层容易做到，上面那一层要人来定。

面对协作类缺口，起作用的能力只有一个：让谁做了什么留下痕迹。这件事的形式很朴素，就是每一次改动都留下时间、对象和人。它的价值在事后，出事的时候几分钟能定位到哪一次改动，不用把当时在场的几个人一起问一遍。

三类能力有先后。操作类的能力和协作类的能力可以直接买，买来配一下就能用。数据类的能力要先有人把口径写下来，写不下来的时候，买来的展示能力会变成一堆看起来热闹但读不出结论的图表。

判断某款工具覆盖了哪一类，有一个不需要介绍材料的办法：看它默认打开的第一个页面是什么。第一个页面是操作入口，说明它的重心在动作层；第一个页面是一堆数字，说明重心在展示层；两个都不是，那它可能更偏其它用途。

还有一层要分清。工具能接的是执行，接不了的是决定执行什么。同一句「把价格铺到多家」，铺哪些店、铺成什么样，这些决定不在能力范围里。看清单的时候，把这类决定单独标出来，不要混进去当成缺口去比。

缺口和能力对上的时候，使用时会有一种很明显的感觉：原来要花半天的事，现在花十几分钟，而且这十几分钟里没有来回切换。对不上的时候，工具装上了，动作也确实点得到，但那种半天变十几分钟的变化不会出现。

有一个具体案例可以看三类的叠加。一家店做节日活动，要给几家店同时换主图、调价格、发一条公告。三件事的性质完全不同：换主图属于操作类，调价格属于操作类加数据类，发公告属于协作类。

做的时候如果只有操作类的能力，换主图和调价格能一次性铺开，公告还得挨个通知。这时候顺不顺取决于另一件事：有没有一个固定的、所有人都会看的通知位置。没有的话，通知这件事会一直靠人挨个催。

做完之后的复盘更考验覆盖度。这次活动效果怎么样，几家店分别是什么反应，这几个问题的答案要靠数据类的能力才拿得到。拿不到的时候，复盘只能停留在「感觉比上次好」这个层级。复盘这一层缺了，前面两次做得好不好就无从积累，下一场活动还是要从零开始想。

还有一个容易被忽略的细节。三类能力里，操作类的能力见效最快，装上就能感受到；协作类的能力见效最慢，通常要等到一两个月后出了事才发现有用。所以选型时人对协作类能力的评价普遍偏低。

这个偏低是有代价的。因为出事是小概率事件，平时用不上的能力在主观上就不值钱，等到真出事的时候再去补，补的过程又是在忙乱中做的。把它提前配好，成本不高，但需要在平静的时候做。

最后说一条边界。三类能力都是执行层面的补充，它们都不回答「这件事该不该做」。调价、换图、发公告，每一件该不该做、做到什么程度，都是人先定，工具只负责做得齐、做得快、做得有痕迹。

不要为用不上的能力付费

有一个反复出现的现象。把功能清单摆在一张表里的时候，人很难不去选最长的那一份，哪怕那份长出来的部分自己用不上。这不是判断力的问题，是比较这件事本身的性质决定的：多的东西看得见，缺的东西看不见。

于是付费里有一部分是为「万一用得上」买的。这句话在采购别的东西时也许成立，用在管理工具上往往不成立。因为工具的价值不来自它拥有什么，而来自它替你减掉了多少次具体的麻烦。减不掉的，拥有也就只是拥有。

闲置的能力带来的代价通常被低估。人们以为闲置就是不划算，损失的是钱。实际损失更大的是选择成本：功能越多，操作路径越长，找一个常用按钮要多翻一层，新人上手要多学几天，日常每一次操作都多一点点摩擦。

这个摩擦每次都小，累起来就明显了。一个团队每天在系统里做成百次操作，每次多花两秒，一天就多花几分钟，一个月下来是几个小时。这部分时间不出现在任何报表里，却实实在在从日常里被抽走了。

还有一个更隐蔽的影响。功能多了以后，人会倾向于去试那些原本不需要做的事。既然有这个能力，那就用一下看看，于是本来可以不做的事情被做了。做出来之后还要维护，工作量的增长常常是从这里开始的。

比较务实的做法是给自己划一条线：这一项在我这里一个月会用几次。答案是零次或者一次的能力，无论它在介绍里显得多重要，都不该成为选型时的加分项。选了它，等于为别人的场景付了自己的钱。

判断一项能力会不会用得上，可以拿手上的具体场景去套。比如一项能力是同时管理很多店的价格，那就想一下自己有没有过「好几家店的价格要一起调整」这件事。有过，而且是常态，那这项用得上；从来没有过，那这项就是为别人准备的。

这个办法的要点是用过去发生的事，不是用未来可能发生的事。未来会发生什么没人能准确判断，用未来做依据，几乎每一项能力都会显得可能有用，讨论也就失去了筛选的作用。这个区分看起来只是措辞上的讲究，实际会影响判断的稳定性，过去的事有记录，未来的事没有。

还有一类能力，用得上但不够频繁。比如一项工具做得很好，但一个月才会用到一次。这类能力要不要为它付费，取决于它的替代成本：如果不用它，那一次要额外花多少时间。花得不多，就不必为它单独掏钱。

在做这件事之前，先确认自己那几条主要缺口有没有被覆盖。主要缺口是每天都要面对的，它们才是选型时该看的重点。把注意力放在主要缺口上，边角能力的吸引力会自然下降，因为缺少使用场景支撑。

另外一个常被忽略的点是成本不只有购买。工具本身要有人去配、去维护、去跟其他人的操作对齐，这部分人力成本会持续发生。能力项越多，这块的持续投入越大，有的时候它比购买那一笔更重。

把这两部分加起来看，判断会清楚很多。购买是一次性的，配和维护是持续的，一个能力项即使不要钱，只要它带来持续的维护，就依然是一笔支出。用这个角度去滤一遍，能滤掉相当一部分看起来免费的选项。

有一个具体的边界情形，是自己以后可能会扩到那个规模。回答这个问题用现在的节奏推，不要用设想的节奏推。现在每周的改动次数有多少，按这个数量乘上一个合理的增长幅度，再判断那项能力什么时候才会用上。

如果按这个推算，那项能力要到一年以后才可能用上，那现在为它付费就不划算。一年的时间里，工具本身也可能变化，到时候再选一次也许更合适。现在付的钱是为了一年后才可能发生的事。

另一个边界情形是行业里其他人都在用。同行的选择可以参考，但要先看清同行处在哪个阶段。同行已经在做大规模冲量，他的缺口分布和你不一样，他选的工具对你可能只有一半适用。同行在用的东西可以问、可以看，但要不要跟着买，仍然要回到自己那份清单上判断。

还有一个可以用的动作，是就某一项用不上的能力去问一下已经在用的人，问他实际一个月用几次。得到的答案常常比介绍里说的低很多。这个动作花几分钟，能省掉一笔可能一直闲置的支出。

便宜的选项也有它的边界。如果某个便宜的工具能把主要缺口补上，其余能力都不要，那它是划算的。划算的判断依据是覆盖了主要缺口，不是价格本身，价格低的工具补不上缺口同样是不划算的。

最后要留一点余量。给主要缺口的覆盖率留一成到两成的富余是合理的，因为缺口会随着规模变化。留得太多就变成先前提到的为万一付费，这个尺度自己把握，但要有意识地把握，而不是顺着感觉走。

更换工具的成本要不要算

有一个时间点几乎每个店群都会遇到。正在用着的工具出了点小毛病，可能是某次导出少了几个字段，可能是某个页面加载慢，于是换一个的念头冒出来。这个念头通常出现在具体的小问题上，而不是出现在一次完整的成本核算之后。

念头之所以容易冒出来，是因为换的代价分散在未来的几个月里，眼下看不见。而眼前的不顺是当场能感受到的，一重一轻，判断自然会偏。这种偏并不来自贪便宜，它来自代价的显现时间不一样。

换工具的第一项代价是迁移。旧系统里积累的东西要搬过去，这里面包含历史记录、已经配好的规则、各店之间已经对齐的口径。搬的过程不只是复制，还要重新核对一遍，因为两套系统的字段定义往往不完全一致。

第二项代价是人的重新熟悉。界面换了，原来的手势和路径全部作废，每个人都要经历一段效率回落的时期。这段时期里动作会变慢，出错会变多，而且不完全体现在数字上，更多体现在大家的情绪里。

第三项代价最容易被忽略，是旧工具里沉淀下来的做法。用了半年之后，很多操作已经变成了条件反射，什么情况下点哪里不需要想。这些做法是跟着具体工具长出来的，换一个之后全部得重建，重建的过程没有捷径。

这三项加起来，幅度往往大于新工具带来的改善。所以产生换的念头之后，可以先做一件简单的事：把这三项各估一个大概的量级，再拿来跟当前那个小毛病比。比完之后，相当一部分换的念头会自动消退。

估算迁移代价有一个简单的办法：列出旧系统里有多少东西是别人配好、而不是默认就有的。配好的规则、对齐过的口径、约定俗成的操作顺序，这些都算。列出来的条数越多，迁移的代价越大。

估算重新熟悉的代价，可以看这个团队过去换过多少次内部流程，以及每次换完之后多久恢复原来的产出。有过类似经历的话，这个时间通常心里有数，可以直接拿来参考。换过一次之后，这个数字可以记下来，下次再有换的念头时，它是最直接的一个参考。

估算沉淀做法的代价最难，因为它没办法量化。一个可以用的办法是回忆一下最近有没有出现过「这个我得找某某问一下」的情形，如果这类情形很常见，说明做法已经沉淀在人的习惯里，换工具会把这些经验一起打散。

把三项估完之后做一个比较。如果三项加起来的量级明显大于当前那个毛病，那就先不换，改成把那个毛病想办法绕过去。绕过去也是一种处理，只不过它的成本落在日常操作里，比较分散，不太引人注意。

如果三项加起来确实小于那个毛病，那换是合理的，但换的方式可以更稳一点。新旧并行一段时间，让常用的几件事先在新系统里跑通，其余的照旧，跑通之后再整体切过去。并行期的余量不大，但能避免一刀切之后的效率真空。

还有一个判断原则可以用。那个毛病如果只影响手感不影响结果，可以先放一放；如果它已经开始影响结果，比如某一类数据长期取不到、某一种操作长期做不齐，那就是该动的时候了。用这个区分，能把纯情绪性的换和真正必要的换分开。

有一个具体的记录方法可以降低换的代价。从开始用第一款工具的时候，就把配过的规则、对齐过的口径、约定过的操作顺序记在一个单独的文档里，不记在工具内部。这份文档的位置要固定，让所有人都知道它在哪，不然它会在某次整理中被顺手清掉。

这份文档平时看着没用，但它是这个团队的管理资产，跟用什么工具无关。换工具的时候照着它在新系统里重配一遍就行，不需要重新讨论一遍当初为什么这么定，省下的不只是时间，还有反复讨论消耗的耐心。

文档的写法不必正式，一条一句就够，比如某类商品的价格下限是多少、某类字段在几家店里保持一致、哪一类改动需要先跟谁确认。写的是结论，不必写推导过程。越是浓缩成结论的条目，日后重新配起来越省事，因为不需要再把推导过程走一遍。

有了这份文档，换工具的代价结构会变化。迁移这一项会明显下降，重新熟悉这一项还是躲不掉，但至少不用一边摸索一边重建规则。三项代价里去掉最重的一项，换与不换的判断会理性很多。

还有一个细节值得记一下：换工具前后各记一周的日常动作耗时，用同一套口径。两组数字放在一起，能直接看出这次换值不值。不记这一组数字的话，过两个月回头，人对这次换的评价基本取决于最近一次遇到的不顺。

如果最终决定不换，也把这个判断记下来。写清当时为什么没换、那个毛病后来是怎么处理的。等到下一次再有换的念头冒出来，翻一下这条记录，可以避免同一件事被反复讨论。这条记录不必写得多长，两三句话把当时的场景和结论写清就够用了。

最后一行的格子基本是空的，那类缺口买什么工具都填不上

试用的正确方法是什么

有一个常见的试用方式：拿到账号之后先到处点一遍，看看界面顺不顺、菜单好不好找、操作流不流畅。点完之后印象不错，就下单了。过后回头想，试用期里真正验过的东西其实很少。这种感觉在试用期的前半段尤其强烈，因为那几天注意力都放在新东西上。

这种试用方式偏到手感上去，原因不难理解。手感是当下立刻能感知的，效果要过一段时间才显现。试用期通常只有几天，几天里看不到效果，能看到的只有界面和响应速度，注意力自然落在那里。

手感本身不是不重要，它每天都要被用到，太别扭的东西确实影响使用。但它只回答了一个问题：这个东西用起来顺不顺。它回答不了另一个问题：这个东西填的是不是我那类缺口。后一个问题才是选型要回答的。

要回答后一个问题，试用就必须带着清单进去。清单上写的几件事，各拿一件真实的活走一遍。走完之后看的不是顺不顺手，看的是这件事的费劲程度有没有下降，下降的是原来那个环节，还是只是换成了别的环节。

这里有一个容易误判的地方。有的工具会让操作变快，但总时间没有降，因为省下的部分在核对那里又还回去了。这种情形下的人容易觉得有改善，因为动作确实轻了，代价是整个流程并没有真的缩短。

所以试用结束时可以给自己一个明确的判据：清单上最费劲的那两件事，现在做一件要花的时间有没有明显变化。变化明显就算过关，变化不明显或者只是位置挪了挪，说明这次试用还没有验证到关键的地方。

试用要带进去的第一样东西，是最费劲的那件事的真实素材。比如要试改动铺开的这项能力，就准备一批真实的商品，按真实的规则改一遍，看它做完之后的状态跟你预期的一样不一样。素材用真的，不要用现造的数据，现造的数据往往很规整，规整的数据试不出麻烦。

要带进去的第二样东西，是一个时间记录。试之前先估一下手工做这件事要多久，试之后记一下实际花了多久。这两个数字摆在一起，比任何主观评价都有用。它们不会被当时的心情影响，也比较不出错。

要带进去的第三样东西，是做完之后接着要做的下一件事。工具做完了这一步，后面那一步是不是还要人接。要接的话，接的过程顺不顺。很多工具在单点上很快，但在交接口上留了一堆手工活，这一层要试出来。

试用期间要刻意制造一次异常。比如故意填一个不常见的取值，看它会怎么处理；或者做一次对大批数据有影响的改动，看它有没有二次确认。异常路径往往比正常路径更能说明这个工具是不是替人想到了下一步。

试用还有一个容易被忽略的部分，就是问别人的操作感受。自己觉得顺，一起用的人不一定觉得顺，因为每个人的动作习惯不一样。几个人分别试一下同一件事，得到的反馈会更有参考价值。有时一起用的人一句话就能点出自己没注意到的别扭，这一句比自己试一整天更有价值。

试用结束时把记录收起来，对照清单上的几件事写一句结论。结论不必长，写清这几件事比原来省了多少、有没有新的麻烦冒出来。这份结论会变成下一轮要不要买、买哪个的依据，比印象可靠。

最后提醒一件事。试用期里人对新工具的容忍度普遍偏高，遇到不顺会习惯性地想「可能是我还不熟」。这个想法本身有道理，但要在试用结束前把它排除掉，办法是找一个之前没用过的人来试，看他会不会卡在同一个地方。

有一个具体的试用安排可以参考。第一天只看不做，把清单上要验的两三件事在系统里各点一遍，确认这些能力存在、路径能走通，这一步花的时间不长。这一步的目的只是确认能力存在，不要在这天就下结论，界面顺不顺说明不了多少问题。

第二天开始做真实素材。把最费劲的那件事实际做一遍，做的时候记时间，做完记下有没有需要手工接的部分。这一天是最关键的，能不能得出判断基本看这一天。做的时候尽量照平时的节奏，不要为了试工具而调整顺序，调整过之后试出来的结果就不准了。

第三天做异常。故意填错一个值、故意对一大批数据下手，看它的反应。反应合理，说明它替人想过出错的情形；反应粗糙，说明这些情形要靠使用的人自己小心，长期下来会不断消耗注意力。

试用期间要避开一个陷阱，就是让最熟悉工具的人去试。熟悉的人上手快，会把很多不顺手的地方用技巧绕过去，留下的印象偏高。让一个平时只用最基础功能的人去试，得到的反馈更接近多数人的真实体验。

试用结束之后的记录建议固定三项：主要缺口的上手耗时、需要手工接的部分、出现的异常反应。三项写清，一份试用结论就成型了。用同一套三项去试第二家，两份结论可以直接对照。三项都偏向过程，不偏向感受，这样两份结论放在一起才有可比性。

最后一点关于试用期的长度。如果试用期只有两三天，那就不要试图验证频次低的缺口，把验的范围缩到每天都在发生的那一两件事上，验透。摊得太开的话，每件事都只碰了一下，最后什么都验证不了。

按缺口选出来的东西针对性更强，闲置的能力项和换工具的冲动都会低一些

选型本质是管理问题

有一个现象常被拿来当反例。两个规模差不多、类目也接近的店群，在同一段时间里选出来的工具完全不一样，而且各自都用得挺好。如果选型真是功能比较，这种情况就不该出现。而且两边的评价都不低，事后问起来，各自都能说出自己选的那个解决了什么。

它出现的理由是两边的缺口不同。一边的痛点是每件小事都要做好几遍，另一边已经过了那个阶段，痛点是几个人之间的活分不开。缺口不一样，被选中的能力自然不一样，两个选择都对。这不说明两个人中有一个判断错了，只说明被称作工具的那件事，在两边指向的不是同一个问题。

同一款工具在两家店效果差很远，也是同一个道理。甲家的缺口正好落在工具有能力的那一块，用起来立竿见影；乙家的缺口在别处，工具装上去以后能用，但用不到点子上，于是评价就不高。

这两种情形指向一个共同的结论：工具本身有强有弱，但强度是相对于缺口而言的。脱离了缺口谈谁更强，讨论就没有落点。这也是为什么照着别人的选择买，结果常常对不上。把这个道理记住，别人的使用体验就只是一个参考，不能直接搬过来当自己的结论。

还有一个更能说明问题的现象：有的店群换了好几款工具，每一款都只用了几个月，每次换完都觉得问题还在。换到第三第四款的时候，问题通常已经不在工具上了，它一直待在原处，只是没被当成问题看待。

让缺口显形，其实不需要工具先到场，一页纸就够。把每天卡住的地方写下来，归到三类里去，排一遍轻重，这件事做完之后，选型的答案已经出来了大半。剩下的只是按着这份答案去试，试的过程比挑的过程短得多。

这个说法可以通过一个判断来理解。设想一下，把当前最贵的那款工具直接给你，装上之后，你的日常会不会马上顺起来。如果答案是会，那你的缺口确实在能力那一层，选型方向也不难定。反过来，如果装上之后日常该忙的还是忙，那就说明缺口不在这一层，往上加配置也不会变。

如果答案是不会，或者只有一部分会，那说明剩下的那部分不归工具管。这部分通常是分工、口径、边界这类东西，它们不花购买预算，但需要有人坐下来把它们写清楚。不写清楚，工具装到第几款都填不上。

这解释了为什么有的团队在选型之前先花一周做整理，而不是花一周试工具。整理的成本很低，一周之后不仅缺口清楚了，一些不需要工具就能解决的事也在整理的过程中被顺手解决掉了。整理本身就是一次筛除，筛掉的往往是那些用工具也解决不了、但一直被当成工具问题的条目。

它也解释了另一个常被误读的现象：同样一款工具，有人用得很好有人用得不好。差别往往不在对工具的熟悉程度，而在用之前有没有把要它接的那一段定义清楚。定义清楚的那一边，工具一进来就到位。

按这个思路，选型的最后一步不是签合同，而是把清单上被划掉的那几条对照一次，确认它们是靠工具划掉的，不是靠当时多派了人划掉的。分不清这一点，下一轮还会在同一个地方卡住。两种情况在当时的感受上很接近，都是事情终于不卡了，过一段时间才看得出分别。

把顺序摆成这样，选型这件事的形态就变了。它从一个采购动作变成了一次自我梳理，采购只是梳理完之后顺手做的一件事。梳理清楚之后，买哪个往往不再是难题，因为可选项已经少了很多。

还有一层意义，是这份梳理可以反复使用。店群的阶段会往前走，缺口会换位置，但梳理的方法不变。过一段时间把清单重列一遍，对比两次的结果，能看出这一段时间的调整究竟有没有落在自己真正缺的地方。

这个说法有一个很好的检验方式，就是把清单交给另外一个人，让他只看清单，不看工具，试着说出这个团队现在最该解决什么。说得出来，说明清单写得清楚，缺口是明确的。这一步不需要他懂工具，只要他读得懂清单上的条目，能指出哪一条最要紧就行。

说不出来，通常有两种原因。一种是清单写的是感受而不是事实，读的人抓不到具体动作；另一种是清单上条目太散，看不出主次。两种原因都指向同一件事：梳理还没有做到位。两种情况都好处理，前一种把形容词换成动作，后一种按频率重排一遍，半小时能做完。

这层关系也解释了为什么同一份缺口清单，隔一段时间重列会不一样。店群往前走了，缺口的位置会移动。原来排在首位的是动作重复，过半年再看，它可能已经被解决了，排到前面的是资源分配。

资源分配这类问题有个特点，它需要的不是执行能力，而是判断依据。哪家店的品该加码、哪家店该收缩，判断要先看各站点整体的品类结构和价格带落在什么位置，知虾站在的是站点分析与多站点数据这一层。

这一类判断依据和工具的能力是两回事。能力解决的是手上动作做得多快多齐，依据解决的是往哪个方向做。两者缺一不可，但顺序上依据在前。方向没定就动手，动作越快，偏得越远。顺序摆对了，工具进场之后是在把已经想好的事做齐，而不是替你想。

所以一份好的缺口清单，最后往往分成了两栏。左边一栏是工具能接的执行缺口，右边一栏是自己要定的判断事项。左边那栏决定买什么，右边那栏决定怎么用。分完这两栏，选型这件事基本就落地了。

常见问题（FAQ）