闭环思维之follow through和及时反馈

上周晚上一点多大佬果然大佬们都精神好 在企业微信群分享了他的一些思考，看到后觉得太有道理，深受启发，对照着自己平常的工作方式，聊下自己的体会，写出来分享给大家

以下是原话：

····省略一大段 ····

闭环思维主要是两点，第一凡事要 follow through，跟进到底; 第二是及时反馈，主动反馈。

1. 推一个流程，不是流程发布了就完事了，如果没有后续的流程宣讲，监督，反馈，改进，就不是闭环，流程就得不到真正落地
2. 开发一个功能，不是提测了就完事了，也不是上线就完事了，还有上线后的功能检查，用户反馈，都做到位了，才是闭环
3. 大家做事情，如果有遇到你的 leader 或者 peer 主动来问你进度，那你就要反思了，反思自己的主动反馈是不是做得不够，说到主动反馈，特别是跟自己leader的主动反馈，其实很多人都做得不够，很多人担心会不会打扰到 leader，leader 会不会觉得烦，等你做了 leader 后，你就会明白，leader 不拍打扰，不会烦，leader 最怕下属给他 surprise，平时不反馈，以为一切正常，突然在 deadline 到来前说出问题了，要延期了，如果遇到重大项目，关键项目，出现这种 surprise，leader 会吐血

····省略一大段 拍手叫好的马屁 ····

看到这段话后，我反思了下我自己的工作方式，挺有感触的，聊聊自己的理解。

闭环思维

平常自己把代码码完，部署好后，扔给测试，自己就去接着码别的代码去了，测试有 bug 再改，也没有了解过写这段代码是为了啥业务，后续推进是怎么样的，用户用的感觉这么样。管它勒，没空~~，我还要去看看 流行的 Flutter，single-spa，又出了哪些新框架，内心觉得自己很勤快啊，没划水~~，一般这种跟进问题其实心里觉得都是产品经理或者项目经理该做的，自己只要把代码码好就可以了， 思考了下如果跟进了这个流程了，在编程的过程，视角会在一个更高的地方，我把这个闭环拆成 2 个维度 1： 以业务为主线，牵涉到 开发，产品，运营这条线； 2： 以项目架构为主线，牵涉到 前端，后端，项目部署，认证体系，鉴权体系，数据库，日志这条线

以业务为主线

第一，最直接的好处是能预估到接下来可能遇到的业务场景，提前在代码层面留好口子，方便扩展。 第二，当熟悉目前做的这件事事干什么，效果怎么样，在接下来和产品开需求评审的时候就可以提让产品信服的建议，产品和开发最常见的问题，就是产品提出某个需求，开发觉得很傻逼，不想做，产品让开发说个 1，2，3理由，开发来又说不出原因，来回就是这个功能没意义，实现有难度..... ,要是很明白刚才说的这些，就能说出个让产品信服的 1，2，3 来

以项目架构为主线

这个意思是 弄明白当前项目的架构，部署，登陆认证，鉴权....，而不是仅仅停留在 后端给 API，负责渲染就可以了，这样的好处是 能明白自己目前做的东西，处在项目架构的哪个位置，出现 API 调不通可能出现在哪个整个架构的哪个地方 还有就是和后端交流 撕逼 也有话语权，本质上前端随着工作年限的增加，自然而然会参与到 项目的架构设计，接口定义中去，而且前后端很多设计思想是相同的(比方发布订阅这套，前后端都有)，了解这些都有利于自己在技术视野的成长，也方面和别人吹水。

及时反馈

这个感触更深了，之前在 SGM 负责 围绕 Angular 框架的基建工作，从来没主动给韩老大汇报下自己工作状况，除了每周的周会(有时候也不开)讲讲自己的工作情况，平常在基本没有给他讲自己现在做的事，心里想着 和上面真是一模一样，担心会不会打扰到 Leader 啊 ， Leader 这会可能在开会啊，可能在开车啊，可能在聊骚啊，反正就是各种心里想的理由，在开发过程中遇到些问题，能通过代码搞定，绝不会让他找找啥资源，看能调动下不，有时候韩老大就会主动过来问下，现在在做啥，遇到啥问题没有，需不需要外部资源，幸好自己还比较靠谱，没捅啥娄子；

跟 Leader 多沟通，多汇报，讲自己遇到的困难，讲自己的想法，讲自己的解决思路，这样 Leader 心里不慌，遇到问题给你出主意，协调外部资源，比自己一个人埋头吭哧吭哧强多了，领导知道你的想法，这样也能更加了解你做事风格，擅长点，以后也好给自己安排任务。

及时反馈 最重要的一个点，应该是沟通，时时牢记， 主动沟通，和 Leader沟通，和团队同事沟通，和兄弟部门沟通。

以上是我的心得体会，分享给大家，欢迎留言讨论。