闭环思惟之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沟通，和团队同事沟通，和兄弟部门沟通。

以上是个人心得体会，分享给你们，欢迎留言讨论。