Shopee把六个环节写成一张进度表

进度表要写什么

最常见的错误是把进度表写成工作日志。日志记的是谁在什么时候做了什么，进度表记的是东西交到哪了、下一步谁接。前者回答忙不忙，后者回答动没动。这两个问题完全不同，混在一张表里，两个问题都回答不了。

第二个常见错误是把环节写成部门名。写部门名的时候，交接关系是隐形的，因为部门之间的传递方式从来没有被写下来。改成写环节之后，每个格子对应一段具体的活，交接的方式才有地方落笔，也才能被核对。

第三个错误是一开始栏位就铺得太开。有的人建表时列了二十几栏，什么都想记。栏位越多，填表的人越懒得填，两周之后表格就变成空的。建议从六栏起步，跑顺之后再按需要增加，而不是一次到位。

还有一种是表里全是最终结果，没有中间状态。只写本月销售额是多少，看不出这一步之前卡在哪里。进度表要记的是过程量，比如词表整理到几成分级、监控名单确认了多少个，这些才是能推动下一步的信息。

最后一个常见问题是表建完之后没有固定的更新时点。谁想起来谁填，结果就是所有人都在等别人先填。更新时点不影响表的内容，但它决定表会不会被继续使用。没有时点的表，多数活不过一个月。

动手建表的第一步是先把六个环节按链条顺序写成一列。顺序不用纠结，先按常见的先后关系排，比如数据口径、选品判断、关键词清单、竞品监控、内容与图文、诊断排查。排完再按实际做法微调。

第二步是给每个环节写一句它的产出是什么。这句话不用长，一句话能说清就够。写的时候注意用名词短语，写东西不要写动作。写东西才能被交接，写动作只能被完成，两者的作用完全不同。

第三步是把相邻两个环节之间的产出对一遍。上一个环节的产出，下一个环节用不用得上。用不上的地方先标出来，不要立刻改流程。标出来之后，往往会发现有的环节是孤立的，它的产出没有下游，或者它的输入没有上游。

第四步是给每一行找一个负责人。负责人不一定是做这件事的人，但要是能对这条状态负责的人。找不到负责人的行先标一个待定，在下次会上定下来。没有负责人的行是表格里最先变陈旧的。

第五步才是加栏位。前面四步做完，栏位其实已经呼之欲出了，缺什么一眼能看出来。这个顺序能避免一开始就把表设计得很复杂，因为需求是从实际流程里长出来的，不是凭空想出来的。凭空想的栏位通常没人填。

有一个可参考的例子。一家店最初把表做成了周报的格式，每周写六行文字说明。跑了三周之后没人愿意填，因为写说明太费时间。后来改成六行表格，每行只填状态和一句变更原因，填表时间降到几分钟，表就一直用下去了。

这个例子的启示是，表能活下来的前提是填得动。设计的时候不要按理想状态设计，要按最忙的那一周来设计。最忙的时候还能填完的版本，才是能长期用的版本，其它版本都只是理论上的完整。

还有一个边界是团队里有人不习惯用表。这种情况下，可以先让他在表上只填自己那一行的状态，别的不用管。等到他发现看别人的行能帮自己省掉几次询问之后，参与度会自己上来，不需要强制。

另一个边界是业务特别简单的店。只有一两个人、环节高度重合的时候，这张表可以简化成三行，只记数据、选品与执行三段。表的复杂度和业务的复杂度要对上，简单业务用复杂的表，反而是负担。

记录这张表本身的历史也有价值。每次调整栏位时写一句改了什么、为什么改。一年之后回看这些记录，能看出自己的流程是怎样一步步成型的，这比任何外部的方法论都更贴合自己的实际情况。

表的价值在于把环节之间的关系固定下来，而不是记录工作量

每个环节的输入输出栏位

输入栏位要写上游交过来的东西，而且是具体形态。写「关键词数据」太笼统，写到「竞品链接、对应词、近三十天的销量档位」才够用。写得越具体，上游才越清楚要准备什么，下一个人也才知道怎么接。

输出栏位写的是本环节交出去的东西。判断写得够不够，有一个简单的办法：把输出栏位拿给下游看，问他照着这个能不能开工。如果他还需要再问一遍，说明输出栏位写得太粗，需要拆到字段这一层。

