很笨卻很實際,死纏爛打+問對問題=突破!


    「沒有辦法,真的沒有辦法,根據過去的經驗,整個測試就是要這麼久…」坐在我旁邊座位的一位先生,不斷地向電話那端的人這麼說。

    本來對這位先生一直在講電話,讓我在高鐵列車上無法好好地休息有點不高興,聽到這裡,倒是勾起了我的一段回憶,也忘記了要繼續不高興下去…

    死纏爛打

    如果您是位專案經理或是一位主管,你的某位同事告訴你,「根據過去多年的經驗,整個工作就是要這麼久,不可能再縮短了…」,您會怎麼做?是輕易地被這位「專家」說服了,還是繼續跟他/她死纏爛打下去?

    就我的管理經驗,這種「沒有辦法」、「不可能」的說法,總是不斷地在發生,而我也總是一直在想辦法破解這種說法,打破這種既定的僵固思維。理由其實很簡單,因為專案的時程總是被壓縮地愈來愈短,人力總是永遠地不足!

    這種不斷壓縮專案時程的情況,不僅常見,也根本就無法避免。因為,市場上總有一些競爭對手,不斷地在縮短產品的上市時程,而我們也不可能將之視若無睹,拱手把商機讓給對手,這就是人類自由市場競爭的殘酷現實!

    曾經有個專案,一位同事就和我發生過類似的對話:「威廉,你們這些PM不懂啦,無線通訊的規格很複雜,要做的測試項目就是這麼多,而且那些貴得要死的測試儀器,也常常要依據不同的測試條件,來手動調整設定各項參數,這些都很花時間的啦…」

    當時身為專案經理的我,深知若是無法加速這些關鍵功能的測試,後面即將開展的外部認證測試,很可能就會開天窗!而且,錯過了這次的外部認證測試,下次就得重新預約該實驗室,整個專案將會有極大的時程延誤風險。

    因此,我去找了這位同事,跟他「面對面請教」那份內部測試項目清單(check list),嘗試理解整份測試工作的脈絡和關鍵突破點所在。雖然那份表格對我來說根本就是份天書,但若非是我硬著頭皮去請教,我根本就不可能有機會找到突破點,因為,對方是這個領域的「專家」!

    問對問題

    「阿芳(化名),我們先來看這幾個需要超過五分鐘以上的測項,他們有沒有可能跟其他的測項合併起來一起做,卻不會影響測試的客觀性?」我問了這個「很笨」卻「很實際」的問題…

    「如果合併幾個測試項目一起做測試,結果是pass的話,那就可以視這幾個合併的項目都OK。可是如果測試結果是fail的話,那麼還是得回到個別的測項,一個一個地重測,這樣就不會比較快啊…」

    「您說的沒錯!不過,我問您一個問題,您對於您的程式碼能通過測試的比率有信心有多少%?」

    「應該99%以上不會有問題吧…」阿芳不假思索地,立刻回答我。

    「好,既然信心這麼高,那麼我們就不妨來賭一下,合併測試後都pass的機率應該是很高的。那就麻煩妳review一下全部的測試項目,看看有哪些項目是可以合併測試的,可以嗎?」

    「你說的也有道理,我們可以試一試,看看這樣可以省多少時間…」阿芳被我說服了第一關。可是她沒有想到,我接下來還有其他的招數…

    「阿芳,我看這些測項裡,有一些需要調整很多的儀器參數,有一些不用,那這些需要調整儀器參數的,是不是就是很花你們時間的地方啊?」

    「對啊!而且要很小心,要多check幾次才可以開始進行測試。不然,萬一設定錯誤,測了半天,結果就會都沒有用,還要重來啊!」

    「嗯…那這些需要調整的儀器參數,妳有沒有把它們依照需要花費的時間排序過,看看哪些調整動作最浪費時間?」

    「這個嘛,我倒是沒有想過耶…」

    「好,那我們可以這樣排看看,比如說,這10個測項都需要調整A參數為2.0,可是它們中間又有其他的測項,是會把A參數調成1.0的,我們如果把這10個測項都集中排在一起,那A參數只要調整一次,就可以測完這10個測項,中間換測下個測項都不用再動它,這樣不就有可能可以省下不少的時間了?同理,如果這10個測項還有其他的共同處,例如,需要調整B參數,我們又可以如法炮製,讓B參數只要調整一次,就可以測完這10個測項,中間換測下個測項也都不用再動B參數,這樣全部review一輪整份check list,搞不好可以省下非常可觀的時間耶…」

    突破

    「喔~~~我懂了,這樣我們真的有機會可以省掉不少時間耶!」

    「完全正確!」我對著睜大眼睛微笑的阿芳比出讚的手勢


    「永遠保持懷疑!」並不是要你去懷疑對方是不是在說謊,而是讓你去懷疑,對方可能不知道,其實,世界上還有很多改善工作效率的可能性!

    光是「永遠保持懷疑」也還不夠,你還必須要有打破沙鍋問到底的行動,即使對方是專家也無所懼。因為,唯有行動,才能把靈感刺激出來,才能把它加以證實,才能有機會突破現況!

    照片來源:http://www.newdmagazine.com/