有很多軟體系統專案，做得很累，做得很多，除了學到經驗之外，最後卻沒有什麼價值。而這種爛專案，似乎是常態，正常的，專案都是這樣的。為什麼那麼慘？不是技術越來越進步嗎？有很多管理的架構與的流程方法之類的專業可以參考使用嗎？為什麼還是一堆忙是很忙，累是很累，但成效與成本根本不成比例的專案呢？

傻蛋的觀察是，關鍵在需求。需求分析是誰做的，需求分析的品質好壞，決定這個專案是輕鬆愉快有成效，或是忙到累翻還被嫌。事實上，需求到底是怎麼被決定出來的，與需求分析的實際操作，通常並不是真的有專業技術含量的一個作業，比較常見的是那種半官僚半敷衍的假裝很專業實際上只是和怕被老闆抓到摸魚而沒事找事做的那種工作方式。

需求是怎麼決定的？需求是花錢的客戶決定的。負責做專案需求分析的人，是為了滿足客戶的需求。但心態與做法不一樣，結果也會不一樣。通常，都是收集客戶提出的需求，一條一條的看，快速弄個雛形的畫面給客戶想像，最後再產出一個詳細可驗收的需求規格讓客戶簽字，這就算完成需求分析了，之後只需要逐條按照合約上的規格實作，那麼，完成驗收與拿到報酬就不是問題了。嗯，那又怎麼樣了呢？假如客戶已經把需求分析做到一百分了，想要什麼清清楚楚，照著客戶的要求把細節全做到位，確實可以是一個成功有效率的專案。但既然客戶把架構與細節全部都想好了，作需求分析的人基本上只是寫文件與確認而已，其實需求分析是客戶做的，而非作需求分析的專案經理做的。成功的需求，只要是有執行力的開發團隊都能做好，甚至讓客戶直接寫需求規格，搞不好更有效率。

常見的情況是，客戶提出需求，但客戶並沒有把架構與細節都想清楚，而是只有一個大概的，模糊的方向，想要的應該是什麼。接著客戶常常會提出系統需求，系統流程與業務邏輯和一些對介面設計的想法。接著是關鍵，通常就是負責需求分析的人問些問題，客戶回答問題，目的是讓作需求分析與系統分析的人充分了解客戶的需求，然後做下可行性分析，給個方案，接著就是和客戶逐條確認最後的需求規格了。需求分析在哪裡？這種情況下，需求分析的任務只在問與答之間而已。經由問題客戶發現沒想清楚，然後把不足的部分想更清楚，修正需求，再確認需求。其實這樣的模式下，需求的分析依然是客戶自己做的。客戶的需求分析能力強，專案就會有成效，能力很弱，專案就注定不會有成果。一百分的需求加上一百分的執行是一百分的成果，五十分的需求加上一百分的執行，成果不是七十五分，而是五十分。專案開發的一系列工作，從需求分析到系統分析，架構設計，實作，測試驗收等等，基本上都是執行的工作，整體績效完全受到需求品質的支配。

公務員思考模式的需求分析往往是專案注定從一開始就很慘的關鍵。客戶提需求，負責需求分析的專案經理或系統分析師是由討好客戶的角度出發的，是為了讓客戶覺得他們自己提的需求被了解了，而且開發團隊很專業，把細節都弄得很完整，好讓客戶願意簽下需求規格文件並開始進行專案開發。至於需求本身到底可不可行，概念上到底有沒有矛盾，專案本身到底追求的是什麼核心目標，這都不關需求分析者的事，他的工作就是讓專案可以被簽下來，然後有驗收的依據而已。所以呢？這個需求是一百分還是二十分不是考量的重點，重點在技術面的細節上，每一句需求是否明確，是不是和客戶說的完全一致，嘿，是不是照客戶說的做如果不對都是客戶的責任，是這樣的。於是客戶就需要確認這些技術性的細節，重要的是這些技術性的細節倒是常常有相對明確的對與錯的答案的，於是產生了大量的技術性的工作與任務出來。客戶在確認這些細節的時候，很容易就忘了他們對專案目標整體性的瑕疵之類的大問題，當拉出一個專案進度管理的時候，細節任務數量把分母撐大，隨著那些其實只是技術細節的需求被確認，雙方都會有專案順利進行的感覺，結果就是重要的問題反而被忽略了。一份看似完整與專業的需求文件，如果充滿了龐大精確的細節，卻缺乏整體性的架構與定義核心價值方向，光看規格文件就可以知道這應該是爛尾專案。客戶會在開發過程一直都很滿意他們提的想法被實踐出來，但會在接近最後實踐的時候發現這滿足不了他們真正的使用者的需要。想改需求？那就是額外的成本與延遲的時程了，運氣差點，結構完全不對，系統核心需要重新設計，大部分的細節的設計實作全是白工。一般情況是，客戶的能力普通，需求分析的嚴謹程度也普通，於是有些需求規格上的定義不足之處，對於不滿的客戶，會擴大其解釋，於是要做的事就會變得很煩，即使對客戶的價值並不大，不凹白不凹，照規格照合約走嘛。

