2004-04-26 10:27:33萬年碰釘男

這個規劃書根本是個屁!

***********************************************************************
  這篇文章的圖很有趣, 諷刺軟體專案發展的實況, 可能需要一點實務經驗的人看了才會笑得噴飯, 這張圖被pchome縮小過了, 要看原圖可複製以下網址:
http://vb.infoserv.com.tw/bullet/1649809.jpg
(轉貼自小雄研究中心)
************************************************************************

2004年4月26日星期一 天氣陰涼

  在蘇州待了一個多月,終於在4/20日返回台灣。因為某些因素,老婆並沒有跟我一起回來,仍打算繼續多留一個月。返回台灣以來最重要的事情,就是處理手上的工作F公司的進銷存管理及業績計算系統。
  F公司的這套進銷存系統的開發,著實已經成為我的一個夢魘。
  原本去年九月接下的這個案子,預計最晚年底就該結案,如今竟然拖到四月底都還無法終結,會不會持續拖到五月呢?我真是沒把握…。超過半年還搞不定,是一定要回頭檢討箇中原因的。我認為『溝通不良』是一大關鍵,客戶與專案經理的溝通情況怎樣我是不知道,但現在回過頭省視當時的契約書和專案規劃,過於草率,尤其專案規劃有寫跟沒寫一樣,根本是個屁!到頭來,現在追加的許多煩人的設計,根本就是原本專案規劃書所沒有明列的項目。
  再加上F公司本身的作業流程就有問題,辦公作業並無正規化,很多流程是依照過去的習慣。要軟體系統去適應她們沒有規章的作業方式,實在是一件讓人沮喪的事情。而她們雜亂無章的作業方式,再透過專案經理轉述給我,有時也不是那麼一回事,常常害我白走冤枉路去try她們真正想要的東西。
  從今年一、二月,我就一直有結案的錯覺,然後大夢初醒的打擊。
  每當我以為終於完成了,將工作結果上傳到網路上,想想總算可以放下身心的重擔,隔天往往從客戶那邊傳來與期望不合的消息。
  「啥?原來你們要的功能不是這樣喔?」
  好,再教育、再溝通吧。
  此外,朝令夕改也是癥結之一。最令我頭痛且修改再三的就是業績計算這回事了:
  原本只是單純的說,F公司的業務員將商品銷出,依售價與成本價的百本比,來給予較高的業績獎金或是較低的業績獎金,如果售價低於成本,則無業績獎金,每個月初結算前一月的薪資時總計。
  Ok,聽來簡單,我很快的就搞定了。
  什麼?因為F公司的客戶大多是批發商,分批大量進貨都是累積到月底結帳,所以業務員就算以較高的售價賣出,也必須等到月底確定收齊款項才發獎金,如果該業務員錢收不齊(就算收了部分),該月份的獎金就不發放。
  靠!怎麼之前不講清楚,好吧,傷點腦筋多寫個檢驗收款的程序吧,這下沒話說了吧。
  啥咪?如果業務員拖了太久才把款項收齊(超過三個月),也是不發獎金的,這是業務員讓客戶拖款過久的懲戒。而且如果業務員超收款項,為了獎勵,超收溢付的部分以較高的業績獎金發放。因為客戶會溢付款項通常是用來預先抵付下個月的貨款,所以這些超收所得的業績獎金還要從下個月業務員的業績獎金中扣除。
  臉色鐵青的我,到此已經覺得事態不妙,因為這勢必要更動之前的基礎設計和演算法,之前做的等於是白工。
  當然會演變成讓人頭疼的原因,還牽涉到她們銷貨作業的單據亂無章法,資料比對困難,之前我只需要將銷貨金額加總,計算獎金即可,現在為了『超過三個月就不給獎金』的限制,我必須一張張銷貨單去比對日期是否為三個月內,這樣系統速度肯定比較緩慢,必須重新設計更好的演算法…。
  那幾天,我簡直打開電腦看到F公司的案子就有噁心想吐的感覺。
  後來我就帶著NB逃到蘇州去,避免被電話疲勞轟炸。換個環境,在蘇州美麗的山水田園風光下工作,真正落實行動生活主義的哲學:工作不忘休閒與玩樂。
  當然,還有一個重要的目的就是嘗試軟體外包和跨兩岸合作的模式是否可以配合,畢竟我之後的計畫是打算做偏向SA(System Analysis)的部分,Coding的工作就外包給大陸,運用當地廉價的技術人員(日後我會在其他文章中詳談此次大陸行的感想)。
  在蘇州的這段期間,我偷偷把MSN上專案經理C小姐的帳號封鎖,讓她找不到我,偶爾才現身一下。
  總算將業績計算依照客戶的要求完成了,交件時透過網路上的視訊會議(網路真是太方便了,利用視訊會談和檔案傳送交件的方式,實現了跨兩岸軟體合作的契機),專案C小姐又說出了驚人之語:
  「不對,你這個計算結果不正確。超過三個月收齊的帳款不發獎金沒錯,但不是全部都不發。例如,A客戶總共欠了十萬塊的帳款,如果對方是分批償還,在三個月內先付了七萬塊,剩下三萬塊超過三個月才付清,那七萬塊還是有獎金的,只有最後的三萬塊沒有獎金,你現在這個等於十萬塊的全部獎金都泡湯了…。」
  「妳當初不是這樣講的…。」我痛苦地埋怨。
  「不,我當初就是這個意思,是你自己沒搞清楚、弄明白。」
  馬的,口說無憑。再下去只會翻臉,演變成口水戰。
  「好…好…好,我知道了,我馬上修改就是了…。」
  「多久可以好,拖了半年了,客戶已經在抱怨了。」
  @!%#$^&@#…,會拖這麼久,我一點都不覺得是我的問題(其實也許有一點吧,不過人比較不易察覺自己的缺點)。
  「盡快就是了。」取消對談,我隨即把專案經理C小姐再度納入MSN的封鎖名單內。
  (嘻,嘻,嘻。盡快,你盡快去死好了。)
  C小姐提出來的修改,似乎不大。但對於程式設計人員來說,這是極為複雜且艱苦的工作,同樣又幾乎要推翻之前的設計與架構。
  原本我的演算法為了執行效率的考量,決定在計算業績時,只針對本月有付款的客戶來回溯他前三個月積欠的帳款明細做查驗,我以為超過三個月前的帳款反正已經沒有獎金了,沒有查驗是否收齊的必要。
  現在變成,假如一個客戶積欠帳款兩、三年才付清,但是她在兩、三年前,有一筆三個月內支付的款項,我在做業績獎金計算的時候,必須要能追蹤到這筆兩、三年前的資料納入計算。簡而言之,程式變成必須清查該客戶『所有』的交易與付款紀錄,勢必這套系統使用的時間越久,資料量越多,查驗越費時,系統會越用越慢…。
  是的,我又必須重新設計新的演算法則…。
  這個問題讓我頭痛了好久,終於在我回台灣的第一個晚上完成。第二天早上,C小姐電話裡傳來清晰爽朗的聲音:
  「跟你說啊,對方手下的業務員反應並力爭,認為即使客戶沒付清所有款項,超過三個月後,反正三個月內收到的部分款項,無論最後客戶拖多久才付清的,都一定有業績獎金,不如只要超過三個月就先把這些獎金發了吧,不用等到客戶的錢收齊才發。對方也覺得這樣做帳方便,不無不妥,所以…。」
  沒力了…,我苦笑著,感覺事情不可能再出乎意料中的糟了。
  終於,在我寫這篇文章前,C小姐沒有再給我更進一步的指示,而她上述最後的遺願,我也完成了,伴隨著無法抑止的苦笑完成的。接下來是一、兩個月的上線測試期,錢要入袋為安的日子似乎還有段路要走、要等待…。
  因為我並沒有親自會晤此次專案的客戶廠商,所以很多本來可以遏止情況如此惡化的機會無法出手。例如一些做法和規定實在不合理,我認為一定會出問題要再修改的,卻無法當面與對方商量溝通,只能抱著納悶和狐疑照著對方的意思做了。而且所做若超出原本規劃書的範圍,我也可以據理力爭或是提出議價空間。
  偏偏我們的專案經理說穿了只是搶生意的業務員,不經思索就給了滿嘴承諾:  「這個功能沒問題,交給我您放心好了。」
  交給妳?最後是交到我身上吧。
  最後這個業績計算的功能,我不確定是客戶廠商一開始就沒交代清楚,還是C小姐轉述給我的時候丟三落四。如果是前者,案子都進行到快結束了,C小姐為了拿到尾款只好不得已扛下,那我必須說,C小姐沒有善盡專案經理的職責,並且保障我們底下這些人的權益。
  若是後者…,那這C小姐真是…@!@#%$#$^#!
  其實當初接案子的文件如果有『詳盡明確』的規劃書,而不是簡單的一行「本系統須有自動計算業務員業績之功能」鳥不拉雞的屁話,整件事情就簡單且輕易多了。
  那個系統規劃書根本是個屁!現在想到還是很氣…!
  所以,這再次是一個接案族的教訓,為了搶案子而不多思考、滿嘴承諾,文件不好好備妥簽約,就算搶到案子也是飲鳩止渴的行徑。因為一個拖拖拉拉、搖擺不定的案子,極可能延誤你日後接到其他好案子的機會,甚至造成你很大的身心壓力。
  最後我要說一句話:
  那個爛系統規劃書根本是個屁!屁!屁!屁!屁!屁!屁!屁!屁!屁!屁!屁!屁…………。