微軟專案求生法則之求生技能5（轉）

避免採用開放式工作隔間
有個老生常談的論調，說開放式的工作隔間有助於軟體專案間的溝通。問題在於這樣的隔間溝通起來反而雜亂無章，連帶影響生產力。有效率而良好的溝通還不如在茶水間放部汽水機來進行。開放式工作隔間有助溝通的論調乍聽起來很吸引人，可是經不起確切考驗，而且軟體研究資料清楚顯示開發人員只有在一兩個人的辦公室內最具生產力。

一些研究發現開發人員在隱密、安靜、一兩個人的辦公室內工作和在開放式隔間的辦公室內相比，前者的生產力比後者要高出2.5倍。軟體開發是個需要高度思考的活動，如果電話響個不停，廣播系統播個沒完，人們在你四周走來走去，每隔幾分鐘就來打擾，怎麼可能專心思考問題。

---------------------------------
身為主管的工作要求是每隔幾分鐘就轉移注意力以達到管理效果。
---------------------------------

一般軟體開發人員要求幾個鐘頭內最好不要轉移注意力，才能專心。許多組織沒辦法提供開發人員安靜隱密的辦公室。他們有的是空間不足，有的是要留給副總裁之類的人用。有些組織發現，將他們的開發團隊安排到另一個環境去會更好些。其他組織則試著讓開發人員帶著耳機工作杜絕干擾，或者乾脆讓他們在家工作。至於其他沒辦法提供開發人員安靜隱密而不受干擾的組織，只好自求多福了。

使用者參與度

軟體使用者參與的程度對軟體專案很重要。軟體成功的關鍵在於設計出一般使用者愛用的產品。如果沒有使用者的參與，軟體開發人員常常會考慮技術層面而忽略使用者的需要。這樣的話或許軟體產品中塞進過多功能，使用者實際用到的卻沒幾種。

要想開發出使用者愛用的軟體產品惟一方法，在於問問使用者的是什麼，把開發中的產品先告訴使用者，並問問使用者喜不喜歡這東西，聆聽使用者的心聲並參考他們的意見。

也許專案團隊得努力好幾次才能瞭解使用者要的是什麼。使用者們也必須瞭解開發人員讓他們看的雛形跟未來的成品也許相差十萬八千里。有時有分辨出哪些可能是未來的“使用者”都有困難。這些都會在以後提到。

由於使用者的參與消除了一大變數——摒除了“差不多先生”的心態，這樣一來專案所費的時間就少得多了。如果使用者沒從頭參與，以後對專案產品進行檢視時，一定會指出有好些地方沒照顧到他們的需要。這時開發團隊就得面對一個艱難的抉擇：依循原來的預算與時程目標而忽視使用者意見，或是在專案的下游階段接納使用者意見而讓預算跟時間超出預期限制。通常開發人員會妥協，先採用可立即修正的使用者意見，而將難以立即採用的意見留到程式的下個版本去處理。說老實話，讓使用者在產品還具可朔性時愈早參與愈好，而且最好是在那些不被喜歡的東西出現以前。

由於“做了比沒做好，早做比晚做好”的觀念，使用者對自己參與開發過程的專案反而比沒讓他們參與的期望更深。表面上，愈早讓使用者參與開發的軟體愈能滿足使用者需求與期望，而這也成了一種質量的認定方式。實際上這樣的軟體缺陷的確更少，因為它們在開發過程中方向變動較少，而讓產品架構、設計方式與實作更穩定。如果在專案中途才加入使用者需求，被迫將沒想到的功能加進體質不良的現有構架中時，軟體質量一定會大副下降。

除了及早參與、持續參與外，很少有軟體專案一開始就找出真正良好的解決方案，一般都必須在使用者坐下來說“是的，這就是我要的軟體”以前做出不同版本的使用者介面雛形。一個良好而成熟的使用者介面雛形可以讓專案推出後廣受歡迎，不過軟體的適用性得在開發時就調練好。參照使用者所需導向而做低廉、小型的修正，就不用到了專案末期再大興土木以致付出高昂的代價（本文使用的階段性完成策略提供了這樣的過程中修正方式）。

