路，还是要一步一步走

很少有时间和兴趣写博客，特别是认识到自己的不足之后，时间基本花在看书上。但是，今天的经历不得不让我提起兴趣写一下博客……

首先是一场面试，做一个技术面试，candidate一开口一句，我是做架构的，崇拜之情油然而生。随口问了问除了MVC模式之外其他的分层模式，回答不知。看简历上写了“了解TCP/IP原理”，随口问了下，亦不知。又看了熟悉Oracle管理，问了下问题，回答的勉强……其实从其他方面看，该candidate还是不错的……还是推荐给HR做下一轮，当然，应该不是架构师层面的……

然后，好友约吃饭，开始听故事，某婚宴相关网站招聘了一个“技术总监”，年龄目测而立之年左右，从表面看年轻有为。但是，他的管理却让我这个自评价不太有兴趣研究管理的人哑然失笑。

以下是此君所做的流程

1.首先，关于开发，每个新需求或者更改都必须建立一个branch(后面变成每人每天只创建一个branch)，然后更改完后提交，测试、然后合并代码，再测试，上线前再测试。可以想象一下许多开发人员同时开发多个模块的情景……

2.规定开发流程，所有的开发、改动、修正，需要审批。审批基本通过邮件。

3.使用“禅道”这个项目管理软件，来进行项目的进度管理，并规定各个task完成的时间，每日晨会追问进度。

4.其他项目管理无关的事情，比如混编，是一些见仁见智的问题，不多说了。

私下以为，该总监犯了以下错误：

1.branch的建立策略，永远只为发布建branch，《持续交付，发布可靠软件的系统方法》中的这句话，客观说来，还是科学的。不必要的branch，一般只会造成管理混乱和效率低下。过多的测试就说明了这一点。

2.所有的流程需要审批，是属于传统的“重载”流程，而“禅道”管理和每日晨会，是属于scrum的（http://www.oschina.net/p/zentaopms/）“轻载”型 的敏捷开发。前者好比集装箱，后者好比小轿车甚至摩托车，用摩托车去拉动集装箱，或者说，用小型车发动机发动航母，其效率和效果可想而知。

3.“禅道”我没用过，不好妄加评论，但是在这个故事中，除了meeting外（不知道是不是 stand meeting），我没听到sprint、plan meeting、point等对应的词。项目中似乎没用scrum，而且从第二条来看，也不像用了敏捷开发，使用敏捷开发方式和工具来管理“重载”流程，窃以为不太适合。

4.如果用“重载”管理，那对应的文档、流程、培训机制什么的，也要预订好（题外话，估计是已经有了）。

其实此君的所作所为的确导致了人心涣散，效率低下。

毕竟我是局外人，除了凭个人经验做点评论以外，也不好提出什么建议去指手画脚。应该也有人会认为我的观点不一定准确，亦或许该总监方法需要磨合期。但是，个人认为，管理的作用应该给投资人和老板带来最大的效益，而效益的来源正是团队的效率，团队的效率来自于合适的方法。即是收获大于成本，不管投入多大，在烧完钱之前，带来更多的、客观的利益。但是，方法流程的采用，要有理有据，经验和书本上的不一定全对，但是科学的结合实际情况还是有必要的。

其实以上两个故事，也说明了，Title对应的是对应的责任，而不仅仅是对应的工资，我承认这个社会有点浮躁，我们要在MainLand China生存，与哪些二代们比拼，的确需要一定的浮躁，毕竟我们的起点不及别人，但浮躁带来虽然应该是快速跑，只是跑的同时，一步一个脚印还是要夯实。回头想想，或许我去面试，我也会表现的很差，或许我的管理，也会让别人觉得可笑。

记录于此，以为勉励。