我们是怎么开始写‘失败日志’的

去年年中，我们团队在做一个客户管理系统升级项目。项目不大，六个人，周期三个月。按理说应该挺轻松，结果前六周就卡住了两次迭代，每次都是因为“以为对方知道了”——需求变更没同步、接口字段改了没通知、测试环境配置漏了一项。

最后一次开会，产品经理摔了笔：‘能不能有点责任感？’

我没说话，但心里清楚，不是没人负责，而是责任太分散，信息像漏勺里的水，从缝隙里全流走了。我们每天站会讲进度，每周填Excel汇报，可那些‘小问题’永远进不了会议纪要，也上不了PPT。

那天晚上，我在家翻管理类书，看到一句话：‘透明的失败比虚假的完美更有价值。’第二天上班，我跟大家说：‘从今天起，每人每天下班前写一条‘失败日志’，不用长，五十字就行，写你今天搞砸的事，或者差点搞砸的事。不批评，不追责，只记录。’

有人翻白眼，有人说‘又要填新表？’，但我坚持。我还加了个条件：必须公开，放在共享文档里，全员可见。

为什么是‘失败日志’，而不是‘每日总结’？

我们试过很多工具。Trello、飞书任务、钉钉待办……都挺好用，但它们天生带着‘完成导向’。打钩、划掉、绿条进度满格，让人上瘾。可问题是，管理不只是推进度，更是预防风险。

‘失败日志’的核心不是记录错误，而是建立一种‘容错文化’。当一个人敢写下‘我把测试数据删了，幸好有备份’，说明他不再害怕暴露弱点。而别人看到这条，会想：‘哦，原来他也犯这种错，那我下次传文件前得多确认一遍。’

两周后，变化悄悄发生。有人写：‘我以为前端同事知道我要改字段名，没提前说，导致他返工两小时。’第二天，这人主动在群里@所有人发变更通知。还有人写：‘我昨天没看日志，不然就能避免重复踩坑。’——你看，连阅读习惯都被带动了。

最意外的是，日志里开始出现流程建议。比如：‘每次部署前能不能有个 checklist？’、‘需求评审时能不能拉上运维？’这些原本需要专门开流程优化会才能挖出来的问题，现在每天自动冒出来一条。

失败日志 + 自定义表单 = 管理的‘最小闭环’

光写日志还不够。有些问题反复出现，比如环境配置、权限申请。我们决定把高频‘失败点’转成自动化提醒或审批流程。

这时候，我用了蓝点通用管理系统。它不像ERP那么重，也不像Excel那么散。我们用它的无代码表单功能，做了几个小工具：

• 部署检查表：每次上线前必须填写的10项确认，少一项就不能提交。
• 权限申请流：谁申请、谁审批、时效多久，全程留痕，还能自动抄送日志文档。
• 失败案例库：把日志里有价值的条目归档，打标签，比如‘沟通遗漏’、‘配置错误’，新人入职可以当学习材料。

关键是，这些都不是一开始就设计好的。我们是先有日志，再从中提炼模式，最后用工具固化。蓝点的好处是改起来特别快，今天发现漏了个字段，明天早上就能加上，不用等开发排期。

有次老板来看我们的系统，说：‘你们这不像管理系统，倒像个团队日记本。’我说：‘对，就是日记本，只不过每一页都能变成流程节点。’

它不是万能药，但治得了‘假装高效’

当然，失败日志也不是天天都有人写。忙起来的时候，有人拖到晚上十点补一条：‘今天太忙，忘了写日志。’——这本身也是个失败，值得记下来。

还有人担心被上级用来‘秋后算账’。所以我们明确规则：日志不纳入绩效考核，管理层不能截图问责。它的唯一KPI是‘是否促进改进’。如果一个问题被提了三次还没解决，那该追责的是流程，不是个人。

现在回头看，最大的改变不是效率提升了多少，而是团队说话的方式变了。以前开会，大家习惯说‘没问题’；现在会说‘有个风险，我昨天日志里写了’。这种坦诚，比任何OKR都珍贵。

上周新来的小哥问我：‘为啥不直接用大厂的项目管理软件？’

我说：‘因为它们总想帮你把事情做对，而我们先要学会承认做错了什么。’