<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[不忘初心]]></title><description><![CDATA[功崇惟志、业广惟勤]]></description><link>https://blog.youkuaiyun.com/playermaker</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; playermaker]]></copyright><item><title><![CDATA[划了边界，为什么团队还在互相甩锅？]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/163297134</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/163297134</guid><author>playermaker</author><pubDate>Mon, 03 Aug 2026 08:00:00 +0800</pubDate><description><![CDATA[摘要： 多数团队在职责划分后仍陷入扯皮，核心问题在于只划边界而未定义"如何对接"。真正的治理关键在于将边界转化为结构化接口标准，需明确交付物、格式、验收标准和验收人四要素。通过制定清晰的对接规格卡（如PRD模板、签字验收机制），可减少模糊地带，避免依赖上级仲裁。这一方法适用于跨部门协作、人机交互（如AI任务指令）等场景，本质是以接收方需求定义接口契约，从源头降低协作摩擦。（149字） 关键点： 问题本质：边界≠终点，未定义的接口才是扯皮根源]]></description><category></category></item><item><title><![CDATA[从混乱到自运转：四阶段路线图]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/163221467</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/163221467</guid><author>playermaker</author><pubDate>Sat, 01 Aug 2026 10:00:00 +0800</pubDate><description><![CDATA[治理不是一步到位的。你不可能今天读完这10篇文章，明天团队就井然有序。但你可以按这个路线图，每个月推进一个阶段。]]></description><category></category></item><item><title><![CDATA[16个指标治乱不治人]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/163051804</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/163051804</guid><author>playermaker</author><pubDate>Sat, 25 Jul 2026 10:00:00 +0800</pubDate><description><![CDATA[先建秩序，再量效能。大多数团队度量体系失败的原因是：在混乱中铺指标，逼着团队在废墟上造假数据。]]></description><category></category></item><item><title><![CDATA[跨部门甩锅的终局解法：一张RACI矩阵就够了]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/162810968</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/162810968</guid><author>playermaker</author><pubDate>Sat, 18 Jul 2026 10:00:00 +0800</pubDate><description><![CDATA[谁做、谁批、问谁、告诉谁——四个字母，终结所有甩锅。跨部门协作最需要的不是沟通技巧，是权责边界。]]></description><category></category></item><item><title><![CDATA[六条公约：让团队从“推着走“到“自己跑“]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/162633669</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/162633669</guid><author>playermaker</author><pubDate>Sat, 11 Jul 2026 10:00:00 +0800</pubDate><description><![CDATA[《好团队靠规则而非管理：六条研发治理公约》指出，高效团队的核心在于建立规则而非依赖管理。文章提出六条可落地的治理规则：1）需求必须通过统一入口提交，避免随意打断；2）明确权责对等，杜绝推诿；3）固定迭代周期，控制变更；4）信息透明共享，消除协作盲区；5）持续迭代优化规则；6）用数据驱动决策。这些规则通过简单明确的团队规范（如"提需求走系统，私聊不算"）即可落地，三个月后规则将自动替代管理者80%的重复协调工作，从根本上释放管理效能。文末强调，秩序建立应先于效能度量，否则数据容易失真。]]></description><category></category></item><item><title><![CDATA[线上故障，不能靠“谁先看见谁处理“]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/162631758</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/162631758</guid><author>playermaker</author><pubDate>Mon, 06 Jul 2026 13:27:21 +0800</pubDate><description><![CDATA[线上故障处理常因缺乏明确流程导致效率低下，关键问题在于依赖"谁看见谁管"的随机机制。有效的工单治理需建立五节点闭环流程（待接单→关闭），设定四大SLA指标（如响应≤1小时）替代模糊的"尽快"，并规范工单与需求/缺陷的流转路径。落地只需三步：用共享表格记录工单、制定基础SLA规则、定期复盘未关闭事项。通过流程化和数据化约束，可系统性解决工单无人响应的管理问题。]]></description><category></category></item><item><title><![CDATA[Bug不是你修不完，是你没管对]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/162631732</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/162631732</guid><author>playermaker</author><pubDate>Mon, 06 Jul 2026 13:26:22 +0800</pubDate><description><![CDATA[47个Bug丢在群里，最后谁修了？没修的那些去哪了？缺陷治理的本质不是消灭Bug，是让每一个Bug都有归属。]]></description><category></category></item><item><title><![CDATA[什么样的交付才算“完成“？]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/162631656</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/162631656</guid><author>playermaker</author><pubDate>Mon, 06 Jul 2026 13:23:46 +0800</pubDate><description><![CDATA["差不多就行"是研发团队最贵的四个字。交付有标准，质量有底线——这不是玄学，是规则。]]></description><category></category></item><item><title><![CDATA[两周迭代为什么比“随时插单“快40%？]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/162631615</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/162631615</guid><author>playermaker</author><pubDate>Mon, 06 Jul 2026 13:22:13 +0800</pubDate><description><![CDATA[GCR体系提出标准化2周迭代方案：前段为功能开发禁插单期，后段为缓冲治理期集中处理缺陷/插单。通过需求分级、透明收纳、规则管控，某商城项目上线周期从6-8周缩短至4周，插单次数减少80%，交付率提升至90%。关键指标显示，控制变更率（≤15%）比单纯追求速度更重要，本质是通过保护专注时间减少无效切换。实施只需两步：固定迭代节奏+严格管控插单。]]></description><category></category></item><item><title><![CDATA[需求治理：研发混乱的源头，90%的团队都卡在这一步]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/162631386</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/162631386</guid><author>playermaker</author><pubDate>Mon, 06 Jul 2026 13:19:13 +0800</pubDate><description><![CDATA[研发团队最累的往往是研发负责人，根源在于需求入口失控。GCR体系提出需求治理的六个标准节点（待完善到已完成），每个节点须明确责任方和交付标准。通过"需求漏斗"三层过滤机制（评审、排期、验收）筛选高价值需求，并建立严格的变更管控规则。一个典型案例中，团队通过关闭僵尸需求、优先级分类和严格执行漏斗流程，两周内将200+需求削减至47条有效需求。实施需求治理只需做到三点：统一需求入口、建立价值漏斗、制定变更规则，即可显著减少30%无效劳动。]]></description><category></category></item><item><title><![CDATA[一个CTO被裁后的30天：我把18年踩坑经验提炼成了这套诊断方法]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/162629996</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/162629996</guid><author>playermaker</author><pubDate>Mon, 06 Jul 2026 12:15:43 +0800</pubDate><description><![CDATA[一位被裁CTO将18年团队管理经验提炼成研发治理框架，指出混乱根源在于缺乏结构化规则。文章提出"GCR全域诊断框架"，通过需求、迭代、交付、缺陷、工单五条生命线评估团队状态，并提供快速诊断工具。作者强调治理不是换人或工具，而是建立可落地的流程标准，将常识转化为规则。案例显示，这套方法曾帮助团队从需求积压、迭代混乱中恢复秩序。文章核心观点：技术团队效能问题本质是治理缺失，需系统性构建规则而非局部修补。]]></description><category></category></item><item><title><![CDATA[18年全栈到CTO：我为什么死磕中小企业研发效能]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/162548814</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/162548814</guid><author>playermaker</author><pubDate>Fri, 03 Jul 2026 13:06:27 +0800</pubDate><description><![CDATA[我写代码18年了。从.NET 2.0写到Blazor，从一个人写到带50人团队。中间做过技术总监，做过CTO，也创过业。这两年我经手过不少中小企业的研发团队，发现一个规律——但老板的第一反应永远是：加人。然后加班。然后堆工具。三个动作走完，钱烧完了。效率没变。]]></description><category></category></item><item><title><![CDATA[人人都会Blazor —— 3.7 组件生命周期]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/134908411</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/134908411</guid><author>playermaker</author><pubDate>Fri, 15 Dec 2023 00:00:00 +0800</pubDate><description><![CDATA[只有完全搞明白了组件的生命周期，你才能把组件玩的游刃有余，不仅仅需要深厚的功底和基础，还得了解非托管资源的垃圾回收机制，否则，一旦页面上组件过多，肯定就会引起性能的问题。那么回过头来了解生命周期自然也是必不可少的知识。]]></description><category></category></item><item><title><![CDATA[人人都会Blazor —— 3.6 数据绑定]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/134908181</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/134908181</guid><author>playermaker</author><pubDate>Sun, 10 Dec 2023 14:45:53 +0800</pubDate><description><![CDATA[当用户在输入框进行数据变更时，相应的变量立刻就得到变化。]]></description><category></category></item><item><title><![CDATA[人人都会Blazor —— 3.5 布局]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/134698735</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/134698735</guid><author>playermaker</author><pubDate>Tue, 05 Dec 2023 00:00:00 +0800</pubDate><description><![CDATA[有些应用元素（例如菜单、版权消息和公司徽标）通常是应用整体布局的一部分。将这些元素的标记副本放入应用的所有组件是一种效率较低的做法。每次更新其中一个元素时，都必须同时更新使用该元素的每个组件。这种方法的维护成本很高，并且如果缺少更新，还可能会导致内容不一致。那么 “布局” 就是用来解决这些问题的。]]></description><category></category></item><item><title><![CDATA[人人都会Blazor—— 3.4 事件处理]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/134392911</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/134392911</guid><author>playermaker</author><pubDate>Thu, 30 Nov 2023 00:00:00 +0800</pubDate><description><![CDATA[某些情况，你可以自定义事件，例如，把和onmouseout给结合起来使用。通常，通过以下步骤启用具有自定义事件参数的自定义事件。在wwwroot/{PackgeId}或{AssemblyName}.lib.module.js创建一个 JS 文件，并有一个导出函数：return {});固定的 JS 文件名称：程序集.lib.module.js 或 包名称.lib.module.js：浏览器能识别的事件，如 click change 等：需要返回与下面事件参数相等的对象。]]></description><category></category></item><item><title><![CDATA[人人都会Blazor —— 3.3 参数]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/134392479</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/134392479</guid><author>playermaker</author><pubDate>Fri, 24 Nov 2023 09:58:48 +0800</pubDate><description><![CDATA[参数是最常用的组件特性，需要非常熟练的掌握才会事半功倍，同样地，组件的参数设计也会让使用者不禁的感叹设计者的水平。]]></description><category></category></item><item><title><![CDATA[人人都会Blazor—— 3.2 组件]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/134392239</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/134392239</guid><author>playermaker</author><pubDate>Fri, 24 Nov 2023 09:57:50 +0800</pubDate><description><![CDATA[路由是页面访问的基础，笔者建议，对那些不需要使用导航访问到的组件，不要定义路由，以免造成不必要的成本，例如显示异常的解释成本（这不是bug…）。]]></description><category></category></item><item><title><![CDATA[人人都会Blazor—— 3.1 路由和导航]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/134391100</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/134391100</guid><author>playermaker</author><pubDate>Fri, 24 Nov 2023 09:54:37 +0800</pubDate><description><![CDATA[导航和路由是最基础且很常用的知识，你可以根据自己的需求去定义路由导航。当然，好的路由设计可以使你的站点看起来更专业，这也是体现你水平的最佳时机。]]></description><category></category></item><item><title><![CDATA[人人都会Blazor —— 2.3 依赖注入]]></title><link>https://blog.youkuaiyun.com/playermaker/article/details/134390628</link><guid>https://blog.youkuaiyun.com/playermaker/article/details/134390628</guid><author>playermaker</author><pubDate>Mon, 20 Nov 2023 00:00:00 +0800</pubDate><description><![CDATA[依赖注入技术已经是 .NET 中非常基础且成熟的技术，所以这里就不作为重点进行介绍了。就是要注意的是在 Blazor 中，依赖注入的生命周期会有所变化，特别是 WebAssembly 中，没有所谓的 Scoped，即使你注册成为了 Scoped 服务，也会被当作 Singleton 方式来对待，这点一定要注意。]]></description><category></category></item></channel></rss>