[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"navbar-knowledge-categories":3,"contact-config-global":54,"knowledge-category-pm-methodology":64,"knowledge-article-pm-methodology-scrum-dev-team":65,"knowledge-related-pm-methodology":75},[4,9,14,19,24,29,34,39,44,49],{"id":5,"name":6,"slug":7,"description":8},"a6913f07-4f69-410b-894b-8ad485fe9d3d","行业资讯","industry-news","行业最新动态、趋势分析与政策解读",{"id":10,"name":11,"slug":12,"description":13},"6ac6bafb-d4b9-4bb5-af5b-0445a490bb59","项目管理方法论","pm-methodology","项目管理方法论：敏捷、瀑布、看板、IPD、PMO 与需求管理的完整方法体系",{"id":15,"name":16,"slug":17,"description":18},"dcfce6aa-bc09-43ec-94f8-0e4a68f91c17","销售管理方法论","sales-methodology","销售管理方法论：客户管理、销售流程、线索转化与业绩增长的方法体系",{"id":20,"name":21,"slug":22,"description":23},"9550a30f-0d03-4425-b270-6bdc5544a497","企业经营方法论","business-methodology","企业经营方法论：协同办公、流程规范与中小企业经营管理的实践方法",{"id":25,"name":26,"slug":27,"description":28},"9e41a50e-d63b-416b-bfc1-c1fdcce39956","最佳实践","best-practices","项目管理实战经验、技巧与案例分享",{"id":30,"name":31,"slug":32,"description":33},"8fa2b13d-ac6f-420f-b632-e0bca16f3cf9","客户案例","customer-cases","各行业客户成功案例与解决方案",{"id":35,"name":36,"slug":37,"description":38},"930cf125-4c2f-4350-92cc-bb569725b168","PMS 产品手册","pms-manual","智序PMS 项目管理功能说明与操作指南",{"id":40,"name":41,"slug":42,"description":43},"fbaf7f73-3fed-4a15-a09c-ddaec190d761","CRM 产品手册","crm-manual","智序CRM 客户关系管理功能说明与操作指南",{"id":45,"name":46,"slug":47,"description":48},"5673a7c8-936f-4e17-a38e-e0eff8cb87fe","OA 产品手册","oa-manual","智序OA 协同办公功能说明与操作指南",{"id":50,"name":51,"slug":52,"description":53},"3d13795b-1858-4000-9255-95ca2df96abe","产品知识","product-knowledge","产品功能介绍",{"id":55,"scope":56,"page_key":57,"phone_label":58,"phone_number":59,"wechat_label":60,"wechat_id":61,"wechat_qr_url":62,"enabled":63,"created_at":55,"updated_at":55},"","global",null,"罗经理","15221020919","微信咨询","lhmopms","\u002Fwechat-qr-official.png",true,{"id":10,"name":11,"slug":12,"description":13},{"id":66,"category_id":10,"title":67,"slug":68,"summary":69,"reading_time":70,"view_count":71,"content_html":72,"content_json":57,"published_at":73,"updated_at":74,"module":57},"9e98f3e4-fb69-45bd-bb97-1426592fdc52","敏捷 Scrum 怎么在研发团队真正落地（不是开站会那么简单）","scrum-dev-team","Scrum 落地最大的坑，是站会开成了汇报会。只有 44.7% 的开发者觉得站会有用，一个 15 分钟的站会真实成本是 38 分钟。落地第一步：团队拆到 6-8 人，站会改成「谁卡住了、要谁帮」，Sprint 别当承诺用，每个迭代只改一个地方。",5,1,"\u003Cdiv style=\"background:#fdf8ee;border:1px solid #e6c97a;border-radius:8px;padding:16px 20px;margin:16px 0;\">\n\u003Cp style=\"margin:0 0 6px;font-size:15px;color:#8a6d1a;\">\u003Cstrong>全文约 1900 字，阅读约 5 分钟。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp style=\"margin:0;font-size:15px;color:#333;\">\u003Cstrong>重点内容：\u003C\u002Fstrong>Scrum 落地的坑不在流程，在站会开成了汇报会。真正有用的站会是「谁卡住了、要谁帮」，不是「我昨天干了啥」。落地第一步：团队拆到 6-8 人，站会砍到 10 分钟，每个迭代只改一个地方。\u003C\u002Fp>\n\u003C\u002Fdiv>\n\n\u003Cp>有个数字我第一次看到时不太信：只有 44.7% 的开发者觉得每日站会有用。换句直白的话，一半多的人每天站那儿 15 分钟，不是因为它有用，是因为不站比站更难看。\u003C\u002Fp>\n\n\u003Cp>站会本来是 Scrum 里最轻的一个仪式，现在成了被吐槽最多的一个。Atlassian 拉了 5000 个知识工作者做调研，80% 的人说大多数会议砍一半时间都能开完。落到站会身上更狠，只有 12% 的会议真的能在 15 分钟内结束，站会跑成半小时是常态。\u003C\u002Fp>\n\n\u003Cp>问题不在站会，在问错了话。经典三问是：昨天做了什么、今天做什么、遇到什么障碍。这三个问题一出口，站会就自动变成汇报会，每个人对着经理报进度，不是跟同事对齐卡点。\u003C\u002Fp>\n\n\u003Cp>淘宝广告引擎团队当年落地 Scrum 的复盘写得很实在（邹磊，网上公开的 PPT）。他们的晨会三个毛病：人太多一起开、超 15 分钟、开发报喜不报忧。他们的解法第一条就是拆团队，每个 Scrum 控制在 6 到 8 个人，别超 10 个。\u003C\u002Fp>\n\n\u003Cp>我先把结论放这：Scrum 落地，站会、团队规模、估算，这三件事搞砸一件，整个敏捷就变成形式主义。\u003C\u002Fp>\n\n\u003Ch2>站会改成「谁卡住了」，不是「我干了啥」\u003C\u002Fh2>\n\n\u003Cp>三问里最有价值的是第三问，前两问基本是废话。我昨天写了代码、我今天继续写代码，这种话每天听一遍，一个月之后谁都懒得听。\u003C\u002Fp>\n\n\u003Cp>把问题反过来问：今天有谁卡住了？需要谁在几点前配合？淘宝那个案例里，敏捷教练插了一句「接口文档阻塞联调，需要谁在多长时间内解决」，全场安静，然后产品经理缩着脖子说中午前给。这才是站会该干的活。\u003C\u002Fp>\n\n\u003Cp>加州大学尔湾分校有个研究，开发被打断一次，平均要 23 分 15 秒才能重新进入状态。所以一个 15 分钟的站会，真实成本是 38 分钟。站会越短越值钱，超时的站会是在拿整天的专注度去换一顿没营养的进度播报。\u003C\u002Fp>\n\n\u003Ch2>团队拆到 6-8 人，别一屋子 20 人开站会\u003C\u002Fh2>\n\n\u003Cp>大团队开站会是灾难。有调研显示，7 到 12 人的团队，15 分钟根本不够用；超过 9 人，80% 的人都说 15 分钟不够。人一多，每个人就憋着等轮到自己，别人说的话跟自己没关系，站会就成了轮流念简历。\u003C\u002Fp>\n\n\u003Cp>淘宝的解法就是拆。一个 Scrum 6 到 8 人，每个 Scrum 干的事是相关的，这样别人说话你才关心。20 人的团队别硬凑一个站会，拆成三个小组各开各的，反而省时间。\u003C\u002Fp>\n\n\u003Ch2>Sprint 别当承诺用，估时本来就在猜\u003C\u002Fh2>\n\n\u003Cp>Scrum 里最伤士气的是估算。计划会上估的时间跟实际差出一截，产品经理就慢慢不信你了。淘宝团队复盘的原话是「每次项目计划会，估计出来的时间都是不靠谱的，以至于产品经理会丧失对你团队的信任度」。\u003C\u002Fp>\n\n\u003Cp>他们的补救很具体：新人估人日要打折；双周开始前设计就得先做，大项目先只估设计时间；每个双周默认去掉 3 个人日，5 月 9 月 10 月还要多算假期。\u003C\u002Fp>\n\n\u003Cp>说白了，估时是猜，别把 Sprint 计划当成对客户和老板的承诺。State of Agile 报告里，不到一半的团队说 Scrum 带来了可衡量的生产力提升，很大一部分就是被「估不准、怪团队」这个循环耗掉的。\u003C\u002Fp>\n\n\u003Ch2>看板加 WIP 限制，别让任务「进行中」卡七天\u003C\u002Fh2>\n\n\u003Cp>看板是 Scrum 落地的低成本抓手，三列就够：待办、进行中、已完成。但很多人看板一挂就当装饰，任务卡在「进行中」一个星期没人管。\u003C\u002Fp>\n\n\u003Cp>加一条 WIP 限制就治好了。WIP 就是同时进行的任务数，经验值是团队人数乘 1.5，4 个人同时别开超过 6 个活。超过 WIP 的任务自动拉出来复盘，别让它变成看板上的僵尸。\u003C\u002Fp>\n\n\u003Ch2>什么时候别硬套 Scrum，看板更合适\u003C\u002Fh2>\n\n\u003Cp>Scrum 也不是万能的。固定两周一个 Sprint，碰上个线上紧急 bug，等不到下个迭代就得修，Sprint 的边界反而成了拖累。有些团队一天改好几次需求，硬按 Sprint 走，每回都被「下个迭代再说」顶回来，产品和开发的怨气都攒着。\u003C\u002Fp>\n\n\u003Cp>这种场景，看板比 Sprint 顺。看板是连续流，做完一个接一个，不设迭代边界，靠 WIP 限制控制节奏。开发被打断率高、运维客服类工作、需求像流水一样来的团队，用看板更省心。\u003C\u002Fp>\n\n\u003Cp>判断标准就一条：你的活儿是「一批一批做的」，还是「一条一条流进来的」。前者用 Sprint，后者用看板。Scrum 和看板也不是二选一，不少团队是 Sprint 管研发、看板管线上问题，两套并着用。\u003C\u002Fp>\n\n\u003Ch2>回顾会别贪多，一个迭代只改一个地方\u003C\u002Fh2>\n\n\u003Cp>回顾会是 Scrum 里最容易走形式的一个。真开起来的团队，问题是开完没行动项，下次还是老毛病。\u003C\u002Fp>\n\n\u003Cp>中小团队更实用的做法：每个迭代回顾会只回答两个问题，哪里做得不好、下次改哪一处。然后把这一处写进下个迭代计划，下次回顾会先检查改没改。一个迭代改一个点，一年下来是二十几个实质进步，比写一篇复盘报告强。\u003C\u002Fp>\n\n\u003Cp>博客园有个团队写过实例：接口文档反复改，前后端老打架，一次回顾会之后定了「接口冻结」，开发开始 3 天内文档不许动，bug 直接降了 40%。这种一个点一个点的改，才是回顾会该产出的东西。\u003C\u002Fp>\n\n\u003Cimg src=\"\u002Fimages\u002Farticles\u002Fmethod-scrum-dev-team.png\" alt=\"站会三问重构：从汇报三连到卡点对齐，附 15 分钟真实成本 38 分钟的时间账\">\n\n\u003Ch2>最后说句实在的\u003C\u002Fh2>\n\n\u003Cp>Scrum 落地这事，工具是其次的。你缺的不是一款能开站会、挂看板的软件，是先把团队拆小、把站会问对话、把估算当估算不当承诺。\u003C\u002Fp>\n\n\u003Cp>真要从今天动，我就劝你做三件：把站会改成只问「谁卡住了、要谁帮」；团队超过 10 人就拆；下个迭代回顾会只定一个改进点，先改站会超时这一条。这三件做到，Scrum 就不是开给领导看的表演，是真能帮团队交货的节奏。\u003C\u002Fp>\n\n\u003Cp>需要一套能挂看板、跑 Sprint、记回顾的项目管理系统，可以看看「智序 ORDR 项目管理系统」，看板、迭代、需求池都在一个地方，不用再拿 Excel 和群聊凑合。\u003C\u002Fp>\n\n\u003Cp>\u003Ca href=\"\u002Fsolutions\u002Fagile\">点这里看敏捷研发怎么落地 →\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Cp class=\"article-infringement\">如有侵权请与我们联系\u003C\u002Fp>\n","2026-08-30T22:34:20.696921+00:00","2026-08-30T22:34:22.389666+00:00",[76,83,89,96,101,106,111,117,122,127,132,137,142,148,153,158,163,168,173,174],{"id":77,"category_id":10,"title":78,"slug":79,"summary":80,"reading_time":81,"view_count":82,"module":57},"9b26fa81-b66b-4a35-b4d2-99a788835f24","敏捷 vs 瀑布：如何选择适合你团队的项目管理方法","agile-vs-waterfall","敏捷和瀑布到底怎么选？不是非此即彼。Standish Group 跟踪 5 万多个项目发现：敏捷成功率 42%、瀑布只有 13%。本文给你 3 个判断标准和最容易被忽略的混合用法。",3,2,{"id":84,"category_id":10,"title":85,"slug":86,"summary":87,"reading_time":88,"view_count":71,"module":57},"bf169d74-4c21-49db-ab37-ce1851c40c11","华为 IPD 流程能直接抄吗？中小企业落地的 5 个变形","huawei-ipd-5-adaptations","华为 IPD 那套 2500 多个流程文件，中小企业照抄成功率不到三成。这篇不讲虚的，讲清楚哪些该抄、哪些该砍，落地时的 5 个变形——组织、流程、评审、文档、工具，全往轻里改。",6,{"id":90,"category_id":10,"title":91,"slug":92,"summary":93,"reading_time":94,"view_count":95,"module":57},"91bdfa68-2dc1-4bf1-82b8-32d60b6359d0","产品经理的需求池与迭代管理实战","pm-requirement-pool","需求不进池子，就等于不存在。本文讲产品经理如何用需求池+迭代，把杂乱诉求变成可交付的版本。",8,0,{"id":97,"category_id":10,"title":98,"slug":99,"summary":100,"reading_time":94,"view_count":71,"module":57},"873b1b54-ca7b-4ea7-b41c-a27d3f39f979","项目计划怎么做才不失控：不是变化太快，是计划没做对","how-to-make-project-plan","PMI Pulse 2018 调研显示，65% 的项目没达成原始目标，规划不当是头号原因；52% 的项目经历过范围蔓延，平均成本超支 27%。做好项目计划的四件事：目标拆到能执行、排期留缓冲、管住范围蔓延、标清依赖和检查点。",{"id":102,"category_id":10,"title":103,"slug":104,"summary":105,"reading_time":94,"view_count":95,"module":57},"33b1ab6e-de87-4c63-bcd3-72ec1f364df0","项目进度管理怎么做：先承认人算不准时间","project-progress-management","Standish CHAOS 2020 显示只有 31% 项目按时完成，带病完成项目平均耗时是原计划的 222%；计划谬误研究表明 99% 置信的截止日期只有 45% 的人真正完成。进度管理的关键不是把估算做准，而是拆到里程碑、把进度摊开、让风险自己冒出来。",{"id":107,"category_id":10,"title":108,"slug":109,"summary":110,"reading_time":95,"view_count":95,"module":57},"09ff93ce-095f-4952-b82a-fc35c7ddf026","IPD 项目管理软件：集成产品开发怎么落地（中小企业视角）","ipd","IPD 不是流程图，是华为花 40 亿买的决策机制。中小企业落地抓需求端到端+阶段评审两条就够，别照搬全套。",{"id":112,"category_id":10,"title":113,"slug":114,"summary":115,"reading_time":116,"view_count":95,"module":57},"eb92f2fd-c566-47f3-aba3-54dd6b1cede0","瀑布项目管理系统：传统项目管理怎么做","waterfall-pm-software","瀑布模型不是老古董，金融、政务、硬件开发离不了它。本文讲清什么项目该用瀑布、五阶段怎么走、变更怎么管不乱，附选工具的几个要点。",7,{"id":118,"category_id":10,"title":119,"slug":120,"summary":121,"reading_time":94,"view_count":71,"module":57},"b2fb05df-4f54-4c6d-9b39-5002113a11a8","敏捷研发项目管理软件与系统：研发团队怎么落地（Scrum+看板）","agile-dev-pm-software","敏捷研发项目管理软件怎么选、怎么落地？Scrum 和看板在研发团队的实际跑法，选工具盯这四个点。",{"id":123,"category_id":10,"title":124,"slug":125,"summary":126,"reading_time":94,"view_count":71,"module":57},"99fc8bce-de45-4ffc-9550-335935b0e59f","IPD 到底是什么？一文讲透集成产品开发的 6 个核心阶段","ipd-6-stages","IPD 不是华为专属，也不只是一张流程图。这篇把集成产品开发讲成人话：它到底在解决什么、6 个阶段各自卡在哪、中小企业落地最容易踩的几个坑，看完能判断自己的团队适不适合上 IPD。",{"id":128,"category_id":10,"title":129,"slug":130,"summary":131,"reading_time":88,"view_count":95,"module":57},"e0e616fa-6d62-4bf5-b843-4c51382cec87","项目经理最常踩的 5 个坑：踩中一个项目就延期","pm-5-pitfalls","项目经理的常见痛点就五个：需求说不清、节点守不住、沟通断、知识留不住、优先级乱。Standish、PMI 的公开数据能证明每个坑都能把项目拖到延期，这篇逐个拆开讲，附真实案例和止血办法。",{"id":133,"category_id":10,"title":134,"slug":135,"summary":136,"reading_time":116,"view_count":81,"module":57},"94dc2585-1c85-4bdc-a4fc-302791a2fd32","IPD 和项目管理到底有什么区别？制造企业最容易踩的 3 个坑","ipd-vs-pm","太多制造企业把 IPD 当成高级版项目管理来推，这本身就是第一个坑。本文用真实案例拆解 IPD 与项目管理的本质区别，以及制造企业落地最容易踩的 3 个坑。",{"id":138,"category_id":10,"title":139,"slug":140,"summary":141,"reading_time":81,"view_count":95,"module":57},"9d3d891d-1211-48f0-8853-1d77ab332f14","研发团队如何用看板+敏捷管好需求与缺陷","rnd-kanban-agile","2024 State of Agile：71% 组织在软件研发中用敏捷，看板是使用率最高的规划工具（77%）。但多数团队只把看板当高级待办清单。本文给一套让需求与缺陷真正流动起来的落地方法。",{"id":143,"category_id":10,"title":144,"slug":145,"summary":146,"reading_time":147,"view_count":95,"module":57},"6b9f5810-f801-431b-8b36-543a3ea8f4c2","PMO 如何管理多个并行项目（项目组合方法论）","pmo-multi-project","PMO 的难题不是管一个项目，而是让十几个项目在资源、优先级、风险上不打架。本文给一套项目组合管理框架。",9,{"id":149,"category_id":10,"title":150,"slug":151,"summary":152,"reading_time":70,"view_count":95,"module":57},"e6605c92-e3f7-4c2b-8341-09c4339232c7","需求怎么管理：从需求池到落地的完整方法","how-to-manage-requirements","需求管理不是记清单，而是统一收口、优先级排序、与迭代打通的系统工程。一文讲清需求怎么管理。",{"id":154,"category_id":10,"title":155,"slug":156,"summary":157,"reading_time":81,"view_count":71,"module":57},"6e2ef9fa-fea2-4264-ba41-17373ab5d307","产品需求管理：PRD 之外，如何让需求真正落地","product-requirement-management","Standish CHAOS 报告把「不完整需求」列为项目失败首要原因（13.1%）。本文给一套从用户洞察到上线验证的需求管理落地动作，重点讲透验收标准。",{"id":159,"category_id":10,"title":160,"slug":161,"summary":162,"reading_time":70,"view_count":81,"module":57},"e765dbaf-7d85-4f89-acb7-7ce18a2e3eb3","IPD 管理是什么：华为花 40 亿买来的教训","ipd-management","华为 1998 年花 5.6 亿引入 IBM 的 IPD 体系，十年总投入 40 亿，高端产品上市周期从 70 个月压到 20 个月。但 90% 的中小公司其实不适合照搬 IPD。",{"id":164,"category_id":10,"title":165,"slug":166,"summary":167,"reading_time":88,"view_count":71,"module":57},"6f0c298a-1fa0-4c42-b3da-7f0329a86c09","项目总是延期，问题到底出在哪？真凶大半不是技术","pm-delay-causes","项目延期极少死在技术，多半死在需求没定清、范围蔓延、工期拍脑袋、沟通断层这四件事。Standish 2020 说软件项目只有 31% 能按时按预算交付，PMI 2023 说 37% 的项目失败直接挂钩需求变更频繁。附真实翻车案例和三步止损顺序。",{"id":169,"category_id":10,"title":170,"slug":171,"summary":172,"reading_time":70,"view_count":81,"module":57},"50f2893d-02b3-4094-a554-085b903fa0c5","需求反复变更，怎么控住不蔓延","scope-creep-control","需求反复变更会把项目拖成无底洞。泰国一个仓库系统，功能从 20 个膨胀到 67 个，预算从 280 万涨到 620 万泰铢，工期从 4 个月拖到 11 个月。根子不是客户贪心，是你每次变更都免费接。给变更设一道「要付钱」的坎，再配一张变更请求单、先算工期预算质量三笔账，范围蔓延能拦下大半。",{"id":66,"category_id":10,"title":67,"slug":68,"summary":69,"reading_time":70,"view_count":71,"module":57},{"id":175,"category_id":10,"title":176,"slug":177,"summary":178,"reading_time":71,"view_count":95,"module":57},"f464f734-2f26-40a2-b840-4553d750d7da","从混乱到有序：中小团队项目管理流程搭建指南","small-team-workflow-setup","中小团队项目管理流程搭建的四个原则和五个步骤。从需求收集到Sprint回顾，帮助15人以下团队用最小的流程成本实现最大的管理收益。"]