夜雨聆风每个都有真实案例 + 根因分析 + 你可以做什么
上期我们认识了 8 个关键角色，这期来看「事情会怎么出错」。
新手做项目，几乎一定会踩这 10 个坑。不是因为你不够聪明，而是因为这些坑「看起来不像坑」。
这期的讲法：每个坑都用「真实故事」开头—— 看完故事，你就知道「哦，原来这就是那个坑」，然后我会告诉你「你可以做什么来避开它」。
这些建议，不需要你懂代码，只要你在项目里（不管是什么角色），都能用得上。
小王是一家金融公司的业务员。公司要做一个「内部数据分析系统」。
产品经理问了小王 3 个问题，就回去写 PRD 了。
3 个月后系统上线，小王一试——完全不是他想要的。
问题出在哪？
产品经理问的是：「你要一个能查数据的系统，对吗？」
小王说：「对。」
—— 但小王真正想要的是：「能自动生成日报，并且一键发送给领导」。
「查数据」和「生成日报并发送」，完全是两回事。
因为需求阶段没聊透，做了 3 个月，做出来的是「错的」。
- 业务人员说不清楚需求
：「我要一个好用的系统」——什么叫「好用」？没说清楚。 - 产品经理没追问
：「好用是什么样？能不能举一个具体例子？」——没问，就按自己的理解写了 PRD。 - PRD 没有让业务人员确认
：写出来就直接给开发做了，没人再核对一遍「这写的是不是我要的」。
- 多问「为什么」
：产品经理来问需求时，你多问几句：「你问我这个，是要解决什么问题？」—— 帮他更准确地理解你的需求。 - PRD 要「签字确认」
：PRD 写完后，你要认真看一遍，确认「这写的是不是我要的」—— 如果有偏差，这时候改还来得及。 - 用「场景」来描述需求
：不要说「我要一个好用的查询功能」，要说「我每天都要查 3 个产品的净值，现在要手动查 3 次，希望能一次全查出来，并且导出成 Excel」。—— 越具体，做出来的东西越接近你的预期。
某创业公司要做一款 App。技术负责人说：「我们要用最新的 XXX 框架，这个很酷，性能很好！」
团队里没人用过这个框架。
前 2 个月进展很慢—— 大家都在「边学边做」。
做到第 3 个月，遇到一个奇怪的 Bug，全团队没人能解决。
最后花了 2 周，在外面请了一个「专家」来帮忙，才解决。
如果一开始选一个「团队熟悉的技术」，这 2 个月本来可以做出更多功能。
技术负责人有「追新」的心理—— 用最新的技术，简历上好看，跟朋友聊天时有面子。
但最新 ≠ 最好。最适合的技术，是「团队熟悉、社区活跃、出了问题能找到解决方案」的那个。
- 问一句
：「这个技术，团队里有人用过吗？如果出问题，能找到解决方案吗？」—— 不需要你懂技术，只要问这一句，就能让技术负责人三思。 - 看「社区活跃度」
：让技术负责人给你看「这个技术的社区活跃吗？最近 3 个月有没有更新？出问题去哪里找答案？」—— 如果社区不活跃，说明用的人少，出了问题很难解决。
某电商公司要在「双 11」前上线一个新功能：「一键凑单」。
时间很紧，测试工程师说：「这个功能还没测完，能不能延期上线？」
产品经理想：「双 11 流量最大，如果不能上线，就错过最佳时机了！」
老板拍板：「上线！有问题后面再修！」
上线当天，流量暴增。
「一键凑单」功能有个隐藏 Bug：某些情况下会重复扣款。
有 30 多个用户被多扣了钱。
公司不仅要退款，还要公开道歉，品牌形象受损。
如果当初多花 3 天把测试做完，这一切都不会发生。
「差不多就行」的心态 + 「时间来不及了」的压力 = 跳过测试环节。
但测试是上线前最后一道防线。跳过测试就上线，就像「房子没验房就入住」—— 住进去才发现墙面渗水、电路短路，修起来成本更高。
- 坚持「测试不完不上线」
：如果你是产品经理/项目负责人，不要因为「时间来不及」就压缩测试时间。可以「分批上线」（核心功能先上，非核心功能后面再迭代），但不能「未经测试就全量上线」。 - 问一句
：「这个功能测试覆盖率是多少？」—— 测试工程师会告诉你「覆盖了 80% 的场景」还是「只测了正常情况，没测异常情况」。如果后者，要警惕。
老张是一家公司的后端工程师，写代码很厉害。
但他有个习惯：不写注释（「这行代码是干什么的」不写说明），也不写文档（「这个功能是怎么实现的」不写记录）。
他说：「代码写得这么清楚，一看就懂，不需要注释。」
3 个月后，老张生病请假了。
另一个程序员小李来接手老张的代码。
小李看了 3 天，完全看不懂：「这个逻辑是为什么要这样写？这个变量代表什么意思？」
最后，小李花了 2 周才把老张的代码逻辑搞清楚。
如果老张当时写了注释和文档，小李 2 天就能接手。
程序员有一种错觉：「代码是我写的，我肯定永远记得它的逻辑。」
但事实是：3 个月后，你自己都看不懂自己写的代码。
注释和文档，不是「给別人看的」，而是「给 3 个月后的自己看的」。
- 问一句
：「你们代码有注释吗？如果这个人离职了，别人能接手吗？」—— 这是个很好的「团队成熟度」测试问题。靠谱的团队会告诉你「我们有代码规范，关键逻辑必须写注释」。 - 要求「交接文档」
：如果有程序员要离职/调岗，要求他写一份「这个功能是怎么实现的」文档—— 这样后面接手的人不至于抓瞎。
某公司的代码库（存放所有代码文件的地方），有 30% 的代码是「死代码」—— 就是「已经不用的功能，但没人删掉」。
为什么会这样？
每次加新功能，程序员就在原来的代码上加新的。
原来的功能不用了，但也没人删：「万一下次要用呢？删了到时候找不到。」
3 年后，代码库变成了「垃圾场」：
新功能要加一个逻辑，发现有个「好像类似」的旧函数—— 要用它还是重新写？ 测试工程师要测一个功能，发现代码里有 3 个「疑似相关」的函数—— 都要测吗？
「不清理」的本质是「怕删错了」。
但没有「不用的代码」会因为「没人删」而自动消失—— 它只会被「越来越多」，直到整个代码库变成「烂摊子」。
- 问一句
：「你们定期做代码清理（重构）吗？」—— 靠谱的团队会每个 Sprint 留出 10% 的时间做代码清理，防止代码库变成垃圾场。
程序员小刘和小陈分别负责两个功能。
小刘在写「日报生成」功能时，需要用到「产品信息」数据。
小陈也在写「产品查询」功能，也用到了同一份产品信息。
两个人各写各的，用了两套不同的数据格式。
最后联调的时候发现：小刘的程序读不了小陈的数据—— 要花 3 天重新统一格式。
如果他们一开始就沟通过：「我需要用到产品信息，你打算用什么格式？」—— 5 分钟就能统一，不用浪费 3 天。
- 坚持开「每日站会」
：每天 15 分钟，每个人说三件事：昨天做了什么？今天打算做什么？有没有卡住的地方？—— 这是最简单、最有效的沟通方式。 - 有卡点立刻说出来
：不要「自己先研究一下」—— 如果 30 分钟没解决，就要说出来，让团队帮忙。
项目刚开始时，技术负责人做了一个决策：「用户数据存在本地服务器，不上云。」
没有人问「为什么？」，也没有人记录下来。
1 个月后，新来了一个运维工程师。
他问：「为什么用户数据存在本地服务器？放云端不是更安全吗？」
没人能答出来。
技术负责人也不记得了（「当时可能是考虑成本吧？也可能是考虑性能？」—— 不确定。）
最后花了 2 天重新分析利弊，结论是应该上云—— 如果当初记录下来，2 天就可以省掉。
- 重要决策要有书面记录
（专业说法叫 ADR—— Architecture Decision Record）：记录「什么决策、为什么做这个决策、谁做的、什么时候」—— 不需要长篇大论，3-5 句话就行。 - 在会议纪要里记录决策
：每次开会讨论了某个技术/产品方案，会议纪要里要写清楚「最终决定是什么、为什么」。
老板问程序员：「这个功能要多久？」
程序员想了一下：「大概 2 周吧。」
2 周后，老板问：「做完了吗？」
程序员：「还差一点，再给我 1 周。」
1 周后：「那个功能改了一下需求，要加 3 天。」
又 1 周后：「联调的时候发现接口有问题，要修 5 天。」
从 2 周变成了 2 个月。
老板很生气：「你当时说只要 2 周的！」
程序员也很委屈：「我没想到中间会有这么多意外。」
低估工作量有两个原因：
1. 只估算了「写代码」的时间，没算其他环节（需求确认、设计评审、前后端联调、写测试、改 Bug、部署上线—— 这些加起来可能跟写代码的时间一样长）
2. 只算了「正常情况」的时间，没留缓冲（人生病了、电脑坏了、需求变了、遇到技术难题了—— 这些都是「计划外」的事情）
- 要求「拆细估时」
：不要问「整个功能要多久」，而是问「这个功能可以拆成哪些小任务？每个小任务要多久？加起来再乘以 1.5 倍缓冲」。 - 用「1.5 倍原则」
：任何时间估算，都乘以 1.5。比如程序员说 2 周，你心里预期 3 周。这样就算有意外，也不至于「严重超期」。
某互联网公司上线了一个「用户注册」功能。
程序员为了赶进度，用户密码没有加密—— 就是说，密码在数据库里是「明文存储」的。
3 个月后，黑客入侵了数据库。
所有用户的密码全部泄露。
公司不仅要通知所有用户修改密码，还面临法律诉讼。
如果当初花半天时间做「密码加密」（这是一个很基础的安全措施），这个问题就不会发生。
- 从第一天就把安全当成需求
，而不是「事后补救」。上线前问一句：「有没有做安全评估？用户数据会不会泄露？」 - 如果是金融/医疗/政务系统
，一定要请专业安全团队做一次「安全审计」—— 就像盖房子要找质检站验收一样。
某公司做了一个内部系统，上线那天大家很兴奋。
一个月后——
用户发现一个 Bug，不知道找谁反馈，就放弃了 系统某个晚上崩溃了，第二天早上才发现（因为没有设置监控告警） 新来的员工不知道这个系统是干什么用的（因为没有使用文档）
上线前就要做好这几件事：
- 指定负责人
：这个系统上线后，谁负责日常维护？（出 Bug 找谁？用户反馈转给谁？） - 设置监控告警
：系统崩了要第一时间收到通知（就像家里装了烟雾报警器—— 着火了自动报警） - 建立用户反馈渠道
：用户遇到问题，要有一个明确的地方可以反馈（比如：微信群、意见反馈按钮、客服邮箱） - 写使用文档
：告诉用户这个系统是干什么用的、怎么用、遇到问题找谁
零基础想学开发？这份 5 步路线图请收好
每一步都有「你可以做的具体行动」，不需要你先学会写代码
课程 4/5 ｜ 避坑指南篇
预计阅读时间：12 分钟
下期：课程 5/5 ｜ 学习路线篇
