《空號》：聊聊我在阿里外包3個月學到了什麼。。。

一切不可能，終將化爲尋常。
喜歡一我的就說喜歡，心存感恩就說謝謝；說反話並不會引發別人的關注，只會把人越推越遠。。
本文已收入至個人 GitHub倉庫，歡迎Star： github.com/JavaKongHao,裏面也有我我的聯繫方式有什麼問題也能夠直接找我。

前戲：今天是十二月二號，是個特殊的日子，今天是12月的第一個工做日，本月也是19年的最後一個月。
就在今天，空號破處了————發生了第一次交通事故，追尾女司機。（好在，剎車及時，事故不大）
複製代碼

咳咳。。。前戲結束，我們進入正題。。。

正確的面對一個需求

  多問幾個爲何：這好比你這個需求背後的目的和價值是什麼？作了以後有什麼預期的收益，爲何這麼作就能夠達到這個收益，你能夠不直接問業務方，可是你也須要問本身，業務方的這個目標和作這個需求的路徑是否能夠匹配得上，若是實現路徑存在邏輯漏洞或者不是最佳的則這個需求也就沒有作的必要性；
  給出替代方案：通過上面的步驟，其實你會發現你已通過濾了一批無效的一句話需求，而有些需求多是有必定的存在價值，可是可能業務方提到的點並非有效的方案或者說成本太大的方案，這時你就須要思考替代方案，儘可能經過現有方案或者小成本的方式來知足業務方，間接的達到「拒絕」的效果；
  不能直接說不，但能夠有條件的說是：當你肯定這個需求是 ok 的，但你確實暫時抽不出時間來搞定這個事情的時候，這時關鍵在於咱們不能直接拒絕業務方，久而久之會影響到後續的合做關係，這種狀況你能夠說：這個需求我接受，可是我可能須要較長一些的緩衝時間或者砍一些需求(部分知足)。又或者必需要按時上的話，不能保證項目的上線後的效果、質量等，讓業務方來作部分的取捨

提高開發效率和質量

你是否爲一個口頭需求而忙不迭失的改代碼，又由於種種緣由，須要改回去？

你是否由於，拿到需求後沒有充分理解，制定技術方案，而致使寫到一半寫不下去？

你是否由於，一千我的，一千零一種代碼風格，而致使花大量時間理解業務？

你是否由於。。。。
複製代碼

影響開發效率的狀況千萬種，惟有規範化流程，纔是解決問題的正道。

也許不是全部項目都支持「瀑布模型」，可是標準化的流程，絕對通用！！!

懷有感激之情擁抱code review，新人怕code review就像怕Error同樣。某大佬同事說，code review是一種哲學，不只提高代碼質量，也是一次學習的機會。他會不斷鞭策你作得更好。

從業務先贏到業務與成長共贏的轉變

不少新人，抱着去公司去學習的心態進入到一家公司，這樣的心態究竟好很差呢？首先，企業確定是歡迎具備上進行的員工的，可是企業也不是福利機構，招你進來是讓你來創造價值，創造利潤的。

之前，咱們團隊內宣揚業務先行、業務先贏，後來發現，業務是先贏了，可是我的的技術成長、沉澱，有些拉跨，那如何完成業務與我的成長共贏呢？

老闆們對此也進行過討論，結論是：團隊內的之間的學習交流佔比百分之70%，我的積極主動佔比30%。當你冷漠的拒絕別人的提問，就是給本身關閉一扇門，每一個人主動去幫助身邊的人成功，去分享本身學的新技術，你會收穫的更多。

你有沒有在閒暇時刻主動去汲取一些？對待新技術，你是否依然擁有熱情？學後有沒有沉澱?是否有作筆記、文檔或是博客等形式的輸出？

關於思考業務賦能和作技術規劃，實際上是一個很是值得不斷探討、摸索的過程，建議平時多和老闆， 團隊內大佬 溝通和交流，他們是過來人比較有經驗，能夠在思考的深度和格局給出很是多的建議，有的時候這種交流會有一種醍醐灌頂的感受。

不要隨便造輪子

前段時間，阿里併購網易考拉，完成跨境業務電商佈局。阿里有一種若隱若現的文化，告訴我，人家有不錯的東西直接用就好（"拿來主義"沒什麼很差），網易考拉跨境業務作的好，不必再去花時間再作一個。

當第一次接觸框架時，我就在想這輩子必定要寫個牛逼的框架，供世人使用。看着別人用本身的框架，臉上露出知足而又神祕的微微一笑緩緩走過。

不少對技術狂熱的朋友，熱愛源碼，並想作一些研發，造一些輪子，但咱們都知道一個成熟的技術須要時間的考驗，須要拍坑，要很長的週期才能達到比較好的效果。

不管是緩存，數據庫，搜索，消息中間件，等等不少隨便列幾個，都有一類多套的成熟的解決方案。能夠根據不一樣業務需求選擇使用。

若是你必定要作，先問本身幾個問題。你要作的是解決什麼問題？爲何要作這個（沒有可採用的技術嗎）？你該怎麼作？

批判性與結構化思惟

