從某軟體引發的深思總結

一、技術因素

做慣了胖端的人，是很難習慣做三層的。但不重要，反正客戶、實施要的是應用，是真三層假三層都無所謂了。

所以胖端做慣了的人，在瀏覽器這種強制瘦端模式下就容易折了，因為思路一直沒變，仍然把瀏覽器寫的胖胖的。

沒想到啊沒想到，網路效能、瀏覽器安全色性這兩個因素。效能、穩定性都堪憂。

而且，過去定製開發人員只需要掌握一門開發語言一門SQL就搞定，門檻低，招聘人培訓人速度快/複製快/出苗多。現在需要掌握前端，這就一系列JS、DOM\BOM、HTML、CSS、XML、XMLHTTP、JSON、WebService。還得遭受瀏覽器不相容性、弱網路連接、無狀態串連、網路效能、IE緩衝/後退前進按鈕/IE右鍵菜單、父子視窗控制、事件觸發。這讓長期搞區域網路搞原生胖胖端的人情何以堪？新增這麼多技術門檻要求，招聘難/招聘成本高/培訓成本高/成長慢/跟不上業務發展節奏，怎能不讓定製開發部門/實施部門/服務部門/營運支援人員部門火大？

二、功能代碼因素

平台有架構如地基，但上面亂蓋樓那就必然倒。所以還需要應用功能代碼架構/架構約束。但棋差了一招，太多的心思放在做平台變形金剛上去了，全搞模型驅動拖拖拽拽去了，業務、資料庫、功能代碼架構的時間被擠了。忘了一個根本：不管你是跳高還是伏地挺身，客戶和一線看到的就是一套軟體，是要去處理客戶商務程序的。

沒有功能代碼架構約束，再好的功能設計資料庫設計也是白費，因為不遵守。即使你有最佳代碼模板有編程規範，但100多個開發人員，你能管住他們的每一行代碼？可以這麼實現也可以那麼實現，先把功能實現了，反正你看到的是一個功能，內部是怎麼一團麻，你也沒細審查。

就是這樣，定製開發越來越難，越來越難穩定下來。神馬平台架構地基都不管用。其實功能代碼架構，比地基通用平台更重要。

所以，業務設計、資料庫設計、平台、功能代碼架構，一個也不能少啊。沒有各方面的得力領軍人，乘早先別動手。

另外還有個路徑節奏問題。從原型、到2個試驗、到產品1.0、到2個試驗、到產品2.0、到推廣，這條路有這麼長。別想一口吃個胖子。

三、配套因素
一套企業軟體，需要長鏈條的配套才能真正良好交付。但你如果培訓成長成本高門檻要求高時間長，這就懸了。軟體初版功能不全不細不要緊，定製開發的設計/開發/測試能否跟上、諮詢和售前能否跟上，專案管理能否跟上、部署實施初始化能否跟上、培訓能否跟上、持續應用提升能否跟上，話務中心能否跟上，營運支援人員能否跟上？

四、上下產品重疊因素

上下兩個現金牛明星產品，多年曆練，從業務功能到Team Dev到營銷策略到渠道到實施到營運支援，全成熟，全配合流暢。突然出了一個這樣一個高不高低不低的，怎麼營銷定位？怎麼銷售定位？本來營銷銷售都愛新東西，都存著很高的新期待，但被現實的實施、培訓、營運、定製開發所驚怕，不敢推陳出新了，還是現金牛可靠，兩其重擇其輕。

最後一句話：中國製造不強，別妄想做中國生產製造管理。

                       做好集團管控，因為中國人喜歡大而不強靠人堆。

                       老老實實做好軟體，讓軟體擅長解決的歸軟體去解決，該管理顧問經營顧問擅長解決的讓他們去解決。別想直奔著解決客戶現實業務去。軟體商無法承受之重，把自己清醒定位好。

謹以這篇文章給自己以後的職業生涯多多提醒、常來自己讀讀、冷靜再冷靜。看別人，想自己。