|
JB是硅谷经年的VP Engineering （工程副总），带领经历过几间大大小小的新创公司成功出场，经验丰富，成果丰硕，不要看他这样大忙人样，他每天傍晚到十点固定把时间留给家人，是个工作与家庭并重的家伙，“这样才能长久啊～”他说。
几次晃过他公司楼下，他都因为开会没有办法溜出来喝杯啤酒，今天好不容以逮着他，我们就坐在旧金山Soma区，2nd与Howard St.附近的Eddies酒馆小酌。
最近怎样，他问。
“忙啊，跟以前一样，开发产品兼救火，新创公司不都这样？”
怎么感觉你们那边一直在救火，紧急事件很常发生吗？他皱了皱眉头。
“是吧，因为产品开发赶快，交货在即，有时候就会有紧急事件，这时候就要去修。”
看你的表情，好像团队很享受这个过程是吗？他笑笑。
“恩，只要最后有平安解决事件，那种炙烈的讨论与 group hacking 很刺激，团队的士气高涨，合作无间，让大家感情很好！”我把手张开，奋力解释。
了解，那应该也有一两个很强的工程师出尽风头吧？老板也是其中之一？
“是啊，那种解出来后，被当作英雄的感觉很爽（笑），不过最强的还是我老板，他深知整体系统的运作，出将入相，每次都能够及时找出问题点，对症下药！”
这种英雄式的团队看起来很风光，但是其实很容易累死三军。你们用的 Scrum 架构是借镜于二次世界大战后最优秀的管理理论发展出来的东西，怎么听起来你们只学到皮跟骨，一点都没有用到精髓？
“噎？我觉得我们执行得还不错啊”这次换我皱眉头了。
这样啊？那你们每次产品都可以赶上交货日期吗？
“应该算有，每次交货日前团队要冲刺熬夜一下，但是大概都有赶上。”
真的吗？一开始应该还好，但是渐渐慢下来了吧？你们真的很想两个礼拜就熬一次夜吗？
我为之语塞，所有新创团队不都是这样用肝与时间换出来的吗？为什么他好像觉得这样经营团队的方式很蠢？
要知道问题点，你必须要先学会工作的本质，分类，还有为什么会有紧急事件。到我公司里面来，我们需要一块白版，他说。
唯有从头到尾完成的工作，才有价值
走进他们砖墙围绕的办公室，他从冰箱中拿出两罐啤酒，递给我一罐，示意要我走进那有块大白板的会议室等他，坐定后，他自顾自拿着笔在白板上口沫横飞起来。
工作是一个生产价值的过程，他的概念跟工厂其实很像，原料从一边进去，经过生产与加工，有价值的成品从另一边出来，你有工作，组织有产出，皆大欢喜。
跟工厂有不同生产线，生产不同产品一样，每个人的工作都有分不同种类，各自生产不同的价值，以你最熟的工程师工作而言吧，大概可以分为以下几种工作：
1. 产品功能开发工作－开发产品新功能 2. Bug 的修复工作－修复产品问题 3. 业务营运工作－维持公司产品营运 4. 救火大队工作－产品营运出问题，抢救的工作
知道你的工作分为几种，你就可以视觉化每种工作，画出你每种工作的价值流程图，来，你上白板来画出你们第一项产品开发的所有步骤流程吧。
我接过笔，在白板上画出几个方格与箭头：
设计功能 -> 架构讨论 -> 功能开发 -> Code Review -> 测试 -> 部署上线-> 功能营运
你觉得对公司而言，你功能做到哪个步骤才会产生价值？ “应该是上线营运后才能真正发挥效果吧？”我说。
没错，在制造业中，有个概念叫做“半完成品”，英文叫做 Work In Process，或是直接叫 WIP，简单来说，就是制造到一半的东西，这种半完成品卡在中间，不能当原料或完成品卖出，一点价值也没有，是制造业的死敌。你虽然在知识经济下工作，概念是完全一样的，唯有从头到尾跑完的工作才有价值，其他都是 WIP ，堆再多都一点用也没有。
穷忙、瞎忙、当英雄，不是主管的工作
现在你有4项工作分类：“产品功能开发工作”，“Bug 的修复工作”，“业务营运工作”与“救火大队工作”，前3项工作听起来都很合理，也都可以分别画出其价值流程图，执行完毕后，也都能够创造价值，但是你想想，第四项“救火大队工作”完成后，有为整个系统带来任何价值吗？
“系统就能够正常运作了”我搔搔头。
再回答我一个问题，紧急事件发生时，其他工作的排程怎样？
“当然全部延后啊，救火优先。火救完了，进度再用力赶回来就是了”我一付理所当然地嘴脸说。
没错，救火工作不会为组织产生任何新价值，不仅如此，还让其他工作能产生的价值延后，整体效能降低，最可怕的是，他通常还没有办法预测，你有可能整个月都在救火，组织价值的进度就会落后整整一个月。
然后救火的英雄模式结束后，整个组织为了赶原来的进度就进入了加班模式，加班模式完成的品质会比正常模式差很多，也会为未来埋下很多紧急事件的地雷，就形成了恶性循环，不断加班，不断赶进度，不断穷忙，不断瞎忙而不自知。
英雄模式的确会让团队的英雄们看起来很风光，很努力，很屌，但是英雄会累，团队会累，一天工作 12 小时，绝对不是任何公司组织的长久之计。
“有出路吗？”我睁大眼睛。
身为主管，你的工作跟工厂厂长一样，要确定每条价值的生产线都正常运作无碍，还要确定你们产出的同时，在不影响效率的情况下减少未来的紧急事件。不是跟你一起下去救火，当英雄。
你要在紧急事件发生前就解决他们，方法就藏在你之前画出来的价值流程图中。既然知识经济也是条条的生产线，我们就可以借镜制造业品管的方式，管控最容易发生问题的流程，以你上列“产品功能开发工作”的价值流程来说吧，这么多的意外事件，首先要检查的是Code Review与测试这两个步骤的执行有没有问题，需要的话，要进行Code Review check list的定义与训练，全自动化测试的流程，机器能做的，就不要让人去做，人类绝对不会有机器精准。
在问题的源头解决问题成本最小，不然你觉得Toyota为什么给工人看到问题就停掉整条产品线的权限？难不成要等到整批问题产品都做出来了才在后面敲敲打打补救吗？
“但是这样步骤成本会变高，会慢下来啊！Startup不是要Move fast and break things吗？”我翻出Facebook的座右铭挑战他。
你要注重的是整个系统的速度，而不是单一步骤或是单一员工的速度，以整个系统而言，如果不是在瓶颈上改善，根本快不起来，能创造实质价值的产出也不可能会增加。
“瓶颈？”我问。
在瓶颈上的改善才是改善，其余都是浪费时间
工厂就像是一个大沙漏，原料从沙漏的上面留下来，经过各个工作站，在沙漏的另一边成为可以卖的完成品。
很久以前，在Theory of constraints（限制理论）或是Lean manufacturing（精实生产）这些慨念出来之前，工厂中的每个工作站为了表现，都尽全力发挥每个工作站的产能，制造出大量的 WIP，用力把这些 WIP 推往下一个工作站中。但问题来了，每个工作站的速度是不一样的啊！这些大量产出的 WIP ，就堆在速度慢工作站的前面动弹不得。
这个速度最慢的工作站就是所谓的“Constraint（限制）”或是“Bottleneck（瓶颈）”，就像沙漏中最细的部分一样，它你整体产出的的决定因素。
任何在瓶颈以前的产出改善都只会让WIP堆积如山，同样的，任何在瓶颈后的效率改善都完全没有办法增加产出，因为瓶颈硬生生地卡在那边。
只有针对瓶颈产出的改善可以让整个工厂快起来！听起来很直观，有点白痴，但是在这些理论出来之前，根本没有人注意到，每个工厂的员工都在穷忙，看起来工厂生气蓬勃，存货满地，但是却怎么也快不起来，交不了货，赚不了钱。
“具体怎么做呢？”我问。
你列出“业务营运工作”这项的工作流程试试。
客服团队交托客户需求 -> 系统自动化处理客户资料 -> 工程师手动确认资料与报表完整 -> 交还客服团队确认 -> 移交给客户
你们都卡在哪里呢？
“工程师手动确认资料与报表完整这边”
那你觉得“系统自动化处理客户资料”这边多给你几台超级电脑，或是多给你 10 位客服人员，让你“交还客服团队确认”速度加倍，对整体产出有帮助吗？
“当然没有。”
是啊，这时候，不管客服多用心经营，电脑速度多快，或是客户需求大增，都完全没有效果，工作只会堆积如山，公司也不会赚更多钱。
“看起来理所当然啊，大家应该都懂吧。”
是的，但是这时候上面来一条命令，要每个部门提高效率，你看看客服部门会不会半夜打电话叫工程师死命地做下去？这些客服就连哄带骗地带工程师去吃饭，帮他们买饮料，罩的工程师会成为客服的英雄，资深工程师也会因为忙于做事没有办法训练新来的工程师，客服v.s.工程师的黑市就渐渐形成了。
“但是整体产出还是不会变好”
没错，但是成本增加了，工时增加了，沟通成本跟管理成本都增加了。解决你“工程师手动确认资料与报表完整”的最好方式是把人工的部分拿掉，不管是直接写进你的产品中，或是让营运工程师写程式来后制，不计一切地在瓶颈处加速，整体产出才会增加，公司才会赚钱。
“XXX！我老板是白痴，不会带。”
你在跟我聊之前不也是白痴吗？想经营团队，就要把个别英雄拿掉，注重整个系统的产出。做 startup ，你不能当蝙蝠侠，你要学会当球队教练。
他拍拍我的肩，硅谷很大，你以为这些千万人团队怎么打造出来的？不是只有骇客松跟创业活动，生态圈内所累积的资本，技术，跟方法论才是精髓。
慢慢来，人生很长，但是硅谷就这么大而已，他说。 |
|
|
