技术文章

小团队一聊流程，气氛经常有点微妙。有人觉得流程是大公司那一套，麻烦、慢、形式主义。也有人觉得没有流程不行，需求乱、上线乱、问题也乱。这两种感觉都对一部分。小团队确实怕流程太重。人本来就少，再天天填表…

聊团队安全感，很容易被误解成“大家都开心就好”。其实不是。软件团队当然需要目标，需要压力，也需要对结果负责。没有压力的团队会松散，没有结果意识的团队也很难交付。但如果一个团队完全没有安全感，问题会更…

很多新人进团队，第一句话就是：“你先熟悉一下代码。”这句话太常见了。说的人通常也没恶意。团队忙，项目赶，老同事手里都有活，先让新人自己看看，似乎是最自然的安排。但问题是，一个陌生系统的代码，对新人来…

软件团队里，会议很容易越开越多。需求评审、技术评审、站会、周会、复盘会、临时对齐会。日历看起来很充实，群里也一直有人说“拉个会聊一下”。但很多人心里其实清楚：有些会开完以后，问题并没有变清楚，只是大…

项目延期以后，复盘会很尴尬。因为大家都知道项目没按时交，但每个人都能说出自己的理由：需求变了、接口晚了、测试环境坏了、线上问题插进来了、某个同事请假了、评审时没想到这个边界。这些理由很多都是真的。但…

很多团队一说代码质量，第一反应就是加强 Code Review。这话当然没错。Review 很重要。但如果一个团队平时没有质量标准，需求又赶，设计也没对齐，测试用例也不完整，最后指望 Review …

我以前拆任务，喜欢把一个大需求拆成几个模块。前端页面一个任务，后端接口一个任务，数据库表一个任务，测试用例一个任务。看起来很整齐，排到项目管理工具里也挺像那么回事。但真正做起来，经常会发现：任务是拆…

做软件久了，你大概率听过这句话：“需求又变了。”说这话的人通常有点无奈，有时还带点火气。开发觉得自己刚写完，产品又改；产品觉得自己只是补充细节，怎么就叫变更；测试觉得验收标准一天一个样；业务觉得我一…

刚开始做技术负责人时，人很容易有一种错觉：是不是我得比所有人都懂，所有问题都能答，所有代码都能接？这种想法挺正常。毕竟很多技术负责人都是从开发里长出来的。以前靠的是把代码写好，把问题解决掉。突然有一…

有一段时间，我对“带团队”这件事的理解特别简单。需求来了，拆一下任务；谁熟哪块，分给谁；每天问问进度，快延期了就多催两句。听起来也没什么问题，很多小团队刚开始都是这么跑的。但后来我慢慢发现，真正让人…