銷售為了拿訂單，給客戶承諾這也能做，那也可以做。真正到了專案落地才知道，哪有那麼簡單，各種需求就來了，尤其是做工業方面的，要求必須高可用，影響生產還得賠錢。工業方面軟體，資料量巨大，歷史原因暴多，改變極其困難，談起來感覺很簡單，做起來，簡單的增刪改都會極其困難！

之前做ZF網站，對方很喜歡紅色，老是覺得這不夠紅那不夠紅。就是那種鮮紅，不是暗紅也不是淺紅，調到#FF0000他還嫌不夠紅。

怎麼解釋是他電腦顯示器的問題，甚至用不同顯示器去接他的主機，他都不認同，不認同也就罷了，還卡著這個問題，不讓工程繼續……

最後還是老闆有辦法，就這個問題，找他上級來視察一下工作，就指著這個介面“做的還不錯嘛“，然後就通過了。

IT行業最大的問題就是大部分時間都是外行指導內行，對工作量沒有個明確的評估。需求是無止境的，但是現有的團隊單位時間能完成的工作量是一定的。

我做產品的時候，經常和需求部門說一句話“只要錢到位，玻璃全乾碎！”對於開發而言，只要有足夠的資金、人手和時間，任何需求都可以完成（大不了僱傭數學家，使用最先進的架構，找獵頭挖行業頂尖的架構師）。

如何平衡需求和工作量呢？透過內部核算的方式應該最適合，讓業務人員負擔開發部門的人員投入成本，這樣他們就會權衡一些功能的必要性。有些時候開發的成本已經在一定程度上超出了銷售價格，那麼還要高層出面考慮付出的部分是否會為將來帶來更好的積澱。如果會為公司的品牌價值或者產品線的市場競爭力帶來提升，那麼企業就投入這部分的成本。

如今的市場競爭，真的也沒辦法給軟體公司更多的迴旋空間。畢竟很多時候，你不答應，有些二貨出來瞎答應。也不管最後能不能做到，先把專案拿下來再說，很多專案外包都做成了一錘子買賣。因為抄底價格開發方沒利潤就開始糊弄，選抄底價格的金主多又是什麼也不懂，交付成果的時候總感覺自己的需求應該100%實現，拿到的東西就是被騙了（很多時候，需求也是模糊不明確的，甚至需求都不能真正解決痛點，弄得專案顛三倒四的反覆修改）。有經驗的產品負責人，多半對能完成80%以上的專案就基本可以可以接受了。

所以作為 開發人員，說明白自己為一些無理的需求需要付出多少工作量就夠了。不過個別的時間也是自己的能力和資源做不到。在一個網際網路專案我做開發的時候，我們公司的產品和需求部門不想購買OCR（sdk和本地化部署都捨不得掏錢），想讓我們開發部門自己做。作為專案部門負責人，我開始自己研究python的tesseract-ocr，基本實現了docker部署完成單執行緒的服務。但需求部門說用不了，他們要在短時間內處理大量的文件（上千份jpg，rar壓縮包上傳到OSS，自動解壓，然後在1分鐘內處理所有的OCR取樣，然後資料入庫）。結果悲劇就此開始了，OSS本身解壓就很慢、併發去排程若干個OCR執行緒（計劃/任務/狀態）、一異常處理（很多圖片人眼都識別不了、業務部門說沒法規範要圖片）、大量併發的資料寫操作（佇列優先順序）、OCR的日誌系統的加入（獨立後臺，log的定期清理，先壓縮，再週期性儲存）。最開始本以為i很簡單的東西，卻將整個專案組的開發進度拖慢了2個月。後來高層還批評了我們開發部門耽誤了整過專案的進展。

說這個就是為了說明，有能力去做，看了起來很簡單的需求也別輕易就開始動手。一定要深度評估。

我開發過程中遇到最無聊的需求是想把一個系統開發成一個超級變形金剛。可以隨時進行二次開發，定製業務流、業務流要穿出各個企業、最重要的一定要是一般的文員就能快速的上手做業務的定製（零程式碼，無需強邏輯，所有資料流和資料自動生成 ）。我記得那次我和需求部門說,"你們還是等等人工智慧再發展個百十年吧。"

根據不同領導，頁面顏色樣式根據個人喜好改變，顯示欄位也可以隨意設定，而且匯出Excel檔案的格式也是個人喜好來定。