需要什么样的流程，愚以为要看公司规模，系统特性，人员组成来决定，大象不会跳舞。
打快攻有快攻的流程（抢市占），禁区防守有防守的流程（巩固现有势力），看产业模式
而定，没有一定标准做法。
原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个优秀的人才
一
: 起
: : 拖下水被绑手绑脚不再信任？
: : 为了那一个人，与其设计各种稽核制度防止他做错，不如一开始九排除他，让剩下九
个
: 人
: : 顺顺利利做事，这才是正解吧！？
: : 让不对的人一开始就不要溜进来，团队也不会被污染，好的人才更不会觉得被牵累！
: : 这才是我为什么要跟大家请益的出发点。