前提：專案週期很緊，原型到設計的時間很少，急忙趕出設計粗稿
問題：是否花時間召開測試，前端移動端，產品，客戶等其他人員（人事，前臺，財務等）進行內部稽核？？？
現實：實際生產中存在這些問題，產品設計不合理，有很多問題，有想法的程式設計師對其進行了優化，沒想法的程式設計師按照設計圖來，結果導致了兩種不同風格的頁面，有些測試根據實際使用者體驗高的一方進行統一，有些測試只是按照實際的設計圖是什麼樣子的，他就是什麼樣子的，這是一個讓我很頭疼的問題，我是一個測試，是一個不安分的測試，我呢以我的使用者體驗為準，最終選擇了使用者體驗高的一方，現在的問題是這是在產品做出來之後才做的修改，修改時間和成本都提高了，也造成了程式設計師，測試和產品之間的不團結，不統一，都有想法。有想法其實是好事，集眾人的智慧做出來的產品我想肯定是更優於由某個人單獨完成更好，一個好的產品需要一個團隊一起協作，一起思考，一起改善去完成它。針對這樣的問題，我們能怎麼做呢？
建議：相信大家也經常開會，各種評審會，但是很多時候都只是匆匆了事，達不到我們開會的目的，為了開會而開會。首先我們開會主要是為了明確目標，確認方向，減少不必要的爭吵。但是很多時候，開會的時候大家都很安靜，有想法也不想講，不敢講，針對這個問題，我覺得這是一個適應的過程，可以先從強迫性的要求開始，讓大家都發動自己的腦袋去為這個專案提建議，提想法，即使亂說胡說也沒關係，先讓我們有這種開會勇於提意見想法的氛圍。經過一段時間的磨合，我相信這個會議會越來越有趣，在一個充滿議論聲的評審會中，這是我期望看到的，當然還需要一個決策者。在這些都有的情況下，我覺得應該適當多給評審會一些時間，讓每個人都能發表一些自己的意見，評審結束之後，把我們改動的地方進行記錄，改動的效果做成設計圖，併發送給決策者進行稽核，通過之後正式提交開發，進行生產，到這一步開始，整個專案組就要以設計圖需求文件為主了，任何與設計圖和需求文件不符的地方都是bug，需要進行修正，即使你的想法很好，但也需要需求確定才能進行修改。
方案：評審之後進行領導稽核，評審時間建議延長，真正達到評審的實際作用。