批判性思惟

①批判性思惟究竟是什麼？批判性思惟是指本身在決定要相信什麼或者要作什麼時所進行的合理和反思性的思考。

    ②爲何須要批判性思惟？爲了更好的學習，更加理性客觀的去思考問題，解決問題。咱們天天都接受外界很
    多信息，咱們對於信息和知識須要對話、互動，經過篩選和甄別造成本身合理的判斷。而這個對話、互動、
    篩選、甄別的過程就是一個批判性思惟的過程。

    ③3W模型。觀點的來源是什麼（what）？爲何是這樣（why）？不是如此又是怎樣（how）？
複製代碼

ps：我以爲3W模型，真的太萬能了。作任何事我均可以問本身，是什麼爲何怎麼作。

最後，請不要懷疑，惟一不須要懷疑的就是懷疑一切。

結構化思惟

①創建目標

	如何對事物抽象出具體目標，或是一個完整的任務？

②目標拆解（拆解維度）

	象限法則，根據輕重緩急去拆解任務。

	根據複雜程度去拆解。

	任務拆解的方式千萬種，具體業務具體分析，選擇一種最好的方案並討論。

③子項達成
複製代碼

決策前充分討論，決策後堅定執行。

高度與格局

若是說五感是人類對世界信息自覺得是的初級判斷，那麼認知則是人類對世界機理自覺得是的高級判斷。若是相似五感的接收器的改變世界的根本面貌（實際上是幻想），那麼認知的差異，一樣可讓咱們生活在不一樣的精神世界。

眼界決定高度，多看、多想、多保持好奇心、多問幾個爲何，長此以往天然就邁上了一個新的臺階。

不少人老是抱怨在本身公司只是寫增刪改查，沒有成長。那爲何一樣是CRUD,有人能從小公司走進BAT呢？一樣是寫if-else，有沒有想過如何code更優雅呢？

若是以普通的視角去看，那麼螺絲釘那也就只是一顆螺絲釘，可是若是跳脫出目前的視角，站在更高的角度去看，它實際上是航母的一部分。你的主管並非由於他是你的主管因此他就應該你比更高瞻遠矚，而是由於他看問題的高度比你更高、想得更遠、作得更深，因此才成爲了你的主管。

有意識地超前想一步，多想一點，學習一個技術一個組件，想一想爲何要學這個，能解決什麼問題。舉個例子：學Redis，爲何要學這個？學這個能作什麼？若是隻是想到緩解數據庫壓力就過低級了。有人說「鍵盤敲爛，月薪過萬」，沒有思考的代碼，是危險的。仍是要多思考，從宏觀角度，提高自我知識體系。

關於提高格局和看待問題高度，推薦兩本書《杜月笙傳》、《原則》。

關注軟技能成長

咱們是技術人，但咱們的工做中，代碼並非所有。咱們團隊可能僅佔百分之30

咱們有pd須要去了解需求，須要瞭解需求背景，一個需求開發以前須要交流技術方案

開發過程當中，咱們須要和相關的同窗去溝通，上下游進度不理想咱們還要去推進進度

開發完成，咱們又要去協做，完成聯調，提測。

出現問題，咱們又該對外怎麼說，對內怎麼作？
複製代碼

當你發現一個問題，有沒有以正確方式去落地？一聲不吭悶頭幹，你會發現幹得好沒事，幹很差惹身騷。（沒有團隊意識是很可怕的）

不管你身處何處，所爲什麼職，我相信你都不是孤軍奮戰，團隊或有大小。時刻擁有團隊意識，owner意識，作一件事情，爲你們想想必定沒有壞處。技術能讓你走的高，可是綜合素養才能讓你走得遠。

owner意識，時間觀念，以終爲始，閉環思惟，保持敬畏，事不過二，設計優先，善於提問，空杯心態。是否查漏補缺？

關於軟技能範圍太廣了，這塊我以溝通交流爲主線。推薦《認知心理學》、《傳播學概論》

及時自我總結

1.需求迭代的同時，兼顧問題的覆盤，總結，概括，團隊內分享。避免下次出現相同相似問題。

2.是否由小到大，見微知著。從需求出發，是否理解某一塊業務，理順上下游關係

3.經過一塊業務，是否充分理解相關技術框架/基礎組建的用法

4.整個項目構建，設計上，有哪些作的很差的地方？可否提出合理的改進意見或者推進改進？

5.團隊上：進度安排，溝通協調是否存在不足？
複製代碼

失敗的緣由千奇百怪，成功者的經歷不盡相同。成功者之因此成功，概括爲三點:解決錯誤，覆盤錯誤，避免錯誤。

聯繫我/公衆號

空號 | 文 【原創】【轉載請聯繫本人】 若是本篇博客有任何錯誤，請批評指教，不勝感激 ！
喜歡一我的就說喜歡，心存感恩就說謝謝；說反話並不會引發TA的關注，只會把Ta越推越遠。
本文已收入至個人 GitHub倉庫，歡迎Star： github.com/JavaKongHao,裏面也有我我的聯繫方式有什麼問題也能夠直接找我。