如果客戶的精明在於不讓開發團隊佔到便宜，如果需求分析的專業在於不讓客戶為所欲為的佔便宜，那結果往往就是做得很累卻毫無成效，而這，似乎是這個產業的常態模式。

需求分析就是需求分析，只有把需求分析做好，專案的整體最終價值才能確保。需求分析該怎麼做才能做好？其實重點在於其本質。需求到底是什麼？其實就是，客戶需要的價值，客戶的客戶需要的價值，客戶與這個專案概念相關的一群角色的整體價值與利益。如果是客戶的內部專案，那只需要問客戶需要的價值就夠了，但客戶不是一個人，可能有一個負責談需求的，有一個拍板定案的，還有一些需要為這些新需求執行新任務的。實際上，客戶內部的一些相關的人搞不好對同一個專案就有不同的立場了，更不用提客戶想的專案和客戶的客戶意見未必不是矛盾的。完美的需求分析是不可能的。但是，至少要把重要的有影響力的角色都拉進來考慮，才能確保專案需求的品質是可以接受的。老闆往往不會管基層執行的細節，也不會管有沒有利益衝突與可行性的問題，但專案是被這些人執行的，完全忽略這些人的需要，也是行不通的。基層執行者往往是為了自己生活快樂點而在提需求，戰略考量與組織整體利益往往不敵個人一點小利益，完全由基層的需求考量來做規劃往往不會有任何成效。同樣的情況也發生在客戶與客戶的客戶之間，客戶認為這樣的專案應該能達到什麼成效，但可能沒有考慮他的客戶的需要，最後這樣的專案很難不成為一廂情願的做白工。需求的品質本身從來就不是專案管理的技術性任務，這是和溝通，管理與決策有關的。沒有絕對完美的專案計畫，所有專案都是一項或大或小的賭注，但重點是至少要知道賭的是啥，而非是靠模糊自己的理智的一廂情願的白日夢在進行鴕鳥式管理。

所以可以這樣認識需求分析的本質，專案的意義與範圍，有哪些相關的重要角色，每個重要角色重視的價值是什麼與這些角色之間的利益關聯，最後就是，這個專案賭的是什麼，這些被重要角色關心的價值與重要性，哪些是專案的核心目標方向，那些是限制條件。另外，核心方向只能有一個高度內聚關聯的一組目標，不然什麼都要的專案目標沒有可行性，會變成只是找事做的處理雜務。這個過程並沒有標準答案，每個人做都會有些細微差異，但找到要賭的價值是什麼這一點只要完成，那這樣的專案需求品質就不會差到哪裡去。既然知道要賭什麼，需求細節自然是以滿足最大標的需求為指導方向，也沒有必要為那些與最大賭注無關的細節浪費太多精神。拍板決策的人要知道想賭的是什麼，如果猜錯了就猜錯了，認賠中止專案，雖然也可以算是一種失敗，但如果一開始就沒有清楚的目標與賭注，那樣茫茫進行的專案，只會陷在細節裡頭，連帶把管理者的注意力從核心業務吸引到非關鍵的事務上頭，自然不會有什麼成效，長久下來士氣低落，反而是更累的。

需求分析時，比較好的角度是關心對方想要的價值，而非對方隻字片語的細節。引導對方把整個需求分析走一遍，找到這個專案核心的賭注，在架構設計上，甚至在需求規格的定義上，往往都可以加以簡化，省掉很多烏煙瘴氣的細節雜務，而在核心價值的流程部分，可以投入更多的專注力，把這部分的細節做得更完善。主要目標達成了，就算枝微細節沒有做得很精美，客戶基本上也會滿意了。唯一的例外是那種，客戶的專案需求與目的本身就沒有一個拿得出名目的賭注方向，只是為了做而作，或是為了不實際的面子虛榮而進行，本身就沒有理性的基礎存在，這樣的案子基本上就是一種腐敗，接了下來，如果不對需求明確定義謹慎小心，就會被客戶搞死，而客戶除了搞死開發團隊之外，白日夢也沒有實現的條件，一邊只為了賺對方的錢，另一方只為了搞死對方讓自己的錢不覺得白花，如果是這種客戶的這種專案，那同樣的需求分析方法，也就不適用了。

說實在的，做事的方法都差不多，就算不是軟體系統的專案，道理也是差不多的，沒找到核心價值與賭注，懵懵懂懂的進行的專案，基本上都是很難有所成效的，沒事找事做的失敗專案。專業團隊的執行力，看的一定是最終成果，而最終成果是由一開始的目標所支配的，不能掌握這個道理，或許專業技術方法學再多，專業的管理流程套再多，都是沒用的吧？無能，或許只是一個念頭，一種態度而已唷！