1.理論與實踐差異
問題場景:計畫和風險(進度、質量等)在實踐操作中有偏差
解決辦法:計畫先行,盡早暴露不好的風險,最小成本處理
2.研發質量提高
問題場景:功能調整影響原功能(反覆、驗證成本)
解決辦法:自測、草稿設計、草稿場景驗證
3.測試質量提高
問題場景:常規、非常規測試,功能點測試要點不足
解決辦法:多業務場景測試用例、功能點測試要點羅列
4.計畫執行偏差較大
問題場景:過於理想評估計畫,實際執行不可預期偏差較大
解決辦法:要做充分計畫,羅列計畫要點,預留足夠緩衝時間
5.集中測試對進度干擾大
問題場景:功能開發調整完畢,集中提交,測試驗證時間較長
解決辦法:區域性交付,做階段性驗收測試,確保已驗證功能穩定性
6.客戶驗收緩慢
問題場景:客戶遲遲不願驗收,是因為一些不太願意說、做的事情要做完
解決辦法:多與客戶溝通,找到客戶顧慮,解決痛點,推進下一步
7.後期測試發現重大漏洞
問題場景:發現重大漏洞,雖不是我們這邊導致的,但對整體專案影響不好
解決辦法:專案經理要多想,要替客戶多想,把控範圍、進度、質量、風險等
8.注意與客戶溝通方式
問題場景:與客戶溝通,不要用理論的形式交流,多關注客戶的痛點
解決辦法:注意把控不同角色關注點,平靜、平和、淡定,莫著急,平穩推進
注意良好溝通方式學習,平息對方顧慮和急躁,以合作共同解決為出發點
9.多做一點,可減少很多成本
問題場景:研發提交的功能總會留乙個小尾巴,測試覆蓋測試也不太嚴謹
解決辦法:在不超範圍前提下,如果只是成本(進度、質量、實現難易程度)很小,風險很小,
對功能優化、功能bug修復、功能體驗公升級,那就隨手多做一點,可以達到很好的效果
10.客戶提出的無理要求
問題場景:客戶針對模糊的需求提出可擴充套件的無理要求,甚至超需求的無理要求
解決辦法:跟客戶很好的溝通,把範圍往小了圈定,針對最根本的痛點,滿足最小的需求
不是不做,可以做,往小了做,解決目前最緊急、最根本的痛點問題,以解決問題為宗旨
11.客戶提出的需求和問題
問題場景:客戶說要對某個功能設計進行修改,客戶說要實現某某需求
解決辦法:客戶告訴你的未必是他真的想要的,需要多場景、多角度幫他分析,讓他自己深入分析,並告訴你結論這到底是不是他想要的
如果不具備快速驗證發布條件,不需要那麼快的響應速度,避免朝令夕改,很是頭痛和疲憊,幫他們深入分析,讓他們想清楚他們真正想要的是什麼
1.研發提交測試流程
問題場景:
研發修改bug完畢,未進行**發布,直接將bug狀態進行修改,測試回歸bug,未通過是因為未發布。
假設昨天測試提交的bug,昨天開發改好了,把bug狀態改為已解決,卻沒有進行發布。
今天測試登陸,看到bug已解決,進行回歸測試,驗證還是不可以。其實是沒有發布導致,浪費測試時間。
解決方法:
為提高團隊運作效率,大家有成效的工作。
研發修改完bug,在相關調整功能發布之後,再到bug管理平台修改bug狀態。
2.缺陷提交規則
問題場景:
測試測過的功能,還潛藏著嚴重的bug,或是一些不合理的邏輯操作、不合法的資料操作還是會有bug產生。
使用者使用場景測試不全,只進行符合規則的資料進行測試,卻沒有進行非法資料、非法操作進行測試,測試深度不夠。
測試使用操作不方便,不好用,跟常規的使用習慣不一致。
解決方法:
測試為確保專案質量,需要進行多瀏覽器、多邊界值、各種可能的使用者場景、不合規的操作、不合法的資料進行測試。
bug都要登記bug管理平台,嚴重bug需要研發進行解決,非嚴重bug研發酌情處理,
非嚴重bug登記,也是以防問題或是好的優化建議被遺忘(優化需要討論確定修改方案),為孵化產品做優化儲備,提高產品易用性、提高使用者體驗。
3.為什麼要組織相關評審活動
評審的目的是為了在真正投產前,進行設計把握,整合大家的意見,以確保該項檔案或是該項活動是正確的、有價值的,降低一些不可預期的成本損失。
如:需求的遺漏、設計的不合理、專案管理的不到位、質量風險等等。
4.某模組問題層出不窮
問題場景:
研發對乙個功能完好的模組進行功能調整,導致產生不必要的bug和問題,而且未經充分測試直接丟給客戶。
尤其是在推動使用者驗收,進行驗收測試的時候,更需要保持執行環境的穩定性,如果出現重要模組的重大bug很不好。
解決方法:
研發對功能進行調整,不能盲目自信,一定要自測,且覆蓋到相關的使用場景;
如果研發沒有時間測試,一定提交到測試部,讓測試人員進行充分測試,不能把未經測試的**直接發布丟給客戶使用。
5.研發工作被打擾
問題場景:
來自客戶的問題、現場同事的問題、測試同事的問題,直接找到研發這邊處理的,都會對研發的開發工作造成中斷。
研發一旦被打斷需要重新梳理思路,容易導致**不嚴謹,潛藏一些bug在裡面。
或是陷入整天忙於處理問題,而忽略主體功能開發工作;處理的小問題,而影響大功能。
解決辦法:
緊急嚴重問題,及時響應處理;非緊急嚴重問題,可參考如下建議:
(1).客戶的問題、現場的問題,及時記錄彙總,集中抽時間,向研發請教或討論;
(2).測試的問題,登記bug管理平台,集中抽時間,向研發反饋問題,溝通狀況;
(3).專案經理把關,專案經理有責任保護研發團隊的開發工作不受干擾,可以幫助協調處理、登記非必要問題;
(4).研發自我把控,告知相關人員,研發工作相對重要,請將問題記錄,在某天某時找我溝通,確認問題細節;
6.常規功能的常規驗證和提示
問題場景:
有些功能缺失常規的校驗邏輯,基本的驗證邏輯不能得到保障,不合法的資料得不到控制,影響專案的質量。
對於可以明確對應不合法操作或不合法資料的,最好可以提供明確的資訊提示,便於客戶、測試、開發自己理解。
如:表單頁面,兩個起始日期的大小校驗;上傳附件功能,檔案格式校驗、檔案合法校驗(exe程式)、檔案伺服器找不到;
表單錄入儲存,基本的郵箱、手機號碼、輸入長度、輸入型別、非法字元錄入、sql注入等等
解決辦法:
常規功能的常規驗證,可以建立問題知識庫,而不是僅僅存在每個人憑經驗的腦海裡,梳理出來。
研發每次開發常規功能時,要注意邏輯的嚴謹性,確保最基本的驗證必須通過;
測試每次測試常規功能時,必須先把基本驗證,驗證通過才可以進行業務測試或高階測試;
這個可以慢慢的彙總積累起來,可以來自個人、來自團隊、來自外部開放的資源。
7.uat測試通過而生產環境出問題
問題場景:
在uat環境下測試通過的功能,在生產環境下出現問題,除了環境搭建的差異導致問題的其他問題;
在uat環境下測試的資料過於簡單,在生產環境真實的生產資料,發現一些bug和體驗性的問題;
解決辦法:
盡可能模擬生產環境,一些初始化的資料和配置項,嘗試模擬搭建一套生產環境;
盡可能用生產環境的資料進行uat測試,不要做簡易資料的功能測試,盡早發現問題,不要推到生產環境再解決;
8.源**的版本管理
問題場景:
對於要交付的功能,已經開發完畢,測試完畢,**已經穩定,沒有進行發布部署。
繼續進行新功能開發,新功能還未開發完畢,就進行發布部署,在同一套**裡面進行修改。
解決辦法:
需要確保交付的**穩定,做好**分支管理,**版本管理,熟練使用源**管理工具tfs;
需求分析 專案日誌管理系統
使用者故事 專案日誌管理系統 第一次迭代 1,使用者登入,顯示對應使用者管理模組。2,使用者寫日誌。備註 日誌儲存方式 a 本機檔案方式儲存 b 區域網檔案儲存 c 資料庫儲存 3,使用者瀏覽自己的日誌 4,使用者更改登入密碼 5,使用者退出。第二次迭代 1,驗證使用者登入是否是管理員,顯示對應的使...
實訓專案日誌(一)
故事版 動作設計 寒假期間,我們對專案進行了初步的構想。最後將目標鎖定 製作一部三維動畫。寒假完成了劇本內容的設計,形成了劇本初稿。期間,我參與了劇本的設計修改工作。故事以母子親情為主題,講述了母親去世後兒子因思念母親給過去的家撥 後發生的一系列充滿奇幻色彩的感人故事。兒子 少年 青年 中年 老年 ...
專案管理系列一
從技術轉向管理,重點要調整好心態 可以這樣設計提公升的路線 pm 經理人 高層管理運作者 ceo 專案經理的各個方面的能力及其比例 1 溝通能力 84 2 組織能力 75 3 班子建設 72 4 領導能力 68 5 解決問題的能力 59 6 技術能力 46 其實,還有乙個很重要的能力 執行力 對於乙...