從技術開發做到管理團隊、帶專案，我清楚在面對產品報出來的問題時研發人員與管理人員所考慮的問題重點有時是不同的尤其 臨近產品重要節點的時刻，研發人員更注重對問題的分析、定位和提供解決方案，而專案管理人員則著眼於專案全域性考慮，如修改是否會引入新問題、是否會導致版本發布延遲、問題是否值得修改等。這種差異也是正常的，因為研發和專案管理人員站在的層面不同、對問題思考的角度也不同，但是這種不同的消除我認為最終一定會歸結到一點：對產品帶來的價值和損失。
產品在開發階段報出來的問題，按照正常的問題管理流程進行分析、修改、上庫和驗證，這是沒有問題的，因為一般我們還有足夠的時間去發驗證方案和發現新問題。但是如果在產品的重要節點，甚至是在快要上市的時候突然報出來一些問題，我們該如何處理呢？當然，對這些問題的分析還是必須要做的，但是是否需一定要解決，我的經驗是從如下幾方面考慮：
問題復現的場景使用者是否會經常遇到
內部beta使用者的輿情分析（如果場景使用者會經常遇到，那麼輿情必然高）
與產品對應的競品表現如何（一般要比競品表現好，做參考）
關鍵干係人的要求，如產品經理要求等
如果這問題符合這幾條，尤其是前兩條，我認為該問題一定是要在產品的重要節點前或上市前要解決的（我想內部beta使用者的輿情對產品和公司的影響一定要比實際使用者報出來後要小的多），但是對於問題的解決方案我認為一定要考慮如下幾個方面：
問題的根因分析是否清晰
解決方案的風險是否考慮全面
測試用例設計是否全面
解決方案的風險是否經過實際驗證而排除
如果是概率性問題是否經過壓測
也只有乙個解決方案經過了如上幾個方面的評估，這個解決方案才能最終上庫。還有另外一種常見的情況：三方問題。一般來說，三方問題當然需要由三方來解決，但是三方解決的話一般會面臨如下兩個問題：
三方是否願意解決
三方的解決時間能夠跟得上產品的上市時間
對於這種問題我認為我們的工作至少要做到如下幾個方面：
指定直接負責人與三方進行直接的溝通，推動三方對問題的處理
內部要提供乙個備選方案，並且該備選方案至少要能夠通過上述五條的評估
我想也只要內部做了這些充分準備工作之後，在面對三方無法解決問題，或解決問題週期太長時，我們才能做到有條不紊。
AND一些經驗
目錄 一 參考 1 程式設計師2020工作規範范文 總結 good 適合多看，程式設計師每天 每月做的事情總結了 一 目的 1 在公司來了很久了，有時候一些經驗想把記錄下來，專案 做人 等等 一 專案 1 板卡 pci2012a分為支援和不支援音效卡的 一 做人 1 不要過度依賴別人 1 有問題立馬...
debug的一些經驗
1.儘量減少debug，少用debug，優秀的程式設計師總是花80 的時間來思考如何解決問題，20 的時間來動手完成 而糟糕的程式設計師總是用20 的時間去寫 80 的時間去除錯 動手之前盡量想好如何去做，並且已經為你自己的思路做了充分的實驗。2.盡可能的提高debug的效率，設定合適的斷點，使用快...
重構的一些經驗
當我們已經對設計模式倒背如流時，卻往往發現在實際 編寫中有生搬硬套的感覺。設計模式是前人經驗的總結，直接拿來用合不合適呢？這讓我想起了大學一位老師告訴我們的一條學習的道路 知識,理論,智慧型 設計模式是很一種優雅的 智慧型 但對於我們初學者來說還僅僅是留存於文字的 知識 把 知識 融合到自己的開發中...