找到适合的工作方式 就会事半功倍

书名   争球：事半功倍的工作艺术

作者   Jeff Sutherland

年份   2014

阅读难度  ♥♥♡♡♡

参考价值  ♥♥♥♡♡

畅销信用  ♥♥♥♡♡

本文全长  3500字阅读时间  9分钟

事半功倍，听上去很诱人。

今天我介绍的这本书，它让我反思自己曾经从事的行业 为什么从高端市场高收入，渐渐走向低端竞争低效率。没错，我说的就是建筑与城市规划设计咨询行业，简称设计咨询。

中国城市规划脱胎于计划经济。国家有五年计划，按计划执行，总该万无一失了吧？当然不是！

市场经济，资本当先。市场经济下的设计咨询行业，面临的最大挑战是需求变量：客户变更需求，会造成设计团队反复修改，成本增加；重要项目的婆婆多、验收关卡多，目标变量不可控。

项目管理成功，意味着团队能按时交付客户满意的产品，同时有所盈利。

设计咨询行业 最大的成本是人力时薪x工作时长=人力成本
我知道有很多设计咨询机构，都不会因为成本超支叫停项目，而是一边跟客户软磨硬泡补签合同追尾款，一边放任设计师超长加班，稀释时薪。如此一来，设计咨询行业渐渐落入试探客户需求、生产力低下的恶性循环。
我今天介绍的这本书，它启发我们在项目偏离轨道时，如何通过迭代和调整，重回正轨。

01

一种更灵活的工作方法

美国FBI在2000年开发了一款刑事案件网络管理系统。这个项目的预算超过1.7亿美元，然而经过5年的研发，项目却以失败告终。上百个软件工程师写的70万行代码，最终因为没有可展示的产品统统作废。
如此重要的项目，为何落得这般下场？
原因有很多，系统设计不当、糟糕的项目管理……但归根结底是因为选择了一种笨重的工作方法。
当时的FBI，创建了一个面面俱到、体量庞大的启动计划。项目仅创建需求一项，就动用了300个人花六个月起草，写成600页的“需求描述”文档、400个“变更申请”文档。
项目失败后FBI不得不换种方法，把项目分解成600个用户故事，以不超过15人的轻型团队组织工作，而不是之前的300人。由产品经理为任务确定优先级并派发给团队，每个任务周期不超过两周，结束前要作演示。
结果呢？只用了不到一半的预算，项目在两年内就成功了！这之后联邦特工们一直在案件调查中使用这个系统。
FBI后来用的这种工作方法，借鉴了软件开发者常用的Scrum(直译“争球”)。
它的核心动作是定期喊停，让项目参与人员反思已经做过什么，确定接下来要做什么；共同商讨遇到哪些障碍；对下一步工作的分工协作达成共识。
《争球：事半功倍的工作艺术》作者杰夫・萨瑟兰是一名企业家，很擅长讲故事，他讲述自己如何用这套方法拯救了耗资亿计的火箭飞船制造项目，扭转亏损的洗衣店、婚礼策划生意。萨瑟兰的生意经里，最重要的是准时交付。
他把工作组织方式分为瀑布法和敏捷法。

左：瀑布法    右：敏捷法(Agile)

瀑布法强调的是时间线、程序化和秩序性，比如汽车生产流水线。项目被分解成若干段，只有上一阶段所有工作完成后才能进入下一阶段；必须罗列所有需求才进入实施；客户拿到最终产品之前，几乎没有任何反馈。
建一座大楼、批量生产牛仔裤……瀑布法是适用的。因为这些任务都经过漫长的前期分析，很少中途变更需求。
但是，还有些工作依赖用户反馈，不能从一开始就对产品提出精准的要求，比如开发手机app、写网络小说。若想完成这些任务，必须对变化有很强的适应力。这就需要用到跟瀑布法相反的敏捷法。

电影《摩登时代》里展现生产线工人的工作状态

敏捷法强调的是优化组合，倾向于将项目作为一个整体来处理，而不是切成不同阶段。工作的组织围绕任务节点而非文本。所以这种方法项目前期的管理文档很少，分析用时更短，允许客户全程参与。
靠敏捷法取得成功的典型是微信。不求一步到位，1.0版上市后不断测试、获得用户反馈，持续调整、增加新功能。
值得一提的是，用敏捷法组织工作用的是sprint冲刺，每次冲刺最终都有可交付的成果。冲刺以周为单位，从一周到四周不等。开发团队在冲刺中磨合协调，不断吸收客户反馈，及时捕捉错误，交付客户最想要的产品。冲刺里有局部没能如期完成的任务也无伤大雅，它们很可能会被项目经理整理到下一个冲刺。
总之，这种工作方式相对灵活，不作没成果可展示的消耗动作。

02

两种管理方式利弊的比较

“其实，这个项目我们几个月前就完成了，

只不过日程表显示它到年底才完工。”

图片来自 Cartoon Collections

两种管理方式

归根结底是两种风险控制术

