Oracle神諭

對軟件設計和改進的過程中，將自己當作用戶，對自己的軟件認真仔細的走一走。

我們是作為研發的成員，我們的目標在于生產軟件。但是更為關鍵是軟件研發出來后如何使用？如何使用問題又歸結到軟件如何進行設計？設計決定研發成果（功能體），而研發成果又促成了軟件如何進行使用。但是反向的邏輯就是要在設計的過程中，充分考慮使用者的感受和習慣。在設計時，要這樣想？如果你再用這個系統進行運作，你會怎么樣？感覺是"哦！酷斃了"還是"shit！一堆...."。
 　　當然作為我們研發出來的后的實施團隊就更加重要，因為軟件體是固化的（交付后一階段的研發成果），但是使用的方法和思路要給使用者提供，如果沒有一定的思考，就很難讓用戶滿意。
　　其實，根本上是兩個方面。一是，如果你使用，如何進行設計；二設計出來后，如何進行實施？

事找人，不是人找事。--- ---
關鍵是如何形成待辦事項？
(1)將需要做的事情一一列出，并按照事情緊急及重要程度排列；
(2)有些事情不是短時間內（一天半天）就能完成的，最好能跨越周期安排相應的事項，形成日程安排（計劃調度），必要時按照甘特圖的形式進行輔助。

第一大惡人!

（1）客戶的需求是非常關鍵的，哪怕我們就把原來的需求羅列出來。這個也是非常重要的，然后是相應的解決方法，如果是已經開發出來的，將產品演示出來。如果沒有就實際說明是需要進行開發的。給客戶的需求一定要留一章來講PPT；
（2）客戶的需求和我們目前的產品的差異度，主要還是將前提的調研結果與我們的產品的吻合度、差異度（將來開發的重點）；但是這個東西也比較敏感，如果感覺差異較大，可能影響客戶的選擇。中間可能自己清晰，操作過程模糊處理。
（3）重視需求調研階段。一定要將此階段作為重點，在整個研發周期中要有一定的比例，另外實施周期也是非常關鍵的。
（4）產品的業務流程的演示是非常關鍵的。一定要保證業務流程的演示正常、講原有的功能比較好的功能點展示出來。
（5）Portal的方面的重視。我們分離出對外或協作單位的Portal。用戶在目前的情況下，一般是比較拒絕客戶直接在企業系統中使用的。Portal的使用，可以為客戶提供一個專門的門戶來進行使用。
（6）在前期的項目接單過程中，也要強調團隊協作，需要一個總體的協作或者售前的Team Leader。特別是對應大的客戶。
（7）細節決定成敗。

      客戶需要的是運營經驗+管理系統的支持。一般很少有公司說，我們運營模式很不錯，但是IT有些差，我來給你完善的需求你來給我們實現。更多的是要你的系統能給運營本身帶來什么東西？能夠給管理帶來什么提升？ ...提升...
     IT的投入帶來運營的提升，帶來公司價值的提升，這才是關鍵。你來指導，而不完全是定制。強勢未必是件壞事情。
     強調研發是對的，但是更多的是你已經實現了什么？你的產品功能如何？如何來提升價值？運營咨詢+IT技術支持+ 產品研發

軟件研發和項目運營是兩件事情。項目運營中會出現很多系統在測試階段沒有出現的問題，這個時候要非常謹慎。
開放式的項目方式的操作方式是最復雜的，因為代碼沒有凍結的時刻，隨著運營的過程，系統要不斷的進行調整、測試、上線。

... ...