跳到主要內容

找出客戶真正的需求(問題)

在執行專案過程中有些事件,就跟「你想通了嗎」[1]一書中提到的情景類似,不過當下卻沒有察覺,都是事後解決才發現問題的癥結。
案例一:
在系統即將完成的後期,客戶才表示,其中一項W功能要增加一個新的表單,當初只談好要作2個表單,每個表單其實是對應到他們現有 一項業務,客戶負責提需求的人忘了提出他們還有另一項業務是不同於前2項的,必需要作一個新表單來專門處理這項業務。如果幫客戶做,則延長開發時間,不合 成本,但若拒絕,則這個系統又少了一項執行重大業務的功能,客戶接受度降低。當然我方大可以不符合約的理由正當的拒絕,但似乎不夠圓融,雖然後來我方委婉 說明,希望客戶打消此念頭,但客戶仍持續提出要求,這似乎是個兩難個局面。
後來的解決方法是在兩個原有的表單加上一個可以自由輸入的欄位,這樣,原有2項表單便免強可以轉作第三項業務使用,算是兩方都滿意的解法。不過這方法一開始也沒想到,是跟客戶討論的時候,被提醒的。這件事,問題的擁有者客戶,並不是我,也就是問題並不是「要不要作第三個表單?」,而該是客戶心理想的:「怎樣才能讓系統幫我處理第三項業務?」如果這樣思考就能跳脫出先前作新表單的思維中。
案例二:
我們要接手前一家公司做好的系統,並對其作部份的修正,需求很明確,但在專案一開始我們對技術與對方的程式碼都不熟悉的狀況下,客戶基層主管R就要我們提 出每項功能的時程,因為距離預定上線的時間只剩一個月,我們彼此又是第一次合作,因此主管R希望我們儘早告訴他我們的schedule。不過在不熟悉對方 系統架構與程式碼的狀況時,實在是很難估計明確的時間。這是一個兩難局面,隨意給一個時程,恐怕造成我們自己未來難做事,不給時程,客戶又相當堅持。
這問題的解決仍然是因為跟客戶溝通的拉鋸過程中,他偶然提到的訊息,因為他要給系統的user、主管一個交代,因此才要我們提出明確時程,因為距上線只有 一個月,我們就答應在三個星期後完成,中間的時程,之後再提出,這樣才算達成共識。一開始問題好像是「怎麼估計出工作時程?」,但是如果換到問題的擁有 者,主管R身上時,問題變成「我怎麼跟主管、user報告,系統何時可以完成?」
雖然我們常常聽過「換個角度想」,但是要換到哪個角度,卻是個問題,以上兩個都是比較簡單的狀況,只要我們換到問題的擁有者身上去思考,就可以找到問題的 真正解決方法。雖然一開始問題的擁有者好像是我們,但其實都是因為客戶有問題,才會造成我們的問題,要透過「誰造成這個問題」、「這問題從哪來的」等問題,來找到真正的問題擁有者。

[1]你想通了嗎?(Are You Lights On?), 唐納德‧高斯,傑拉爾德‧溫伯格, 經濟新潮社

留言

這個網誌中的熱門文章

iframe DOM 被移動造成重新載入

如果用 javascript 去搬動 iframe DOM 的位置, 瀏覽器會將其內容重新載入,這是現有 HTML 規格 > When an iframe element is inserted into a document that has a browsing context, the user agent must create a nested browsing context, and then process the iframe attributes for the "first time". 範例: http://jsfiddle.net/pZ23B/ 測試結果: * Safari 3.1 / Win: reload * Opera 9.5 / Win: reload * IE10: reload * IE7 / IE8: not reload (部份摘自 https://bugzilla.mozilla.org/show_bug.cgi?id=254144 ) 參考: * https://bugzilla.mozilla.org/show_bug.cgi?id=254144

JavaScript 關掉瀏覽器頁面

如果你直接呼叫 window.close() 來關掉目前的頁面的話,你應該會在 console 看到以下訊息: Scripts may close only the windows that were opened by it. ( 我在 Chrome, Firefox, IE 11 都試過) 主因就是你並沒有用 JavaScript 開啟這個頁面,所以也不能用 JavaScript 關掉它。這是 HTML window.close() 的規格 規定,各家瀏覽器應該都遵循。 隨著瀏覽器安全性增加,以下方法已經不適用了,可參考 這個討論 。 有個變通的辦法就是: window.open(location, '_self').close();

Web Dynpro 前後端資料流動機制 (Dataflow)

在Web Dynpro中提供3種資料流機制[1],只要適當地設定,可以不用寫程式就將畫面、中間層控制器(controller)到後端模型物件的資料自動化地、牢靠地綁在一起,使得不管前後端某一方有資料變動,變動部份都會自動地流動來保持一致性,使得前後端都能存取到同一份資料。 context 關鍵元件是 context,每個controller都有一份屬於自己的context,它扮演MVC架構中的M (model),web dynpro的實做方式比較像是該controller的「資料空間」,它由node(資料節點)與attribute(資料屬性)組成,controller可以透過wdContext這個預先產生好的 shortcut variable(捷徑變數)去取得context的資料內容。 context中必須要建立node才可以儲存資料,一個node代表一個collection(集合物件)裡面仍可以含有node, attribute,node裡面的一份資料實體就是一個element,一個node可以有一個或多個element(這部份可以透過cardinality property設定),其結構就是該node所包含的結構。 data binding 此種機制可以將UI元件的資料跟context中的某個node或attribute綁定在一起,context中的改變會自動 更新到UI元件上,UI元件的改變也會自動寫入到綁定的context node(or attribute)中。通常UI元件所綁定的node(attribute)是由component controller對應過來的。 context mapping 每一個controller都有屬於自己的context(資料空間)如果要達到彼此共享資料,則要透過context mapping機制,一旦mapping設定好,則會在另一個context產生一個同樣的結構的node,兩邊的controller會存取到的是同一分資料,任何一邊的資料更動都會散佈到設定好mapping的node。 不過在web dynpro裡,只允許將custom controller or component controller的node對應到view controller去,不允許從view controller對應回來,主因是嚴格遵守MVC...