專案流程優化是乙個持續過程，每個公司，每個團隊情況不一樣，總原則是：如果在專案過程中你感覺到某一點很彆扭、很不爽、痛了，那麼這就是優化點。
優化的手段是多樣化的，如通過流程規範去約束、開發和利用工具去輔助等等，都是優化方式。
流程優化是一件需要團隊合作才能做得更好的事情，所以任何優化都需要與團隊各角色達成一致，才能夠有效地去落地。同時，優化過的流程要持續堅持去落地，作為負責人要起到督導作用，才能讓團隊持續精進。
1）規範需求 list 評審
有些團隊可能會今天提乙個需求，明天提乙個。對此，可以制定乙個每週過需求 list 的時間，統一安排過本週的需求，並對需求進行優先順序排序，開發和測試可根據本週的人力情況去安排本週的需求，避免需求亂提。
而且各個角色要有乙個明確的對接人，統一收斂到介面人，不要面向全員提需求。
2）制定需求截止時間
3）緊急需求流程
若有特殊情況，比如 cto 直拍的緊急需求，要走特殊流程，需要傳送郵件抄送產品及各技術老大，老大回覆後才確認修改或增加需求。
出需求雖然是產品的工作範圍，但乙份需求的質量一定程度上會影響整個專案的質量。
比如，跨部門的專案，由於涉及到外部系統，如果前期產品調研不夠充分，對於業務邊界了解不夠清晰，對互動系統的是否可實現性無法確定，會直接導致開發階段的問題。
所以從整個專案的角度出發，測試也需要關注需求的質量。
1）需求是否達到評審狀態
若需求前期調研不充分，產品對邊界系統了解不清楚，疑問點較多，此需求存在很多不確定性，開發/測試負責人可先將需求打回（可根據情況選擇委婉或強硬）。
2）需求的可行性
產品需要說明需求的預期收益，需要用歷史資料說話，否則投入人力去做，卻絲毫沒有收益，從資源層面來說是一種浪費。
如果開發和測試評估，需求實現難度大，沒有資料做支撐，此需求需要重新調研。
風險如何定級？
是否已經建立風險登記冊並同步給相關方？
風險問題反饋給誰統一跟進和管理？
風險 review 機制如何？
...設計階段包括開發設計及 ui 設計。這個階段比較常見的問題有：ui 設計與需求文件原型圖不一致、開發設計沒有文件等。
ui 設計圖
ui 設計圖與需求不一致，會導致開發和用例設計不能夠明確以誰為準。尤其涉及到前端頁面的需求，不一致是很大的乙個痛點。
開發設計文件
開發設計文件可以跟開發提訴求並落實到文件，尤其是與外部系統互動的文件。
測試階段可以做的事情很多，可以根據自己所在團隊的情況而定。一般是對測試過程的監控，使測試更順暢，更高效。也可以通過專案結束後的資料分析，比如 bug 佔比及趨勢、每週的線上 bug、二次上線率等來對測試流程進行優化。
如自測用例要佔總用例的 30%，開發需要執行完自測用例且通過率為 100% 後再進行提測。
有時，開發執行自測 case 可能與測試執行方式不一致，有時開發會用假資料 mock，但真正走流程可能會有問題。執行自測是為了後續的測試流程更順暢和高效，所以可以要求開發執行自測的方式是要從前端觸發，而不能後端直接 mock。
用例評審會可確定自測 case 範圍，與開發達成一致。
若自測用例執行不通過，後續怎麼打回。
郵件提測 or 口頭提測 or 平台提測，根據情況制定。
包含但不僅限於：
bug 流**比如已解決狀態只能開發去更新；已關閉由測試執行等。
bug 解決方案：尤其關注不是 bug 的情況，測試要提高 bug 的質量，與開發約定不是 bug 的範圍。
bug 分類：嚴重級別、型別根源、優先順序等可根據自己所在團隊的情況制定規範。
有些同學在測試過程中是默默執行的，比如排期三天的測試需求，到了測試階段，兩天過去了，群裡沒動靜，相關 leader 可能會對此需求的進度不了解，所以可以制定測試進度報告定期同步給相關方。
測試進度報告一般包含以下資訊：
見《如何編寫測試報告》。
漫談專案質量保障 協作流程優化
在本文之前，筆者曾分享過一篇關於質量保障流程的文章 漫談專案質量保障 協作流程 文章簡述了筆者參與的專案協作流程，同時對流程中一些不同尋常的協作節點進行闡述。由於多種原因限制，之前分享的流程存在一定的不完整性，所以本文將繼續分享 漫談專案質量保障 協作流程 優化後的版本。初版的協作流程如圖1 1所示...
IT專案流程
1 產品經理確認需求，畫rp 2 ui設計師根據rp出設計稿 並切圖 3 前端工程師根據設計稿和切好的，搭建頁面。前端工程師可以對資源提出自己的需求。4 後端工程師根據rp及功能與前端工程師確認介面，包括每個介面的相關字段，資料字典等，達成一致後，開發介面並撰寫介面文件以供前端工程師使用 5 開發任...
MYSQL SQL優化流程
常去想想以前的東西，懷舊不是用感傷的，是溫故知新，加油！1 盡量將複雜的sql拆成幾個簡單的查詢 2 盡量使用表連線，減少使用過 in not in 3 儘量減少子查詢的使用或者將其合併出來 4 盡量將 in not in exists not exists變為 join 語句，減少 合併子查詢 1...