个人成长. --- 三个原则

行走江湖，每个人都有自己的处事原则，有些原则只适合自己，有些可能普适大众，有些是好原则，有些是坏习惯，如人饮水，冷暖自知。

一，闭环原则

如果你能够在完成自己工作任务的过程中，及时的把自己的工作成果反馈给你的 Leader 和相关协作人，总能够带来各种惊喜。你的反馈或许提升了团队效率，也可能改变了产品决策，同时你会因为持续的反馈获得更为重要的任务和职责，因为你是一个能够让事情形成闭环的家伙，一个脱离了低级趣味的人，一个靠谱的人。

闭环就是让事情有始有终，任务从启动到结束，形成一个完整的链条。CTO 给你安排了一个技术预研任务，你应该定期反馈的工作包括：技术选型、遇到的困难、解决的办法、最终的预研结果等等。任务的最后，你应该提交一份技术预研报告，并针对这样一个结果发起一次评审。

从一个独立的自我来说，具备这种反馈意识，迈出主动让事情闭环的第一步，你会发现，世界完全不同了。

可惜的是，很多技术人员只对技术有热情，对反馈毫无概念。接到任务之后默默预研，完成之后默默等待下一个任务的降临，只要没人问，就一直牙关紧咬，目光坚毅，打死也不说。如果分配任务的人疏忽了，这个任务可能无疾而终了。

闭环原则是工作中最常用也最有效的原则，但很少有人能够一直做到，以至于我需要不停的在工作中强调。这个道理就像“运动和良好的饮食可以帮助我们保持健康和身材”一样，几乎所有人都知道，但少有人做到。

二，谁难受谁推进原则

无论是谁，工作中总会涉及到大量的协作任务。A 依赖 B，B 依赖 C， C 依赖 A，好了，看起来这是个死循环，到底该谁去推进这件事呢？有的领导会再设置一个 D，去协调 A B C 的工作，结果 A B C D 攒一桌开始打麻将了。真的需要那么多的协调者么？并不是。

在跨部门或多组协作的时候，到底谁去推进工作，谁在观望等待？这里面有个简单的处理原则，如果这件事不做，你自己的部门或小组会非常难受，那么就毫不犹豫的去主动推进这件事。

举个例子，发布会临近，如果设计师没有提供设计图，产品经理没有提供产品规格，谁最着急？程序员们！这件事的最终结果是发布会期间必须上线新网站，设计可以慢一点，需求可以缓一缓，但后果是程序员们进行技术实现的时间会越来越少，程序员才是最难受的！所以技术组必须不断的催促设计师提供最终的设计稿，产品经理尽快提供参数规格，最终网站才能顺利的上线。如果技术等设计、设计等产品、产品等技术，是做不好事情的。让美好的事情持续发生，这一点说起来容易，做到真的很难！

如果技术等设计、设计等产品、产品等技术，是做不好事情的。让美好的事情持续发生，这一点说起来容易，做到真的很难！

三，Think bigger

总是从更大的层面考虑问题， 

在做一件事情的时候，往往会下意识的从更大的范围来考虑它。Think bigger！无论是什么，从更大的尺度去考虑，看看它会变成什么样。

你运营了一个公众号，每天一篇原创，写了两个月了，似乎没什么效果。那么拉长时间的维度，如果你坚持写，写了一年，写了十年，会是什么局面？

定好一个学习目标，无论什么情况，每天花费一个小时在这个领域，半年后看效果。如果不行，十年呢？很多时候，当你用一百倍的尺度思考了某个问题、产品和行为之后，你会发现生活的真正面目，有时候你会被自己吓一跳的。

参考：

   个人成长