項目有風險
今天下午15點，團隊成員D向他的主管Z反饋他測試的項目有風險：項目在測試周期內，但在用例評審時發現有一處功能邏輯有爭議，需要產品經理跟業務方確認，可能出現的情況有：
1 不變更需求，功能邏輯按現有實現處理；
2 需求變更，功能邏輯對應地進行改動，會產生新的開發工作量和測試工作量。
目前進展是已經提醒產品經理跟業務方確認，但催了兩次依然沒有最終結論。
主管Z意識到D的反饋略晚，但依然提醒該同學應該將現有的影響、可能出現的風險盡早同步給相關方（產品經理、研發同學、相關測試同學以及他們的主管）。
為了確保信息傳達一致，最好的形式是在聊天軟件里將事情描述清楚，然后 @對應的人。于是D把Z拉進了該項目的溝通群。
進入溝通群后，Z翻看了群成員和該項目的聊天記錄，很快發現了幾個現象：
群成員：這個群里有該項目的產品經理、研發人員和測試人員，但除Z之外，沒有產品經理和研發人員的主管在群里。
事項跟進：D同學昨天和今天上午均提醒產品經理要跟業務方確認，產品經理回應已經在跟進，但遲遲沒有確定下來，并計劃明天上午再進行溝通。
風險周知：D在群內更多強調了當前是測試階段，需求確定不下來是不合理的、有風險的，但并沒有提及風險點究竟是什么，是只影響當前項目上線延遲，還是影響多個需求上線延遲。
如上，Z認為有如下問題：
群成員：一線同學在日常項目溝通時傾向于只拉具體對接的同事進群，覺得沒有必要拉主管。
不拉主管，優點是自己做得不足的地方，主管看不到，心理壓力小；缺點是自己做得好的地方，主管也看不到，而且主管不知道做得不好的地方是什么，他都不知道應該如何輔導你。
所以，Z認為不拉主管進群的缺點更明顯。
且這個項目已經出現了風險，理應將這些風險同步給各方主管，所以群里沒有主管是非常不可取的。
事項推進：推動他人跟進的事項，建議定一個deadline，否則，只要當事人說在跟進中，其他人就只好等著，等多久完全憑個人感覺。
定deadline的好處是給彼此一個時限、一個契機，解決了更好，沒有解決可能就需要問題上升了，因為超出時限未解決，通常不是需要再給更多的時間，而是問題超出了當事人的能力范圍，需要引入更大的力量了。
風險周知：如果項目沒有提測，作為QA，可以提醒大家有風險；但項目已經在測試周期了，這個階段QA是主導角色，應該對時間更加敏感，對項目的風險更加警覺。
應該非常醒目地把明確的風險和影響進行周知，比如該項目如果需求變更，需要新增多少開發工作量和測試工作量，進而對后續項目的影響是什么，等等。
當前項目的風險如何應對
基于上述的問題，Z進行了如下動作：
把產品經理和研發人員的主管拉入群內；
針對當前的情況，請研發同學和測試同學分別輸出了確定性的風險和影響；
@了產品經理和研發人員的主管，請他們特別關注該問題。@具體的產品同學：什么時間能給出結論，以便確定該項目的后續事項，進而降低項目風險。
3分鐘后，產品經理的主管群內回復：我們討論一下回復。
兩個小時后，產品經理給出了結論，具體不贅述，大體結論是需要進行產品變更，產品經理的主管隨即回復：給大家添麻煩了，這次改動產品側按流程進行需求變更，請技術同學評估改動影響和風險。
接著，研發同學和測試同學分別給出了工作量評估、項目上線時間和對后續需求的影響和對策。
此時，Z單獨跟D同學聊天：看，這就是同步主管后的響應速度和態度。D同學反饋：解決好快！！！后面遇到此類問題，我知道該怎么做了。
以后項目的風險如何規避
該項目上線后，應該盡快組織一次三方復盤，收集各方在本次項目中的痛點和癢點，并討論出解決方案，避免后續項目出現此類問題。
思考：何時是理想的風險反饋時間點？
在上述案例中，當前項目出現風險時，在什么時間點反饋，更為理想呢？
我認為，剛發現風險時就應該反饋風險，在本案例中是需求評審時，那么在需求評審結束后，可以對當前情況進行說明，識別可能產生的風險，并周知到相關方及其主管。
其次，需求提測時，如果風險還在，也需要再特殊說明一次。
因為提測后就進入了測試周期，這個階段是上線前最后一個階段，此時出現風險極大概率會導致項目上線延期，進行相關方周知一是報備風險，
二是給到協同方一定的壓力，促使協同方盡快把需求確定下來。
行動吧，在路上總比一直觀望的要好，未來的你肯定會感謝現在拼搏的自己！如果想學習提升找不到資料，沒人答疑解惑時，請及時加入群： 1007119548，里面有各種測試開發資料和技術可以一起交流哦。
最后：?下方這份完整的軟件測試視頻教程已經整理上傳完成，需要的朋友們可以自行領取?【保證100%免費】
軟件測試面試文檔
我們學習必然是為了找到高薪的工作，下面這些面試題是來自阿里、騰訊、字節等一線互聯網大廠最新的面試資料，并且有字節大佬給出了權威的解答，刷完這一套面試資料相信大家都能找到滿意的工作。
)
