[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"knowledge-category-pm-methodology":3,"knowledge-article-pm-methodology-timesheet-accuracy":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},"d39d8d54-2eec-4c57-a13a-b4a06c029afb","工时统计为什么永远对不上？三个漏点加一个新盲区","timesheet-accuracy","计划外动作没入口、审批链比任务链还长、事后凭记忆补，这三个漏点让工时数据天然失真。叠加 AI 相关的隐性工作没被度量，工时统计对不上是流程问题，不是员工不诚实。文末给出三条可落地的修法与工具对比。",6,0,"\u003Cp style=\"background:#f5f3ff;border-left:4px solid #7c3aed;border-radius:8px;padding:14px 18px;margin:0 0 24px\">全文约 2500 字，阅读约 6 分钟。\u003Cbr>重点内容：工时对不上不是员工不诚实，是填报动作本身在造假。三个漏点（计划外动作没入口、审批比任务还长、事后凭记忆补）加一条新变化（AI 相关的 31% 工作量压根没被度量），修好这四条，工时才算数。\u003C\u002Fp>\n\n\u003Cp>上个月一个做软件项目的项目经理在会议室拍了桌子。他说的不是加班太多，是一句更狠的话：连续三个月团队加了八十小时班，系统里的工时总数只多了三十。剩下那五十小时去哪了，全在聊天记录和口头汇报里。\u003C\u002Fp>\n\n\u003Cp>这不是他一个人的故事。我这几天搜了一圈，工时管理是项目管理里吐槽密度最高的环节之一。有项目经理每周五下午都在催工时表，催完发现某模块工时异常低，一查是负责的工程师习惯周五补记账，那周出差忘了补。也有一家公司搞过填工时比赛，要求周五前填报率 100%，最快填完的部门有奖励，私下的速填秘籍是固定项目、固定小时数、批量复制粘贴。\u003C\u002Fp>\n\n\u003Cp>结论有点扎心：工时对不上，从来不是人的问题，是填报动作本身在生产假数据。\u003C\u002Fp>\n\n\u003Cimg src=\"\u002Fimages\u002Farticles\u002Fmethod-timesheet-accuracy.png\" alt=\"工时填报失真的三个漏点与AI新增盲区\">\n\n\u003Ch2>漏点一：计划外的活，系统里没有入口\u003C\u002Fh2>\n\n\u003Cp>老杨那家公司用的工具功能很全，界面也漂亮。问题出在一个具体场景：测试阶段临时加了两天压力测试。这种计划外动作在系统里找不到对应条目，工程师干脆就不填了。填了也没人批，审批流卡在变更申请环节，走完要三天，等批下来任务都做完了。\u003C\u002Fp>\n\n\u003Cp>于是大家开始记影子账。有人用 Excel 另拉一张表，有人发微信报备，还有人等月底统一补录。补录时细节早忘了，数字全靠估。行业调研里有个数字：手工填报工时模式的误差率最高可到 35%。\u003C\u002Fp>\n\n\u003Ch2>漏点二：审批链比任务链还长\u003C\u002Fh2>\n\n\u003Cp>研发团队迭代节奏普遍一周一版，一个工期三天的审批等于跨越两三个迭代。让工程师为三天的计划外动作去走三天流程，他理性上就会选择不填。\u003C\u002Fp>\n\n\u003Cp>还有更隐蔽的一种偷工。有个工程师被质疑工时太规律，每天上午四小时开发、下午四小时测试，一丝不差。他的回答是，本来工作就被打断很多次，真正回忆起来根本记不清，你们爱看什么数据就给什么数据吧。工时填报一旦逼到人开始编，数据本身就失去意义了。\u003C\u002Fp>\n\n\u003Ch2>漏点三：事后凭记忆补，越补越偏\u003C\u002Fh2>\n\n\u003Cp>有位朋友在 IT 公司做项目经理，最怕月底催团队交工时表。每次都像赶作业，大家都在补记，填得差不多就行，偶尔还会碰到工时冲突，某个人一天在两个项目组里都报了 8 小时。按 150 美元一小时的时薪算，一个工程师每周有 6 小时耗在追审批、重建表格、修发票错误上，一年就是 4.68 万美元的计费能力蒸发。这笔损耗不出现在任何一张报表上，只在年底复盘时被归到范围蔓延或者难搞的客户头上。\u003C\u002Fp>\n\n\u003Ch2>新增漏点：AI 相关的活儿，现在压根没被度量\u003C\u002Fh2>\n\n\u003Cp>Harness 的《2026 年工程卓越状态报告》调查了美、英、法、德、印五国 700 名工程从业者与管理者，结论是开发者每天约 31% 的时间消耗在与 AI 相关但现有度量体系不追踪的隐性工作上，折算下来每人每周约 1.5 个工作日。\u003C\u002Fp>\n\n\u003Cp>这 1.5 天花在哪？在 AI 生成代码和人工验证之间的等待里，在评审队列的拥堵里，在反复确认 AI 改动有没有引入回归的排查里。这些环节消耗的是真实人力，可传统工时填报里根本没有它们的位置。\u003C\u002Fp>\n\n\u003Cp>同一份调查里，94% 的受访者表示技术债、验证时间和开发者疲劳没有被现有生产力指标追踪，把审查 AI 代码准确性列为最大摩擦来源的占 53%。这三个数字口径不同，一个是问哪些因素没被追踪，一个是问哪个环节摩擦最大，都是受访者占比，不是占总工时的比例。但方向清楚：平台看到的是这个人这个迭代填了 80 小时，看不到有多少被消耗在验证上。\u003C\u002Fp>\n\n\u003Ch2>工时长，不等于产出多\u003C\u002Fh2>\n\n\u003Cp>斯坦福一项覆盖五万多名软件工程师、跨数百家公司的研究发现，约 9.5% 的工程师产出接近于零，被研究者叫作幽灵工程师，他们的产出相当于中位数工程师的 0.1 倍。远程环境里这个比例是 14%，坐办公室的是 6%。作者自己也说用代码提交衡量产出有偏差，但它至少揭穿一件事：填了 80 小时和干了 80 小时的活，是两回事。\u003C\u002Fp>\n\n\u003Cp>国内也有类似的账。某互联网产品团队 2023 年的效能数据里，单日加班 3.2 小时，其中 35% 花在 PPT 美化和会议纪要归档这类非核心工作上；需求交付延期率同比上升 28%；一个 P2 级的界面颜色调整需求消耗了 132 人时，把 P0 级安全漏洞修复的资源挤掉了。同一份数据里，68% 的科技企业存在高加班低产出现象。看到工时排第一的人，我要打个问号。\u003C\u002Fp>\n\n\u003Ch2>免费的工时工具，坑都藏在人数和锁功能上\u003C\u002Fh2>\n\n\u003Cp>免费选项不少，但免费在这行有固定套路。按 2026 年公开定价：\u003C\u002Fp>\n\n\u003Cul>\n\u003Cli>Toggl Track 免费版最多 5 个用户，计费费率、开票、项目盈利分析都不在免费范围内，Starter 每人每月 9 美元。\u003C\u002Fli>\n\u003Cli>Harvest 免费版 1 个席位 2 个项目，带着发票生成这个卖点，但项目上限一扩就装不下，Pro 每人每月 12 美元。\u003C\u002Fli>\n\u003Cli>Clockify 免费版项目数和用户数宽松，但计费费率、收入跟踪、开票、排班、GPS 全部锁在付费档，入门每人每月 3.99 美元。\u003C\u002Fli>\n\u003Cli>TimeCamp 不限用户免费，入门每人每月 2.99 美元。ONES 免费 30 席，支持云、私有云和隔离网部署。\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>15 人团队要用开票能力，Clockify 标准档每月 82.35 美元，Harvest 是 135 美元；50 人时差距拉到每月 275 美元。\u003C\u002Fp>\n\n\u003Ch2>我会怎么搭这套工时\u003C\u002Fh2>\n\n\u003Col>\n\u003Cli>把填报动作嵌进已有动作。让人从任务卡里直接记工时，而不是打开另一个系统填一张表。智序项目管理软件这块是任务详情页直接挂工时入口，不额外开页面，多一步就少一次拖延。\u003C\u002Fli>\n\u003Cli>给计划外动作留一个必须能填的分类。压力测试、线上救火、临时支持，都要有对应条目。分类不解决所有问题，但能让人有地方写，而不是不写。\u003C\u002Fli>\n\u003Cli>审批链不许长于任务链。三天的审批配一周的迭代，规则本身就要改。可以改成事后抽审，或者按项目类型定不同审批时限。\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Cp>还有一条关于态度。工时数据拿来做资源调配和项目复盘，一拿去跟绩效挂钩，填报质量立刻掉到底。前面那个绩效翻车的例子很典型，前端小李加班最多，绩效分却不如后端小王，因为小李懒得每次都提额外任务申请，系统里只比平均高 10%，小王高 35%。拿不完整的数据判人的绩效，判错的不是人，是流程。\u003C\u002Fp>\n\n\u003Ch2>智序项目管理系统对比节\u003C\u002Fh2>\n\n\u003Ctable>\n\u003Cthead>\u003Ctr>\u003Cth>工具\u003C\u002Fth>\u003Cth>免费版人数\u003C\u002Fth>\u003Cth>工时填报位置\u003C\u002Fth>\u003Cth>部署方式\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\u003Ctd>智序 ORDR\u003C\u002Ftd>\u003Ctd>不限\u003C\u002Ftd>\u003Ctd>任务详情页内直接记\u003C\u002Ftd>\u003Ctd>私有化 \u002F SaaS\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Toggl Track\u003C\u002Ftd>\u003Ctd>5 人\u003C\u002Ftd>\u003Ctd>独立计时器为主\u003C\u002Ftd>\u003Ctd>仅云\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Harvest\u003C\u002Ftd>\u003Ctd>1 席 2 项目\u003C\u002Ftd>\u003Ctd>独立计时器\u003C\u002Ftd>\u003Ctd>仅云\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Clockify\u003C\u002Ftd>\u003Ctd>不限\u003C\u002Ftd>\u003Ctd>计时器 \u002F 手动 \u002F 自动\u003C\u002Ftd>\u003Ctd>仅云\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>智序项目管理软件的定位是工时跟着任务走，不是工时单开一个系统。时间挂在哪个任务上，报表里就在哪个项目下，中间不需要人工对齐。免费版不限人数在工时场景里价值不小，因为工时数据的价值来自覆盖率，五个人准的数据比二十个人缺一半的数据有用得多。价格上企业版 399 元每人每年，买断 699 元，旗舰版 599 元每年或 899 元买断。\u003C\u002Fp>\n\n\u003Cp>工时数据怎么用才不变成考核武器，我另外写一篇。更多做法看 \u003Ca href=\"\u002Fknowledge\u002Fpm-methodology\">项目管理方法论\u003C\u002Fa>。\u003C\u002Fp>\n\n\u003Cp class=\"article-infringement\">如有侵权请与我们联系\u003C\u002Fp>",null,"2026-10-09T08:00:00+08:00","2026-10-08T23:59:43.727173+00:00",[20,27,32,38,43,48,53,60,66,71,76,81,86,92,98,103,108,113,118,123,128,134,139,144,149,150,156,161,166],{"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":13,"view_count":25,"module":16},"bf169d74-4c21-49db-ab37-ce1851c40c11","华为 IPD 流程能直接抄吗？中小企业落地的 5 个变形","huawei-ipd-5-adaptations","华为 IPD 那套 2500 多个流程文件，中小企业照抄成功率不到三成。这篇不讲虚的，讲清楚哪些该抄、哪些该砍，落地时的 5 个变形——组织、流程、评审、文档、工具，全往轻里改。",{"id":33,"category_id":4,"title":34,"slug":35,"summary":36,"reading_time":37,"view_count":14,"module":16},"91bdfa68-2dc1-4bf1-82b8-32d60b6359d0","产品经理的需求池与迭代管理实战","pm-requirement-pool","需求不进池子，就等于不存在。本文讲产品经理如何用需求池+迭代，把杂乱诉求变成可交付的版本。",8,{"id":39,"category_id":4,"title":40,"slug":41,"summary":42,"reading_time":37,"view_count":25,"module":16},"873b1b54-ca7b-4ea7-b41c-a27d3f39f979","项目计划怎么做才不失控：不是变化太快，是计划没做对","how-to-make-project-plan","PMI Pulse 2018 调研显示，65% 的项目没达成原始目标，规划不当是头号原因；52% 的项目经历过范围蔓延，平均成本超支 27%。做好项目计划的四件事：目标拆到能执行、排期留缓冲、管住范围蔓延、标清依赖和检查点。",{"id":44,"category_id":4,"title":45,"slug":46,"summary":47,"reading_time":37,"view_count":14,"module":16},"33b1ab6e-de87-4c63-bcd3-72ec1f364df0","项目进度管理怎么做：先承认人算不准时间","project-progress-management","Standish CHAOS 2020 显示只有 31% 项目按时完成，带病完成项目平均耗时是原计划的 222%；计划谬误研究表明 99% 置信的截止日期只有 45% 的人真正完成。进度管理的关键不是把估算做准，而是拆到里程碑、把进度摊开、让风险自己冒出来。",{"id":49,"category_id":4,"title":50,"slug":51,"summary":52,"reading_time":14,"view_count":14,"module":16},"09ff93ce-095f-4952-b82a-fc35c7ddf026","IPD 项目管理软件：集成产品开发怎么落地（中小企业视角）","ipd","IPD 不是流程图，是华为花 40 亿买的决策机制。中小企业落地抓需求端到端+阶段评审两条就够，别照搬全套。",{"id":54,"category_id":4,"title":55,"slug":56,"summary":57,"reading_time":58,"view_count":59,"module":16},"eb92f2fd-c566-47f3-aba3-54dd6b1cede0","瀑布项目管理系统：传统项目管理怎么做","waterfall-pm-software","瀑布模型不是老古董，金融、政务、硬件开发离不了它。本文讲清什么项目该用瀑布、五阶段怎么走、变更怎么管不乱，附选工具的几个要点。",7,1,{"id":61,"category_id":4,"title":62,"slug":63,"summary":64,"reading_time":37,"view_count":65,"module":16},"b2fb05df-4f54-4c6d-9b39-5002113a11a8","敏捷研发项目管理软件与系统：研发团队怎么落地（Scrum+看板）","agile-dev-pm-software","敏捷研发项目管理软件怎么选、怎么落地？Scrum 和看板在研发团队的实际跑法，选工具盯这四个点。",2,{"id":67,"category_id":4,"title":68,"slug":69,"summary":70,"reading_time":37,"view_count":13,"module":16},"99fc8bce-de45-4ffc-9550-335935b0e59f","IPD 到底是什么？一文讲透集成产品开发的 6 个核心阶段","ipd-6-stages","IPD 不是华为专属，也不只是一张流程图。这篇把集成产品开发讲成人话：它到底在解决什么、6 个阶段各自卡在哪、中小企业落地最容易踩的几个坑，看完能判断自己的团队适不适合上 IPD。",{"id":72,"category_id":4,"title":73,"slug":74,"summary":75,"reading_time":13,"view_count":14,"module":16},"e0e616fa-6d62-4bf5-b843-4c51382cec87","项目经理最常踩的 5 个坑：踩中一个项目就延期","pm-5-pitfalls","项目经理的常见痛点就五个：需求说不清、节点守不住、沟通断、知识留不住、优先级乱。Standish、PMI 的公开数据能证明每个坑都能把项目拖到延期，这篇逐个拆开讲，附真实案例和止血办法。",{"id":77,"category_id":4,"title":78,"slug":79,"summary":80,"reading_time":58,"view_count":25,"module":16},"94dc2585-1c85-4bdc-a4fc-302791a2fd32","IPD 和项目管理到底有什么区别？制造企业最容易踩的 3 个坑","ipd-vs-pm","太多制造企业把 IPD 当成高级版项目管理来推，这本身就是第一个坑。本文用真实案例拆解 IPD 与项目管理的本质区别，以及制造企业落地最容易踩的 3 个坑。",{"id":82,"category_id":4,"title":83,"slug":84,"summary":85,"reading_time":25,"view_count":25,"module":16},"9d3d891d-1211-48f0-8853-1d77ab332f14","研发团队如何用看板+敏捷管好需求与缺陷","rnd-kanban-agile","2024 State of Agile：71% 组织在软件研发中用敏捷，看板是使用率最高的规划工具（77%）。但多数团队只把看板当高级待办清单。本文给一套让需求与缺陷真正流动起来的落地方法。",{"id":87,"category_id":4,"title":88,"slug":89,"summary":90,"reading_time":91,"view_count":14,"module":16},"6b9f5810-f801-431b-8b36-543a3ea8f4c2","PMO 如何管理多个并行项目（项目组合方法论）","pmo-multi-project","PMO 的难题不是管一个项目，而是让十几个项目在资源、优先级、风险上不打架。本文给一套项目组合管理框架。",9,{"id":93,"category_id":4,"title":94,"slug":95,"summary":96,"reading_time":97,"view_count":14,"module":16},"e6605c92-e3f7-4c2b-8341-09c4339232c7","需求怎么管理：从需求池到落地的完整方法","how-to-manage-requirements","需求管理不是记清单，而是统一收口、优先级排序、与迭代打通的系统工程。一文讲清需求怎么管理。",5,{"id":99,"category_id":4,"title":100,"slug":101,"summary":102,"reading_time":25,"view_count":59,"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":97,"view_count":26,"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":13,"view_count":65,"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":97,"view_count":25,"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":97,"view_count":65,"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":37,"view_count":14,"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":14,"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":97,"view_count":14,"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":13,"view_count":14,"module":16},"9a166304-7a61-45f7-87cc-409e6dfe7acf","市场部项目怎么做？活动、投放、内容排期别再各管各的","marketing-department-project-management","市场部最怕活动、投放、内容三摊事各管各的，临上线前撞车。用看板、死线、单一事实源把三摊事串到同一条时间轴上，少踩坑。",{"id":145,"category_id":4,"title":146,"slug":147,"summary":148,"reading_time":13,"view_count":14,"module":16},"bea90647-8a3b-4cb0-ad0d-3fb24b9c3033","项目一多就延期？大型集团多项目管理，资源队列才是真凶","multi-project-resource-queue","多项目管理管不下来，根子不在进度表而在资源排队。需求容量比、上下文切换成本、在制品限流，三个数字讲清多项目的资源治理。",{"id":9,"category_id":4,"title":10,"slug":11,"summary":12,"reading_time":13,"view_count":14,"module":16},{"id":151,"category_id":4,"title":152,"slug":153,"summary":154,"reading_time":13,"view_count":155,"module":16},"3cb958ad-bbc1-4b24-8e53-fe9122b1c106","工时统计为什么永远对不上？四个根因和三步补救","timesheet-mismatch-why","工时表和财务对账总差三成？四个根因拆解+三步补救顺序，先修口径再动工具。",10,{"id":157,"category_id":4,"title":158,"slug":159,"summary":160,"reading_time":13,"view_count":14,"module":16},"61f35806-4b89-4e43-aff4-4246d9cdd30e","研发团队工时数据怎么用，才不会变成考核武器","timesheet-data-not-weapon","工时表最危险的一刻是它准的那一刻，数据一准就会被拿去做排名，一排名就开始假。本文讲清为什么管理者忍不住用工时排名、排名之后数据怎么失真，以及正确的四个用法：找偏差、看阻塞、算资源、算账。",{"id":162,"category_id":4,"title":163,"slug":164,"summary":165,"reading_time":13,"view_count":59,"module":16},"902085ea-9f80-4ecc-aacd-7f09f0cd2e07","项目风险管理怎么做：九成登记册活不过一个月，问题出在哪","project-risk-management","CHAOS 2020 显示近七成项目没有完全成功，可多数团队的风险登记册活不过一个月。本文拆登记册四大死法：没人看、写成话题、只评一次分、没有触发信号，给出七列字段、机械升级规则和周评审节奏的落地做法。",{"id":167,"category_id":4,"title":168,"slug":169,"summary":170,"reading_time":59,"view_count":14,"module":16},"f464f734-2f26-40a2-b840-4553d750d7da","从混乱到有序：中小团队项目管理流程搭建指南","small-team-workflow-setup","中小团队项目管理流程搭建的四个原则和五个步骤。从需求收集到Sprint回顾，帮助15人以下团队用最小的流程成本实现最大的管理收益。"]