一天內「被噴」7.5小時後感

1、被噴日程：

8：30 會議室開會

8：50  領導開噴

11：45 上午被噴結束

16：00 下午會議開始（開噴）

18：00  由噴工做思路轉向噴具體工做

20：30 」被「完成部分工做後回家繼續幹活

被噴點一：考慮問題缺乏宏觀

    被噴以下：大家啊，作技術出身的，考慮問題就那麼眼前一丁點的事，在我看來技術的問題都不是事隨便找個程序員就解決了，總考慮這麼丁點的東西怎麼作管理？作管理要把眼界放開，考慮問題怎麼能這麼細節？這和寫程序不同！@#￥%……&*（.....30分鐘+

    其實最近我也一直在考慮關於」技術思惟「的問題，即作什麼事都是喜歡鑽進去並且爲法自拔的陷入到細節中。根據自身的經歷和身邊的朋友來目測，這也許是作技術人員的一個通病，喜歡安靜、踏實的幹活，正是因爲這樣的心理致使程序員在考慮問題的時候不善於考慮處理事情的宏觀思路。

    什麼是宏觀，這個概念是相對的。我舉個例子（理想化的狀況下）：

    場景以下：

    村長：管理整個村，爲每家每戶作服務。

    縣長：管理整個縣及下面全部的村，每一個村向縣彙報內容。

    市長：管理整個及市下面全部的縣，每一個縣向市彙報內容。

    過於細節的狀況：縣長髮現某村的某戶出現了矛盾，之身去該村處理該戶問題。

    咱們不可否定該縣長的工做態度和工做成果。縣長確實是在處理和解決問題，但若是一個縣長老是處理村長該處理的問題，這個縣長真的稱職嗎？當有一天市長來到該縣問起：「這個縣的整體狀況怎麼樣？」，縣長回答：「哦，A村的某戶發生了什麼矛盾，我是怎樣解決的。B村的某戶發生了什麼矛盾，我是怎樣解決的......」。

    宏觀看待問題：站在縣長的職位上，所謂的宏觀回答市長的問題應該是「A村*****，B村******，但也有些住戶是***樣的，例如：A村的某戶、B村的某戶」。

    佔在不一樣的位置考慮的問題不同要宏觀，在和職位匹配。

    回到咱們熱忠的行業：若是你是設計師，應該考慮設計而非具體的實現。若是你是架構師，應該考慮架構而非設計和實現。若是你是PM，應該考慮管理干係人的指望，頁非技術實現細節。定好位，而後把高度提起來，堅定剋制本身看到代碼就想敲慾望。

被噴點二：若是有多條路可走，必定要選擇最取巧的

    被噴以下：解決問題的方式有N多種你信不信，這件事讓我處理我有10種辦法對付他，到大家手裏怎麼就這麼難!@#$%^&*30分鐘+

    園子裏確定有不少朋友都帶過私企和外企的項目，這類項目用戶有強列的需求和迫切的願望，在帶項目的時候用戶會把前面的不少路都主動鋪的很平，如：主動向領導彙報，主動發會議通知，主動發變動通知。致使咱們這些半技術半管理的二不像人員在處理項目的時候一直覺得用戶便是如此。當遇到不配合的用戶時還使用咱們最善於使用的手法去處理這個問題：踏實的幹活，客戶確定會滿意的。很傻很天真有木有。

    當遇到問題的時候，一種方式行不通必定要換一種取巧而且可以快速推動項目的方式。舉個最簡單的例子，你與客戶溝通始終得不到答案，對方的藉口就是「領導出差」等領導回來再說。這種狀況咱們怎麼辦？爲了推動項目上的工做咱們仍然與該負責人聯繫？發郵件打電話催他？少年，作事不是寫程序......

    方案（也許不妥）：一、再次給該負責人發郵件，郵件抄送全部相關領導。二、直接給能定事的領導打電話。三、四、五、6...

    咱們回頭想一想，爲何不能從一開始就直接找到這個領導而後讓該領導去安排下面的人去處理此事呢？

    兩種開展工做的線路，你會選擇哪一種？

    1.自下而上：與負責人溝通，定不了事讓該負責人去找領導肯定。

    2.自上而下：直接與領導溝通，讓領導安排負責人去作具體的事。

被噴點三：最大的風險就是本身不知道什麼風險

    被噴以下：你說下，這件事你是怎麼計劃的？回答：第一步&&**，第二步&*（。|||| 什麼？你就這麼作？誰給你確認了？若是第二步不&*（。這麼辦你怎麼規避這個風險？回答：即然已經第一步&&**，那麼第二步必定是&*（。||||什麼？第二步確定不成立，你就是在閉門造車，這些問題不考慮清楚一但發生了怎麼辦？最可怕的就是本身都不知道項目有風險！@#￥%……&30分鐘+

    作程序員出身的咱們老是覺得咱們作的事就像寫的程序，method a 調用method b 調用method c....而後結束...這又回到咱們最初的問題，程序員考慮問題太理想化。當咱們跳出程序員這個行業後會發現咱們不少程序員的思惟定式禁錮着咱們作事理想化。預知不出風險的存在。如：咱們要由北京去上海蔘加一個重要的會議，計劃是坐飛機能夠準時到達。那麼咱們是否要考慮飛機晚點的backup去規避不能準時到達的見險呢？作項目，要常常在本身考慮的問題前加「不」，若是「不怎麼怎麼樣」，個人備選解決方案是什麼來碰見風險。見險管理也是很重要的。

後記：

    此博文只隨便寫了幾點。悲催的被噴了整整一天，各類問題各類噴，說話被噴（工做思路有問題，這個問題你考慮過沒有？那個問題考慮的太不全面），不說話也被噴（太技術開會不說話），請問我是該說話仍是不應說話？雖然自信心有些小小的受挫，但仔細想一想有不少點仍是有道理的。有時候以爲本身更喜歡安逸的寫代碼，這也是一種生活方式。但是咱們獲得的是什麼呢？走出程序員的圈子，極可能咱們連事情都表達不清楚，不信？你對着鏡子去歸納一下新聞聯播就知道了~

版權：http://www.cnblogs.com/iamlilinfeng