參予開發過程的使用者用不著很多，在Jakob Nielsen的《Usability Engineering》一書中指出，當軟體適用與否的測試人數在3～9個時，價格獲益比最好。

在1994年，Standish Group對8000件以上的軟體專案進行檢查。結論是使用者的參與是專案成功最顯著的因素。在那些失敗的專案中，缺乏使用者反應是失敗的主要因素。計算機軟體的專家指出快速開發專案能夠成功的最重要因素在於讓一般使用者全程參與開發過程。

----------------------------------
讓使用者參與專案開發過程可說是重要的軟體專案求生技能。
----------------------------------

產品簡化主義

成功的軟體專案開發從需求制定到產品推出、繼而被接受，都需要一種“化繁為簡”的定位方針。因為軟體開發工作相當費神，若能將專案徹底簡化必然事半功倍。功能規格、設計與實作都應該簡化。許多開發人員沉迷與複雜性，誤以為“數大便是美”，事實上只有簡化專案才是成功的唯一出路。

當開發人員致力尋求專案目標流程的簡化時，可說又向成功邁進了一大步，對一般使用者也可能造成影響。一個功能通常可分兩小時版、兩天版和兩週版，開發人員應該一開始先弄出兩小時版，通常這個版本的解決方案最簡單直接，問題最少。開始實際操作後，如果解決方案還不夠，他們才應制作兩天版甚至兩週版的解決方案，再看看這樣是否可以解決問題。解決問題的一貫態度是，先簡單後複雜，才不致於因噎廢食。

法國作家Voltaire說一篇散文不是在“增一字則太多”時完成的，而是在“減一字則太少”時完成的。軟體專案亦同，應該是從軟體中去除不必要的東西以進行簡化，而不是不斷加上更復雜的東西。

焦點防在推出軟體

有效率的開發團隊全心全力著重產品的推出。微軟公司尤其重視“產品推出”。對產品推出有功的開發人員會獲得一個“產品推出”獎，感謝他們的努力。在微軟工作了許多年的開發人員一般都有一大堆產品推出獎。這樣簡單的做法強調一件事，微軟公司不是靠著開發軟體賺錢，而是靠推出產品賺錢，當然這也是大部分生產軟體的公司賺錢的方式。

對於無論是替內部使用者開發軟體或對一般大眾發行軟體的開發人員來說，焦點是一樣重要的。一個清晰的前景描述可以讓任何軟體開發團隊對產品推出的目標相同。如果開發人員到了專案結尾都還對產品的看法有歧義，將被迫花費上許多時間、努力與金錢來讓他們的看法一致。

一個清楚的架構也有助於讓開發團隊在目標上步伐一致。反之，就難以同心同德。如果一套良好的產品架構確立了，專案的開發焦點自然集中在技術層次上。

軟體開發團隊必須確保每個技術性決定都朝著簡化系統功能的方向前進。如果是開發大學教育專案，也許有必要讓專案任意複雜化。不過當團隊在開發商用產品時，他們的任務是提供最簡單的問題解決方案，任何違反這些原則的決定都應被否決掉。

本文所要傳達的資訊是軟體開發工作本質上主要為了滿足實際目標，這個工作有著濃厚的美學標準與科學成分。有效率的軟體開發人員瞭解軟體專案不是為了讓他們有個築夢堡壘，而他們也依此排定各項條件的優先順序。微軟公司的經驗顯示，這樣得到的行動方針能夠在專案團隊中培養。沒有共識的開發人員對於專案是一個累贅，對組織可說沒什麼用處。

====================================================================
求生檢查

專案團隊在專案初期就規劃了一套解決高成本潛在問題的方法。

專案藉助規劃審查，在專案完成約10%時決定要不要繼續進行下去，以此強調上游工作的重要性。

專案做到了積極的風險管理。

專案規劃強調洞悉力和專案控制。

專案規劃包含使用者從頭到尾的參與。

專案在高生產力的環境中進行，或是假設專案成員生產力恐有不足而先做準備。

專案規劃尋求由簡而繁的辦法，而不是反過來做。
====================================================================

[@more@]