描繪遠景，設定目標：產品的遠景是什麼？計畫需要做什麼實現這個遠景？明確各個階段的產品目標，為什麼設定這樣的目標？
市場調研，競品分析：通過針對性的市場調研和充分的競品分析，測算產品市場前景和風險成本。
收集需求，排優先順序：收集各業務市場部門反饋的需求意見，做典型使用者的深度訪談，組相開發設計運營人員頭腦風暴，明確產品核心功能和開發需求優先順序。
組建團隊，定負責人：依據產品定位和投入資源，組建合適的虛擬開發小組，指定專案負責人，團隊相互熟悉各個崗位人員。
成果：《競品分析報告》、《產品立項說明書》、《產品brd文件》
工作概述：基於產品定位和運營策略，與產品各需求方進行深度的需求溝通，將抽象繁雜的需求整理分析成可落地執行的方案，召開需求評審，排定各功能點的開發優先順序，規劃產品各個版本迭代的功能計畫表，設計產品原型，撰寫產品需求說明書，與設計開發團隊溝通確定各階段的完成時間節點，明確產品實際上線時間，與市場運營團隊溝通上線運營計畫方案等。
需求分析，原型設計：與市場業務運營同事深度溝通，形成初步的需求大綱，功能列表，組織團隊全員頭腦風暴，分析需求的真偽及緊迫性，確定需求開發優先順序，制定產品功能迭代計畫表，設計產品原型初稿及頁面結構圖；
需求評審，確定方案：由產品經理牽頭召開需求評審會議，向開發團隊詳細講解產品邏輯流程和互動細節，評估技術實現的可行性。對不明確的需求做二次需求更新；
需求文件，開發周期：依據需求評審結果，修改設計最終版原型及互動，標註原型及撰寫產品需求說明書，管理後台資料相關資料統計等需求，技術根據需求文件反饋每個階段的完成時間節點。
成果：《產品prd文件》、《產品互動原型稿》（低/高保真）、《產品開發進度計畫表》
工作概述：基於原型互動稿及產品prd文件設計產品頁面效果圖，與產品溝通確定詳細的互動細節及效果。與需求業務方確定完善效果圖設計最終版，依據開發需求進行效果圖細節標註，設計產品icon及應用市場審核宣傳材料，配合市場運營部門設計產品運營活動頁面等。
素材收集，確定風格：在深度熟悉產品整體業務流程和商業需求的基礎上，確定頁面主輔色，制定互動方式，操作與跳轉流程、結構、布局、資訊和其他元素；
介面設計，規範輸出：設計產品頁面、圖示、icon，**及一些介面互動的表現。與前端開發溝通，明確切圖命名及標註規範，輸出最終設計稿。
ue測試，整體覆盤：產品測試階段包含ue測試，負責測試頁面的還原度及互動的易用性，針對設計稿和需求文件提出測試反饋優化意見。產品上線發布後，全面覆盤本次設計架構和細節，總結設計經驗和優化迭代建議，並撰寫相關的分析優化報告。
成果：《psd原始檔》、《切圖原始檔》、《互動描述及標註細節規範說明》
工作概述：分為使用者端、服務端兩類開發。其中使用者端開發，主流有ios和android，依據需求文件和設計稿，實現前端頁面的互動效果，與服務端確定資料交換介面協議。服務端開發依據需求文件，設計資料庫表結構，評估核心複雜功能的實現方案，撰寫開發設計概要文件及反饋重要功能的完成時間節點。
成果：《開發設計概要》、《介面協議文件》、《自測通過的產品1.0版》
工作概述：參考產品需求文件和開發設計概要，撰寫產品測試用例，召開用例講解會，對產品全方位的進行測試，將測試不通過的內容反饋給開發，判定bug嚴重程度和跟進修復進度，評估產品上線發布的可行性，協助產品和業務人員撰寫產品驗收報告。
測試型別：功能性測試、容錯性測試、效能效率測試、易用性測試、相容性測試、壓力測試等
成果：《測試用例》、《測試bug反饋記錄表》、《測試驗收報告》
專案完成之後，需要發專案參與的所有人員組織起來，總結專案過程中的問題，避免以後再次發生，個人覺得這點很重要。
1、基準庫的封裝不能馬虎，包括各種基類，utils等，前期可能做不到完美，隨著專案的開發過程中逐漸優化，有時間應該提交到jcenter上面，採用遠端依賴的方式可以加快編譯速度，並且能減少專案的冗餘度。
3、第乙個版本不用考慮那麼長遠，做什麼元件化之類的東西，但是相應的功能模組需要分開，儘量減少耦合度，為後面專案增大做元件化開發減少壓力。
5、時間允許最好寫點單元測試，如果前期沒寫單元測試，一旦專案大了，後面你會更不想寫了。
6、不要放太多的library**到專案中，導致最後乙個專案有很多個moudle，導致編譯時間很長，勁量提取你需要的功能放到基準庫中，減少moudle的數量，如果整個moudle的功能基本都需要，可以考慮打包成aar的方式依賴，減少編譯時間，專案的依賴邏輯一定要清晰，不能混亂。
7、寫完專案之後，回過頭來欣賞下自己的專案，你會發現，可能有很多地方都有更好的方式實現，大部分看第三方庫的**比看自己寫的**多，多看自己寫的**，才能發現自己的問題所在，這點是提公升自我的乙個方法，個人覺得比較重要。
開發規範流程
第一步 專案 系統開發，確定專案邊界和業務，當然是通過需求文件來確定，有明確 標準最好 實際生產是逐步明確，那要有個框架體系，在框架中逐步明確。使用寫書來模擬，就是先確定這本書的涵蓋範圍 傳授知識點 寫出對應目錄 然後對應目錄填充內容。這就是框架，內容最容易變化。使用什麼表達方式 推薦是 成本低 傳...
app開發流程
接著是大功能模組 編寫以及大概的介面模組編寫。在介面模組編寫之前，開發者可以在模擬器做大的功能開發。但事實上，對於inotes開發來說，模擬器是不夠用，simulator的多觸點 multi touch 支援是非常弱的，很多touch的測試是無法在simulator做的。特別值得注意的是，在功能開發...
軟體流程 開發流程規範
1 prd 介面文件 資料庫文件等按sprint分開整理並同步到confluence 2 前後端分離開發模式下，後端設計介面開發文件，同步到confluence，同時提供mock介面 3 後端功能初步拆分後，由各開發自主評估工期，再由專案leader評審 前端開發人員根據原型圖評估工期 測試人員根據...