输入和输出之间应该能对上。上一个环节的输出栏位，应该和下一个环节的输入栏位基本一致。对不上的地方就是接口缺口。这类缺口不需要每次都修，但一定要被看见，因为看不见的缺口最后都会变成临时沟通。

有的环节输出不止一份。比如选品这一段，可能既要给关键词环节一份候选品清单，也要给内容环节一份卖点方向。这类环节需要在表里多设一行，把不同的输出分开记，否则下游会去争同一个产出，谁也说不清该拿哪一份。

输入输出的格式也要写。是表格还是文字，字段顺序有没有要求，时间口径按哪一天算。这些细节看起来琐碎，但它们决定了交接能不能一次成功。格式不写清楚，第一次交接通常要来回两三次才能对上。

填输入栏位的时候，可以按三个问题来写。上游交的是什么、用什么格式交、什么时候交。三个问题各写一句，输入栏位就填完整了。缺任何一句，这个栏位在交接时都会留下争议的空间。

填输出栏位的时候反过来问。下游要什么、用什么格式要、什么时候要。两边都填完之后对照一遍，能发现不少偏差。有的偏差是合理的，比如上游一次交一批，下游一次只用一部分；有的偏差则是接口没有定义清楚。

写到字段这一层的时候，建议给每个字段加一个口径备注。比如销量这一栏，是按付款时间算还是按完成时间算。备注写在表头或者单独一列里都行，关键是写下来。口径不写，同一栏里早晚会混进两种算法。

如果某个环节的产出是文字类的，比如一份判断结论，也要给一个固定的结构。结论、依据、下一步动作，三段就够。结构固定之后，下游读起来快，复盘的时候也容易比较不同期的结论差异。

填完一轮之后，建议拿最近一期的真实数据试填一遍。试填能暴露很多设计阶段看不出来的问题，比如某栏其实没人有数据、某栏需要额外的取数工作。试填一次花的时间，比在正式使用中返工要少得多。

一个具体的例子。关键词这一段的上游交付物写的是选品结论，太笼统，下游每次都要再问一遍是哪几个品、为什么选它们。后来把交付物改成候选品清单加一句入选理由，下游的询问次数明显减少。

另一个例子是关于格式的。原来上游交过来的表列顺序不固定，下游每次要手工调一遍。后来在输入栏位里写明列的顺序要求，上游照着交，下游就不用再调整了。这个改动只花了几分钟，省下的是每周一次的手工整理。

边界条件是上游不稳定的时候。有的上游是外部合作方，交付时间与格式都很难约束。这种情况下，可以在本环节的输入栏位里加一栏来料核对，写明这一期实际收到的东西和约定的差在哪，把不可控的部分记录下来。

另一个边界是产出带有判断的部分。比如选品这一段，除了清单还会附一个倾向。这类输出在表里要写清哪个是必须交的、哪个是附带的。不区分的话，下游会把附带的部分当成必须，反过来要求上游每次都给。

记录方式上，建议把输入输出的样例存一份。每一份交付物保留一个真实的样例，放在和表同一个位置。有了样例，写栏位的时候有参照，交接的时候也可以直接拿样例对照，不用靠文字描述去想象。

前四栏是表能不能用起来的关键，后两栏决定表能不能推动事情

交接点怎么标

交接指的是一个环节把产出交给下一个环节这个动作。表里要给每个交接点一个编号，编号里带上前后两个环节的序号。这样出问题时，说一句几号交接点有问题，所有人就知道在说哪一段，不用从头描述流程。

交接点上要标的最重要一项是交付时间。不写时间，上下游对什么时候该拿到东西的理解会差很远。时间不一定要精确到小时，写清是当天、次日还是本周期内就够用，关键是双方对同一个说法有共同的理解。

第二项要标的是验收方式。是下游看一眼就收，还是要对照几个条件逐条核。验收方式决定了交接要花多久。没有约定验收方式的交接，通常会演变成下游拿着东西反复琢磨，既慢又容易起争执。

第三项要标的是退回条件。什么情况下下游可以把东西退回去重做，这个界限要事先说好。没有退回条件，要么下游不敢退，硬着头皮用不合格的输入；要么下游随意退，上游白做很多无用功。

