这是一篇字节内部信，来自张一鸣 2015 年写的文章。我非常非常认可，也经常给团队讲，今天也分享下~

对一份工作我们经常回答做了，或者做完了。但是每一个回答，代表的含义并不相同，很多时候是“做了”，并不是“做好了”。

• 这个功能我开发完了 ---- 但是没有跟进到测试并上线；

• Bug 修改已经上线了 ---- 但只改了一处还有许多类似 bug ;

• 新的设计已经上线了 ---- 但却没观察线上对比效果，没有跟进用户反馈；

• 员工需要的物品买了 ---- 只是没人知道使用，如何获取；

• 关于 xxx 邮件我已经发了 ---- 发了并不保证大部分人看明白了；重要问题并没有再确认关键人已经收到了。

• 内部工具已经开发好了 ---- 但没有推行起来被同事用起来，比如说明不清晰；

• 候选人已经沟通了---- 只是打了个电话简单问了下，并没有深入沟通；

• 发了内测通知 ---- 但是没有真正让内部用户用起来，或者没有后续收集到内部反馈，也就是没有发挥内测作用。

行百里而半九十，甚至很多情况下做了，虽然花了 90％的时间，效果接近于 0 ，其实是浪费人生。

• 比如一个功能开发：那就应该是该功能如预期的被用户使用了，统计后台上看到效果了；

• 比如添加一个办公设施，就是该设施被使用了，给同事带来便利了！ ;

• 比如写了一个总结文档或者通知文档，则是该文档让需要阅读的人看到了，看懂了，对阅读者产生了帮助。

• 好理解、有说明，不需要每次再依赖你，容易很多人用起来了---- 比如上线工具或者模块，应该在页面 上有清晰的说明如何使用，而不是每次都要找到作者请教或者帮忙；

• 稳定、可信赖，不是一个反复需要fix,给自己和他人制造负担的工作---- 比如发现一个容易犯错的 bug,不仅解决了该bug,还增加了单元测试避免再出现；

• 有反馈有数据，能够根据反馈继续改进，能够量化效果---- 比如内部工具上线了，应该关注使用的 DAU,询问没有用起来的同事有什么问题，提高它的使用率发挥它的作用；

• 解决问题背后的问题，成为其它工作的基础和示范---- 比如同事开会反馈会议室的水笔没水了，不仅更 换了水笔，还写了提示：请将没有水的笔随手丢进垃圾桶，并建立了更换机制；比如发现一个AB测 试验证了产品设计，那么把这个测试方法做成工具并给好说明，供其它同事之后每次类似设计使用。