公司和軟體系統開發分成兩部分，一部分叫產品，另一部分叫開發
他們之間的矛盾是這樣的，開發總是認為產品，文件或者產品的定義不清楚而，產品認為開發總是找事，或者說肯定是一次性不說不清楚的，所以文件有問題是理所當然的。大家都沒有錯。所有人讓開發也參加產品的討論會。希望這樣可以解決問題，這樣能解決問題嗎？
首頁是術業有專攻，沒有認真的化時間和精力，總結和思考整個軟體或者業務流程，人多只能浪費時間。
軟體做為我們日常生活的一部分，我們是否有思考過，什麼是軟體系統？
最直觀的理解是，他是有用的，他們幫助我們做一些事情。最簡單的資訊儲存，和資訊查詢。對於更多的系統還是停留在這個層次。
對於乙個面向企業的軟體系統，那就是對於企業有用，能幫助企業完成企業業務系統。有用。企業向外提供價值，當然企業也需要其他系統的幫助，當然包括軟體系統。
簡單理解軟體系統就是乙個能幫助我們工作的乙個工具。
那我們怎麼造這個工具呢？這就是產品和開發的工作。
首先我們要找到我們工具的用武之地。這是從工具已經造好的情況下考慮。但是如果我想利用軟體賺錢，那找乙個企業的問題，從問題出發，看看造什麼軟體能幫助企業。重點搞清楚問題。
根據這個問題，找和這個問題相關的人和事。現在肯定是人通過系統完成一些工作，所以還是需要人參與，所以一定要搞清楚和問題相關的人，尤其是通過角色。事是和這個問題相關的事件。例如企業系統中使用者資訊的認證工程，會和會和後期的發薪酬和商保有很大的關係。
總之，是要了解和這個問題有關的企業業務流程。總結畫圖。從總體什麼了解和這個問題相關的人和事。
接下來，深入到每個事，分析乙個事中的人，分別都負責什麼。例如，普通的使用者提交自己的資訊，系統的管理用負責審核個人資訊，他們共同的目標是確保資訊準確。
從中找到系統能幫助什麼？也就是系統的責任。系統能做的就是儲存、計算、統計。
重點，從對業務流程的分析中，總結可能優化的點，看看能否緩解問題。如果能分清人的責任和系統的責任。
下一步就是對系統的責任，詳細的描述。開發人員開發分析設計、coding.
這不說產品互動。
產品會討論，對於乙個系統，它承載了太多。乙個產品同時又多個角色在用，這些角色的利益是衝突的，產品有可能還會影響未使用產品者的利益。產品影響銷售人員的業績，為了更好賣，產品可以這樣做。但是產品為了維護自己的形象，不能那樣做。技術認為這樣產品太難開發，應該是那樣。和系統相關的人，都是站在自己的利益處想問題。所以產品會是站在乙個中立的角度，從產品的遠景出發，平衡不能角色之間的利益，完成整個產品。
重點平衡產品相關人員的利益。
不應該作為開發人員，更多的時間和精力，應該是在技術方法研究。對於產品如果不能深入了解，只是參加會議。沒有什麼效果，浪費時間。
首先從相關的業務流程開始講，讓大家從整體上，知道我們在做什麼。搞清楚我們要解決問題，從問題出發。引導大家慢慢理解，和產品同學分析和設計產品的過程是一樣。不能一上來就是原型，不停在不同的頁面之間跳轉。
產品文件中應該由業務流程和系統責任。用原型和文字詳細描述。
原型是具體的，流程圖是抽象，都是需要的。
重點是描述清楚系統系統的責任。然後在有了這個系統之後，系統是怎樣參與到業務流程中的，也是需要先用流程圖說明。在用原型說明。
同樣的問題，用不能形式說明，更容易記住和理解。
thrift開發問題總結
作為目前最流行的rpc框架，thrift不僅提供了通訊協議，同時提供了網路框架，解脫了程式設計師的生產力。thrift也是阿帕奇hadoop系列的rpc實現工具。本文主要聚焦在實現的thrift系統中，遇到的各種問題。但是thrift在隱藏一些底層細節的同時，也給應用層帶來了一些不確定性，這些不確定...
VS C 開發問題總結
1 新建的mfc 對話方塊cstring和char 的轉換一直失敗 vs工程預設配置 在網上看了很多cstring轉char 的方法，但是轉換一直失敗，例如以下幾種方式 cstring m ipaddr 192.168.1.100 char ipaddr lpstr lpctstr m ipaddr...
H5開發問題總結
local 和session 都無法直接訪問物件，當你定義乙個 json 以後 通過setitem 和getiem 後發現無法正常使用，應為local session 都是支援字串的訪問，所以這是需要兩個步驟第一就是在存的時候吧json 轉化成字串，當取出的時候再把字串解析成json 例如 var ...