在新创事业让同事投资一项新技术，也是很昂贵的。所以要学的话，大家一定也都全都要会，否则就会一直很贵。

这是 documentation 可以带来的价值。

5. 要有测试环境和政策

从昂贵的教训里面我学到的就是一定要有测试环境和 policy。在 Rails 中将环境切分成好几份，并没有超困难。而且一定要有测试环境（staging），是因为每个人开发的环境不一样，在当下焦点在自己电脑前，很多设计并不会考虑那么多。丢上远程服务器你才会知道炸掉一大片，或者是性能极度不好。这都是会伤害商业信用或者搞砸交易的（比如说你跟客户谈好明天on档一支几十万的广告，但明天因为人为疏失倒站一天，请问你要去挪谁的队列给他，一天到晚发生这样的事。谁要跟你做生意？）。

至于政策就更重要了。

很多加班的状况其实都是不必要发生的。比如说在头脑不清醒的时候写了烂 code commit 上去。导致自己清醒时要去清理这摊烂泥。在吃饭前或下班前部署了最新版的 code，结果中午倒站数小时；原本可以准时下班，十点都走不了。

但写了好东西不直接 commit master 和不马上部署，会让 RD 非常痒。这种病连我都不能倖免。

但是商业网站是不能一天到晚失火的，团队还是有人要去捍卫这种大局。所以最后也只好执行了这样的规范：

1、写功能一律上 feature branch

2、上线前必须使用开发服务器， apply feature branch 测过一轮

3、绝对不在中午 11 点 - 12:00 部署，绝对不在 17:00 后部署。

4、部署流程必须使用工具自动化，出事要能回转。

5、执行了这样的规定之后，几乎就没有人需要饿着肚子修 bug，半夜因为软件的问题跳起来加班修理了。

因为我深信：长期处在失火/救火的环境下，会快速减低一个团队的战力。

热血的投入通常会让人有假象，我投入的工时越高，成果会越好。事实上这是一个彻底的伪命题。而创业初期的不稳定，忙碌，失火，更让你会有只要我努力加班，一切就改善的错觉。肾上腺素最多只能让你撑三个月，接下来一切都会破灭的。作一个网站要到可以出场，大家比得是命长，而不是 Startup weekend 冠军。

6. PM 的话听听当参考就好，但要好好沟通