跳到主要內容

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

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

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

這個網誌中的熱門文章

JavaScript 關掉瀏覽器頁面

如果你直接呼叫 window.close() 來關掉目前的頁面的話,你應該會在 console 看到以下訊息:
Scripts may close only the windows that were opened by it.
( 我在 Chrome, Firefox, IE 11 都試過)主因就是你並沒有用 JavaScript 開啟這個頁面,所以也不能用 JavaScript 關掉它。有個變通的辦法就是:
window.open(location, '_self').close();

ZK 教學 - 使用 MVC 或 MVVM?

不管是現在剛開始接觸 ZK 或是用過一陣子的人都可能會遇到的問題是到底要用 MVC 或 MVVM 的方式開發。從 ZK 8 之後又把 MVVM 的能力更佳的擴展,所以 MVVM 會是一個功能更強的開發方式。但 MVC 在使用上比較直覺,仍有其優勢,所以我想決定性的因素會比較是開發者的偏好專案的特性。你可參考下面的比較來決定哪種方式比較適合你。優勢比較MVVMViewModel 較不易受畫面變動影響。
因為 ViewModel 沒有變數直接指向 ZK 元件,因此若是畫面上有元件更改,ViewModel 一般不需要修改ViewModel 較易於在不同頁面中重用。
因為 ViewModel 只包含資料跟業務邏輯,若是不同頁面需要的資料跟業務邏輯相同,就可以重用同一個 ViewModel例如 A 頁面按按鈕執行搜尋,B 頁面點選單執行同樣的搜尋,則可以重用同一個 ViewModel 中的 command,只是兩個頁面 data binding 寫在不同的元件上。畫面較易於重用(易於模組化)。
透過 shadow component 跟 template 機制,可以將一段頁面的片段做成可以接受傳入參數套用 Responsive Design 的成本較低。
通常需要針對不同裝置設計不同版面,但是顯示的資料內容大同小異,因此 ViewModel 多半可以重用易於套用美工所設計的畫面,或是網路上現成的元件。易於整合第三方 javascript library 或 widget。
因為 ZK 8 提供了一個可以讓你透過 javascript 去呼叫 ViewModel 中的 command (client side binding) 的方式來跟後端溝通ViewModel 的可測試性較好。
因為 ViewModel 不需要繼承特定類別跟實作特定介面,可以輕易地執行單元測試MVC操控元件方式直覺好學、易懂。
MVVM 控制元件較不直接,需要了解 zk framework data binding 的行為可以完全使用元件所提供的所有 API。
仍有極少部分 ZK 元件行為沒辦法用 MVVM 控制。例如產生 Messagebox, Listbox.renderAll(), Popup.open()。但這都可以改用直接控制元件的方式來解決,只是就是非 MVVM 的方法,喜歡維持一致的開發模…

ZK 教學中文書 - ZK 教練

2016年開始做了不少場教育訓練,覺得台灣工程師應該會蠻希望有一本中文的教材,因為目前網路上多是零散的文章,英文的文件雖然完整,但是太龐大,大部分的人應該無從下手。因此最近開始撰寫一本教學書:「ZK 教練」(書名是老婆提供的點子),也為自己在這份工作推出一個代表作。
本書會包含以下幾個特點,幫助讀者更有效地學習:
範例專案
本書附帶一個範例專案,裡面包含所有書中提到的範例程式。你可以輕易地將整個專案執行在 jetty 上,透過瀏覽器看到執行結果,有助於了解程式碼。練習專案
執行 maven 指令可以產生一個練習專案,它以範例專案為基礎,但是刻意移除部分程式碼,好讓讀者練習之用。因此你可以產生範例專案來練習,若真的遇到困難再參考完整程式。圖片解說
儘量以各式圖片解說概念。我認同 Head First Design Pattern 一書中提及的理念,學習不是只能靠文字,其他的媒介可以讓大腦得到更多資訊,更增強學習效果。情境 FAQ
ZK 目前已經是個頗為成熟的框架,功能很多,因此不熟悉的人常常不知道實務上某個情境要用什麼功能來解決,這裡會列出各個常用的情境並提供連結指向建議使用的 ZK 特性 當然目前本書尚未完成,歡迎給予回饋。
去看看 ZK 教練