軟體產業之範疇認定─峽谷到底有多深(上)吉賽普‧德雷納的義大利設計師,常常對行銷人員說,『不要告訴我你們要一座橋,要讓我知道峽谷有多深!』
假如,搬家是一門專案,
相信大部份的人都知道搬家要做什麼、有哪些過程、要外購什麼、目的是什麼、如何驗證?
可是,場景一但轉到軟體專案,
專案的交付標的,可能馬上就成為一座深不可測峽谷上的一座橋,
舉例而言,像是到美髮沙龍做髮型設計前,
好的設計師通常會先問客戶想要的樣子:
『我要看起來年輕』、『我想改變一下造型』、『我想剪頭髮但是不要感覺太短』會依據客戶的年齡、髮量、髮質、髮況,舉出過去的經驗(reference)、未來可能的樣貌(modeling)、甚至是使用的工具、技術(Frame Work or tools)一一溝通,以求得一個共識後,開始進行。到這裡,可能已經有人想到,完成後,到底要拿什麼依據來讓客戶驗證範疇跟品質是為『嗯~真的有比較年輕』、『真的沒有太短』的依據。
純專案型的軟體開發,全然客製化的量身訂做,它其實正是一個『從無到有』的過程,於是乎軟體工程、SOP、CMMI等的方法,夯到爆炸的原因,正是因為大多數服務提供者已經面臨到『無中生有』的手法是需要再被催熟和規範的。
任何的客製化服務,若是淪落於我們『自我感覺良好』但『客戶感覺不佳』的境地,就像是我們在大峽谷上勉強架上了獨木橋,巍巍顫顫、搖搖顛顛。
基礎就是錯的時候,改善,也只不過是在獨朩橋上鍍了層金箔,或是由一座變成兩座,讓它看起來,似乎稍稍比較良好而已。
既然無論再怎麼定義,仍然避免不了所謂『認知』上的落差,那麼在時間、範疇、成本專案限制的鐵三角中,是否也難免時間的延宕、成本的驟增、品質的低落的結果?讓失敗的專案機率分子,又添一椿?
客戶真正的需求、期望與最終團隊執行出來的結果,常常不是一座橋就能跨越的距離,因為有時候,誰都不清楚峽谷究竟有多深?
作 者:李君婷,PMP


專案溝通管理實務分
溝通管理
前言:
溝通管理在實務中,對於專案成敗有莫大的影響,相當多的專案管理人員普遍對於溝通的方法與策略感到困擾,比如跨部門協調,內部資源協調,客戶協調......等等.藉由PMP課程系統化的學習,專案管理人員可以更加理解對於不同的專案型態應該著重的溝通角度與手法藉以透過有效率的溝通來提昇專案整體成功率,對於溝通管理我提供一個實務經驗,分享給各位.
案例:
背景:
標的:某電信公司簡訊系統專案
金額:120萬美金
交期:6個月
驗收條件:系統正常發送簡訊,帳務系統可正常出帳網管可正常監控
過程:
這個案例最後是失敗的,交期超過6個月,且減價驗收,本案硬體建置部份不多,
主要以軟體為主,甚至是高比重客製化軟體專案,以專案的角度來看在前段的
客戶需求蒐集,以及溝通管理沒有完善,導致後段執行時發生,交付標的與客戶
需求不符,雙方認知落差很大,甚至連基本的網路管理軟體,均與客戶的期望不
同,無法統整至客戶既有網管系統,最後的結果是,為了應付驗收,不斷的修改
與測試軟體,此時,時程已嚴重延誤,但仍需符合客戶最基本的驗收標準,才同
意付款結案.
分析:
1.業務與市場與客戶溝通不夠確實,答標書承諾過多,違背專家參予判斷的原則.
2.簽約後細部客戶需求溝通因為研發團隊在國外,僅能利用書信與電話會議進
行討論,再次早成需求落差.
3.礙於公司體制於投標階段無專案經理與軟體研發團隊參予,導致需求不清,
後續變動不斷擴張導致專案無法收歛終致時程延誤.
4.後期專案經理因有結案責任,不斷再公司內部業務與內部研發及客戶間扮演
溝通橋樑,平衡雙方認知差異,擬定可交付標的但書進而推動內部研發團隊
接受軟體須修改事實,並協調客戶收歛過多擴張的需求與支付部分款項,展
現結案誠意.
5.現場執行工程師因技術力不足,摸索時間過長,無法提供有效預警,亦導致
多次重工,客戶整體觀感不佳.
改善:
1.先行指派專案經理與技術支援團隊餐與投標作業,提供有效的專業意見.充
分與客戶溝通,避免專案嚴重鍍金狀況發生
2.進行細部功能與需求討論時,應由專案經理主導, 邀集研發團隊與客戶需
求人(重要利害關係者)進行溝通會談,確認需求,並做成書面記錄.
3.執行高客製化比重專案,建議公司內部採用臨時編組方式,先行指派專案與
技術團隊進行投標建議,減低風險發生率
4.專案經理應建議此類型專案執行時,國外需支援經驗豐富的專家,將本國工
程師技術力與以提升,甚至常駐,立即回應客戶需求,或扮演與後端研發團
隊的橋樑,避免因為多層次溝通,導致訊息失真.
作 者:彭祖揚,PMP
