解決乙個問題，可以靠個人的能力，也可以靠組織的流程，組織的流程就是組織的能力。
組織設計流程考慮的是可靠、可重用。論解決問題的效率，通過組織的流程大概率是不如靠個人能力的。但組織擁有很多個「個人」，乙個流程可以由多個「個人」共同完成，對於每乙個參與的「個人」，感受到的可能是「組織流程比個人能力解決問題更高效」。
因此，乙個可靠、可重用、又讓每乙個參與的「個人」感覺良好的流程，需考慮 3 個方面：
組織流程不健全時，很多問題要靠個人的能力來解決。隨著組織流程慢慢完善，組織對個人能力的要求逐漸下降，會出現「有能力但不出活」的現象，即兩個人能力差很大，但產出的價值卻差不多。這時候，需要讓有能力的人去負責流程中更複雜的點，或者去解決流程覆蓋不到的問題。
我是搞工程的，不是搞科研的。「能想通」和「能落地」二者互為充分必要條件。如果做乙個架構，我說我只有想通的能力，沒有落地的能力，那我覺得我根本就沒有想通。因為那些不能落地的因素，我就沒想通或者沒想過。
以前，我對切換領域有個感悟：要先從專家心態切到小白心態，好奇、求知、敬重。現在，我覺得這個感悟不夠深刻，境界還差得遠。讓自己切換心態，還是在和自己較勁。為什麼自己會有專家心態？永遠是小白心態，以求知為樂才是更美的境界。這也是受論語的啟發：
子貢曰：「貧而無諂，富而無驕，何如？」子曰：「可也，未若貧而樂，富而好禮者也。」
一些職場感想
不要相信領導給你畫的大餅 離開了，就不要回去 他說的為你好，都是套路而已 你會比你想象的更優秀 不要認為提增加工資不好意思，你不提，他永遠不會給你加工資 這就看你所處的隊友是怎麼樣的 如果隊友是乙個很拼的，可能你需要比他更拼才能出人頭地，當然也要注意方法，不是埋頭苦幹，隊友不知道，領導不知道 如果隊...
Coding的一些感想
1.明確模組要實現的功能，著重明確需要提供的介面，並在程式設計中對介面進行思考和改進，力求在其它模組的呼叫過程中，無論本模組如何改動，都不會對其他模組造成影響 2.編寫 的過程中，應該做好注釋的工作。本人在前期開發的過程中，經常懶得寫注釋，造成以後再用到這部分 時，就會如同重新寫一遍一樣，重新閱讀，...
最近的一些感想
第一次出差，感覺就是客戶最急迫的事情就是解決他們的現場問題，經過qa的多次測試來發現其中可能存在的隱患，並解決他們，為量產做好準備。然後就是如果有經過測試的rom.bin最好儲存乙份，以免在更新軟體之後測試出問題，不知道什麼原因，然後又無法恢復到以前的測試版本，出差需要帶一些筆，紙之類的東西，記錄一...