交接点还适合标一个异常记录栏。写得简单一点，只记时间、现象、处理方式。积累一段时间之后会发现，出问题的总是那几个固定的交接点。这几个点值得单独拿出来重新设计一次交接方式。

标交接点的第一个动作是数一数有几个。把相邻环节之间的传递全部列出来，包括那些靠口头完成的。数出来的数量往往会比预想的多，因为不少传递动作因为太日常，平时根本不觉得它是一次交接。

第二个动作是给每一个交接点定一个交付物名称。名称要能指向一份具体的东西，比如某期的关键词分级表，而不是笼统的数据。有了名称，上下游讨论的时候指的是同一个东西，争执会少很多。

第三个动作是标交付的时间点。写清是周期内交付还是事件触发交付。周期内交付的写清是哪一天之前，事件触发的写清什么事件发生之后多久内。两种交付的时间说法不一样，混着写会让人无所适从。

第四个动作是标验收要求。写清下游要检查哪几项，通过的标准是什么。验收要求不需要复杂，两三行能说清就行。写下来之后，双方对合格的理解就统一了，接受与否不再靠感觉。

最后一个动作是给每个交接点配一个记录位置。可以是表里的备注栏，也可以是单独的一张异常记录。这个位置要让人一眼能找到，并且能一直追加。没有记录位置，交接点上发生过什么谁也说不清。

有一个案例。一家店把交接点编号之后，发现在六行表里居然有十一个交接点。其中三个完全重复，是两个人都以为对方该做同一件事。去掉重复动作之后，等于省下了一部分人力，而这个发现纯粹来自编号这个动作。

还有一个案例是关于验收的。原来交接靠一句你看着办，接手的人常常返工。后来在交接点里写明验收看哪三项，返工次数降了下来。约定的作用不在于严格，而在于让双方对合格有同一个理解。

边界条件是交接频率很低的情况。比如每月才交一次的环节，双方都不熟练，容易出问题。这类交接点更适合配一份简短的检查清单，每次交接前对着过一遍。频率低意味着靠记忆是不行的，清单是必要的。

另一个边界是并行交接。有的环节会同时给两个下游供货，这时候一个交接点要拆成两个，因为交付时间和验收要求可能不同。挤在一个交接点里，会导致两边都以为自己拿到的是同一种东西。

记录上建议给每个交接点留一个累计出问题的次数。次数本身不重要，重要的是哪些点排在前几。排在前面的那几个，就是这条链条上最容易断的地方，值得花时间重新设计一次交接方式。

状态怎么记

状态是这张表里最容易失控的一栏。取值太多，填的人记不住，最后每个人用的词都不一样。取值太少，又看不出到底堵在哪。比较顺手的一档是六个：未开始、等上游、进行中、卡住、已交接、已验收。

这六个取值里，最有价值的是「等上游」。它直接暴露了链条上谁在等谁。哪一个环节长期处在等上游状态，说明它上面那一段就是当前的堵点。这个信号比任何分析都直接，也是这张表最容易给出的信息。

「卡住」和「等上游」要分开。等上游是外部的、需要别人推进；卡住是这一段自己动不了，可能是判断没把握、可能是缺信息。两者要采取的动作完全不同，混在一起会让人不知道问题出在谁身上。

状态后面要跟着日期。只有状态没有日期，看不出这一段停了多久。有了日期，一眼就能看出哪些环节已经很久没动。判断「很久」不需要精确的阈值，同一张表里对比几行就很明显了。

状态更新要由这个环节的负责人来做。别人代填，填出来的状态往往和实际不符，因为只有做事的人知道这一步到底卡在哪。指定一个人替所有人填表，通常两周之后就变成照抄上一版，表就失去意义了。

落地的做法是先确定取值，再写清每个取值的判定条件。未开始是没有动作发生；等上游是本环节已经准备好但缺输入；进行中是有动作在推进；卡住是自己这一段动不了；已交接是产出已经交出去；已验收是下游确认接收。

判定条件写清之后，填表的人就不会在相邻的两个状态之间犹豫。比如「等上游」和「卡住」这两个最容易混，有了明确的判定条件，一个看有没有缺输入，一个看自己能不能动，区分起来就清楚了。

