这一场旷日持久的Hand Over

八 10

首先，这件事情与我无关，只是有些困扰。

这是一个规模不大的项目，现在是在维护阶段。前维护的人小A已经离职了，离职前花了不到一下午把项目移交给小B和小C维护，由于小C有其他项目，所以小B一直是一个人在维护（其实小B也有其他项目），但是最终，这个项目是要交给小C的。现在小B马上又要走了，理所当然，就要移交给小C。这次，却花了4天。

可能是小A走得太急，只给小B半天时间来熟悉项目，但是从小A走到现在小B把项目维护得有条不紊。

现在小C来接手了，其实很简单，因为小A走的时候移交他也在，这次的移交理应只需要知道之后小B又改了啥东西就可以了。可以这次，却花了4天。

那这4天，小B和小C都干了些什么呢？

首先小C还在忙着他自己的项目，小B在小C的Leader的要求下，给只需要一个人维护的项目建立一个自动的Daily Build。小B之前没有配置过Daily Build工具，于是自己在那里查资料，建环境，写测试脚本，就这样2天过去了。

我觉得Handover时候并不需要帮以后的人把以后的环境都建好吧，特别是现在没有的环境，以后这个项目怎么操作是你们以后的事情，Handover应该是使以后的人明白这个项目里面的业务逻辑，编码规范，技术框架，接口定义方式等这些和项目有关的东西。

而且只有一个人维护的项目需要一个自动的Daily Build吗？我高兴的话，一天Build他个200次？够不？

接着，小C又让小B把现在所有的issue都处理掉再给他，可以，很合理，但是你是不是也要同时了解一下这些issue是什么呢？

又花了1天，小B处理好了所有issue，小C来了，耷拉着脑袋，很不情愿得搬着椅子在小B边上坐下，开始Handover的最后步骤，介绍项目。

我承认，小C确实很细心，用软件录了一下午小B的操作和讲解，就是不知道以后有没有时间看。

我的困扰是：有些事其实可以做得很简单，但是有的人就是喜欢弄得很复杂，这是不是和自己的前途紧紧相连的呢？每天讲流程流程，有的流程是不是必要的呢？在当我们把时间都花在流程上的时候谁来干活呢？质量如何保证呢？成本如何降低呢？

四有新人