-
带团队以后，我才明白的事
我刚开始带项目的时候，理解得挺简单。需求来了，拆一下任务，排一下时间，谁负责前端，谁负责后端，谁负责测试，最后盯着进度往前推。那时候我以为，只要自己技术判断还可以，项目大概率...
-
小团队什么时候需要流程
小团队一聊流程，气氛经常有点微妙。有人觉得流程是大公司那一套，麻烦、慢、形式主义。也有人觉得没有流程不行，需求乱、上线乱、问题也乱。这两种感觉都对一部分。小团队确实怕流程太重...
-
绩效、激励和团队安全感
聊团队安全感，很容易被误解成“大家都开心就好”。其实不是。软件团队当然需要目标，需要压力，也需要对结果负责。没有压力的团队会松散，没有结果意识的团队也很难交付。但如果一个团队...
-
新人培养，不能只靠“你先看代码”
很多新人进团队，第一句话就是：“你先熟悉一下代码。”这句话太常见了。说的人通常也没恶意。团队忙，项目赶，老同事手里都有活，先让新人自己看看，似乎是最自然的安排。但问题是，一个...
-
怎么开一个不浪费人的技术会议
软件团队里，会议很容易越开越多。需求评审、技术评审、站会、周会、复盘会、临时对齐会。日历看起来很充实，群里也一直有人说“拉个会聊一下”。但很多人心里其实清楚：有些会开完以后，...
-
项目延期时，真正要复盘什么
项目延期以后，复盘会很尴尬。因为大家都知道项目没按时交，但每个人都能说出自己的理由：需求变了、接口晚了、测试环境坏了、线上问题插进来了、某个同事请假了、评审时没想到这个边界。...
-
代码质量不是靠 Review 喊出来的
很多团队一说代码质量，第一反应就是加强 Code Review。这话当然没错。Review 很重要。但如果一个团队平时没有质量标准，需求又赶，设计也没对齐，测试用例也不完整，...
-
任务拆分不是把大需求切成小需求
我以前拆任务，喜欢把一个大需求拆成几个模块。前端页面一个任务，后端接口一个任务，数据库表一个任务，测试用例一个任务。看起来很整齐，排到项目管理工具里也挺像那么回事。但真正做起...
-
为什么需求总是在开发中变形
做软件久了，你大概率听过这句话：“需求又变了。”说这话的人通常有点无奈，有时还带点火气。开发觉得自己刚写完，产品又改；产品觉得自己只是补充细节，怎么就叫变更；测试觉得验收标准...
-
技术负责人到底负责什么
刚开始做技术负责人时，人很容易有一种错觉：是不是我得比所有人都懂，所有问题都能答，所有代码都能接？这种想法挺正常。毕竟很多技术负责人都是从开发里长出来的。以前靠的是把代码写好...
专题 / 9 篇
MES现场落地手记
做 MES 系统，最怕一开始就关在会议室里画大架构图。真正的问题往往藏在产线、设备、点位表、扫码枪、测试机和现场网络里。这个系列会从现场落地视角，拆开 MES 架构该怎么做。
专题 / 11 篇
高并发海量数据系统架构
这个系列会用一个活动商品与订单系统作为贯穿案例，从缓存、数据库、消息队列、一致性、服务保护、热点流量、可用性和可观测性几个角度，讲清楚高并发系统真正要做的工程取舍。
专题 / 10 篇
一个技术负责人眼里的软件团队
带软件团队最难的往往不是把任务分下去，而是让团队对目标、节奏、质量和风险有同一套理解。这个系列会从技术负责人的视角，聊聊小团队真实交付里的那些麻烦事。
专题 / 9 篇
带团队以后，我才明白的事
带团队以后才会发现，技术负责人面对的不是简单的分任务和催进度，而是目标、节奏、质量、风险和人的状态。这个系列会聊一些真实项目里慢慢想明白的事。
专题 / 12 篇
公司把 AI 用起来
企业 AI 真正难的，往往不是选模型或搭 Agent，而是让负责人亲自使用，让员工愿意改变工作方式，再把流程和数据一点点整理成 AI 能够调用的企业能力，而不是停留在一场漂亮的演示里。
Latest