[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"knowledge-category-pm-methodology":3,"knowledge-article-pm-methodology-agile-landing-2026":8,"knowledge-related-pm-methodology":19},{"id":4,"name":5,"slug":6,"description":7},"6ac6bafb-d4b9-4bb5-af5b-0445a490bb59","项目管理方法论","pm-methodology","项目管理方法论：敏捷、瀑布、看板、IPD、PMO 与需求管理的完整方法体系",{"id":9,"category_id":4,"title":10,"slug":11,"summary":12,"reading_time":13,"view_count":14,"content_html":15,"content_json":16,"published_at":17,"updated_at":18,"module":16},"37512f3e-3b8b-41b8-9d96-446cdcd5b83f","敏捷落不了地，是因为你的系统只认一种方法论","agile-landing-2026","方法论是参考不是教条。74% 的团队早已改用混合或自研的敏捷，系统却还在假设全世界只跑一种方法论。拆四个方法论和业务场景对不上的例子，再用智序项目管理系统的功能回答三个问题：需求怎么管、任务怎么管、迭代怎么管。",8,2,"\u003Cp style=\"background:#f5f3ff;border-left:4px solid #7c3aed;padding:14px 18px;color:#4c1d95;font-size:15px;line-height:1.8;\">全文约 3200 字，阅读约 8 分钟。\u003Cbr>重点内容：74% 的团队早就改用混合或自研的敏捷，系统却还在假设全世界只跑一种方法论。拆四个方法论和业务场景对不上的真实例子，再回答用敏捷开发软件产品时最实际的三个问题：需求怎么管、任务怎么管、迭代怎么管。\u003C\u002Fp>\n\n\u003Cimg src=\"\u002Fimages\u002Fagile-cover.png\" alt=\"敏捷落不了地，是因为系统只认一种方法论\" \u002F>\n\n\u003Cp>先讲一个常见的画面。\u003C\u002Fp>\n\n\u003Cp>公司下定决心上敏捷。站会排进日历，迭代定成两周，看板贴到墙上，工具也买了，培训也做了。三个月后回头看：需求该延期还是延期，缺陷还是堆在测试阶段，唯一的变化是大家每天多花二十分钟更新卡片。更别扭的是几个具体场景。线上一个按钮颜色错了，开发说五分钟改完，流程上它得先开需求单、排进迭代、过评审、等发布窗口。硬件外包那边更懵，对方按打样、试产、认证的节点报进度，系统里只有「本迭代还剩几个故事点」这一种语言，两边对不上，最后各自记各自的账。\u003C\u002Fp>\n\n\u003Cp>工具没少买，培训没少做，为什么落不了地？我的判断很直接：不是团队不行，是系统默认全世界只跑一种方法论。而真实世界早就不是这样了。\u003C\u002Fp>\n\n\u003Ch2>方法论是参考，不是教条\u003C\u002Fh2>\n\n\u003Cp>先看几组数据。Digital.ai 第 18 期 State of Agile 报告（2025 年）里，74% 的团队说自己在用混合、融合或者自己改过的敏捷模式，其中 48% 是混合，26% 干脆是自研。VersionOne 同年的敏捷状态调查里，52% 的组织同时用敏捷和瀑布。Scrum.org 2025 年的数据说全球 68% 的敏捷团队用 Scrum，但同一批从业者也承认，Scrum 越来越多是跟看板、DevOps 组合着用，很少单独扛全场。\u003C\u002Fp>\n\n\u003Cp>翻译一下：绝大多数团队根本没在跑「完整的敏捷」。这不是执行力问题，是业务场景决定的。\u003C\u002Fp>\n\n\u003Cp>举四个例子，都是方法论和场景对不上的典型。\u003C\u002Fp>\n\n\u003Cp>第一个，软硬混合的团队。这类公司软件自研、硬件外包，内部其实是两种节奏。软件两周一个迭代，跑得挺顺；硬件那边的节奏是结构设计、打样、试产、认证，一环扣一环，改一次硬件不光是人月的事，模具周期和认证排期都摆在那。你让硬件团队跟着软件的两周迭代走，他们每个迭代末都交不出「可演示的增量」，几次之后看板就成了形式。反过来让软件干等硬件的节点，又白白丢掉快速试错的机会。做安全关键系统的团队更极端，需求可以迭代着拆，但验证与确认那套合规义务装不进两周冲刺，只能按节点交付。\u003C\u002Fp>\n\n\u003Cp>第二个，强合规的行业。金融、医疗的团队都懂：需求要冻结，变更要评审，全程要留痕，审计说来就来。敏捷宣言说「响应变化高于遵循计划」，合规体系说「计划外不留痕就不能上线」。这不是谁对谁错，是约束条件不同。Forrester 2025 年的调研把这事说得很明白：需求高度不确定、技术路径清楚的项目，敏捷优势最大；需求稳定、合规要求严的项目，瀑布那套文档和审批反而更可靠。IBM 2025 年的系统开发报告也提到，瀑布模式在大型基础设施项目里的按时交付率能到 72%。需求早就锁死、改一次代价巨大的项目，硬套敏捷才是真风险。\u003C\u002Fp>\n\n\u003Cp>第三个，小改动和运维工单。线上一个文案错了、一个按钮颜色不对，改完五分钟，验证十分钟。为它开需求单、排迭代、过评审，流程成本是修改本身的一两百倍。我见过最真实的后果：团队学会绕过系统，直接找开发改，系统里的数据越来越假，看板上的完成率和真实进度脱钩。Digital.ai 那份报告里有个数字很应景：53% 的团队承认自己没法可靠地排优先级，因为底层数据不可信；52% 说没法有效衡量业务结果。工具里的数据假了，比没有工具更糟。\u003C\u002Fp>\n\n\u003Cp>第四个，制造业的打样环节。钧森包装做定制包装，一个项目要过客户需求澄清、结构设计、打样测试、工艺评审、量产上线。打样错了，模具费直接打水漂，客户还不一定给第二次机会。这种项目的关键路径在物理世界，模具周期以周计，敏捷的两周迭代对不上这个节拍。他们后来把研发全流程收进一套系统，89 人全拉进去，人数不封顶（完整案例见\u003Ca href=\"\u002Fknowledge\u002Fcustomer-cases\u002Fcase-junsen-packaging-pms\">钧森包装落地实录\u003C\u002Fa>）。注意，他们用的不是一个「敏捷项目」的模子，是一套能装下打样、评审、量产节点的流程。\u003C\u002Fp>\n\n\u003Cp>四个例子指向同一件事：方法论和业务场景之间永远有偏差，因为方法论是通用解，业务是具体题。正确的用法是取骨架，不取全尸。迭代的节奏感可以留，站会和回顾这些仪式该砍就砍；门禁、评审、留痕该有还得有，别拿「敏捷」当不走流程的挡箭牌。说白了，方法论为业务让路，不是业务为方法论鞠躬。\u003C\u002Fp>\n\n\u003Cimg src=\"\u002Fimages\u002Fagile-scenarios.png\" alt=\"一种方法论，四种套不进去的场景\" \u002F>\n\n\u003Cp>这就对工具提了一个硬要求：系统得装得下多种方法论。同一家公司，A 项目跑 Scrum，B 项目走瀑布门禁，C 项目就是看板加工单，本该在同一个系统里并存。方法论变了，改配置就能跟上；改个流程就得换系统，那不是工具，是枷锁。\u003C\u002Fp>\n\n\u003Ch2>用敏捷开发软件产品，三个最实际的问题\u003C\u002Fh2>\n\n\u003Cimg src=\"\u002Fimages\u002Fagile-flow.png\" alt=\"需求、任务、迭代怎么流\" \u002F>\n\n\u003Cp>说完方法论，说工具。假设你的团队是典型场景：用敏捷方法论开发软件产品，需求会变、按迭代交付。这时候研发项目管理平台到底怎么用？三个问题分别说，拿智序 ORDR 项目管理软件的功能逐个对照。不是替谁做广告，是它的模块恰好按需求、任务、迭代划分，对照起来清楚。\u003C\u002Fp>\n\n\u003Ch3>需求怎么管：不是所有需求都进迭代\u003C\u002Fh3>\n\n\u003Cp>很多团队的需求管理乱在入口。客户在销售那，销售在微信里，支持在工单里，产品经理在文档里，最后谁嗓门大谁先进迭代。智序项目管理系统的做法是先把需求收到一个池子里。免费版用产品需求矩阵，把产品侧的需求和项目工作项对上，需求落到工作项，谁负责、什么状态，一眼看得见。上了旗舰版，需求池把这套走全：收集（客户、销售、支持、内部都往一个口子丢）、分解（大字拆成能估点的小条）、分发（该进迭代的进迭代，该排期的排期）、矩阵（正向反向追溯，哪个需求在哪个版本，覆盖率有没有缺口）。\u003C\u002Fp>\n\n\u003Cp>特别要说一下变更。需求变了不怕，怕的是改了没人知道。需求池里的 CCB 变更把这件事管住：谁提的、影响什么、批了还是驳了、落在哪个版本，全程留痕。软件项目最大的返工来源不是「改需求」，是「改需求没留痕」，三个月后没人说得清当时为什么这么定。免费版也有 RTM 追溯矩阵，需求到工作项到测试双向对，哪条需求没用例覆盖，缺口直接列出来，不用等测试阶段才发现。\u003C\u002Fp>\n\n\u003Ch3>任务怎么管：全公司只有一套语言\u003C\u002Fh3>\n\n\u003Cp>需求定了，进迭代变成工作项。我的建议是全公司只有一套编号体系：需求、任务、缺陷、用例、发布，一个工作项从提出到上线编号不变，走到哪一步都能查。智序项目管理软件的工作项就是这个设计，需求、任务、缺陷能互相关联，测试失败一键转缺陷，不是另起一摊。\u003C\u002Fp>\n\n\u003Cp>状态流转走可配置的工作流，不是写死的。想加一个「待客户确认」的状态，配置里加上，不用等厂商发版。看板上按状态列拖卡片，评论、附件、活动日志都挂在具体工作项上，谁改了什么、什么时候改的，翻记录就有。站会不用另维护一张表，对着看板的列问谁卡住就行。\u003C\u002Fp>\n\n\u003Ch3>迭代怎么管：看板、燃尽图，和一句实话\u003C\u002Fh3>\n\n\u003Cp>迭代三件套：规划、看板、燃尽图。规划阶段把工作项分进本轮，按需求和容量定范围，会中加塞也留在迭代里，不另开一张表。看板按待处理、进行中、已完成分列，拖拽改状态。燃尽图画两条线，理想燃尽和实际剩余，是服务端按真实进度算的，没有工作项或者没填起止日期的时候它直接说生成不了，不编一条假曲线糊弄你。逾期和未关缺陷也不用等周会，先出现在工作台的 AI 预警里。\u003C\u002Fp>\n\n\u003Cp>真跑起来是什么效果，看 xxVR 的案例。做 VR 培训的创业公司，25 个研发，两个月把 Sprint 交付稳定率从 60% 拉到 92%。他们的路子没什么玄的：需求进池子、范围写进迭代、状态看板拖、偏差看燃尽图，一套笨办法坚持跑（案例见\u003Ca href=\"\u002Fknowledge\u002Fcustomer-cases\u002Fxxvr-agile-transformation-case\">xxVR 敏捷落地复盘\u003C\u002Fa>）。\u003C\u002Fp>\n\n\u003Cp>还有一句实话：不是所有项目都要迭代。智序项目管理软件的敏捷方案页有一句 FAQ 原话，「只有看板、没有 Scrum 行不行？行。」迭代看板按状态列拖拽，不强制两周一次 Sprint。同一套系统里，四种内置模板（瀑布、敏捷、混合、通用）并存，按项目切换；旗舰版还能自定义项目模型、工作流和字段模板，官网管这个叫「不被工具模板绑架」。一个公司几种项目并存，本来就是常态。\u003C\u002Fp>\n\n\u003Ch2>先数数你有几个项目在假装敏捷\u003C\u002Fh2>\n\n\u003Cp>写到这，结论已经不新鲜了：方法论是参考不是教条，系统要能装下多种方法论，敏捷开发软件产品就管好需求、任务、迭代三件事。难的是迈第一步。\u003C\u002Fp>\n\n\u003Cp>我的建议很具体：这周回去数一数，你的系统里有多少个项目在假装敏捷。判断标准就一条，那个项目的人愿不愿意照系统的流程干活，不愿意，就是在假装。数完先别慌，挑最别扭的那个，换种跑法试一周：该走门禁的走门禁，该看板的看板，该砍的仪式砍掉。\u003C\u002Fp>\n\n\u003Cp>工具上，智序项目管理系统的终身免费版不限人数、可以私有部署，迭代、看板、燃尽图、工作项、测试、AI 预警都在里面，先拿一个真实项目跑两轮，比买十个授权压着全员用实在。需求池、CCB、甘特这些，等真需要了再升级，官网自己都写了「没有这些，不写成敏捷标配」，这个态度我认可。选型前也可以看看我们之前盘过的\u003Ca href=\"\u002Fknowledge\u002Fbest-practices\u002Ftop10-pm-software-2026\">2026 年项目管理软件横向对比\u003C\u002Fa>，十款逐个对比过，比听销售讲一小时靠谱。\u003C\u002Fp>\n\n\u003Cp>方法论是死的，业务是活的。系统跟不上业务的节奏，先动系统，别动业务。\u003C\u002Fp>\n\n\u003Cp class=\"article-infringement\">如有侵权请与我们联系\u003C\u002Fp>",null,"2026-10-22T01:19:49.537928+00:00","2026-10-22T01:19:50.706059+00:00",[20,27,34,40,45,50,56,62,67,72,77,82,87,93,98,103,108,113,118,123,128,134,139,144,149,154,160,165,170,171],{"id":21,"category_id":4,"title":22,"slug":23,"summary":24,"reading_time":25,"view_count":26,"module":16},"9b26fa81-b66b-4a35-b4d2-99a788835f24","敏捷 vs 瀑布：如何选择适合你团队的项目管理方法","agile-vs-waterfall","敏捷和瀑布到底怎么选？不是非此即彼。Standish Group 跟踪 5 万多个项目发现：敏捷成功率 42%、瀑布只有 13%。本文给你 3 个判断标准和最容易被忽略的混合用法。",3,4,{"id":28,"category_id":4,"title":29,"slug":30,"summary":31,"reading_time":32,"view_count":33,"module":16},"bf169d74-4c21-49db-ab37-ce1851c40c11","华为 IPD 流程能直接抄吗？中小企业落地的 5 个变形","huawei-ipd-5-adaptations","华为 IPD 那套 2500 多个流程文件，中小企业照抄成功率不到三成。这篇不讲虚的，讲清楚哪些该抄、哪些该砍，落地时的 5 个变形——组织、流程、评审、文档、工具，全往轻里改。",6,5,{"id":35,"category_id":4,"title":36,"slug":37,"summary":38,"reading_time":13,"view_count":39,"module":16},"91bdfa68-2dc1-4bf1-82b8-32d60b6359d0","产品经理的需求池与迭代管理实战","pm-requirement-pool","需求不进池子，就等于不存在。本文讲产品经理如何用需求池+迭代，把杂乱诉求变成可交付的版本。",1,{"id":41,"category_id":4,"title":42,"slug":43,"summary":44,"reading_time":13,"view_count":25,"module":16},"873b1b54-ca7b-4ea7-b41c-a27d3f39f979","项目计划怎么做才不失控：不是变化太快，是计划没做对","how-to-make-project-plan","PMI Pulse 2018 调研显示，65% 的项目没达成原始目标，规划不当是头号原因；52% 的项目经历过范围蔓延，平均成本超支 27%。做好项目计划的四件事：目标拆到能执行、排期留缓冲、管住范围蔓延、标清依赖和检查点。",{"id":46,"category_id":4,"title":47,"slug":48,"summary":49,"reading_time":13,"view_count":39,"module":16},"33b1ab6e-de87-4c63-bcd3-72ec1f364df0","项目进度管理怎么做：先承认人算不准时间","project-progress-management","Standish CHAOS 2020 显示只有 31% 项目按时完成，带病完成项目平均耗时是原计划的 222%；计划谬误研究表明 99% 置信的截止日期只有 45% 的人真正完成。进度管理的关键不是把估算做准，而是拆到里程碑、把进度摊开、让风险自己冒出来。",{"id":51,"category_id":4,"title":52,"slug":53,"summary":54,"reading_time":55,"view_count":14,"module":16},"09ff93ce-095f-4952-b82a-fc35c7ddf026","IPD 项目管理软件：集成产品开发怎么落地（中小企业视角）","ipd","IPD 不是流程图，是华为花 40 亿买的决策机制。中小企业落地抓需求端到端+阶段评审两条就够，别照搬全套。",0,{"id":57,"category_id":4,"title":58,"slug":59,"summary":60,"reading_time":61,"view_count":39,"module":16},"eb92f2fd-c566-47f3-aba3-54dd6b1cede0","瀑布项目管理系统：传统项目管理怎么做","waterfall-pm-software","瀑布模型不是老古董，金融、政务、硬件开发离不了它。本文讲清什么项目该用瀑布、五阶段怎么走、变更怎么管不乱，附选工具的几个要点。",7,{"id":63,"category_id":4,"title":64,"slug":65,"summary":66,"reading_time":13,"view_count":14,"module":16},"b2fb05df-4f54-4c6d-9b39-5002113a11a8","敏捷研发项目管理软件与系统：研发团队怎么落地（Scrum+看板）","agile-dev-pm-software","敏捷研发项目管理软件怎么选、怎么落地？Scrum 和看板在研发团队的实际跑法，选工具盯这四个点。",{"id":68,"category_id":4,"title":69,"slug":70,"summary":71,"reading_time":13,"view_count":61,"module":16},"99fc8bce-de45-4ffc-9550-335935b0e59f","IPD 到底是什么？一文讲透集成产品开发的 6 个核心阶段","ipd-6-stages","IPD 不是华为专属，也不只是一张流程图。这篇把集成产品开发讲成人话：它到底在解决什么、6 个阶段各自卡在哪、中小企业落地最容易踩的几个坑，看完能判断自己的团队适不适合上 IPD。",{"id":73,"category_id":4,"title":74,"slug":75,"summary":76,"reading_time":32,"view_count":14,"module":16},"e0e616fa-6d62-4bf5-b843-4c51382cec87","项目经理最常踩的 5 个坑：踩中一个项目就延期","pm-5-pitfalls","项目经理的常见痛点就五个：需求说不清、节点守不住、沟通断、知识留不住、优先级乱。Standish、PMI 的公开数据能证明每个坑都能把项目拖到延期，这篇逐个拆开讲，附真实案例和止血办法。",{"id":78,"category_id":4,"title":79,"slug":80,"summary":81,"reading_time":61,"view_count":26,"module":16},"94dc2585-1c85-4bdc-a4fc-302791a2fd32","IPD 和项目管理到底有什么区别？制造企业最容易踩的 3 个坑","ipd-vs-pm","太多制造企业把 IPD 当成高级版项目管理来推，这本身就是第一个坑。本文用真实案例拆解 IPD 与项目管理的本质区别，以及制造企业落地最容易踩的 3 个坑。",{"id":83,"category_id":4,"title":84,"slug":85,"summary":86,"reading_time":25,"view_count":25,"module":16},"9d3d891d-1211-48f0-8853-1d77ab332f14","研发团队如何用看板+敏捷管好需求与缺陷","rnd-kanban-agile","2024 State of Agile：71% 组织在软件研发中用敏捷，看板是使用率最高的规划工具（77%）。但多数团队只把看板当高级待办清单。本文给一套让需求与缺陷真正流动起来的落地方法。",{"id":88,"category_id":4,"title":89,"slug":90,"summary":91,"reading_time":92,"view_count":55,"module":16},"6b9f5810-f801-431b-8b36-543a3ea8f4c2","PMO 如何管理多个并行项目（项目组合方法论）","pmo-multi-project","PMO 的难题不是管一个项目，而是让十几个项目在资源、优先级、风险上不打架。本文给一套项目组合管理框架。",9,{"id":94,"category_id":4,"title":95,"slug":96,"summary":97,"reading_time":33,"view_count":39,"module":16},"e6605c92-e3f7-4c2b-8341-09c4339232c7","需求怎么管理：从需求池到落地的完整方法","how-to-manage-requirements","需求管理不是记清单，而是统一收口、优先级排序、与迭代打通的系统工程。一文讲清需求怎么管理。",{"id":99,"category_id":4,"title":100,"slug":101,"summary":102,"reading_time":25,"view_count":14,"module":16},"6e2ef9fa-fea2-4264-ba41-17373ab5d307","产品需求管理：PRD 之外，如何让需求真正落地","product-requirement-management","Standish CHAOS 报告把「不完整需求」列为项目失败首要原因（13.1%）。本文给一套从用户洞察到上线验证的需求管理落地动作，重点讲透验收标准。",{"id":104,"category_id":4,"title":105,"slug":106,"summary":107,"reading_time":33,"view_count":33,"module":16},"e765dbaf-7d85-4f89-acb7-7ce18a2e3eb3","IPD 管理是什么：华为花 40 亿买来的教训","ipd-management","华为 1998 年花 5.6 亿引入 IBM 的 IPD 体系，十年总投入 40 亿，高端产品上市周期从 70 个月压到 20 个月。但 90% 的中小公司其实不适合照搬 IPD。",{"id":109,"category_id":4,"title":110,"slug":111,"summary":112,"reading_time":32,"view_count":14,"module":16},"6f0c298a-1fa0-4c42-b3da-7f0329a86c09","项目总是延期，问题到底出在哪？真凶大半不是技术","pm-delay-causes","项目延期极少死在技术，多半死在需求没定清、范围蔓延、工期拍脑袋、沟通断层这四件事。Standish 2020 说软件项目只有 31% 能按时按预算交付，PMI 2023 说 37% 的项目失败直接挂钩需求变更频繁。附真实翻车案例和三步止损顺序。",{"id":114,"category_id":4,"title":115,"slug":116,"summary":117,"reading_time":33,"view_count":33,"module":16},"50f2893d-02b3-4094-a554-085b903fa0c5","需求反复变更，怎么控住不蔓延","scope-creep-control","需求反复变更会把项目拖成无底洞。泰国一个仓库系统，功能从 20 个膨胀到 67 个，预算从 280 万涨到 620 万泰铢，工期从 4 个月拖到 11 个月。根子不是客户贪心，是你每次变更都免费接。给变更设一道「要付钱」的坎，再配一张变更请求单、先算工期预算质量三笔账，范围蔓延能拦下大半。",{"id":119,"category_id":4,"title":120,"slug":121,"summary":122,"reading_time":33,"view_count":25,"module":16},"9e98f3e4-fb69-45bd-bb97-1426592fdc52","敏捷 Scrum 怎么在研发团队真正落地（不是开站会那么简单）","scrum-dev-team","Scrum 落地最大的坑，是站会开成了汇报会。只有 44.7% 的开发者觉得站会有用，一个 15 分钟的站会真实成本是 38 分钟。落地第一步：团队拆到 6-8 人，站会改成「谁卡住了、要谁帮」，Sprint 别当承诺用，每个迭代只改一个地方。",{"id":124,"category_id":4,"title":125,"slug":126,"summary":127,"reading_time":13,"view_count":39,"module":16},"7ff48a5a-a9b3-4a77-ba28-42fcc70a0af2","软件项目和硬件项目到底区别在哪里？","software-vs-hardware-project","软件项目和硬件项目到底差在哪？硬件改一次错误可能要重新投板、重开模具，单次变更成本随阶段从几千元飙到几十万元；软件改一次就是一次 redeploy。这条成本曲线决定了两套项目不能用同一套管理模板。",{"id":129,"category_id":4,"title":130,"slug":131,"summary":132,"reading_time":133,"view_count":39,"module":16},"e252590c-b111-4b30-87bb-3673b882e65b","2026年还需要敏捷研发管理吗？94% 在做，只有 16% 做对","agile-rd-management-2026","敏捷没死，死的是照本宣科那套仪式。2026年真正要回答的是怎么把敏捷落到研发管理上，AI进来以后该砍的仪式得砍。",12,{"id":135,"category_id":4,"title":136,"slug":137,"summary":138,"reading_time":33,"view_count":55,"module":16},"9cd53804-338c-49df-a1b0-154ab278f457","需求管理怎么做？从需求池到验收闭环，别再把需求当一次性文档","requirement-management-pool-to-acceptance","七成项目失败根子在需求。需求池要当过滤层用，需求变更必须过闸门，验收要回写需求池才形成闭环。附三个真实烂尾账本。",{"id":140,"category_id":4,"title":141,"slug":142,"summary":143,"reading_time":32,"view_count":55,"module":16},"9a166304-7a61-45f7-87cc-409e6dfe7acf","市场部项目怎么做？活动、投放、内容排期别再各管各的","marketing-department-project-management","市场部最怕活动、投放、内容三摊事各管各的，临上线前撞车。用看板、死线、单一事实源把三摊事串到同一条时间轴上，少踩坑。",{"id":145,"category_id":4,"title":146,"slug":147,"summary":148,"reading_time":32,"view_count":39,"module":16},"bea90647-8a3b-4cb0-ad0d-3fb24b9c3033","项目一多就延期？大型集团多项目管理，资源队列才是真凶","multi-project-resource-queue","多项目管理管不下来，根子不在进度表而在资源排队。需求容量比、上下文切换成本、在制品限流，三个数字讲清多项目的资源治理。",{"id":150,"category_id":4,"title":151,"slug":152,"summary":153,"reading_time":32,"view_count":55,"module":16},"d39d8d54-2eec-4c57-a13a-b4a06c029afb","工时统计为什么永远对不上？三个漏点加一个新盲区","timesheet-accuracy","计划外动作没入口、审批链比任务链还长、事后凭记忆补，这三个漏点让工时数据天然失真。叠加 AI 相关的隐性工作没被度量，工时统计对不上是流程问题，不是员工不诚实。文末给出三条可落地的修法与工具对比。",{"id":155,"category_id":4,"title":156,"slug":157,"summary":158,"reading_time":32,"view_count":159,"module":16},"3cb958ad-bbc1-4b24-8e53-fe9122b1c106","工时统计为什么永远对不上？四个根因和三步补救","timesheet-mismatch-why","工时表和财务对账总差三成？四个根因拆解+三步补救顺序，先修口径再动工具。",22,{"id":161,"category_id":4,"title":162,"slug":163,"summary":164,"reading_time":32,"view_count":39,"module":16},"61f35806-4b89-4e43-aff4-4246d9cdd30e","研发团队工时数据怎么用，才不会变成考核武器","timesheet-data-not-weapon","工时表最危险的一刻是它准的那一刻，数据一准就会被拿去做排名，一排名就开始假。本文讲清为什么管理者忍不住用工时排名、排名之后数据怎么失真，以及正确的四个用法：找偏差、看阻塞、算资源、算账。",{"id":166,"category_id":4,"title":167,"slug":168,"summary":169,"reading_time":32,"view_count":39,"module":16},"902085ea-9f80-4ecc-aacd-7f09f0cd2e07","项目风险管理怎么做：九成登记册活不过一个月，问题出在哪","project-risk-management","CHAOS 2020 显示近七成项目没有完全成功，可多数团队的风险登记册活不过一个月。本文拆登记册四大死法：没人看、写成话题、只评一次分、没有触发信号，给出七列字段、机械升级规则和周评审节奏的落地做法。",{"id":9,"category_id":4,"title":10,"slug":11,"summary":12,"reading_time":13,"view_count":14,"module":16},{"id":172,"category_id":4,"title":173,"slug":174,"summary":175,"reading_time":39,"view_count":39,"module":16},"f464f734-2f26-40a2-b840-4553d750d7da","从混乱到有序：中小团队项目管理流程搭建指南","small-team-workflow-setup","中小团队项目管理流程搭建的四个原则和五个步骤。从需求收集到Sprint回顾，帮助15人以下团队用最小的流程成本实现最大的管理收益。"]