我記得三年前去一家軟體公司應聘的時候，面試我的是乙個做市場方面的領導，當時他問了我乙個問題：「你認為技術是最重要的嗎，業務一點都不重要嗎？」聽他這麼問，我當時就說不是，業務也很重要，技術要依託於業務才能產生價值。
來到現在幹的這家公司後，前些天又聽到我公司的技術總監說：其實單純做技術是走不遠的，技術要和業務融合。我說：是。
有些公司號稱技術推動，但是在產品的研發，創新投入力度不夠，對市場不做調研，閉門造車，對市場反應冷淡，開發出來的東西競爭力不夠，不能盈利。
其實我認為不管是技術推動，還是市場部門打先鋒，最終目的都是為了公司可以贏利，技術本身再好，不能滿足客戶的需求有個鳥用。需求變了，如果不能依託有利的技術迅速響應，在這個瞬息萬變的社會，肯定會落後於競爭對手，因為競爭對手不會告訴你，哥們兒，你的系統落後了，你的系統太慢了，你的系統改更新換代了，商場如戰場，競爭對手之間大多時候是兵不血刃就一命嗚呼了。
我認為技術推動是要在技術研發上投入很多人力物力的，不是開個會，定個調子就這樣完了，否則搞遲早玩完。你要和競爭對手在技術上競爭，你是否敢於創新是很重要的，因循守舊，抱殘守缺遲早會被對手淘汰掉，本來一開始有很好的競爭優勢，到後來，技術落後於人，再加上對市場反應的冷淡，想趕上的時候都望塵莫及了。
最近翻看了讀大學時的教材「軟體工程」，裡面講到，現代的敏捷開發過程有很多思想是從傳統的瀑布軟體過程中借鑑的，有些專案需要採用瀑布型的開發管理方式，2者的爭論無休止，非要搞個你死我活也沒太多意思，適者生存，不適者被淘汰。我就想了，是不是採用了敏捷的開發過程，是不是真的就可以對客戶的需求做出非常快速的反應？權且這認為，如果真是這樣，很多問題就解決了，但是事實情況是：所謂的快速是有限度的，而且是對需求的變化也是有約束的，不可能天馬行空，隨心所欲。
業務 技術和架構
這兩天準備要接手天津商行的專案。但是在接手的過程中，對整個專案的理解卻是非常的困難。最大的問題，就是對業務的不理解。天津商行的這個專案不大，核心的業務就是日結，及其圍繞在日結之周圍的一些相關業務。其實也並不是特別的複雜，但是轉來轉去，開賬閉賬，憑證科目什麼的，的確對乙個財務的門外漢是異常的頭痛。雖然...
求解IT與業務融合之道
在當前激烈的商業競爭環境中，企業正不斷進行變革，以適應市場和使用者的需求。作為業務重要支撐元素的it，正面臨著越來越大的挑戰。如何充分利用已有的it資源並持續優化資源配置，實現it和業務目標統一，持續推動業務發展，創造商業價值，已經成為眾多企業資訊部門主管 cio甚至更高層管理人員關注的焦點。4月2...
CS與BS技術的融合 業務系統開發的趨勢
對於業務系統的開發而言,特別是大型的業務系統開發,利用cs架構開發,無論是使用者體驗還是開發速度上都有著很大的優勢,但部署 應用範圍及頻寬都存在著很大的侷限，雖然cs三層架構的引入，多多少好解決了一些問題，也還是存在著一些問題，特別是在介面美觀上，cs理論上在ui上可以做得很好，但在這方面，bs程式...