保持模糊的共識?
這種國家大事，可能不是身為市井小民的我們，能夠深入剖析和探討的，但有一個極為類似的問題，則是我們在進行專案管理中，時常發生的狀況。也就是『規格的刻意模糊化』。
很多專案團隊，在驗收時碰到爭議，很大比例的原因，是因為規格不清，或是規格的認知有所差距。我們最常聽到的例子，就是客戶指著規格書中的某一條說：『OO功能當然是包含在這條規格裡面的，現在怎麼沒有呢?』或是：『這個機制怎麼可能沒有XX功能? 這想當然應該要有的啊，不然怎麼用呢?』從客戶的角度來說，這些OO和XX，本來就是系統該出現的內容，但對於專案團隊來說，這則是規格書中所沒有的『規格外』的『需求變更』，為何兩者之間會有那麼大的落差?
其中一個最主要的原因是，當時談規格的時候『沒談清楚』。但，為什麼會沒談清楚呢? 可能是時間不夠，可能是系統分析師素養不足，也可能是甲乙雙方溝通或表達能力不好，但這些不是我想談的問題(因為以上原因都可以透過訓練來改善)，我想談的是另一個看似不該存在，但卻十分常見的原因，就是…甲乙雙方刻意讓規格保持模糊。
這種情況你或許以為不該發生，但實際上卻是最常發生的狀況。
雙方PM為何要刻意讓規格模糊? 理由很簡單，因為雙方都想成案。而模糊化的規格書，最有助於成案(是了，因為可以各自解讀)。有時候靠著一兩張A4的SOW工作範圍說明書，PM和Sale就想把價格和時程談下來，甲方PM可能經歷了漫長的選商和詢價，早已面對(答應上頭老闆)的時程壓力，而乙方Sale正好業績缺的緊，雙方一看對眼，你情我願之下，交易立刻談定，PO馬上開出，接下來的後面一個月皆大歡喜。
甲方PM開始熱鬧的安排Kick-off，乙方Sale本季績效達成，乙方PM接到燙手山芋其實也不太擔心，反正kick-off之後還有半年時間，年底才要驗收。有時候乙方Sale甚至會給PM(人情)壓力，PM也知道規格不清楚會有風險，但不接案難道喝西北風嗎? 先前已經推掉兩三個案子了，總不能Sale拉進來的每個案子都被自己擋掉吧?
如此這般，在沒有詳細規格之前，Deal就談定了。至於工作範圍，人力預估…等文件內容，就算不是『天書』，也是PM透過經驗和直覺所產出的猜測數據。
接著，專案開始，如果這時候開始細談規格，發現距離賠錢不遠，還有踩煞車的可能，然而，事情卻不會那麼簡單。
好不容易案子接進來了，團隊成立。人員安排好了，做了一個月你想停掉這個案子? 這責任要誰扛啊? 而且沒有下去做，你怎麼知道一定會delay呢? 怎麼知道會做不完? 加加班ㄍㄧㄣ一下，或許…應該可以的啦。
內外壓力夾殺之下，乙方PM慢慢接受專案現況，把案子撐下去。這時候關鍵來了，你猜日後甲乙雙方會更努力認真的釐清規格，算出到底有多少差距? 還是索性把頭埋在土裡，能不碰乾脆不碰?
是了，事已至此，清楚的釐清規格，只會造成雙方痛苦，甲方會發現專案一定Delay，乙方得接受案子一定賠錢，再繼續釐清下去，甲乙雙方都非加班不可，既然如此，乾脆保持模糊，大家眼不見為淨。
但，保持模糊有何好處?
首先，面對驗收時，可以用談判的方式來解決，有經驗的PM都知道，驗收不一定是照功能清單Check box勾勾勾，也可以用交換的，到時候拿這個功能換這個功能，拿那個功能換另一個功能，或許可行，因此，乙方PM想著的是…客戶頭都洗一半了，諒他也不敢打掉重練吧?
甲方PM心裡想的是:『規格沒搞清楚是你的責任，想要我付錢當然就是要照我說的來驗收啊，反正我到時候不簽驗收看你是能怎樣?』然而問題在於，同一個規格的文字描述，甲方想的是ABC，乙方想的是甲乙丙，兩者看是相似卻有差別，最後誰說了算呢?
既然規格不清有那麼多風險，那談到很清楚再簽約不是比較好嗎? 問題來了，那前面談規格的那一段成本算誰的? 規格要談的很清楚，就必須花時間，要花時間，就等於要花錢。這錢要誰出? (甲乙雙方都會覺得這是對方該負擔的) 更重要的是，那這樣還要不要成案? 如果談了三個月中途生變，豈不是賠了夫人又折兵?
所以，這種『創造性的規格模糊』，就在矛盾和妥協當中出現了。
在我經歷過的專案當中，需求和規格在很清楚的狀況下才開始進行開發的案子極少，有相當高的比例是在簽約時，規格都還沒有釐清。那規格不清晰怎麼會有預估金額呢? 不要問我，我也覺得很不可思議，但台灣大部分的軟體專案就這麼幹了。
規格模糊並非只有壞處，有時候可能就是得要這樣，才能夠面對瞬息萬變的用戶需求(Really???)。時程較長的大型專案，想要釐清規格恐怕也很難。有時候開發到1/3的階段，用戶需求已經大幅改變，搞不好連當時談規格的用戶都已經離職，一開始談的再詳細也是沒用。(對，規格書很清楚，但end-user會跟你說，這系統他不能用啊，他知道規格書這樣寫，但他不能用你要他簽驗收，他還是簽不下去啊…)
也因此，問題不在規格的模糊，而是在怎麼控制變更。
PM把規格和需求的變更視為常態(從心態上一開始就當作理所當然，這就是會發生的事情)，你就不會擔心(憂慮)規格模糊的問題(而應該在各方面做好面對變更的準備，包含合約)。然而，模糊的規格當然還是必須在日後開發前確認與釐清，這也是我們在Scrum當中，會有Planning Meeting與Sprint安排的原因之一。
規格的模糊並非罪惡，然而在何時，怎樣用適當的方式把規格釐清，讓開發團隊可以即時的進入開發，並且讓客戶滿意，則是專案管理上的一個溝通藝術。
過去在waterfall時代，規格的模糊也常常發生，但往往卻導致UAT驗收的那一刻，你才發現這不是客戶要的(客戶也才發現你根本沒聽懂他說什麼)，如今在agile時代，規格的模糊依舊會發生，但我們卻不害怕變動，透過頻繁的溝通讓變動與規格的釐清在你的掌握中，透過每一個Sprint的Demo/Review讓你的成果被客戶所認同，隨時與客戶保持互動，讓客戶知道你正在為他努力，你也在乎他的需要，這才是PO/PM該達成的使命。
因此，身為PM/PO，不需要害怕規格模糊。但是，千萬別忘記，刻意保持的模糊，是為了達成某個共識(例如成案)，然而終有一天，模糊的事情必須被釐清，隱藏的問題必定被揭露，屆時，就看彼此準備的有多充分了，專案上如此，政治上其實也是。
本篇收錄自 - 『敏捷開發專案管理與架構設計實務』
留言