一份实用指南，教你围绕团队真实的工作交付方式来搭建项目管理系统：为什么通用项目工具最终无人使用、如何还原你真实的阶段和交接、第一版需要什么，以及如何不开例会就看清在进行中的工作。
交付流程无法套用现成项目工具的代理公司、创意团队、承包商、产品团队和服务型企业。
- 一套建立在你真实交付阶段和交接之上的项目模型
- 一个能取代例会的在进行中工作视图
- 一套可以随着交付流程变化而随时重塑的系统
大多数团队都试过项目管理工具，最后又退回到表格和聊天软件。问题不在工具本身，而在于是否贴合。通用项目工具会强加一种固定形态，也就是把任务摆进一列列的看板，而你的交付本身有自己的形态：你的阶段、你的审批、你的交接。当工具和你真实的交付方式对不上时，更新它就变成了无谓的例行工作，然后它就悄悄地被荒废了。这份指南要讲的，就是如何搭建一套真正贴合的系统，让它能一直用下去。
因为它们强加了一种通用形态，通常就是任务在一列列看板之间移动，而你的交付有自己特定的阶段、审批和交接，套不进去。于是大家只是为了应付管理层而维护这个工具，真正的协调却发生在聊天里，工具的信息越来越陈旧，最后它变成了一个需要额外更新的地方，而不是大家该去查看的地方。一套项目系统只有在它的阶段就是你的阶段、用的就是你自己的说法时，才能真正用得下去。
有一个很典型的信号：工具上写着某个项目处于「进行中」，可所有人都知道它其实是「在等客户提供素材」，而这个状态工具里根本没有对应的名字。每一个缺失的状态都是一个小小的谎言，一块布满小谎言的看板没人会信，于是也就没人愿意去维护它。解药不是要求大家更自律，而是一套阶段与现实一致的系统，其中要包含那些工作真正卡住的尴尬等待状态。
正因如此，先把你的交付流程描述清楚、再围绕它来搭建系统，要胜过去配置别人的模板。那些阶段、审批节点和交接才是核心产物，而它们和你的具体工作方式紧密相关。
在做任何看板之前，先还原最近几个项目从开始到完成到底是怎么走的，包括它们在哪里卡住过。你要提取的，是你交付流程的真实形态。
有一家设计工作室，总是把项目丢在「已发给客户」和「客户已回复」之间的空档里，工作在那儿一放就是好几天，既没有负责人，也没有可见的计时。诚实地建模之后，他们的流程其实有八个阶段，其中三个是等待状态，而真正的关键功能不过是给等待状态配上一个计时器，让一个在「等待客户反馈」里卡了一周的项目直接变红，而不是躲在一个笼统的「进行中」列里。别的什么都没改，准时交付率就明显提高了。
项目工具膨胀的速度几乎比任何其他类型都快：工时统计、开票、资源规划、客户门户、依赖关系。第一版应该是能让工作变得可见、并且在往前推进的最小集合。
周而复始的状态例会之所以存在，是因为状态在任何地方都看不见；大家聚在一起，只为口头说出一套好系统本该直接呈现的东西。项目系统的目标，是让这场例会变得没有必要，而不是再加一个大家在会上讨论的工具。
当任何人都能打开一个视图，看到每个项目、它的阶段、它的负责人，以及它已经搁置了多久时，你就做到了。带计时器的等待阶段，能把无声的停滞变成看得见的停滞；一个在「客户评审」里放了八天的项目会自己冒出来，于是对话从「发现问题」变成了「做出决定」。当看板可信且实时时，例会就会缩减到那几件真正需要讨论的事，往往干脆就消失了。
要让系统一直可信，取决于两件源自「自己拥有它」的事：看板与现实一致，因为里面的阶段就是真实的阶段；而且它能一直保持一致，因为当交付流程演变时，你可以自己去改这些阶段。一套围绕你的工作流搭建、不用提工程工单就能自己重塑的项目系统，才是团队愿意一直更新的系统，因为它终于把工作的真实情况如实说了出来。
因为工具强加了一种通用形态，通常是把任务摆进一列列看板，它和你真实的交付阶段、审批和交接对不上。大家只是为了应付管理层而维护它，真正的协调却留在聊天里，于是信息越来越陈旧。一套系统只有在它的阶段就是你真实的阶段、包括工作真正卡住的等待状态时，才能真正用得下去。
还原最近几个项目实际是怎么走的，包括它们在哪里卡住过，然后用你自己的说法把真实阶段命名出来：已接单、设计中、客户评审、修改中、已批准，等等。关键是要包含像「等待客户反馈」这样的等待状态，因为那正是工作在通用工具里藏身的地方。
项目处在一个清晰的真实阶段里、每个项目和阶段都有一位负责人、一个按阶段呈现所有在进行中工作的统一视图，以及明确的交接，让下一位负责人不用收到聊天消息也能知道。工时统计、开票和依赖关系都可以留到第二版。
很大程度上可以。这场会之所以存在，是因为状态在任何地方都看不见。当一个可信的视图展示出每个项目、它的阶段、它的负责人，以及它已经搁置了多久，并给等待阶段配上计时器时，例会里「发现问题」的那部分就消失了，只剩下真正需要决策的事。前提是看板必须实时且真实，而这来自你自己拥有并塑造它。