在过去，作家写一本书可能要花上一年，然后送出版社编辑印刷上架。若想知道市场反响如何，通常要再等半年看销售数据。这样的反馈速度太慢，出版社为了降低风险，倾向于和已经在市场上占得先机的知名作家签约。
可网络文学不是这样。网络作家写一部作品，会从后台读取大量信息，看阅读量、点赞和评论，小说剧情的走向也由读者参与决策、作家执笔完成。网络小说家要想成功，必须能及时满足粉丝，于是一流的网络小说家练就了日更万字、不断涨粉的本领。粉丝对一部连载作品买不买账，只需要两三个月、甚至更短就知道了。
传统作家用的是瀑布法。它不大考虑项目过程中的变量，依赖初始计划(创作大纲)的完备性，一旦初始需求设定有缺陷，与市场要求脱节，项目几乎注定失败。另外，产品直到项目结束后才接受测试，若是在临近结束时发现重大失误，不得不付出高昂的代价，否则满盘皆输。
相比之下，网络写手用的敏捷法更灵活，允许读者在中途变更需求、添加功能(人物 剧情 彩蛋)，以便让产品跟上行业发展。
总结起来就是：对于需要大规划社会协作、任务定义和客户期待都很明确的项目，瀑布法很好；敏捷法则适用于客户需求不断调整、持续改进、反馈周期短的项目。

03

如何评价这本书？

这是一本阐述现象而不是分析方法的书，价值含量并不高。我推荐它的理由是因为：看起来显而易见的事情，其实透露着人类发展的某种共性和趋势，那就是成为彼此协同的共同体。

只要跟人打交道，就难免有混乱、非标准的因素。我不相信有神奇贴药能包治百病，或者任何一种工作方法能解决所有企业的管理难题。本书作者也指出：如果Scrum对你的公司没起什么作用，可能是有没做对的地方。

嗯，这听上去像是句废话。
我认为作者不够诚恳，书中没提到任何敏捷法失灵的例子。失败本身并没有那么可怕，但作者避而不谈，就让这种方法的正当性打了折扣。
企业和组织领导者在选择敏捷法时，应该获得充分的知情权，知道这种方法也有消极方面，比如它对产品经理、创作者的素质要求非常高。产品经理要提前规划；所有创作者都必须能主动思考。另外，由于计划经常改变，这就需要团队内部及客户充分信任，否则会损害团队的稳定性。
反过来看，瀑布法也并不坏，它对许多行业仍然非常重要。
无论选取哪种方法，都要面对一个现实，那就是现代社会的很多任务，需求会一路变化。

04 

读这本书 我的心得

一本价值不大的工具书，该怎么读？
即便一本并不十分出色的书，也能锤炼读者的思想力。比如这样一本除了让我知道软件开发者怎样工作，并无特别价值的书，它提示我们过分鼓吹看似有理的“新”方法有多荒谬。工作方法，其实并没有绝对的优劣。

造一辆车的两种方法 | The CRM Team

同样是造一辆车：一种方法是有明确方案的流水线作业；另一种是需要各部门协同作战，不断升级的组合递进，不断推出新产品。对于后者来说，创作团队最初并不知道能造出什么样的一辆车，所以各部门必须主动推进、密切合作。
这两种看起来截然不同的工作方法，其实都没有错，关键在于你选择谁，才能发挥事半功倍的效果。所以更重要的是背后“谁是大脑？”。
流水线上的工作人员，可能缺乏对产品的整体概念，只知道完成自己眼前这个阶段的成果。而软件工程师需要合作与组合的智慧。一只苹果手机有上百个组件供应商，每家都是特定配件的最优选择，最终在核心工厂组装成手机成品。整个过程需要具有高度鉴别能力和包容的智慧大脑。
敏捷法给我们哪些启示？我观察到，这些年来设计咨询行业自降身价、延时工作已成家常便饭。长期以往，只会伤害团队的专业价值。设计主创们长期疲劳工作，判断力下降，很难持续高水准的创作和学习成长。
与此同时，我们也看到行业内部悄然变化，有不少专业口碑好、生命力旺盛的设计团队，已经把参与感和适应性列入行业发展风向标。我认识的一些团队，甚至借鉴了软件开发团队常用的工作方法，比如
公司内部设立项目经理负责生产经营，让资深设计师专心做设计；
项目经理在拿到项目后，花一天时间把新项目分解成若干可交付产品；
每个可交付产品允许一个人在8-80小时完成，避免保姆式的微型管理；
每个工作日上岗的前15分钟开小组碰头会，成员逐一发言，确认工作进度、反馈困难，确定当日工作目标；
项目经理在会后逐一给出解决方案，如与客户沟通确认、寻求专业增援；
客户参与交付成果的确认和反馈，以便设计小组及时调整方向。
改良工作方法，更好的适应复杂变化。在项目推进过程中，不断提交可交付的最小化产品，与客户保持信息透明，让进度和投入成本可见。
这就是我从软件工程师的工作方法中获得的启发。

参考文献

Jeff Sutherland （2014）. Scrum: The Art of Doing Twice the Work in Half the Time

Liz Parody (2018). How to Manage Modern Software Projects: Waterfall vs. Agile 

往期文章

  - end -