状态变化时建议连同一句变更原因一起记。写一句就够了，比如从等上游变为进行中，原因是上游交来了分级表。有了这一句，回看的时候能还原当时的推进过程，也能看出哪个环节经常要等很久。

状态栏还适合加一个时间维度，就是这一状态已经持续了几个周期。这个数字比变更日期更直观，因为它直接给出停留时长。停留时长最长的几行，通常就是当前最值得处理的位置。

如果表是在表格软件里维护，状态可以做成下拉选择，避免乱填。手写的表可以用固定的符号代替文字，但符号的含义要写在表头或者附注里。无论哪种方式，关键是取值集合固定，不允许临时新增说法。

有一个具体的例子。一家店用六个状态跑了两个月，发现最常出现的状态是等上游，集中在关键词那一段。原因是选品结论给得慢。看清楚之后，他们把选品那一环的交付时间提前了三天，等待就消失了。这个问题靠看数字是看不出来的。

另一个例子是关于状态的诚实度。有一家店要求卡住必须写清卡在哪，结果有人说不出具体原因，只好写进行中。后来改成卡住只需写一句现象，不要求分析原因，记录的真实度立刻上去了。要求太高反而会催生假填报。

边界是跨周期的环节。有的环节一做就是两三个周期，这期间状态一直是进行中，看不出进度。这类环节可以在状态后加一个进度档位，比如刚起步、过半、接近完成。档位粗一点没关系，只要能看出在动。

另一个边界是长期挂起的环节。确实有些环节会因为外部原因长期不动，这时候不要让它一直显示等上游，因为会淹没真正的问题。可以单设一个已搁置状态，写明搁置原因和重新评估的时间。

记录方式上，建议每个周期保留一版表的快照。不需要每天存，每个周期末存一次就够。有了历史快照，回看某个堵点是从什么时候开始的，会非常清楚，也比事后凭记忆回忆要准确得多。

表的更新节奏

最常见的失败是更新频率定得太高。要求每天更新，头一周大家还能坚持，第二周就开始补记，第三周表格里的日期已经和实际对不上。频率定得比实际能力低一档，表反而能活下来，这是很多团队试过才承认的一条。

能坚持下来的做法通常是分层。环节内部的动作天天动，但表上只记状态变化；交接点的交付按周期更新一次；整表检查按周或按结算周期做一次。三层节奏分开，填表的负担就落在可承受的范围内。

固定时点比固定频率更重要。同样是每周一次，定在周一早上和想起来就做，效果完全不同。固定时点会让更新变成习惯，也方便汇总的人在时点之后检查一遍有没有漏更新的行，不必挨个去问进度。

更新节奏还要跟业务的节奏对齐。业务按月做计划，表就按月做一次完整校核；业务按周上新的，表就按周。节奏对不齐的时候，表上的状态和实际工作会错位，读表的人会得出错误的结论。

节奏定下来之后不要频繁改。改一次节奏，所有人都要重新适应一遍。如果确实需要调整，建议先试一个周期，确认负担合适再正式改，避免改了又改，最后没人记得当前的规矩是哪一版。

定节奏的时候可以先算一笔时间账。每行更新一次要花多久，六行加起来是多少，一周更新几次。算完会发现，如果每周每行都完整更新一遍，实际的负担可能超过半小时。这个数字决定了节奏能定多密。

比较实用的做法是分清轻量和完整两种更新。轻量更新只动状态和日期，几秒钟就能完成，随时可做。完整更新要核对输入输出和交接点，按周期做一次。两种更新分开，日常负担就下来了。

汇总的人需要有一个固定的检查动作。在时点之后把表过一遍，看有没有该更新却没更新的行、有没有状态和日期明显对不上的行。发现之后直接去问负责人，而不是自己替他改。代人更新会破坏负责人对表的责任感。

如果连续几个周期都有某些行没人更新，说明这些行对大家没有意义。这时候有两个选择，一个是把这一行删掉，一个是把它拆得更具体。判断哪一种，看它对应的环节在实际工作里是否真的存在。

节奏稳定之后，可以考虑把更新动作往前挪一点，比如在交接发生的当下顺手把状态改掉，而不是等到固定时点补记。当场记录的成本最低，记忆最新鲜，也最不容易漏。固定时点更像是兜底，防止有人忘了当场更新。

