[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-grading-requirement-confidence-zh-CN":3,"blog-adjacent-grading-requirement-confidence-zh-CN":29,"blog-related-grading-requirement-confidence-zh-CN":64},{"id":4,"slug":5,"title":6,"excerpt":7,"content":8,"cover":9,"tone":10,"author":11,"publishedAt":12,"updatedAt":12,"readingMinutes":13,"featured":14,"tags":15,"category":19,"seoSettings":28},50,"grading-requirement-confidence","需求的真实度分级","把需求当成事实来做，是项目延期最常见的原因。需求其实有可信度高低之分。","\u003Cp>客户说“用户一定会用这个功能”时，这句话的可信度和“这个功能符合我们现有的审批制度”完全不一样。前一句是猜测，后一句是约束。可惜很多需求文档把两者写成了同一种语气。\u003C\u002Fp>\n\u003Ch2>三个可信度等级\u003C\u002Fh2>\n\u003Cp>确定：由制度、合同或法规决定，必须实现，比如发票格式、审批层级。\u003C\u002Fp>\n\u003Cp>较确定：有历史数据或实际操作支撑，比如现有系统每天有多少笔业务。\u003C\u002Fp>\n\u003Cp>假设：来自个人判断或行业惯例，需要上线后验证，比如“用户会愿意填写这个表单”。\u003C\u002Fp>\n\u003Ch2>分级之后怎么用\u003C\u002Fh2>\n\u003Cp>确定级需求直接排期，假设级需求先做最小验证，比如灰度给一个部门使用。\u003C\u002Fp>\n\u003Cp>在需求文档里标注每一条的等级，评审时优先讨论假设级的部分，那里才是风险所在。\u003C\u002Fp>\n\u003Cp>承认不确定不是不专业，把不确定当成确定才是。分级让团队把精力放在真正需要判断的地方。\u003C\u002Fp>","","indigo","佳益方圆团队","2026-10-15T09:00:00+08:00",1,false,[16,17,18],"需求","产品方法","风险管理",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":4,"count":21},2,0,"product-thinking","产品思维","需求分析、用户体验与产品设计方法论，以及从业务问题到产品方案的思考过程。","lightbulb","blue","article",{},{"previous":30,"next":47},{"id":13,"slug":31,"title":32,"excerpt":33,"content":9,"cover":9,"tone":34,"author":11,"publishedAt":35,"updatedAt":36,"readingMinutes":20,"featured":37,"tags":38,"category":41},"why-enterprise-systems-age","为什么企业系统会在三年后开始“老化”","系统上线时功能齐全，三年后却处处别扭。问题往往不在代码，而在交付时被忽略的那些变化。","cyan","2026-10-16T09:30:00+08:00","2026-10-18T15:58:14.648+08:00",true,[39,40],"系统演进","架构设计",{"id":13,"parentId":21,"slug":42,"name":43,"description":44,"icon":45,"cover":9,"tone":26,"kind":27,"sortOrder":46,"count":21},"engineering","技术专栏","架构设计、性能优化、AI 集成与跨端方案等一线技术实践，由研发团队持续分享。","cpu",60,{"id":48,"slug":49,"title":50,"excerpt":51,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":52,"updatedAt":52,"readingMinutes":13,"featured":14,"tags":53,"category":57},70,"gov-project-acceptance","政务项目复盘：验收为什么拖了半年","功能早已上线，验收却迟迟没有完成。问题往往不在系统，而在文档、流程和沟通节奏。","2026-10-13T09:00:00+08:00",[54,55,56],"复盘","政务项目","验收",{"id":58,"parentId":21,"slug":59,"name":60,"description":61,"icon":62,"cover":9,"tone":26,"kind":27,"sortOrder":63,"count":21},3,"project-retrospective","项目复盘","从 0 到 1 的真实项目记录，完整呈现问题、方案、踩坑经验与最终结果。","clipboard-check",40,[65,75,84],{"id":20,"slug":66,"title":67,"excerpt":68,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":69,"updatedAt":70,"readingMinutes":20,"featured":14,"tags":71,"category":74},"vertical-product-rules","垂直行业产品的分水岭：把行业默认规则写进系统","垂直不是换一个行业名字。真正的门槛，是能否理解并承接那些从业者习以为常的默认规则。","2026-10-09T10:00:00+08:00","2026-10-18T15:58:14.661+08:00",[72,73],"行业产品","产品设计",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":4,"count":21},{"id":76,"slug":77,"title":78,"excerpt":79,"content":9,"cover":9,"tone":26,"author":11,"publishedAt":80,"updatedAt":80,"readingMinutes":13,"featured":14,"tags":81,"category":83},51,"mvp-boundary","MVP 的边界怎么划","最小可用不是功能最少，而是能完整跑通一条业务闭环。","2026-10-03T10:13:00+08:00",[82,17,16],"MVP",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":4,"count":21},{"id":85,"slug":86,"title":87,"excerpt":88,"content":9,"cover":9,"tone":89,"author":11,"publishedAt":90,"updatedAt":90,"readingMinutes":13,"featured":14,"tags":91,"category":94},52,"user-interview-questions","用户访谈里最该问的三个问题","问“你想要什么”得到的是想象，问“你上次怎么做”得到的才是事实。","teal","2026-09-21T11:26:00+08:00",[92,93,17],"用户研究","访谈",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":4,"count":21}]