超越對手之十--如何做實施調研精彩觀點摘要
|
案例 項目經理小李和一個客戶項目負責人約定要啓動調研了，他寫了份計劃，說明調研派出團隊人數和計劃天數，還說明了調研要了解的大概內容，請企業確認能否按計劃時間啓動和開始。小李在得到企業肯定答覆後來到現場，這才發現企業這邊根本沒有配合好，無論是要求準備的數據還是要求約的被調研對象，都沒有準備。小李不得不調整計劃，在現場重新落實計劃的工作內容。 請問怎樣避免出現這樣的情況呢？ 點評： 企業客觀上都希望項目團隊在現場的工作緊湊合理，不浪費彼此的時間。但用戶並不清楚如何做這種調研，他們能做的就是按照軟件公司意見儘量安排合適人員配合。 如果調研計劃只是含糊說明某幾天要來現場調研的話，實際上用戶領導可能會回答，那你們先來，來了再說。結果到了現場發現準備不足，把大量時間都無價值的浪費在協調調研資源和等待上。 有的人把調研計劃做好，告訴用戶行程，就準備按計劃去現場了，這樣的調研者不及格。 有的人會提前發郵件或傳真給用戶，然後電話確認收到，然後和用戶確認時間無問題，然後再去，這樣的調研者60分。 有的人不但會確認計劃時間，還會認真瞭解企業是否認同計劃內容和是否有相關業務人員配合，得到肯定承諾後再去，這樣的人80分。 有的人還會準備一些前期調研文卷和數據準備清單，讓客戶經理配合落實後再去調研，這樣的人100分。 調研計劃至少要做到80分！計劃發給中國用戶後，大部分用戶一般是不會認真看和落實的，這是中國人做事的習慣，特別是一些地位不高的聯繫人，可能連爲這個事找領導的協調能力都沒有。所以打電話確認的時候一定要請用戶確認是否可以按計劃進行，得到肯定答覆後再出發，這樣計劃執行保障性會高一些，也給別人留下一個認真的印象。 案例 項目經理小李在調研過程發現一個客戶項目中非常關注編碼的問題，而企業的編碼想實現編碼規則，軟件公司現有的產品肯定無法滿足，小李花了很多時間說服企業項目負責人，指出企業現有的編碼也是夠用的，沒有必要在啓動階段花費如此大力氣折騰編碼，項目負責人最後接受他的意見。小李用這種辦法婉拒了很多客戶需求，也就不投入精力進行這些方面的調研了，這樣操作對嗎？ 點評： 控制用戶的需求是合理的項目邊界管理方法，只要和用戶進行過充分溝通，達成共識，小李的做法是無可厚非的。 但如果在調研階段發現用戶認爲是很有價值的問題是公司目前不能解決的問題，並不等於說服用戶後調研工作中就可以迴避。現在可以迴避的問題不等於以後可以一直迴避，更不等於在未來實施過程中永遠不面對。合理的需求總是要冒出來，與其迴避，不如先主動搞清楚，彙報給公司後羣策羣力，看看到底有什麼辦法可以解決。 如果有選擇性問問題，就會遺漏一些關鍵性業務，這樣對調研整體質量有影響，在後續制定解決方案工作中容易遺失業務環節。 如果確實不想引發用戶一些天馬行空的問題，或者的確不想引發他們高度興趣的問題也有合理的迴避方法，不過不是通過不調研達到，而是以單獨認真記錄，但不提供在正式文檔的方式規避。很多用戶的很多需求都是一時靈感，沒有經過認真思考，呈口舌之快，過了也就過了，不形成文字記錄，用戶自己也不記得自己說過什麼了。 如果真是關鍵問題，會不斷在後續階段再提出來的，這個時候再確定寫入正式檔也不遲。 此外越是有公司產品明顯不能解決的問題，越要調研清楚，搞清楚來龍去脈，爲公司今後產品發展提供完整的需求建議。作爲一家負責任的軟件公司，首先要承認自己的軟件不可能解決所有的問題，但一定要在發展過程中逐步解決更多的問題，調研時都回避問題，不就使公司產品失去了發展機會了嗎？ 真正的問題都是迴避不了，繞不過去的。 |
超越對手之十一--如何處理用戶需求精彩觀點摘要
|
處理用戶需求需要知道的三件事 用戶提出的需求很少有不合理的，往往是用戶提出的實現辦法並不能真正解決問題而已。 用戶提出的需求很少有不能解決的，往往是公司在現有資源情況下無法快速響應和服務而已。 用戶提出的需求往往有簡單的解決方法，如果答案很複雜，往往不是正解而已。 如何分析用戶的需求 實施過程鮮有一帆風順的，對於現有產品，用戶提出不滿，提出這樣那樣的問題是常有的事。用戶提出需求的方式往往表現爲強烈需要一個功能，這個時候很多實施人員可能開始考慮這個功能是否合理，是否容易實現，並以此爲基礎和用戶展開談判。 一個有經驗的實施人員這個時候首先應該思考用戶爲什麼有這個需求，不要光看需求的功能描述。首先應該考慮的是：用戶這個需求的本來面目是什麼。有時用戶的需求也是用戶自己加工過的，比如用戶認爲在某個窗體加個字段就可以實現這樣一種業務，但實際上可能不是那麼簡單。因此，我們必須從需求出發把用戶要解決的業務還原，然後再站在全局業務的高度考慮我們到底要解決的是什麼問題。 還原了業務後我們可能會發現很多時候用戶提出的需求往往是管理上的漏洞造成的，技術手段並不能解決業務問題，屬於不合理的需求。 這個時候我們並不能輕易拒絕用戶的需求，而是要和用戶一起推導直到他們發現自己提出的方案並不能從根本上解決問題，然後再和用戶探討真正解決問題的辦法，這樣用戶不但會收回自己的想法，還會建立對你分析能力的認可。 案例 項目經理小李接到一個項目，項目在商務階段爲了爭取合同做了大量承諾，但實際上很多是軟件很難開發滿足的，這個時候企業負責人要求軟件公司兌現承諾，否則不可能驗收項目。 請問小李該怎麼辦？ 點評： 管理系統銷售爲了爭取合同很少有不過度承諾的，這是一種不可迴避的現狀。這種現狀恰恰是造成實施人員的體現自身價值的機會，如何在最小化開發成本情況下有效解決業務問題，而不是指責銷售團隊，或者逼壓開發團隊。 很多過度承諾的內容是用戶心血來潮的產物，真正在做項目時經過深入思考，用戶也會接受理性的目標，不會反覆追究。因此在調研階段提供好的解決方案（提供清晰的項目目標和完整的業務方案）和與用戶建立良好私人感情是多麼重要！ 此外由銷售承諾的很多功能，其實未必是合理的需求實現方式，實施人員在業務調研過程中，往往有可能發現真正解決問題的辦法。一旦和用戶對某個需求功能實現方式形成僵局，實施人員首先要去了解業務，分析這個業務到底想解決什麼問題，這個問題到底可以通過怎樣辦法來解決，可能能找到找到可替代的方案，甚至是更好更被用戶接受的方案。 有的功能可以和用戶一起評估這些要求和我們的主要項目業務目標的符合程度，如果需求對我們主要目標實現沒有幫助，我們就可以盡力去說服用戶先將精力集中在主要目標上，一個項目是不允許有太多分支目標來發散精力的。 如果個別用戶還是非常固執要求實現自己的要求，一個有效的策略就是不主動激起用戶討論這些問題，淡化處理，拖一拖也就可能把問題拖掉了，這也是一種沒有辦法的辦法。 |
超越對手之十二--如何編制實施解決方案精彩觀點摘要
|
沒有清楚定義未來的工作遠景的系統，追隨者會越來越少。 實施解決方案和售前解決方案的不同 1、從售前到實施解決方案要經過一個主體從軟件公司能力宣傳到企業業務支撐描述的變化。 售前階段大部分項目不能提供詳細業務調研的機會，所以售前解決方案以軟件企業功能和實施經驗爲主，結合企業一些特色加以發揮，簡單地說還是以軟件公司爲主，而售後解決方案是建立在詳細業務調研基礎之上，必須結合企業流程詳細展開，以企業爲主描述。 2、從售前到實施解決方案要經過一個從虛到實的變化。 售前階段解決方案重在介紹一些理念和管理思路，總體上存在很多務虛的內容，比如項目目標主要從定性角度闡發，對價值主要從一般認識出發。 但經過業務調研後實施解決方案中要明確提出一些定量的目標，例如產品數據管理怎樣叫做管理了，不能說不出所以然。同時實施解決方案對項目價值點要能結合部門，崗位和業務描述出在不同業務環節的不同崗位責任人能從系統中得到哪些方面的效益，進而支持企業的何種價值點，而不能再是放之四海皆準的泛理論推導。 同樣在售前宣傳的一些概念，要麼在實施階段找到落腳點，要麼在實施階段把這些天上的東西用地面的目標取代。 3、從售前到實施解決方案要經過一個從功能排列到操作串聯的變化。 售前階段對軟件更多的是從功能列表角度去陳列，或者解釋不同應用需要用到哪些功能，在實施方案就中就必須能夠將這些功能真正串接成業務操作，讓用戶能看懂一個業務在系統支持下從原始輸入到最終輸出的全部流程，而不能含糊其辭。 一份含糊的業務方案其實反映的是一個公司，一個項目經理對業務把握含糊不清的狀態。這種沒有業務串聯的方案也難以指導項目團隊成員有效完成配置和開發。 沒有目標定義的項目很難獲得成功。 編制實施階段解決方案常見問題 第一、和售前方案几乎難以區別，都是價值點+功能手冊的模式 實施階段解決方案很容易從售前範本中學習到“假，大，空”的毛病，對軟件價值缺少足夠的邏輯論證，關鍵價值實現業務路徑缺少分析。 實施解決方案很容易成爲功能點的羅列，難以指導用戶形成業務思路，也不能指導實施人員進行業務配置，也無法通過解決方案驗證配置。 實施解決方案過多羅列價值點必要性不大，用戶更願意看到實現哪些業務流程，在過程中改善了哪些環節工作，是如何改善的，要如何實施，最終操作模式是怎樣的。 軟件功能點在軟件功能手冊中有，實施解決方案要針對企業業務進行數據建模分析，然後形成新的業務流程框圖和操作思路說明。 第二解決方案對項目價值點關注很多，對項目目標關注過少，而且不細化，不量化，不提驗證手段。 第三解決方案抄用歷史模板圖片，沒有用用戶的實際數據做圖片。 第四在內容編排上和一些細節上不注意和售前方案呼應，基本不參考售前一些工作成果。 |