題:
在交付時,客戶批評我的報價中沒有寫一些功能。怎麼反應?
Mik378
2016-11-07 02:52:26 UTC
view on stackexchange narkive permalink

作為自由開發人員,我為一個客戶(公司)開發軟件工作了兩個月。

我草擬了一個報價,其中提到了四個功能:A,B,C等。該報價是由客戶簽名的。

在交付時(現在正在發生),客戶端批評缺少功能E,F和G。

一方面,看來軟件I的體系結構內置的代碼可以在幾個小時內輕鬆集成E,F和G。

另一方面,我希望他們是專業的,並意識到他們完全誤讀了我的報價。

作為專業人士應該如何應對?

  • 集成E,F和G,並在不向客戶收取更多費用的情況下交付它們,以避免潛在的衝突。
  • 除非我向他們收取更多費用,否則拒絕集成E,F和G。

編輯-----

正如@Falco在下面的評論中指出的那樣,我要補充一點,我明確要求客戶在產品發展過程中測試解決方案(根據敏捷實踐),但沒有。

“給他們自由的工作來留住客戶”是一個可以理解但現實上很糟糕的想法。它樹立了“如果我們抱怨,他將免費為之做”的先例。甚至讓客戶討價還價都是不好的。這更糟。
“幾個小時的編碼” –關於測試,部署等?
評論不作進一步討論;此對話已[移至聊天](http://chat.stackexchange.com/rooms/48312/discussion-on-question-by-mik378-at-delivery-time-client-criticises-the-lack-of)。
有兩種想法不值得完整回答:(1)問他們:“為什麼要包含E,F和G?”(2)喬爾·斯波斯基(Joel Spolsky)對這種普遍現像做了(有點)幽默的解釋:“我們完全按照他們想要的方式建造了它。合同規定了整個事情的細節。我們完全按照合同規定交付了貨物。但是當我們交付它時,他們垂頭喪氣。”他的建議:習慣它。客戶不知道他們想要什麼。即使他們這樣做,他們也沒有表達它的技能。(https://www.joelonsoftware.com/2002/02/13/the-iceberg-secret-revealed/)
八 答案:
Kilisi
2016-11-07 03:28:03 UTC
view on stackexchange narkive permalink

這很簡單,在執行任何操作之前先按合同約定付款。如果他們想要EFGHIJKL,請給他們報價。這是做事的專業方法。

如果您在因某種錯位的“無論是什麼”而獲得報酬之前進行EFG,請指望被告知要做HIJKLMNOPQRSTUVWXYZ。

做什麼在合同中,得到報酬,然後再談判其他任何事情。

我已經遇到過這種情況很多次了。我不會對此進行長時間的對話,我只是禮貌而專業地要求付款,而且要簡短明了。之後,我將忽略所有不包含付款確認的信息。

”所有超出我最初引用並完成的工作範圍的事情。我很樂意就此進行談判但我需要先為現有工作付款。請隨函附上我的發票副本,並儘快安排付款,以便我們繼續前進。謝謝您的問候,等等。“

有人告訴我,這將使我失去以後的工作,但從實用上講,它很少有,其次,對於沒有付款問題的客戶,我沒有用。自由職業者經常為錢花很多錢,但是如果不及時支付錢就沒有意義。

永遠記住,作為自由職業者,您不在他們的等級制度中,任何輕率這種垃圾會削弱您當前和未來的談判地位。僅僅就此進行參與對話會浪費您的時間和金錢,應該避免。

“有人告訴我,這將使我失去以後的工作”-我想由那些不想付錢的客戶。
他們有時暗示了我自己的員工,他們對公司規模等印象深刻,等等。在實踐中,我知道這是一種談判策略,幾乎總是不停地吸引客戶並獲得更多工作,但是我為他們加價。客戶的規模和成功與否並不重要,重要的是他們在我的口袋裡放了多少錢。
FYPMA-PMA代表“ Pay Me Applies”。正是由於這個原因,許多供應商現在積極地將需求缺口的責任轉移給客戶。因此,未能記錄需求不是我們的錯,不是將需求包括在其“故事”中是我們的錯....工作說明,範圍說明。工作“滿足要求”和“預期功能”。其他任何事情都是范圍蠕變,可以在UAT中進行分類,並且應該有一個UAT,其中包含“真實”用戶,而不是其代理或替代利益相關者。
“ UAT” =用戶接受測試。不是每個人都知道該縮寫。另外,沒有標籤“接受階段”,我認為這個問題需要一個。
[相關話題](https://vimeo.com/22053820)
有趣的是,無論如何,這很少對客戶有用。當我們意識到某些客戶是這樣的時候,我們簡單地提高了所有價格-客戶從討價還價中獲得了樂趣,有一種很好的感覺,就是從我們的錢中騙取了我們的錢,而我們得到的錢與一個可靠的客戶。最瘋狂的情況是,中間人以某種方式說服客戶可以談判這樣的事情-在這種情況下,客戶覺得自己由於中間人而節省了很多錢,而實際上卻損失了很多錢。
@smci打開一個元問題來創建標籤。讓我們討論一下
+1表示*我不會進行長時間的對話*。a)創造擺動空間或b)增加情緒的任何事物都應避免。
-1
如果您知道您已經可靠,專業地交付了合同中的所有內容。然後,是的,任何事情都會使您感到困惑,而當出現問題時,我的策略只是繼續提高價格。我稱其為“ panadol錢”,這是使我忍受頭痛的花費。
@CaffeineConnoisseur或者,正如我的一位好友所說,“ f-ck off”價格。
您也可以為EFG撰寫報價並將其呈現給他們,但隨後*主動*(不要讓他們討價還價)說:“由於我感謝您的業務,並且它並不十分複雜,所以我會繼續包括EFG在內,這一次不收取額外費用。不過,將來,請務必徹底檢查報價,因為超出報價範圍的其他工作必然會產生額外費用。”-也要以書面形式寫成,因此,如果他們嘗試在以後的工作中使用相同的特技,則可以產生電子郵件並說“我已經告訴過您,其他工作將花費額外的費用”。
Viktor Toth
2016-11-07 08:13:12 UTC
view on stackexchange narkive permalink

我是自由開發人員已有30多年了。我在很多場合都遇到過這種情況。但是,在大多數情況下,預防或緩解並非難事。

首先,請確保您的報價內容透徹,字詞明確。

第二,將您的客戶視為合作夥伴;在開發過程中及時告知他們;向他們展示您可以做的事情,例如用戶界面模型,以便他們一開始就完全了解他們將從您那裡收到的東西。和“任務爬升”(使其成為您的支持費用的一部分),隨著規範的不斷發展,因為客戶自己通常在看到一些工作代碼之前才完全不了解自己的要求。這樣,當需要進行相當小的更改時,您可以適應它們(您可以通知客戶,當然,這些更改使您超出了原始規格,但是您預計可能需要進行一些更改,而這些要求並不那麼廣泛,因此您可以

第四,如果儘管採取了預防措施,但您發現自己處在這種情況下,那麼它確實成為一個判斷的電話。有沒有跡象表明這是一個永遠不會快樂的“問題客戶”?然後貼上報價單的字母,當需要新功能時,請為他們提供修改後的報價。 (即使如此,請記住,在您收到付款之前,問題客戶將持有所有信用卡,如果發生爭議,則完全由您承擔舉證責任。最好不要採取即使這意味著吞沒您的自尊心也是如此。)還是這是您與您建立了長期合作關係的客戶,您有理由期望它持續很長的時間,並且您將獲得更多合同?然後儘其所能(在合理的範圍內)使他們滿意(再次,可以告訴他們您所做的超出了原始報價的步驟。)

您不應該期望的一件事就是您的客戶“專業”。那就是您的工作:您是這裡的專業人員,客戶就是那位客戶。當然,擁有一個始終專業的行為但不期望這樣做的客戶是一件好事。不要期望客戶經常不完全了解他們自己的需求。您的工作部分是幫助他們了解自己的需求並教育他們可以提供的東西;當彌合客戶期望與可行現實之間的差距時,您需要採取額外的(小步驟),請考慮採取這一步驟而不必大驚小怪。

客戶已經表明自己是一個“問題”,抱怨而不是討論,他們沒有在構建過程中進行測試,只是在結帳時抱怨。他們不應該休息。不錯的綜合答案,但+1
@Kilisi這是我最喜歡的答案。我已經擔任顧問30年,現在退休了,我想說給他們E,F和G,然後期望他們之間建立聯繫。我重視知道他們想要什麼並準備就緒的客戶。我只有一次同意為不確定的人開發任何東西。當然,這是一場災難。我很愚蠢地同意首先與他們合作。我發現我可以給他們更多時間再說再見。原因很簡單。我給了他們比他們同意的更多的東西。任何爭執都將以我的名義結束。我認為這是一個教訓。
@closetnoc我也喜歡這個答案,知道使用相似策略的顧問,我對此表示贊同,這不是我做事的方式。我也從事諮詢工作已有數十年之久,自那以後,我就通過了那些不夠殘酷的傢伙。
@Kilisi我更喜歡善待自己。就我而言,這是雙贏的局面。30年中的一年還不錯。這是合同之間的一項填充工作。一個簡單的VB工作,當我交付時,他們突然決定要在Access中全部使用。我是系統內部工程師。我知道代碼!我編寫了操作系統,設備驅動程序,協議棧等。VB是正確的事情,也是他們所要求並簽署的。訪問應用程序是一場噩夢!交付後,我將其傳遞給Access程序員,並與他並肩工作直到完成。無論如何,我從Access程序員那裡得到了一個朋友!
@Kilisi在我看來...公司的每項變更都必須重做Access代碼,而我的代碼是一個完整的解決方案。它是一個醫學調查應用程序,允許某人指定調查,按一個按鈕,並自動創建調查可執行文件,並將安裝過程和導出過程寫入磁盤。只需幾分鐘。對於Access,這需要修改每個調查的代碼並手動打包安裝,並且不能導出到SAS和磁盤。最後,這是悲傷地看到我的甜蜜代碼忽略。無論如何,我感到被證明了!
您應該向他們收費:-)我只是愚蠢而已。
Vietnhi Phuvan
2016-11-07 03:40:30 UTC
view on stackexchange narkive permalink

這是另一種情況,客戶希望供應商能讀懂他們的想法,然後推銷該供應商:

  1. 告訴客戶先生,您的報價是基於以下規格他給了A,B,C和D。州政府斷然拒絕在報價單上說過關於E,F,G的任何事情。

  2. 告訴他,雖然您對E,F,G的評論表明僅需幾個小時即可完成,但您將其視為原始報價未涵蓋的其他工作,並且,如果他希望完成工作,他將必須額外支付額外的工作。然後寄給他一張原始工作的發票。

  3. 除非您已支付原始工作的報酬,否則不要做其他工作。

  4. ol>

    不幸的是,您將不得不承擔可能無法獲得不道德的客戶付款的風險。如果對您有幫助,那麼最好儘早確定某個客戶是一個黑洞,這會浪費您的時間和精力,而以其他付費客戶為代價,這總是對您最好。

keshlam
2016-11-07 03:02:45 UTC
view on stackexchange narkive permalink

取決於更改的大小。您的預算應包括一定數量的客戶支持。如果可以解決這個問題,那就太好了。如果不是,請提供其他工作的報價。

注意 ,但是,這部分是您的錯。您確實應該在流程的早期就擁有客戶審查草圖/原型,因此他們確切地知道您期望進行的研究,或者已經簽署了該協議,或者在仍有機會解決任何優先事項/預算時討論了更改優先級/預算的問題。分娩前的擔憂。可能有一個合理的論據,就是如果您沒有這樣做,您應該欠他們一些東西。

只要項目不斷發展,我就要求他們測試增量解決方案,以便獲得一些早期反饋。他們說他們這樣做了,但最終他們承認沒有這樣做(因為時間(他們認為))。他們完全隱含地期望功能。
@Mik378`他們說他們做到了,但是最終,他們承認自己沒有這樣做。'嗯,他們的錯。我同意您只要求付款,然後(如果他們仍然願意)可以討論其他功能。(而且,如果他們不盡快付款,請記住,您可以在許多國家/地區要求某種延遲費)。
@Mik378-我認為這是必須包含在問題正文中的要點!-因為您明確要求他們進行測試,而他們沒有進行測試-他們失去了任何地位。
@Falco,確實是我更新了問題;)
在項目進行期間,最好徵求反饋,如果您沒收到反饋,請告訴他們我可能會有後果。“我需要你們來進行測試,否則我們可能在項目進行到後期之前都不會發現問題”(我會隨隨便便加緊。1.您是否進行了測試,否?我們下周說截止日期,下周可以做嗎?
Jay
2016-11-08 04:23:00 UTC
view on stackexchange narkive permalink

我同意上面所說的大部分內容,所以讓我補充一點。

客戶是否可以合理地期望E,F和G包含在A,B中? ,C和D?我的意思是,例如,如果這是一個在線訂購系統,則A是“客戶可以輸入他們的送貨地址,城市和州”,而現在他們在說:“等等,您沒有給我們一個輸入郵遞區號的地方”,我認為您不能因為A所假設的想法而責備他們。如果現在他們說應該有一種進入國外的方法,那是值得商bat的,應該是在早期討論中已清除。如果規格/報價中提到它,則有理由說它不在此範圍之內,但以此類推。如果現在他們在說他們希望每週報告按郵政編碼和狀態細分的已接收訂單數量,按產品類別交叉引用...不。

我對客戶懷有美好的回憶,他們在交付後詢問如何獲得某些複雜的報告。我說對不起,要求中從未提到過這樣的報告。他說:“我認為這是理所當然的,我可以隨時獲得我想要的任何報告。”就像是的,這就是計算機在《星際迷航》中的工作方式。

如果這些新要求僅佔整個項目的一小部分,即使客戶報價中沒有列出,我也傾向於為了客戶關係而將其提供給他們。但是請告訴他們,您是出於客戶關係的目的而將其贈送給他們的,即使報價中沒有提供。毫不留情地給予自由蜂可以使您時刻保持期望。自從成為自由職業者已有數年了,但我從未做過,但是如果我現在遇到這種情況,我想這就是我要做的事情:進行更改,然後向他們發送帳單,上面寫著“其他功能E, F和G ... 4小時@ $ 150 /小時(或明顯地是您的費率)... $ 600。為客戶關係註銷...-$ 600。淨欠款... $ 0。”然後,您告訴他們您給了他們一個幫忙,以及幫了忙一個多大的忙,並不意味著您會再次這樣做。如果有人嘗試過這種方法,我很想听聽詳細信息以及它是如何工作的。

您說這些新要求只是工作幾個小時。但是,如果這很重要,我會說:“對不起,報價中包含了A,B,C和D。如果您還有其他工作要做,我很樂意為您準備一份新報價。”

順便說一句,您說您在此過程中向客戶提供了原型版本或類似類型的東西,而他們顯然從未看過它們。這當然不是聞所未聞的。這件事發生在我身上,然後當然,當他們最終查看它時,他們有100萬次更改。但這是一個危險信號,表明它可能是問題客戶。如果客戶願意承認自己從沒有看過事情,並願意為返工付費,那很好。我公司現在有一個這樣的客戶,他們直到項目完成後才開始看事情,所以與其等早地進行更改,不如在容易的情況下進行更改,我們等到進行大量返工時才結束。但是,當我們向他們收取返工時間時,他們也不會感到失望。所以我想我們以這種方式賺了更多的錢,所以我們不要抱怨。但是,如果他們不願意為返工支付費用,那麼這就是問題客戶。我會努力讓他們這次開心,收錢,然後避免將來與他們做生意。

非常完整有趣的答案:)
paparazzo
2016-11-07 02:59:18 UTC
view on stackexchange narkive permalink

一些缺點

  1. 稍後支付
  2. 沒有為E,F和G支付
  3. 在交付E時得到I和J F和G
  4. ol>

    如果您真的認為這只是幾個小時,並且會付錢給他們,也許就這樣做。但是它很快就會失控。

    即使您確實引用了E,F和G,那麼我仍然會在第一個請求付款。

@cognacc我真的應該知道EFG是什麼?詢問操作員是否確定只有幾個小時。
Dunk
2016-11-08 02:31:14 UTC
view on stackexchange narkive permalink

我認為,這完全取決於您擁有的客戶類型。如果他們在技術上精通並且應該確切地知道他們的需求,並且由於他們沒有可用的人員而只是在使用您的服務,那麼堅持在定義的工作範圍內是正確的響應。

,如果您接受了一位客戶,卻知道他們不具備預先了解他們將需要的所有特定要求的知識,那麼我來看看,因為他們也在聘請您的專業知識來讓他們知道所缺少的內容。畢竟,您是“專業”開發人員,而不是他們。因此,如果您應該“合理地知道”,如果沒有他們說的功能,他們就缺少應用程序無法滿足其需求的功能,那麼,即使不是大多數,也應該歸咎於您。在這種情況下,您應該下次從錯誤中吸取教訓,但是這次要使客戶滿意。當然,您可以要求更多,但要認識到您在缺少的功能中所扮演的角色。當然,“合理地知道”是一個灰色區域,但是我懷疑您已經知道您是否應該意識到是否需要該功能。如果缺少的功能不是典型的“專業”開發人員應識別的功能,則請遵守合同條款。

這是一個很好的觀點。打個比方:大約一年前,我需要對房子進行一些維修。我給承包商打電話,我們簽了一份合同,他們願意為此工作,我認為這是1800美元。然後幾週後,他們打了個電話,說:“哦,我們做錯了,要正確地完成這項工作,我們將不得不再做一些這樣的工作。這將再花費900美元。”我立即得出結論,這是一個騙局。我一分鐘都不相信他們犯了一個錯誤。試圖使我致力於以合理的價格完成這項工作,然後他們抬高了價格。...
...我可能可以起訴他們違反合同和欺詐行為。我的觀點是:您是專家。如果您告訴客戶,要滿足他們的需求需要做的是A,B,C和D,這將花費$ X,他們可能會以總價為前提簽訂合同。如果他們發現這樣做不能滿足他們的需求,則告訴他們做額外的工作會花費額外的錢,他們可能會認為這是個竅門:您讓他們根據他們負擔得起的價格作出承諾,但現在要做真正的工作,您要求更高。我並不是說您想欺騙他們,這聽起來像是對我的誤解...
...但是我可以看到有人對IT思維一無所知,這只是試圖欺騙他們。
Joel Huebner
2016-11-08 04:38:36 UTC
view on stackexchange narkive permalink

我一直在“工程軟件-蒸氣軟件”的客戶端上。構建新平台確實很費時間,R & D也是如此。您已交付了已簽訂合同所要求的。您有持續支持的機制嗎?是否將此產品用於其他客戶?通過這兩個概念,您可以參與分佈式更新。您必須建立一個可以維護的模型。產品下一階段的複雜性以及測試和確認。您將有一些客戶(如果他們的知識庫允許)堅持要進行Beta測試。您將必須告知他們您的期望值。保持在該範圍內。這為您提供了可管理的更新/升級模型,持續的現金流和滿意的客戶。 IMHO JLH這就是我必須與多家供應商(合併)一起為小型大學實施多階段,多層次,ERP系統的方式。

歡迎來到workshop.stackexchange.com!照原樣,我不太確定您的答案是否能回答問題。您可能要進行編輯,重點是提出問題的可能解決方案,而不是提出一些問題並描述您所做的事情。獲得50的聲譽後,您就可以對問題發表評論,要求提出要求的澄清,以更好地告知您的答案(例如,您是否將此產品用於其他客戶?)。


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...