在專案型組織下，這個問題就沒有討論的必要了。要是職能型組織，連協調員都沒有，部門/階段之間如何控制？
這段時間，某產品線總是出現質量問題。幾乎每次的事故原因回溯分析都會歸結於開發人員的test和code review做得不好，不是介面問題，就是分支問題，要不就是想當然。似乎，這一切都在意料之中。自從上月底，研發的過程執行力度明顯衰減。每次私下與開發人員交流，他們總抱怨進度太緊，沒有時間做這些……其實，對於我們這樣的內部產品研發來說，沒有時間往往只是藉口，常常是自己不願意做或覺得不重要。
基於這樣的背景，我與研發的經理一起，討論出乙個落實研發測試和code review的方案。也就是，在編碼完成後，進行**凍結，以便於記錄單元測試的過程。這樣，sqa就可以對ut基線與st基線之間的**差異進行審計，並對ut報告和code review報告進行核查。於是，我提出了sqa有權依據過程執**況拒絕產品提交到測試部門進行測試，也就是說，正常流程下，研發的設計評審、測試和code review做得不充分，就不能提交系統測試。這個方案在今天的sepgleader會議上被否決了。領導認為，sqa應該定位在服務職能上，不應該有控制專案的權利。
晚上回來，我一直在思考這個問題。直到想到了國家審計署的職能，似乎才有了一些醒示。審計只有監督權，沒有控制權，輸出也只有報告和建議。簡要的說，sqa要做的就是審計、報告、建議，再審計、報告、建議……
可是，sqa常常在審計中迷失。如何才能突破審計的範疇，在更大的空間提公升「增值」的機會呢？這是我們下一步要突破的堅冰。
金融風控專案
一 問題定義 金融的核心是風險控制。自然而然地，ai的主戰場也變成了如何使用ai技術精準的做風險控制。在風控領域，有乙個很重要的問題是 如何通過使用者的資訊來判斷使用者的逾期與否？我們通過收集使用者的基本資訊 地域資訊 社交資訊等來判斷乙個人的逾期概率。資料如下 二 roc與auc 特徵工程 第一 ...
音控燈專案 專案分析
廣場舞太煩，社會矛盾激烈，也沒啥好的治理辦法，仔細想了想，解決問題的辦法還是要從問題本身入手，燈光作為廣場舞必備的三大件之一，可以拿來做做文章 燈光 大媽，只要湊齊這三大件，那必然有一大波人 音控燈的想法就這樣產生，聲音大了我就滅燈，聲音低於標準我就亮燈，我們兩不耽誤，廣場舞團隊也相互監督，不能由於...
測試如何把控專案
測試階段主要分為三個階段，測試前，測試中和測試後。1.測試前 1 測試前要先確定測試方案，比如有些場景的如何模擬，有些條件如何觸發，可以跟開發溝通下 2 資料準備，提前準備賬號或資料等。以及是否需要開發乙個測試小工具輔助測試等。3 再有可以評估下有哪些部分可以提前介入測試，能提前的盡量提前，為後面的...