2014年12月25日 星期四

保持模糊的共識?

最近在新聞上,又有政治人物談起一個有些古老的議題,也就是OO共識。不過一直以來,這個名詞總給人一種虛無飄渺的感覺。有人說OO共識根本不存在,有人說確有這個共識,但實質內容為何? 也不一定人人都可以說的上來…

這種國家大事,可能不是身為市井小民的我們,能夠深入剖析和探討的,但有一個極為類似的問題,則是我們在進行專案管理中,時常發生的狀況。也就是『規格的刻意模糊化』。

很多專案團隊,在驗收時碰到爭議,很大比例的原因,是因為規格不清,或是規格的認知有所差距。我們最常聽到的例子,就是客戶指著規格書中的某一條說:『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,不需要害怕規格模糊。但是,千萬別忘記,刻意保持的模糊,是為了達成某個共識(例如成案),然而終有一天,模糊的事情必須被釐清,隱藏的問題必定被揭露,屆時,就看彼此準備的有多充分了,專案上如此,政治上其實也是。

本篇收錄自 - 『敏捷開發專案管理與架構設計實務

沒有留言: