在大公司工作待過一段時間，看過一些人風光的進來，黯然的離開，而一些人平凡的進來，結果年終考評他最好。總結一下職場工程師的一些工作思維。

優秀案例1：（內務篇---本質工作）

?事件：在iOS 10.3 beta 版本中，我們了解到iOS?KeyChain存儲策略變更，刪除APP之后當前APP在KeyChain中存儲的信息也會被刪除。

蘋果官方回復如下：

This is an intentional change in iOS 10.3 to protect user privacy. Information that can identify a user should not be left on the device after the app that created it has been removed.

It has never been a part of the API contract that keychain items created by an app would survive when the app is removed. This has always been an implementation detail.If a keychain item is shared with other apps, it won’t be deleted until those other apps have been deleted as well.

? 簡單說明：蘋果現在越來越注重用戶的隱私，就引發了這個問題。

?背景：目前iOS 10.3還沒有正式發布，但是iOS 10.3 beta已經暴露出相關問題，我們項目里面又用到了相關技術點，一旦iOS 10.3正式發布，會對我們的項目產生影響。

? 注釋：

? 1.時刻關注業界動態

? 2.今早發現問題和影響面，在問題正式暴露之前，解決掉它?

在得知這一確切消息后，你應該采取哪些行動。

行動：

?1.驗證這個問題==》確定iOS 10.3 beta是否真的出現KeyChain存儲相關問題

?2.分析問題==》目前KeyChain 存儲策略的改變，會對我們項目有哪些影響

? ? ? ? ? a.我們項目中現階段，有哪些代碼會受到相關影響。

? ? ? ? ? b.補救措施有哪些。

? ? ? ? ? c.因為這是beta版本，不能確定，需要后臺配置開關，以防蘋果到時又變卦，這就有了補救方案。

?3.上報問題==》及時向上級領導報告這個問題，上報問題也要看你所在職務做不同的上報策略：

? ? ? ? ? a.如果你僅是小兵一個，而這個問題涉及太多，一時半會做不完，你就要先上報了，請求領導分配一下任務和相關人員的支持.

? ? ? ? ? b.如果你是個leader，那么你把這個任務分配好后，把影響點，應對策略，降級補救方案等等，確定好后，可以上報了。這樣好處，你給領導的的一套一套解決方案，而不是只上報問題。

總結：以后遇到事情后，你按照這樣的思路做事情，領導自然會很信任你，很放心把一些事情交給你。（加薪 、提升? 指日可待）

優秀案例2：（合作篇）

事件：上線了某個業務，產品經理分析打點的數據，發現數據很奇怪，于是，找到技術，懷疑工程師插入打點的數據有問題，凡是做技術的都知道，打點這類工作，凡是不改大的框架，簡單的插入打點代碼，幾乎不會出現錯誤。工程師查看代碼后，說這個不可能是代碼問題。但是產品經理堅持這樣數據肯定有問題。

背景：這類事情嘛，尤其在大公司比較普遍，這事情不是bug，也不影響用戶體驗，而且代碼邏輯簡單，很多工程師幾乎不把這個事情當回事。但是，產品經理等人就覺得數據有問題，和業務場景出入比較大。雙方就互相踢皮球，一直這樣“扯皮”了。

行動：

? ? ? ? 1.從產品入口開始打點

? ? ? ? 2.用戶的每一步操作行為都打上點（包括產品經理沒有要求的數據）

? ? ? ? 3.統計數據

? ? ? ? 4.分析每一步數據，用戶上一步操作，到用戶下一步操作數據比較，一步一步下去，形成漏斗形式，通過這種方式得到最終數據。

? ? ? ? ?5.產品經理獲取數據，一般只是最終數據，缺少中間數據。

? ? ? ? ?6.對比漏斗數據和 產品經理最終數據，來告訴他們數據的合理性。

總結：通過數據漏斗的方式，科學的記錄用戶數據，避免了“扯皮”事件的發生。

舉一個反面例子：

小A（化名）有著5年大公司工作經驗，技術也很優秀，被公司招到架構組，結果沒過試用期，就被勸退了。

原因：小A工作表現和領導的期望值，差距蠻大。

分析：“工作表現”和“期望值”這個怎么解讀。

具體事件：作為架構師，當然是架構方向的事情，做技術的也知道，一旦公司穩定后，哪有那么多的架構可以改造（有些公司KPI），一般公司哪會明確的指出架構方向，大公司都是被業務推著走，所以作為架構師，應該自己主動的去發現，那些可能存在的問題（別在意問題小），只要可以增加app的穩健性，提高代碼開發效率，方便大家用，都可以提出來，并驗證一下。千萬別讓你領導跟你說，“我們架構需要在安全方面在改進一下，比如 - - - ”。（如果你被動提出需求，你離開除不遠了）

第二個事情，就是穩健了，肯定會遇到線上bug等問題，這個時候一定要留下來，積極去分析解決這些問題，就算這個問題不是你的責任，你有時間，一定抽空去解決問題，就算能力不夠解決不了，一定要找相關人員配合解決問題。（該加班的加班，該熬夜的熬夜，至少表明你們作為一個team，一起fighting），千萬不能有那種思維，“不是我的責任，關我P事”這是職場大忌。

簡單的分享這三個案例，給大家一個工作思路吧。畢竟現在，在你周圍同事之間，技術水平都差距不會太大，想要工作突出，除了自身技術過硬之外，在工作思路和工作方法上也需要多學習，多總結。