工作流状态

上个月我帮一家 380 人的智能硬件公司做研发流程复盘，项目负责人打开任务看板给我看的第一样东西，是一张有 23 个状态的工作流截图。他问我一个问题：为什么我们每周都在更新状态，但…

去年我帮一家 420 人的硬件加软件混合研发组织做流程盘点，第一周就撞上一个反常识的数据：他们的项目管理系统里配置了 23 个任务状态，但翻完最近 3000 条任务的变更日志，真正…

我做过一次事后被同事称为“状态考古”的复盘：一个 270 人的研发组织，项目管理平台里累计存在 47 个自定义状态，其中 11 个在最近 90 天里没有任何一次流转记录，6 个状态…

2023 年我接手过一个挺典型的烂摊子：一家做工业 SaaS 的公司，研发团队 180 人，项目管理平台里躺着 11 个工作流状态。从「需求池」到「已关闭」，中间塞了「待评审」「评…

大多数研发团队的状态设计，不是从业务出发，而是从一次会议里的抱怨出发，"这个需求到底在谁手上？"于是有人加了一个状态叫"待联调"，过两周又加…

我给一家 180 人的研发组织做流程诊断时，第一个要的不是需求文档，而是他们的状态列表。他们给了我 14 个：待评审、评审中、待排期、已排期、开发中、开发完成、提测中、测试中、测试…

很多产品经理第一次认真思考“状态”这件事，往往是在一次协作事故之后。我印象很深的一个案例：一个 30 人左右的 SaaS 团队，需求列表里只有“待处理 / 处理中 / 已完成”三个…