一切不可能，終將化為尋常。 喜歡一個人就說喜歡，心存感恩就說謝謝；說反話并不會引起別人的關注，只會把人越推越遠。。 本文已收入至我的GitHub倉庫，歡迎Star：github.com/JavaKongHao,里面也有我個人聯系方式有什么問題也可以直接找我。 前戲：今天是十二月二號，是個特殊的日子，今天是12月的第一個工作日，本月也是19年的最后一一個月。 就在今天，空號破處了————發生了第一次交通事故，追尾女司機。（好在，剎車及時，事故不大）

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

正確的面對一個需求

??多問幾個為什么：這比如你這個需求背后的目的和價值是什么？做了之后有什么預期的收益，為什么這么做就可以達到這個收益，你可以不直接問業務方，但是你也需要問自己，業務方的這個目標和做這個需求的路徑是否可以匹配得上，如果實現路徑存在邏輯漏洞或者不是最佳的則這個需求也就沒有做的必要性；
??給出替代方案：經過上面的步驟，其實你會發現你已經過濾了一批無效的一句話需求，而有些需求可能是有一定的存在價值，但是可能業務方提到的點并不是有效的方案或者說成本太大的方案，這時你就需要思考替代方案，盡量通過現有方案或者小成本的方式來滿足業務方，間接的達到“拒絕”的效果；
??不能直接說不，但可以有條件的說是：當你確定這個需求是 ok 的，但你確實暫時抽不出時間來搞定這個事情的時候，這時關鍵在于我們不能直接拒絕業務方，長此以往會影響到后續的合作關系，這種情況你可以說：這個需求我接受，但是我可能需要較長一些的緩沖時間或者砍一些需求(部分滿足)。又或者必須要按時上的話，不能保證項目的上線后的效果、質量等，讓業務方來做部分的取舍

提升開發效率和質量

你是否為一個口頭需求而忙不迭失的改代碼，又因為種種原因，需要改回去？你是否因為，拿到需求后沒有充分理解，制定技術方案，而導致寫到一半寫不下去？你是否因為，一千個人，一千零一種代碼風格，而導致花大量時間理解業務？你是否因為。。。。

影響開發效率的情況千萬種，唯有規范化流程，才是解決問題的正道。

也許不是所有項目都支持“瀑布模型”，但是標準化的流程，絕對通用！！!

懷有感激之情擁抱codereview，新人怕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,里面也有我個人聯系方式有什么問題也可以直接找我。

總結

以上是生活随笔為你收集整理的《空号》：聊聊我在阿里外包3个月学到了什么。。。的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。