跳到主要內容

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

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

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

留言

這個網誌中的熱門文章

Code Complete, 2ed (中譯:軟體建構之道) 讀後心得

Code Complete, 2ed (中譯:軟體建構之道) 讀後心得 雖然以前在學校有修過軟體工程,但是說實在現在我對建構軟體的整個概念都來自於兩本書:「人月神話」(The Mythical Man-Month)、Code Complete[1]。我畢業後第一份工作是軟體研發工程師,我們公司所開發的系統大約有近百位工程師共同維護,當然各有依功能與專業知識將系統劃分不同的區 塊來維護,在面對大型的系統與這麼多人寫程式是以前在學校沒有遇過的,因此也開始思考怎樣才是好的軟體開發方式。從大學好友那探聽到了Code Complete這本書,花了上千元買了英文版,(現在中文版已出,簡體版聽說只要三分之一的價錢)認真讀了幾篇之後,真是如獲至寶,於是自己讀過後,還跟同事組成讀書會一同研討這本書。 作者 Steve McConnell (個人Blog http://www.stevemcconnell.com/ )著作不算量大,但是我看過的幾本質量都很好,印象中他曾經在微軟工作過,後來成立一家軟體顧問公司 Construx Software 。 這本書(書本網站 http://cc2e.com/Default.aspx )的討論主題很廣泛,但是並不空泛,從最小的、最基本的如何寫出好的程式, 例如函式(routine)、註解 (comment)、變數的命名等,也談整個軟體建構的過程除錯、測試,最後也談到軟體工程師個人能力與技術生涯的發展,算是各方面都有提及。但是我比較 建議有半年以上的實際程式經驗來讀這本書比較適合,我自認為如果我在學生時代接觸本書,可能沒有什麼太大的感觸,因為面對的都是小格局、人數少的小系統, 書中所探討的原則與例子,很多時候沒有團隊開發或大型系統的經驗,很難體會。但稍有經驗的人,看完之後保證在程式撰寫與軟體開發方面的觀念會有很大的提 昇。 Table of Content Laying the Foundation 1 Welcome to Software Construction 2 Metaphors for a Richer Understanding of Software Development 3 Measure Twice, Cut Once: Upstream Prerequisites 4 Key

ZK 與響應式網頁設計(RWD)

響應式網頁設計 (RWD) 就現今而言應該是許多網站必備的條件之一,ZK 框架可以幫你從一個抽象層次較高的角度滿足 RWD,不需要了解 CSS Media Query 的細節。 元件層級 元件層級的 RWD 是由元件內部自動完成的。每個 ZK 元件都能區分瀏覽器的種類,因此會自動依據桌上型或行動裝置瀏覽器來自動調整元件的外觀,不需開發者介入,例如 datebox 在桌面瀏覽器會跳出小月曆: 在手機瀏覽器就會自動變成下方滾動條: 頁面層級 頁面層級的 RWD 因為牽涉到版面設計,因此無法靠元件自動完成,因為畢竟每個頁面需要的版面設計皆不相同,這通常不是一個技術性的決定,而是政策性或設計性上的決定,因此 ZK 提供一些工具讓你實現 RWD。以下根據你想要達成的效果,概述你可用的工具。 寬度、版面自動調整 如果你想要做出的效果是,畫面內各區域自動調整寬度,較窄時調整位置,我非常推薦搭配 Bootstrap Grid 與 ZK 一同使用,因為 易於整合 。使用 Grid system 只要在 div 套上 CSS class,如 col-md-4 ,因此跟 ZK 整合很容易,不需要特別的設定與程式。 元件變換 如果你希望畫面寬、窄時,各用不同的元件來顯示,例如側邊欄在畫面變窄時消失並換成小的選單圖示,這時元件本身當然無法得知要做這樣的轉換,你可以透過 onClientInfo 事件 或 @MatchMedia 來偵測畫面寬度變化,並針對該變化調整畫面元件。 更多細節可以參考以下資源: Use Bootstrap with ZK: Responsive Admin Template 範例專案 線上展示

innerHTML 的安全風險

問題 若你要實作一個使用者輸入的功能,並把輸入的內容顯示在網頁上時,應避免把使用者輸入的值直接指定給某個 element 的 innerHTML 。因為若是使用者輸入包含 HTML、JavaScript, innerHTML 就會解析並執行: var userInput = '<img src="javascript:alert("XSS")">' element . innerHTML = userInput ; 因此可能 user A 的惡意輸入,會被系統顯示到 user B 的畫面上,進而執行特定成程式碼而造成 XSS 攻擊 。 解法 一般會先想到 encode HTML,但是如果只是要顯示文字,將使用者輸入值指定給 textContent 會更簡單,無需 encode,該值會被當成純文字處理,並不會執行 javascript。 var userInput = '<img src="javascript:alert("XSS")">' element . textContent = userInput ;