[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-requirement-priority-zh-CN":3,"blog-adjacent-requirement-priority-zh-CN":30,"blog-related-requirement-priority-zh-CN":65},{"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":29},61,"requirement-priority","需求优先级：谁喊得响不等于重要","优先级应该由影响范围和不可替代性决定，而不是由提出者的职位决定。","\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-06-05T12:23: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":28,"count":21},2,0,"product-thinking","产品思维","需求分析、用户体验与产品设计方法论，以及从业务问题到产品方案的思考过程。","lightbulb","blue","article",50,{},{"previous":31,"next":47},{"id":32,"slug":33,"title":34,"excerpt":35,"content":9,"cover":9,"tone":26,"author":11,"publishedAt":36,"updatedAt":36,"readingMinutes":13,"featured":14,"tags":37,"category":41},41,"lightweight-code-review","小团队的代码评审怎么落地","评审不是找茬，而是让改动在合并前被第二个人理解。规模小也要有流程。","2026-06-07T12:23:00+08:00",[38,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":52,"author":11,"publishedAt":53,"updatedAt":53,"readingMinutes":13,"featured":14,"tags":54,"category":58},81,"third-party-api-change","第三方接口复盘：对方改了字段没通知","合作方升级接口版本，返回结构悄然变化，系统在两周后才出现异常。","cyan","2026-06-03T12:23:00+08:00",[55,56,57],"复盘","第三方接口","稳定性",{"id":59,"parentId":21,"slug":60,"name":61,"description":62,"icon":63,"cover":9,"tone":26,"kind":27,"sortOrder":64,"count":21},3,"project-retrospective","项目复盘","从 0 到 1 的真实项目记录，完整呈现问题、方案、踩坑经验与最终结果。","clipboard-check",40,[66,75,85],{"id":28,"slug":67,"title":68,"excerpt":69,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":70,"updatedAt":70,"readingMinutes":13,"featured":14,"tags":71,"category":74},"grading-requirement-confidence","需求的真实度分级","把需求当成事实来做，是项目延期最常见的原因。需求其实有可信度高低之分。","2026-10-15T09:00:00+08:00",[16,72,73],"产品方法","风险管理",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21},{"id":20,"slug":76,"title":77,"excerpt":78,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":79,"updatedAt":80,"readingMinutes":20,"featured":14,"tags":81,"category":84},"vertical-product-rules","垂直行业产品的分水岭：把行业默认规则写进系统","垂直不是换一个行业名字。真正的门槛，是能否理解并承接那些从业者习以为常的默认规则。","2026-10-09T10:00:00+08:00","2026-10-18T15:58:14.661+08:00",[82,83],"行业产品","产品设计",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21},{"id":86,"slug":87,"title":88,"excerpt":89,"content":9,"cover":9,"tone":26,"author":11,"publishedAt":90,"updatedAt":90,"readingMinutes":13,"featured":14,"tags":91,"category":93},51,"mvp-boundary","MVP 的边界怎么划","最小可用不是功能最少，而是能完整跑通一条业务闭环。","2026-10-03T10:13:00+08:00",[92,72,16],"MVP",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21}]