php外包如何逃离垃圾客户案例(转)
?
php外包如何逃離垃圾客戶案例(轉)
做項目做產品可以有3個境界：1 掙錢的，2 做品牌的，3 很酷的。有的人從境界1做到3，有得人從3做到1。
我是從1做到3，因為有了錢，你才能遠離垃圾項目和不專業的客戶。
?
無論你是單打獨斗兼職之余接個小項目，還是已經成立了公司簽合同蓋大紅章接外包項目，初期階段都遇到過垃圾項目和垃圾客戶。你有可能拿到了搭上了無數個不眠之夜，只獲得了少的可憐的報酬，受了一肚子氣還不落好，客戶正和你在心里互相怒罵。也有可能一分錢都沒拿到，受騙感和屈辱感正驅使你要去百度貼吧上聲討那個客戶公司。更有可能把你的一幫弟兄們一塊拉進了一個大坑，你人生中最重要的資源之一正在廉價地流失。
垃圾項目是一個必經階段：
* 考驗你團隊是否能同甘共苦肝膽相照
* 磨練你的耐心和自我控制力；
* 讓你學習代碼規范、架構規劃、分工設計、進度設計、質量控制等預防規避機制；
* 幫助你健全任務計劃、進度反饋、測試文檔、郵件、合同、備忘錄等重要文檔規范
下一步你要做的就是一看見垃圾項目和垃圾客戶，就跑得越遠越好！！
下面我來講一些可能大家都經歷過的故事：
故事1 你得尊重我們
朋友A：一個小建站公司的創始人，優秀的WEBUI設計師，公司正起步階段。
A偏重設計，主要接一些公司宣傳類型的小站。純界面類的活，后臺拿現成開源的程序那么一套，他做設計又駕輕就熟。遇到一個做少兒智商啟蒙培訓類的公司做宣傳站。一切談妥，A說把公司LOGO發來吧。客戶告之還沒設計出來，你就先做吧。
朋友A按照少年兒童花朵般的特征選用了湖藍和嫩綠的基調配色，這可是2.0流行色，又大方有時髦兒。大大的焦點圖，這可是2.0的流行做法，視覺重心穩定，結構分明，有設計感。
做完客戶表示挺滿意。下面就該把客戶的LOGO和要用焦點圖替換上去啦。
好嘛 LOGO是大紅色的旭日升起狀，下面寫著3字 “紅太陽”。
焦點圖客戶有指導意見了：5張圖對吧，得放我們領導的照片，簽名還有題詞。
拿來一看，全是大爺大媽腆著肚子，指點江山的照片。
朋友A頂著得尊重客戶的想法硬給換上了。
結果就是頁面怎么看也不好看了，能好看得了嗎。客戶不滿意了，于是提供指導意見要求改動改動。這一改動完蛋了，越來越別扭。上線日期已經到了，頁面正在變得越來越難看，朋友A正在變得越來越悲痛，客戶正在變得越來越憤怒。上線前頁面勉強丟到了線上。客戶很不滿意地付了錢，朋友A飛也似地逃走了，一個月后客戶的網站另請人完成了頁面的改版。朋友A上去看了一眼以后再沒勇氣看第二眼。他把這個case永遠地從客戶案例列表中刪掉了。
故事2 我們要做成一個偉大的項目
朋友B：SOHO，一個6~7人規模的web項目開發團隊的領頭人，項目經理，產品端經驗豐富。
B以為遇到了一個天賜良機，坐在他對面的這個人充滿了激情野心與斗志，他健談，機智，敏銳，富有感染力，他善于規劃，他尊重人才，他對互聯網每種盈利模式都熟知，他輕描淡寫地說著手里拿到的強大資源。B的眼睛也閃閃發光：“關鍵是這個人器重我，器重我的團隊，而且報酬也不錯。”
B帶領團隊已經成功做了幾個不大不小的項目，團隊成員都不錯，都能各擋一面。B的每個項目都簽定合同，50%預付，50%尾款，最大程度上保障團隊成員的利益。
客戶說，你現在起就是我最重要的合作伙伴，我們要做成一個偉大的項目。
他們的合作正式開始了。
客戶已經有了一份詳細的項目規劃，雖然看起來不太專業和靠譜，不過總比沒有強。而且項目本身也不是很復雜，功能模塊不多。
年輕而有活力的團隊成員已經開始著手規劃系統技術架構和數據庫結構，每個人都準備借此機會大干一把，創造出一個雞凍人心的產品。
但這個時候B遇到了一點比較郁悶的小挫折，精力旺盛的客戶每天都會在很晚的時候上線來和他討論應該起什么域名，域名一直沒有確定，大家也知道現在好的域名太少了。拼音不行不夠國際化，帶數字的不行不夠專業，太長了不行記憶成本太高，生造詞不行容易流失新用戶，太古板不行不像2.0。
域名問題折騰了B半個多月，買了許多個備用域名，終于確定了一個。有了域名該起網站名稱了，起了網站名稱就需要設計LOGO了。在用中文名還是英文名的問題上、LOGO和名片的設計上又折騰了很久。
科學的分工和任務并行規劃并沒有讓這個小小挫折對整體項目進度造成太大影響。
但是產品端上的細節問題引發了越來越多的陣地戰。比如積分機制，登錄框的放置，首頁第一屏的取舍之類的啦。客戶對他所不了解的技術方面沒有質疑，但是在他所有能理解能看見的地方有著極強的控制欲和偏執。
雖然大部分產品問題，客戶最后還是聽從了B的專業意見，但產品端遲遲不能定稿以及B作為項目經理角色在拉鋸戰上花費的精力已經對整體開發進度造成了延誤。
產品端終于定稿，項目進入前端和程序的整合階段，客戶的精力轉向去談資源和市場。
一天，客戶要求面談某個重要的事情：“我新談下來一批視頻的獨家資源，是來自***機構，有多么****，談下來的難度有多****，我覺得放到我們現在的網站上很不錯，好處有****，現在網站運營的不足有****，市場開拓難度有****，所以我們現在需要加一個視頻頻道。”
B開始覺得大事不好：“您想做成什么樣的？”
客戶說：“我覺得優酷那樣的不錯，能做成優酷那樣的嗎？”
……可行性的拉鋸戰……
……實現度拉鋸戰……
……工期的拉鋸戰……
……插入開發計劃時間點的拉鋸戰……
B擦著汗說：“那費用呢，我們需要增加一點開發費用。”
客戶：“當初你們開價的時候我可一點都沒壓價，我希望我們能拋開短視以項目為重，我們是準備長期合作的，你是我最重要的合作伙伴，我以后不會虧待你們，我現在的預算計劃是****，我的初期投資準備花在*****，已經有人在給我投資****，談妥后給你們的投入是**** …………。”
B妥協了。
于是惡夢開始了。
客戶開始不斷要求增加新的功能點或頻道，以配合他手里掌握的資源和不斷拓展的市場需求。
上線時間延遲；客戶對進度持續施加壓力；團隊成員疲憊、挫敗、不滿；系統架構嚴重偏離初期設計，臨時性處理和補丁越來越多，進度和質量控制體系全面進入混亂階段。
B開始在需求問題上急剎車，對客戶強硬。客戶不滿情緒積累，定下項目上線的deathline。
正常的BUG調試階段從最初計劃的1個月被壓縮到1周。內測版就像一艘四處漏水的大船，團隊成員在長期的連續加班中疲憊和抵觸，客戶看到內測版大發雷霆。
又經歷了痛苦的2個月，項目終于上線可用。
殘酷的結局：
* B和團隊成員經歷了痛苦的大半年，付出的工作量遠遠大于所得到的報酬。
* 客戶宣傳自己掌握的資源并沒有到位，許多功能和頻道閑置后又暫時隱藏。
* 客戶請來另一個的技術顧問對系統架構大加指責，合作徹底破裂。
* 項目上線后半年不到，客戶廢棄了這個項目，轉向另一個自己感興趣有資源的領域。
* 精心的付出和最初產品理想的破滅，以及B的數次失誤，導致B在這個項目失敗后失去了一部分團隊成員。
故事三：朋友介紹的好機會
C：高級程序員，5年代碼工作經驗。在職，工作清閑，偶爾接點私活。
外地人，在北京漂著，8K月薪稅前，偶爾需要加班，有個職業普通的女朋友，買房甭想，打車掂量掂量。宅男，回家了就看看資料看看美劇，長時間持續的代碼工作，視力一天不如一天，脖子和腰也經常不舒服。
C經常想，不知道有多少程序員過著像這樣的生活，不好不壞，無力改變，也沒有理由去改變。
好在他性格溫和，人緣很好，經常會有朋友介紹一些私活給他，除了掙點錢，對生活也是一種填充。
C一個挺鐵的哥們跳槽到一家傳統行業的公司，公司需要開設電子商務的業務，就找到了C幫忙搭個系統，費用也不低，C欣然承應。
客戶公司不大，對互聯網有一定了解，由市場部門和C溝通接洽。 他們并沒有太明確的想法，希望和現行跑的大部分網店差不多就行。C就用開源系統搭個一個，按照客戶的要求建了分類，錄入了一些測試數據。
客戶總是不知道自己要的是什么，但是知道什么是自己要的。
有了可視的DEMO，客戶也就有了想法。他們提出要根據自己的業務特色增加預訂貨物和預定管理的流程。
而此時C還沒有和客戶簽訂正式的合同，只明確了開發費用的總數，也沒有具體寫明任務清單。因為有朋友在這，這家公司做傳統行業也有不少年，信譽上問題不大。所以C也比較放心。先花了一兩周改造了開源程序的流程。
客戶提出界面的風格和品牌形象不太匹配。C找了一堆開源皮膚，讓客戶挑一個。客戶挑了幾個分別換上試試。兩周又過去了。
客戶提出商品的縮略圖尺寸不夠大，圖像質量不夠好。C修改了GD庫和圖片壓縮的參數。
客戶又提出縮略圖列表頁 圖片有橫版有豎版不夠整齊。C只好又修改了縮略圖截取的程序。
此時已經過去了6周，C開始催促朋友，先把預付結了吧。朋友甚至有點驚訝：“還沒把預付給你嗎？我趕緊幫你催催。”
客戶持續像擠牙膏一樣地擠出需求。加個水印啦，添加一種排序關系啦，改下分頁啦。 預付還是沒有到位，補簽合同顯然也不太現實，朋友每周都在表示抱歉，表示一定幫忙落實費用，總是有些財務上的預算上的付款期上的理由。
C已經意識到自己已經掉進了一個大坑：項目時間持續流失，客戶意見時常反復，需求零敲碎打但都不復雜，總體來看也并沒有脫離當初定好的項目框架：利用現成的開源代碼搭建一個客戶需要的網店系統。可是到現在為止所耗費的工程時間和工作量已經足夠自己重寫一套了。
爆發的臨界點終于到了。客戶看了競爭對手的網店，發現了很多新功能，所用的開源系統是同一個，只不過使用了最新的3.0版本。 客戶要求也對自己的系統進行升級。
- C性格再好也忍不住了：“我以前專門提醒過：已經對系統進行了那么多的定制化改造，如果升級，所有定制化需求都得全部重新改一遍。使用開源系統如果要升級就不能做太多改造，如果要定制化就得放棄升級！
- 客戶：“當初也是你建議我們使用開源系統的.”
- C：“你們又想控制成本，又想節省時間，又不知道自己要什么，需求又總是反復，開源系統是最好的選擇了。“
- 客戶：“但是你看，現在很多我們需要的功能沒有，這個問題總得解決吧……”
- C：“如果這個功能是需要的，在項目開發初期不提出？”
- 客戶：“競爭對手有，我們沒有，這個就是必需的。”
C十分氣憤，客戶也很不滿，C的朋友夾在中間也非常尷尬。 費用一分錢還沒拿到，而項目已經過去了2個半月了。
C對朋友忿忿地說：“唉，這事沒法接著干了，我也不讓你難做，費用結不下來就算了，以前就當白干了，就當我給你幫忙。”
朋友：“別別別，你這么說我太過意不去了，我再去和他們部門說說，他們啥都不懂，就是一堆草包。我當初給你介紹是好意，總不能到頭來還讓你吃虧。”
不知道朋友的協調起了作用，還是由于C撒手不干的強硬態度，客戶支付了總報酬的50% 。
C看著拿到手里的錢，算算已經用掉的時間，攤到每個月的報酬甚至都沒到4位數。
雖然C的態度開始強硬起來，但是對項目本身并沒有任何改善。 項目還在像擠牙膏一樣繼續，棘手的問題依然存在，進度變得更加拖拉，C在看不到頭的時間線上 煩惱地進行著無盡的改造……
———-涕淚交加的分隔線———–
————————————————————————————————————————————————————————————————
故事四：大客戶的誘惑
D: 項目經理 web技術服務外包公司的創始人，創辦時間2年，開發團隊規模6~7人，業內口碑良好，主要通過朋友推薦獲得項目。
做外包項目的公司心頭總是有一塊軟傷：收入來源不夠穩定。解決方法當然是找幾家長期合作的大客戶，承接外圍項目或者維護類工程，磨合成本低，價錢公道，合作風險低，作為客戶案例拿出去多體面。
大網站、 知名品牌、 外企和政府都是作為大客戶的理想人選。
D終于遇到了這么一次好機會，某國際知名品牌的web業務部找到了他。
他心里也很清楚，大客戶一般自己的開發團隊齊備。能外包出去的一般都是一些比較棘手、擔責任、跨平臺的活，或者人手不夠，沒人愛干的獨立的外圍項目。
D和甲方的相關部門見面談了談：D的公司的資質和口碑不錯；甲方許諾只要干的好，明年我還有多少多少外包預算……，一拍兩合。
合作這事和招聘差不多，首先要解決的是信息不對稱的問題，信息渠道問題解決了，只要別太離譜，基本都能成，然后雙方各自許諾一番，都懷抱著美好的愿景開始合作，……。
D先給甲方干了一次 跨平臺的歷史數據遷移的活，不錯挺順利，算是試用期OK。
接下來是為甲方新上線的一個產品系列做一套獨立的宣傳平臺，前端 + cms + 專題。
首先需要打交道的是該產品系列的市場部門負責人，先得把產品端效果圖定下來。
對方只提供了一份沒有任何詳細說明的PPT框架圖。D只好反復碰需求，終于弄清楚了對方想做的是什么。D用專業的格式和表述性強的文字重寫了規劃，附上詳細說明，流程圖，框架圖，任務清單，甘特圖，預算清單。請對方負責人郵件確認同意。
程序和產品端開始并行開發了。
產品端部門的遭遇：
首頁的UI demo稿發過去，第二天就收到了甲方的反饋郵件，從配色到間距到配圖到文案，密密麻麻全是修改意見。
設計師隔天送上了修改好的首頁。很快收到甲方的反饋郵件，依然密密麻麻全是修改意見，比如配圖不恰當啦，LOGO的擺放位置不對啦，文案需要改字啦。
設計師隔天再次送上修改好的首頁。很快收到甲方的反饋郵件，仍然還是修改意見，包括配圖需要再更換，文案還是有文字變動啦。
只有等首頁完全敲定了，設計師才敢開始第二批次頁面的設計。
此后大概每批次頁面設計會經過至少3輪的修改，大品牌嘛，總有無數的規范和細節要求，文案和配圖斟酌了再斟酌。產品1是放在產品2的前面還是后面，產品3是被產品2擋住1/2還是1/3。
……
demo終于定稿。對方終于滿意了。設計稿提交到品牌市場部總監那里。
一個不幸的消息傳來~~ 大BOSS認為布局不夠好，要求把三欄改為兩欄。
D只能在自己辦公室里拍著桌子大罵：“靠，原來你TM不是拍板的呀，那天天在那瞎使喚啥呢。”
———————————————
程序部門的遭遇：
程序部分的代碼已經完成了，D交給甲方的IT部門，以便合并到對方的整個web系統中。
之前D和甲方的IT部門的接觸并不多，他們沒提出過什么問題，也沒什么意見，就溝通過關于語言版本、數據結構要求等。等到系統一合并，各種各樣的問題立刻冒了出來。用戶通行證沒法處理做、檢索索引格式不規范、ID位數不統一 等等。
一個突然冒出來的管數據統計的大哥也發來一堆問題郵件：要求預埋log代碼，要求增加統計相關的字段，log格式不規范……
距離約定項目上線剩下的時間不多了，D這時才剛剛被告知了許多應該在項目開始前就應該知會的事。
D在電話里憤怒地向甲方質疑這些問題。
但是看起來沒有人該為此而負責任：
- 市場部門說：“我不是給了你IT部門的聯系方式嗎？你們是搞技術的，你們更應該知道溝通什么”
- IT部門說：“我們不是太清楚你們具體的開發需求什么，不然有些事情會提前提醒你們注意。”
- 數據統計說：“我們一直備有統計方面需求的規范文檔，你應該提前聯系我們。”
D又在自己辦公室里拍著桌子大罵：“我怎么知道數據統計屬于IT部門還是屬于市場部門！！我怎么知道你們的垃圾編制！！ ”
……
冤歸冤，活還是都得干完。D只好緊急組織了加班。
————————-
最冤的事其實還沒到來。
產品整合、系統整合都沒問題了。東西終于就可以上線了。市場人員已經在測試發布內容了。這時D接到了來自甲方的SA部門（網管）電話，說“安全性上有嚴重問題！！不解決這些問題，系統是絕對不會允許上線的。”
D收到郵件一看，都是些莫名其妙的安全問題。比如CMS系統的登錄安全：有很多種解決方案，比如http驗證，比如內網限制IP，但對方提出來的顯然是最麻煩的一種解決方案。
還有一些安全性措施，從工期和實現根本是不現實的。更有一些完全是不必要的。
D和SA溝通后，對方根本不肯進行任何讓步。
D只好和甲方的市場，IT部門進行溝通，聲明上線的阻礙。他們顯然也沒什么辦法，只能說盡量斡旋，讓D盡量配合。
D嘗試改了一些，提出了一些中間方案，都無法得到SA的認同。D很快意識到，自己實際上已經卷入了部門斗爭，正在成為犧牲品……
SA還是不肯讓步，上線眼看就要延誤了，甲方的市場部門也在施加壓力，要求提高配合度。
“MLGB，配合個毛，根本就是強人所難！根本就是在找茬！你們之間的鬼事憑什么要我們承擔代價，憑什么要我們負責任，我們之前配合度不夠高嗎？你們大公司整天講流程，要求流程，這就是你們按流程辦出來的垃圾事？”
D一邊在辦公室里破口大罵，一邊寫了一份語氣強硬的聲明郵件，抄送給甲方所有相關負責人，逐條指出了SA郵件中的漏洞和問題，聲明合作無法繼續，不要尾款，退出項目，同時交付所有開發完畢的源碼。
“去你的大公司，去你的外包預算，去你的明年的合作”
很快甲方發來了致歉的郵件。
SA也發來了可以妥協，什么事都好商量的解決方案。
而D，把它們都直接送進了垃圾郵件箱……
?
總結
以上是生活随笔為你收集整理的php外包如何逃离垃圾客户案例(转)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 这3个快速开发平台，前后端都有，强推
- 下一篇： 北京 php 外包,=== | php外