1樓：阿歡
首先沒有bug是不可能的，其次使用者是需求推動的，如果你的初期產品可以解決使用者的某個痛點，就算bug一堆也不會沒有使用者，反而會在上線後被使用者和資料推動，確定下一步的迭代方向，這時候的方向是真實由市場反饋的，所以可信度還比較高。當前如果在開始推出產品時一點都不能用也是不行的，還是要有取捨，知道使用者最關心的功能點是哪個，著重把使用者關注的功能做好，其他細枝末節確實可以再一步步優化的
2樓：彩虹金剛
不存在完美的質量
測試人員的思想往往會被帶入常識性的誤區。比如：作為專業的測試人員不應該有bug；只要是質量問題就是測試的鍋。
其實這些都是不對的，只有沒被發現的bug，沒有0bug；所以我們不需要追求100%的質量，這個是不存在的。天塌下來還有「高個子」頂著，專案出了質量問題，第一責任人首先應該是最高負責人。
所以有bug或者有缺陷的專案是可以接受或者上線的，但前提一定是這些已知/未知缺陷是在當前可接受範圍內。比如：線上大促，肯定不能是效能有問題；參加大賽，肯定不能是流程中斷問題。
如果說測試也遵循著2/8原則，花20%的精力就能發現80%的bug，那麼我肯定不會把剩下的80%的精力再去發現剩下的20%的問題。首先產出比不高，更重要的是它存在很大的風險。所以剩下的80%的精力一定是思考如何更好的保證正常功能的穩定性，思考各種極端環境可能出現的問題及其對應的預備方案。
而剩下的20%的問題則屬於長尾問題，需要長期不斷的優化和打磨，可能即使你「畢其一生」也發現不完！
3樓：莫小漠
快速迭代。
1、不可能有0BUG的產品，也不可能有0BGU的程式設計師。
2、有時候專案是需要卡時間點的，錯過了某些時間點，哪怕你的產品再完美，也沒有人關注了。
4樓：
速度與質量是兩個一直對立的，追求速度就會降低質量，追求質量就會提高成本和工期。所以沒有絕對的速度和覺絕對的質量，永遠是兩者之間的乙個平衡。
借乙個網圖說明一下：
產品怎麼快速迭代呢？
啊哈時刻產品經理 產品要快速迭代，一般就採用敏捷專案管理。Scrum是迭代式增量軟體開發過程，通常用於敏捷軟體開發。Scrum是乙個包括了一系列的實踐和預定義角色的過程骨架 是一種流程 計畫 模式，用於有效率地開發軟體 在每一次衝刺 乙個15到30 天週期，長度由開發團隊決定 開發團隊建立可用的 可...
使用者研究如何跟上產品的快速迭代？
UIDX 你弄反了。是產品迭代跟著用研跑，不是用研跟著迭代跑。乙個大用研可以規劃出至少2年內的產品路線圖。使用者研究不是研究 使用者現在喜歡什麼 而是研究 使用者是誰，他們什麼樣，他們會喜歡什麼 這樣我們才能決定 產品要做成什麼樣，向哪個方向迭代 說白了，使用者研究是決定目標的，行動是跟著目標走的。...
技術是出於什麼心理，要求產品經理在專案上線以後請他們吃飯？
suknight1985 工資之外獲取額外利益是所有人都希望的，只是隨之而來的風險會影響做這個決定而已。同樣的反過來看，讓人做事情即使是分內的事情，給不給點小甜頭，這個也是有說頭的。反正在我專業領域，沒人敢說這樣的話，你不幹我換個人指導下接著能夠幹，就看大家要不要撕破臉了，事情做好了，作為共同經歷過...