俗話說「人老精，鬼老靈」，最近對這句話深有感觸。最近我們組一下壓了三個專案，兩個專案都是要乙個月之後要交的，產品經理和銷售經理都快急哭了，但是又不知道從那兒下手，開發計畫遲遲排不出來，公司老總聽了她倆反饋的情況，幫我們梳理了一下，頓時感覺眼前豁然開朗。說說自己的體會：
一、擺正心態，不要著急。「不積跬步，無以至千里；不積小流，無以成江河」，在多的工作也得一點點做，著急也沒用，所以就不要著急；
二、控制好自己的工作範圍。就是要對自己（大到公司，小到個人）所做的工作要有非常清晰的範圍定義，不要少做，但也不要多做，專案經理經常犯的乙個錯誤就是想當然的覺得客戶需要什麼功能，然後告訴技術要去做，這個時候做技術的就要多問為什麼，「客戶為什麼需要這個功能」，「客戶用這個功能解決他什麼問題」，「這個功能做完了誰會去用」等等，當專案經理說不清楚的時候，你就完全有理由說你連需求都說不明白，讓我們怎麼做？大多數情況下，這樣可以去掉很多功能；
三、要和客戶保持非常良好的溝通。首先這應該是市場的同事需要做的，通過和客戶良好的溝通，可以得到許多合同之外的資訊，舉個例子說吧，我們在給乙個化工企業做專案，專案的工作量非常大，有工廠的三維模型和二維的工藝流程圖，三維開發的工作量很大，二維的工藝流程圖工作量相對較小，剛開始我們的工作重點都放在三維模型的開發上，但是據我們老總對該化工廠廠長的了解，該廠長是搞工藝出身，對工藝流程圖很重視，而且也特別懂，但是三維模型很少看，所以老總果斷讓我們把開發的重點發在工藝流程圖上，只要工藝流程圖做好，這個專案就差不多可以驗收簽字了。
四、要讓甲方可以隨時看到我們工作的進度。這個甲方可能描述的不太準確，舉例說吧，技術部的甲方是市場，市場（代表公司）的甲方是客戶，有人可能會質疑第一條，說不著急，不著急，等到了交付專案的時間點看你怎麼辦。這就需要我們經常匯報我們的工作進度，或者我們把工作進度做成視覺化的檢視，讓客戶（市場）隨時了解（讓客戶了解工作進度的辦法有很多中，我們老總說最笨的辦法就是寫週報，月報），讓客戶（市場）心裡知道，我們每天都在完成你的專案，每做完乙個完整的功能，可以給客戶部署，演示，如果真到了之前商定的時間點沒做完，99%的客戶都是可以理解的。
五、隨時根據實際情況調整自己的開發計畫。這條建議是針對產品經理的，現實是隨時變化的，計畫也應該根據實際情況隨時變化。制定計畫應該是這樣的：根據現有的資訊指定計畫→市場獲取更多的資訊反饋給你→調整計畫→將改變後的計畫通知給公司和客戶（給客戶既要**通知又要發郵件）→技術部開發→
市場獲取更多的資訊反饋給你→調整計畫→將改變後的計畫通知給公司和客戶（給客戶既要**通知又要發郵件）→技術部開發
...周而復始，一直到專案的結束。
六、跳過中間承包商直接找業主。這個建議是針對市場人員的，如果你們公司是整個環節的最後一節，從業主那裡出來的需求資訊，經過中間承包商的轉述，可能完全就走樣了，所以一定要直接和業主對接，這樣可以少去很多誤導資訊。
關於運維工作的一點感悟
今天上午收到nginx延遲告警，通過新開發的ops平台上，直 到是網路丟包引起的，往常也會有類似告警，一般很快恢復了，當聽到周邊同事說 無法開啟了，意識到問題嚴重性，馬上開啟日誌系統，看到是mysql 異常，直接重啟故障 然後故障恢復。前前後後花費很長時間開發的平台，派上用場。1.乙個好的ops平台...
關於NSDictionary的一點感悟
nsdictionary和nsarray一樣，都不能直接儲存基本型別，比如 int float char等，而只能儲存物件！那該怎麼處理呢？很簡單，先把基本型別轉化成nsnumber物件，存進去 要取的時候，再從nsnumber裡面取出來。具體實現如下 float fnum 10 nsnumber ...
關於忙的一點感悟
最近這段時間開始，工作比較忙，會持續很久，以前也有過，所以有心理預期，也知道怎麼應對。個人投入到學習及寫作的時間會大大壓縮，但我依然會擠一點時間。我會嘗試比較簡短的文本來寫作，也算是隨筆吧。希望各位諒解。分享一下最近的一些感悟 1.忙碌，是一種狀態，我們要調整好自己的身體，這個至關重要，提前把家裡事...