一个实际的例子。一家店把更新节奏定成每周一早上更新状态、每周期末做一次完整核对。跑了一个季度，周一那次基本都能完成，周期末那次经常拖。他们后来把周期末的核对拆成两半，分两天做，拖延就少了。

另一个例子来自跨班次的店铺。白班和晚班各有一批人，一张表两个人填容易出现覆盖。他们的办法是每人填自己负责的行，冲突很少。真正需要共享的是全表的状态总览，那部分由汇总的人每个班次更新一次。

边界是业务波动很大的时期。大促前后各环节的动作密度都会变，这时候固定节奏可能跟不上。做法是临时加密到每天更新状态，大促结束后立刻恢复原节奏。临时加密的规则要事先说好由谁宣布，避免有人加密有人没跟。

另一个边界是人员休假。负责某一行的人休假时，那一行会停更。比较好的处理是提前指定一个临时代理人，只填状态不填判断。代理人只要知道这一段在不在动就够，不需要理解全部细节。

记录节奏本身的变化也值得做。每次调整更新节奏时写一句时间、原因、新的节奏。积累几次之后，能看出哪种节奏在自己的团队里最能落地。这个结论比照搬别人的做法要可靠得多。

越是产出结构不固定的环节，栏位越要写得松一些

表怎么用起来

表用起来的第一步是让它在开会时出现。汇报进度的时候不说大概做到哪了，直接对着表说第几行现在是什么状态。做几次之后，大家会习惯在会前把表更新一遍，表就自然进入了工作流。

第二步是把问进度这件事从口头转成看表。原来需要问一句现在到哪了，现在看一眼表就知道。这个转变看起来很小，但它把大量的同步沟通省了下来。省下来的时间通常比做表花掉的时间多得多。

第三步是把表用作排查的入口。出现对不上或者延迟时，先在表里找到对应的交接点编号，看这边和那边的状态分别是什么。多数情况下，问题能定位到某一个交接点的输入输出不一致上。

第四步是让表承担交接的功能。换人接手时，把对应的几行连同上游交付物的样例一起交出去，新的人就知道要接什么、格式是什么、找谁要。这一份交接比口头讲一遍更稳，也不容易走样。

表能不能用起来，最后看一件事，就是停下来两周会不会有人来问。如果没有人发现表停了，说明它对日常工作没有产生依赖，需要重新想想这张表到底在解决谁的什么问题。有人来问，就是它在起作用的证据。

让表进入工作流，一个有效的做法是把它的检查并入已有的动作，而不是新开一个会议。每周本来就有一次进度沟通，把表放进去过五分钟就够，不必为它单独安排时间。这样表才有机会长期存在。

另一个做法是先在一个环节上试用。选一个交接点最多的环节，只在这两行上认真填两周。跑通之后再铺到全部六行。一次全铺失败的概率比较高，因为一下子要改六个环节的习惯，很难坚持。

用起来之后要留意一种反噬，就是表变成了汇报材料。为了让表好看，有人会把状态往前赶，明明卡着也写进行中。防止这个的办法是让表只用在内部推进，不作为考核依据。表一旦和评价挂钩，填的内容就会失真。

还要留意表的用处是否被反过来用。有人可能拿表上的状态去追责别人的环节，这样会导致下游在表里少记问题。更合适的用法是把表当成找堵点的地图，看到卡住时问的是需要什么帮助，而不是谁的问题。

判断表是否真的在用，看一个指标就够了，就是表上有没有出现过往回改的状态。一张从来没有出现过往回走的表，多半是只报喜不报忧，或者更新跟不上实际。允许状态往回走，表才是可信的。

有一个可以参考的例子。一家店把表放在每周例会的第一个议题，五分钟过完全表的状态。跑了两个月之后，会议时间反而缩短了，因为原来用来互相问进度的时间被省掉了。这一项省下来的时间比填表花的多。

另一个例子是关于新人上手的。原来带新人要把流程口头讲一遍，讲完新人还是记不住。后来让新人先看表，再跟着走一轮完整的交接，上手时间缩短了不少。表在这里起到的作用是把隐性关系显性化。

边界是小团队。三五个人彼此都清楚进度的时候，表的边际价值不大，硬推反而显得多余。这类团队可以先只维护交接点编号这一项，把接口关系写清，其它栏位等到人数增加再补齐。

