用一半的时间做两倍的事

听说，这个书名引发了一些争议。老板角色的人看这本书都认为RD团队读完後就是吃了大补丸，以後做专案只需要一半的时间就好，所以都乐於引进SCRUM。（灿笑）

如果不要使用这麽耸动的书名，中庸一点的，应该是使用「事半功倍」这句成语来说明Scurm，才是比较精准的吧。

但是，不管在原本的书名中，「用一半的时间」，与成语的「事半」，还是会让人有偷鸡的想像觉得好像不用付出什麽力气，就能得到两倍的效果。但事实上，付出多少，就获得多少的等价概念，基本上还是存在於大部分的情况，鲜少有例外。

因为我的教会正在建新堂中(募款中，愿意奉献者请私讯)，我大概能理解建筑业应该是最计较时程的行业，因为他们的工作阶段非常多，不同类型的工班有不同的进场时间，可能还要顾虑现场施工环境、设计图仍可能有错误需要现场修正等等细节。而建筑合约中也可能有提早完工的奖励条款，或者时程延迟的惩罚条款等，因此一个复杂建筑工程专案有着不同的拉力与推力冥冥之中拉扯着。

但建筑类的专案，前期花费大量的沟通时间与精力与发案方进行沟通与细节确认，没有定案之前你很难有可以偷跑的工作先进行。因此这类的专案就是标准的瀑布流的专案进行方式。工作就是一环卡一环，前置作业没有完成前，下一个步骤无法进行。所以这类的工作被诟病的就是通常时程会拉很长，需求方发想开始到最後完成都是很长的期限，但是这样的优点基本上只要前一手的工作做的确实没有问题，下一手工作范围很明确，产出也很清楚。

只是，在软件业，或者新创业圈，时间就是金钱，一个概念的发想，就是要早点丢到市场上运作，才会知道是否有效，或者如何修改，因此不可能让专案人员paper work到天昏地老後才开始动工。

所以相对於建筑类的专案，软件类的专案是最有可能可以多个子专案多箭齐发同时进行，让一组序列的工作可以透过多执行绪的概念同时并发执行出去，达到真正缩等待时间的期望。

但是，写过多执行绪的人应该知道，执行绪的管理才是最头痛的事情!!!更何况，如果发出去的多执行绪彼此还需要沟通，这个管理机制的设计过程才是真正会让人想死的!!

所以想要「事半」「功倍」，我认为不是不行，而是你需要花更多的力气，做更多的事前准备工作，才能让不明就里的人觉得你只用「别人一半的时间」做出「别人好几倍的事」。

首先，你要知道什麽是「对的事情」，要先做；
再来，因为你不是自己做，所以要让大家知道如何「把事情做对」；
再来，因为不是一个人/团队做，所以要让多人/团队之间学会沟通；
再来，因为市场变化快，要不断的与需求方沟通确认「对的事情」持续是对的；
再来，团队一定会犯错，所以要给团队不断地做心理建设与良性沟通；
再来，产品上线後要面对时间与人力被新需求与线上问题给瓜分；
再来........

想敏捷，却没有决心自己要比其他人承担更多的SM或者专案管理人，也不要把敏捷的责任推给工程师了。