專案管理雜談 客戶是上帝嗎?

2021-05-24 15:08:15 字數 1681 閱讀 6700

由於常駐現場開發,與客戶打交道的機會比較多,在專案組成員的眼裡,客戶是什麼呢?是上帝嗎?要樹立以客戶為中心的思想嗎?我估計很多程式設計師都沒有想過這個問題,只是想把工作完成就ok了。由於沒有這種心態,也導致了有些專案組成員在和客戶的溝通中,問題不斷,因為使用者的需求變化導致開發者和客戶的對立也時而有之。

在公司和銷售眼裡,客戶是上帝無可厚非,客戶是軟體公司的衣食父母,是軟體公司生存與發展的基礎,是公司利潤的**。

但在專案組成員的眼裡,這種心態還沒有完全建立起來,或者說是沒有主動的意識。

對於很多現場開發的人來說,公司一般都會要求專案組成員要搞好客戶關係,這一點很多公司的員工的確也能做到,有時候還做到非常好。從這個方面講,客戶是有其優越性,公司員工尊重他,為他服務,讓他體驗了做上帝的感覺。但另一方面,也是關鍵的,客戶希望公司做的專案、開發的軟體能夠真正幫助其解決問題。

客戶一般會從一下幾個方面給軟體打分:

1、功能方面:系統是否提供了完善的功能?功能是否能夠滿足業務需要?

2、穩定性方面:系統的穩定性如何?是否經常出錯或崩潰?

3、操作方面:操作是否簡單?是否符合windows的習慣? 對於bs架構的系統來說,是否操作便利是非常重要的一條。

4、效率方面:程式執行的效率如何?響應時間是否短?對於bs架構的系統來說,要考慮到使用者的忍受力,比如說查詢得到結果的時間不要太長(大於2分鐘)。

5、服務方面:服務是否及時?

6、介面方面:介面是否美觀?

我們也可以試著從這幾方面給自己做的系統打分,評價一下我們給客戶做的系統。 事實上,能做到達到客戶大部分要求的系統少之又少。因此,客戶這個上帝有時候很累、很無奈。軟體公司做的很多系統,自銷售拍胸脯保證拿下合同後,就扔給了專案組,專案組又衝忙上陣,腦子裡就是時間和成本,至於質量也敢有太高的保證,出發點低、需求驅動,基本都是為了專案而專案,加之客戶方缺少資訊化建設方面的規劃,導致專案未結束而新的需求就不斷產生,一邊埋怨系統不能滿足其需要,一邊又在不斷開發新的系統。

既然上帝很累、很無奈,那麼,在上帝眼中,又是如何看待專案組的呢?經常和客戶聊天,也了解了客戶的一些想法,一般比較大的客戶,都有好幾個軟體公司為其服務,客戶也會經常將這些公司進行比較,哪家公司強、哪家公司弱?總體來說,客戶對公司的滿意度不高。主要表現在以下幾個方面:

1、公司規模方面:小公司和大公司之間,都有問題,小公司規模小,員工待遇低、跳槽的多,造成很多不確定性,客戶剛和你把業務溝通得差不多了,你卻跑了,換個人來,客戶還要再重複一遍,客戶覺得煩;大公司比較牛氣,但成本高,開發費用高。

2、業務能力方面:公司方面的業務能力大部分都存在問題,很少有真正掌握其業務的,只有部分公司有領域專家的存在,協助專案組解決問題。

3、技術方面:很多專案組成員自認為是技術牛人,其對新技術、新概念的狂熱追求,自以為是,但這種人只能唬住一時,其實,客戶方有時也有一些技術大拿,不顯山、不露水,其對作業系統、對資料庫、對語言的理解往往高人一等。

如何讓客戶成為上帝?首先我們要有客戶是上帝的意識,要有以客戶為中心,為客戶服務的意識,並把這種意識帶到具體的工作中,帶到我們做的專案中,這就要求我們在開發系統時,要深入了解上該系統的目的,想使用者真正所想,客戶提出問題時首先要接受而不是排斥、拒絕,要反思客戶提出這樣問題的背景,是否是自己設計或開發時缺少了什麼?這有這樣,才有可能提公升客戶服務,從而對軟體公司帶來回報。

專案管理雜談

最近一直再看統一軟體開發過程.並且在帶領團隊開發專案的時候也基本是按照書上所說來展開專案的.回頭看看這些專案覺得有諸多問題.提出來大家一起討論.首先談談專案的開發流程.這個我想都大同小異.a 制訂標準,包括協作標準資料庫標準 標準 在附件裡面規則.rar b 搭建框架,主要包括 1 整體 專案採用的...

專案管理雜談

最近一直再看統一軟體開發過程.並且在帶領團隊開發專案的時候也基本是按照書上所說來展開專案的.回頭看看這些專案覺得有諸多問題.提出來大家一起討論.首先談談專案的開發流程.這個我想都大同小異.a 制訂標準,包括協作標準資料庫標準 標準 在附件裡面規則.rar b 搭建框架,主要包括 1 整體 專案採用的...

專案管理 IC 雜談

廣義來說,任何有目的的行為,都可以看成專案,具體定義,可以參考各種培訓教材。比如pmbok的定義 專案是為創造獨特的產品 服務或成果而進行的臨時性工作具體到積體電路設計公司,乙個專案通常是一顆 或多顆 晶元設計和製造的全流程。也可以是乙個ip的開發。其他的經營活動,比如準備一次團隊建設活動,組織招聘...