［ PL的Project Management］順序很重要，Requirement=>Design=>Implementation

SW process的第一個phase並不是implementation phase，而是requirement phase，也就是說如果project一開始就朦著頭就開始實作階段，那是錯的，也是假的，因為連要做什麼都不知道，又怎麼可能開始做呢，先搞清楚requirement是什麼才是最重要且第一個要做的事。

有的PL為了搶快，或是為了讓老闆看得見產出，即使在做什麼都不明確的情況下，project就投入人力開始implement，這是錯的，也是假的。為什麼是錯的？簡單的邏輯－清楚要做什麼(What to do) ==> 才思考應該怎麼做(How to do) ==> 然後才是開始實作(Do it)，對應的SW process順序就是Requirement phase ==> Design phase ==> Implementation phase。客戶明明要的是要＜重型機車＞，結果你自己很高興地做了一個＜很重的機車＞，然後才發現做錯了，你能要求客戶把需求改成＜很重的機車＞嗎？所以順序不對，就不合理，就是錯的。那為什麼是假的呢？因為現在實作完成的東西，會因為requirement不對、design不合而需要修改，甚至重來，看起來已經完成100%的工作都可能要再歸零重做，也就是現在完成的工作可能都是白工，所以是假的。

Requirement phase (What to do) ==> Design phase (How to do) ==> Implementation phase (Do it)，簡單的邏輯，淺顯易懂，不過＜知易行難＞，看過很多project直接就要開始進入implementation，忽略requirement、跳過design，妄想要一邊實作一邊釐清需求，一邊實作一邊修改設計，這樣的做法或許對很小很小的task有用(因為重工的代價很小)，但對於project來說，那會是讓事變多好幾倍、功減一大半的行為。



順序不錯不對，除了會有重工現象之外，還會有人力和資源浪費或不足的情況，因為沒有先確定requirement然後評估需要多少人力，盲目地投入人力，可能會有太多或太少的情況。曾經就見過project要了幾十個RD進去，但是進去的RD卻連要做什麼都不知道，而且有好一段時間差不多就在idle狀態。而大部份的RD是從其他project拉來的，造成project排擠效應的代價也是很可怕。

如果你抓得住requirement，相信你就會是一個稱值的PL。其實確定requirement在整個project的過程中，算是簡單容易的，除了一些可能需要的新技術survey和study之外，最需要的就是＜溝通＞，需要跟客戶、Market、RD、UI等多溝通以定義好功能要求、介面、操作流程、界限值、內定值等等。一般來說RD只要確定清楚自己負責的requirement就可以了，而PL／PM／老闆還必須排序出所有requirement的priority，找出project的重點方向，這樣在未來發生突發狀況時，才能快速反應做出正確的調整。

另外有一個問題很多人都在問，需要寫SRS（Software Requirement Spec.）嗎？嚴格來說是要寫的，SRS算是正式的文件，對於平台型的project更顯得重要。有SRS的好處是：
１、方便相關人review討論
２、相關人都同意，較不會事後翻盤修改
３、為後來design的依據
４、方便以後接手maintain快速入門上手

不過不可否認的寫正式文件是要花點時間的，甚至有些RD會覺得寫code比寫文件容易。我個人的建議是，當project很小，影響範圍很小，不具備重覆的特性時，文件可以簡化，但是該做的事卻不能省略。過去在帶領FAE時，很多客戶的project都只是做細部或少部修改，基本上project都是三個星期左右工廠就要出貨了，在搶時間的狀況下，可以放鬆FAE不寫SRS等正式文件，但是也不允許在不確定做什麼的情況下就開始亂改一通，SRS可以用跟客戶的討論mail或會議記錄來取代，可以簡化的是形式上的作業，但絕不是可以簡化實質的內容。

Requirement phase (What to do) ==> Design phase (How to do) ==> Implementation phase (Do it)。邏輯的順序很簡單，但實際上project執行起來卻很難，真的這樣做的project可能少的可憐，這是個有趣的問題，我們留下次再討論好了。