另一个边界是远程协作。分工在不同的地方、沟通主要靠线上时，表的作用会明显放大，因为看不见对方在做什么。这种情况下表需要更及时地更新，节奏要比同处一个办公室时更密一档。

记录这张表的使用情况也能帮助判断它有没有价值。可以简单记一下每周因为看表而省掉的询问次数、每月在表里定位到的堵点数量。这两个数字持续为正，就说明这张表在产生实际的用处。

表跑顺之后，问进度这件事本身会从日常里消失

从表到日常动作

第一类日常动作来自状态长期不动的行。某个环节连着两个周期没有变化，就应该有人去问一句为什么。这类问题不需要机制，只需要一个人固定看一眼，把不动的行挑出来，在下次会上过一遍。

第二类动作来自反复出问题的交接点。同一个交接点连续几次出状况，说明交接方式本身需要改，而不是再强调一次要认真。改的方式通常很简单，可能是把口头交代换成固定的一条消息，或者把验收条件写清。

第三类动作来自新增或消失的环节。业务调整时，表里的环节会变。新增的环节要把上游交付物和本环节产出一起补上，不要让新环节空着两栏就开始运转。消失的环节要从表里删掉，留着会让读表的人困惑。

把这三类动作固定下来，需要给它们各设一个触发条件。状态不动的触发条件是连续两个周期，交接点出问题的触发条件是连续两次，环节变化的触发条件是业务调整发生。条件写清，判断就不用每次重新讨论。

最后一步是把这些动作写进每周的固定安排。比如每周固定半小时过表和这三类动作。时间不长，但它让表不至于变成一件建完就放在那里的事。日常动作让表活下来，表又让日常动作有依据，两者是互相支撑的关系。

把三类动作落成日常，可以先定下谁来发起。状态不动的行由汇总的人挑出来，交接点反复出问题的由上下游双方一起提，环节变化的由负责这个环节的人主动填。三个来源都有人负责，就不会出现没人管的情况。

动作落成之后要有回头看的动作。这里说的检查不是加流程，而是在下一次过表时看一眼上一次决定的动作有没有被执行。执行了就看效果，没执行就问原因。执行率上不去的时候，说明决定做得太多，应该减少每次讨论的动作数量。

动作的数量要控制。一次过表挑出十几个要改的地方，最后通常一个也改不了。更可行的做法是每次只挑一到两个，做完再挑下一批。节奏慢一点，但能真正推进，比列一长串待办要好。

还要接受一种情况，就是有些堵点短期内解决不了。比如某个上游的交付能力受限于外部条件，那就把它记录在表里，写明原因和预计的时间，不要反复拿出来讨论。反复讨论一个已知无解的问题，消耗的是整张表的可信度。

长期来看，这张表会慢慢变成业务的说明书。新来的同事先看表，就知道这条链条上有哪几个环节、每个环节给下游什么东西。这份说明书的价值不在表本身，而在于它把原本只存在于几个人脑子里的关系写了下来。

有一个具体的例子。一家店在表里发现某个交接点连续三次出问题，都是因为上游漏带一个字段。他们没有再强调要认真，而是把那个字段加进了上游的模板里，问题就再没出现。这是把反复出现的问题从人身上转到结构上的过程。

另一个例子是关于状态长期不动的。有一行连续四个周期停在等上游，去问才发现上游其实早就交了，只是没有人在表里更新状态。这件事的结果是给交接加了一个动作，交完之后顺手把状态改掉，不再等固定时点。

边界是动作太多的时候。有一家店一次过表挑出了十几件要改的事，第二周一件也没做成。后来改成每次只挑一件，做完再挑。一年下来改成的数量反而更多，因为每件都真的落地了。

另一个边界是确实解决不了的问题。这类问题在表里要标注清楚，写明原因和下次评估的时间，不要每周拿出来讨论一遍。反复讨论无解的问题，会让参与的人对整张表产生疲劳，最后连能改的部分也不管了。

记录上建议给每次动作的结果写一句话。做完之后写实际变化，没做完写原因。这一句话积累起来就是这份表的运行日志。新人接手时看日志，比看表的当前状态更能理解这条链条是怎么走到今天的。

常见问题（FAQ）