需要什麼樣的流程，愚以為要看公司規模，系統特性，人員組成來決定，大象不會跳舞。
打快攻有快攻的流程（搶市佔），禁區防守有防守的流程（鞏固現有勢力），看產業模式
而定，沒有一定標準做法。
原PO看起來想用「方便、快速做事」的流程，但想問怎麼找到適合這樣流程的夢幻人選。
無論後面爭論的內部管理與流程，但一開始如何面試合適的人，都是個值得思考。
最近剛好我也在煩惱這個招募問題，我想會用上機考的方式，給一個lab, 裡面只有一個
簡單的function，但是有bug，我會請面試者找出裡面的bug並修復。
實際上bug不只有一個，最粗淺的就是編譯失敗的語法問題，括號不對稱或是變數存取範
圍不一致這類，這個解不了，我就送他到門口鞠躬說聲謝謝請等待通知。
編譯失敗的問題解決了，如果面試人立即回報說這題完成了，那我就會知道他不是一個細
心的人，只看見眼前的問題，而沒有看到後面跟著的其他問題。
我應該會至少準備四種bug在裡面：
1. Runtime error：8元素的陣列，存取指標應該0-7，但迴圈卻用了1-8，或是迴圈條件
< 故意寫成 <= 來產生此錯誤。
2. 極值檢查錯誤，例如除法，我分母塞入0他有沒有想到這種可能，先檢查出來？
3. 邏輯錯誤：程式本身運行正常不會有error, 但是輸出的結果都是錯的，他找不找得出
原因？
4. 錯誤處理：在一定會有錯誤發生的地方他有沒有想到並處理掉？例如連資料庫或是api
但是面試的辦公室根本不可能連到。
後面這四個都會事前準備好單元測試，面試人交件後自動一跑，看幾個綠燈，就可以大概
知道這面試人的細心程度....
關於原PO的問題，這應該是我會嘗試的方法。
※ 引述《Masakiad (Masaki)》之銘言：
: 其實制度流程沒分兩種，開發團隊講好規則；約定好軟體開發的品質、驗證基準並自動
化
: 、約定時間code review的時程，正是加速品質保證及驗證軟體的速度。這個作法並沒
有
: 什麼多餘跟lock的問題，除非品質跟驗證軟體本身就是多餘。
: 另外有很多方法論來指導上述的實作原則外、也很多公司有進行也持續運轉這機制，若
你
: 還沒有嘗試就趕快試試，不用臆想跟推論這麼多。
: 閣下言談之間我的感覺是不熟這方面的運作，所以另外再建議你找一個熟這方面流程的
人
: 來協助你，這樣才可以解決問題。
: 至於怕優秀人才會因為這樣感到不被信任的問題也不用擔心，優秀人才只會因為沒有這
些
: 機制而離去，原因在於他們嚴格要求自己驗證跟品質，團隊有這些機制對他們來說已經
很
: 習慣，倒是沒有這些機制還要擔心我完美的架構混入其他沒被驗證的糞code，什麼叫委
屈
: ？這才叫委屈。
: ※ 引述《accessdenied (存取違規)》之銘言：
: : 唉唉唉，當初我不用「態度」這個字眼就是知道大家會各自解讀，到底什麼是好的態
度
: ..
: : ...
: : 所以我講白了就是「細心」和「紀律」，還舉了很多實際例子來說明這兩個元素的概
念
: ，
: : 結果有人又簡化回態度兩字，果然底下有開始亂戰了...
: : 拉回主題，前陣子忙著賺錢沒時間好好回應一些想法。有人說制度和流程可以解決，
還
: 提
: : 到權限控管，為什麼我不太認同。
: : 制度流程分兩種，一種是協同合作必要的方式，你負責的範圍是哪裡？東西做好會放
在
: 哪
: : 裡？這是讓大家做事彼此方便快速的約定，是增加效率的。這類似交通規則的訂定，
大
: 家
: : 照著做就流暢。
: : 另一種制度流程，是防弊的，稽核、放行、權限控管，是保持著一種不信任的心態在
做
: 管
: : 理。這就好像除了紅綠燈外，又另外安排了一個交通警察指揮交通（權限、審核放行
）
: ，
: : 並看管所有駕駛人。
: : 後者會產生效率瓶頸，因為每台車都要經過檢查並放行，交通就堵塞了，開發人員再
多
: 、
: : 效率再高都沒用，就是會lock。
: : 每個change都要approve的下場，就是「人皮圖章」開始產生的時候。
: : 再來，有些 team 趕專案加班到半夜怎麼辦？負責approve的人難道發呆配到半夜只
為
: 了
: : 最後幫他開權限和approve？這些都是無謂的人力損耗。
: : 而且優秀的人才，一直在不被信任的環境下做事，心委屈了，流失也只是遲早的事情
！
: : 想想看，你有10個工程師，只為了其中1個心態隨便的人員，就把剩下9個優秀的人才
一
: 起
: : 拖下水被綁手綁腳不再信任？
: : 為了那一個人，與其設計各種稽核制度防止他做錯，不如一開始九排除他，讓剩下九
個
: 人
: : 順順利利做事，這才是正解吧！？
: : 讓不對的人一開始就不要溜進來，團隊也不會被污染，好的人才更不會覺得被牽累！
: : 這才是我為什麼要跟大家請益的出發點。