本來很想寫篇技術分享的文章，構思了很多天，但想來想去還是放棄這個念頭，解決問題的方法總歸有很多種，也很難說我所分享的就是最優的解決方案，雖分享不論分量，也許僅僅只是一個點通思路的想法就足夠，但出于對技術的嚴謹考慮，遂轉入工作方法之分享命題。

以下是我對如何有效及高效工作的方法的一些總結，也是自2004年至今在開發上的一些心得，希望對那些需要幫助的同事們有所幫助。

一、有效溝通

對于溝通，這個我們再也熟悉不過的詞眼，也許你會認為很簡單，不就是與客戶打交道嘛，只要英語好，描述清楚問題，與客戶保持良好和密切的溝通，每天發好Daily Report，每天Skype/MSN保持暢通，要是口語好，那立馬高大上，各種膜拜與羨慕，但豈不知這一切都是溝通的最基本的先決條件，具備這些條件并不意味著我們就能很好溝通和有效溝通。

1. 盡力表述清楚問題，把握重點


2. 集中一個任務或問題
   在A任務沒有討論完之前，不要急于下一個任務


3. 分條描述
   寫一大段各種邏輯相互纏繞的描述，結果客戶只回了一句：I don’t understand. 不如有條絮的分段闡述問題，按邏輯順序列出1), 2), 3)來，用簡練且明確的詞匯表達清楚每一段問題，所有串聯起來不就是一個完整的邏輯，且這樣更有條理性


4. 圖片，鏈接外加關鍵字
   有些問題很難用語言去闡述，那就附帶圖片或鏈接的方式去說明


5. 舉例/畫圖/截圖
   以最直觀的圖表形式，配帶解釋性說明，圖文并茂，即便是英語不好，從圖表中也能分析出一二


6. 提出自己可行的解決方案
   在和客戶溝通之前，要先理出來自己的一套思路，把自己的理解告訴客戶，讓客戶幫你糾正，即便這個思路還不是很正確，且不可盲目無頭緒的去問。 如果是比較確定的任務，客戶拿不定主意，至少應該提出自己的可行方案去建議客戶


7. 永遠不要問客戶How to do?

二、梳理任務

事有輕重緩急，開發也不例外，不論是大任務還是小任務，其實我們都能把它拆分成不同優先級和不同階段的小任務，把需要做的所有點梳理成一個任務結構：

1. 任務優先級一目了然


2. 條理性清晰


3. 不易遺漏


4. 團隊進度很容易掌控，也容易評估時間，客戶也容易掌握項目的進展情況

對于一個大任務來說，這樣的任務計劃就顯得至關重要，好記性還不如一個爛筆頭，如果這個任務的周期很長，誰也難保證我們不會遺漏。我們完全可以借助一個工具，協助我們去管理任務列表，對于大中型團隊性質的項目，我們可以使用TP之類非常專業的項目軟件管理任務；對于中小型1-2人的項目，Trello是完全可以勝任的，我們在之前的項目中與客戶大量使用這個協同軟件，效果甚是明顯。

三、周密的時間與計劃安排，拒絕拖延癥

 

四、注重細節，充分測試

項目不同，有的項目客戶要求寫Test Case，有的則并沒有，當然Test Case并不是萬能的，這就要求我們在提交之前做到充分的測試。

大家稍加留意就不難發現，有的程序員寫的程序很少出錯，客戶滿意率極高；但有的卻頻頻出錯，被客戶打回來的幾率很高，從而客戶的滿意度在直線下降。當我們去Review這些代碼的時候，也許解決問題的思路真的是很不錯的思路，但往往就差在最后兩個關鍵環節——細節與測試。變量未聲明，數據未做過濾，大篇幅的COPY代碼，接口紊亂，瀏覽器不兼容，寫完代碼不測試，或者只測一次等等，然而，當我們再去多問一句：你到底測試過來？聽到的永遠都是很斬釘截鐵的回答：“……我當然測過了……怎么可能有BUG呢……”

一個完整的任務，如何去定義，可能每個人都會說出自己一套規則來，舉個很簡單的例子：

比如一個INPUT框，用戶希望輸入的是一個1-9的自然數，而我們在開發過程中往往會想當然的認為這個框就應該輸入自然數，因為我們對需求很清楚，也在測試中想當然習慣性輸入自然數，結果是測試都統統過了。

但提交之后，在客戶輸入0，-1，1.5，10，9.5后，大家想象會是什么樣的表情？

如果一個任務代碼寫完，只能說是完成了80%，沒有細節只能算是60%，沒有充分測試也僅僅只是個半成品而已。一個這樣的看似完成且很高效的任務，到頭來我們甚至得花雙倍的時間去FIX。

1. 團隊內部相互Review，指正不規范的代碼


2. 有把握的小任務至少測試3-5次，大任務幾十，甚至上千次測試


3. 預想各種可能出現的問題，用各種可能出現的模擬數據排查測試


4. Partner之間交叉測試，自己發現不了問題別人可以發現


5. 任何一次改動，都要考慮到當前接口改變是否會影響到其它功能，并且每個涉及到的功能都應測試


6. 任何一次UI的變化，都應在每個瀏覽器上進行測試它的兼容性


7. 站在非開發者的角度去試用功能


8. 謹慎且按時交付

 五、從客戶身上學習我們所欠缺的

做國內項目，大多面對的是終端客戶，大多數對技術也不甚了解，但對于我們ODC模式的國外項目，我覺得這是我這幾年感觸最多的一方面。 有的客戶懂技術，而且技術素養也很高，這其實對于我們程序員來說是一個絕佳的學習機會，從他們身上我們了解到國外目前流行且常用的領先技術，或者是一種先進的開發里面，一個完整的軟件開發體系，除了我們每天自己不斷的學習，從客戶身上我們也能了解和提升自己的眼界。

比如說：2011年底我們接手挪威客戶的ODC，項目負責人本身懂技術，只要是他看到的好的技術就會推薦給我們，比如說Git、Twiiter Bootstrap，Backbone.js、Angular.js、SendGrid、Laravel、Slim等等，而現在這些都成為了我們團隊主流的開發技術體系的一部分。 還比如2012年的某國外項目，客戶期望一個嚴格且完整的開發體系，開發，測試，代碼規范，代碼冗余檢測等等，我們從中發現了我們很多的不足，在此之后我們針對這個項目進行過很多次的反思，調整，專項培訓，那里不行就專補那里，直到那些劣勢被我們轉化成優勢。

客戶高要求，不僅會讓我們找出自己的不足，更有利于我們凝聚一個嚴謹，高質量高效率的團隊，從另一方面說，其實也在側面成就著團隊的成長。

六、總結項目、分享心得

一個項目結束，但對于團隊或者個人來說，還有一個重要的事情需要我們去做，那就是總結。

那些方面我們做的好，那些方面我們又做的不好？

客戶最滿意我們什么，又最不滿意我們什么？

我們的代碼質量是否有長足提高，我們的效率是否高效？

我們的團隊或者個人進步有多少？

我們是否竭盡全力，需要改進那方面？

……

我覺得這些都是我們在項目結束之余應該思考的問題，如果一個項目做完，沒有留下些什么值得我們改進或者驕傲的東西，那將是多么可悲的事情。當然這有些言重了，重點在于我們在總結中，找出每一個我們做的不到位的地方，揚長補短，在接下來的項目中，讓自己做的更好；找出做的好的地方，分享給其他團隊，或者讓后來人借鑒。

以上是我的對于高效工作的一些心得，希望大家共同探討，也希望大家指正不足之處。