專案流程優化

2022-06-15 14:24:12 字數 2123 閱讀 5812

專案流程優化是乙個持續過程,每個公司,每個團隊情況不一樣,總原則是:如果在專案過程中你感覺到某一點很彆扭、很不爽、痛了,那麼這就是優化點。

優化的手段是多樣化的,如通過流程規範去約束、開發和利用工具去輔助等等,都是優化方式。

流程優化是一件需要團隊合作才能做得更好的事情,所以任何優化都需要與團隊各角色達成一致,才能夠有效地去落地。同時,優化過的流程要持續堅持去落地,作為負責人要起到督導作用,才能讓團隊持續精進。

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...