軟體開發過程中我經常會遇到這樣的問題“軟體某個功能實現上，業務人員說一套，軟體人員說一套”。這裡就透漏出業務和軟體這個既矛盾又依賴的一對小冤家。 業務人員與軟體人員的所說的想法，貌似矛盾，實則一致：業務代替不了軟體，軟體也代替不了業務。業務人員代替不了軟體人員，軟體人員也代替不了業務人員。業務軟體中的業務和軟體的關係，我覺的可以這樣形容：業務就是軟體的靈魂，軟體就業務的肉體，是相互依存一個統一體。業務（行業）軟體需要業務人員和軟體人員密切配合才有可能實現，這個過程裡業務人員負責將軟體要實現的功能要逐一細化，並分類匯總；軟體的人員則是再次拆解這些業務需求（所以軟體開發人員也要對業務應該有較徹底的理解），從軟體實現角度來把業務分類匯總。軟體的介面則可以由業務人員和軟體人員共同討論來確定。在軟體開發初期，需求評審階段。應該有軟體的人和業務的人員共同參加。 與會人員中業務人員要有一定軟體開發知識，軟體開發人員則一定要有必要的業務知識。需要注意的時需求評審過程中，業務人員一定要給軟體開發人員講清業務的來龍去脈，否則軟體開發人員做出來的軟體很可能就不是業務人員所想要的東西。其實軟體產品的需求評審過程一個相互學習的過程，軟體的人學到了一些必要的業務知識；業務的也學到了必要的軟體開發知識。只有這樣才有可能把業務軟體做到業務功能齊全，軟體效能優越。業務（行業）軟體項目中不應存在業務人員越俎代庖，直接給軟體人員規定怎麼實現，這麼做應該堅決杜絕。業務人員考慮問題，出發點畢竟是業務需求，而不會在意軟體的設計原則更不可能徹底理解軟體的整個軟體設計思路（複用、已擴充）。如果聽業務人員這裡加一個欄位哪裡加一欄位，很快軟體代碼就會陷入混亂。代碼混亂的後果就是項目越做代碼越亂，維護成本越高。項目做的最後要不夭折，要不入不敷出。當然公司針對這個情況也有解決方案就是“讓軟體開發人員免費加班”，這樣做的確可以一時奏效。但試想如果你是一個程式員，又碰上這種事情，你會整天加班加點改別人留下的一對亂碼而沒有任何想法嗎？ 參加需求評審、概要及詳細軟體設計評審的人員應該是：業務人員、進階軟體開發人員和架構師以及其他項目干係人。其他開發人員後續可由進階開發人員和業務人員來講解 業務需求，這樣業務人員又可以進一步瞭解到軟體需求是否正確理解了業務）所以業務軟體開發過程中要看清業務和軟體以及業務人員和軟體開發人員的關係。只有弄清這些關係，業務軟體的開發項目才有可能步入正軌。
未完待續
