返回

工科生眼中的未来

首页
关灯
护眼
字体:
第十八章 陷入稀缺的Tom
    周五晚上7点半,从健身房出来换洗完毕,行知一路小跑去饭堂。行知周一到周四都是早上健身,周五则是晚上健身,因为临近周末健身房跟饭堂的人都比较少,打工人一般都早早下班约会或回家陪家人吃饭。可今晚刚到饭堂行知远远就看到埋头干饭的Tom。



    “你还不回家带娃吗?”,行知远远就跟Tom打招呼。



    “快来看多我几眼吧,说不定以后初一十五你有空去给我上香时才能再见了”,Tom反倒招呼行知到他对面坐下。



    看到行知一脸迷惑的表情,Tom继续无奈地吐槽:“长期10116,我都不知道意外跟明天哪个先来。本来就满当当的排期,硬是被紧急插入需求,而且业务都已经跟客户敲定下周的上线时间了”



    “又是倒推的?”行知一脸惊讶地问。



    “对呀,这个月都第5个了,既要维持已排期的又要确保加塞的还要保障质量。”



    “什么需求这么紧急”行知问



    “内容千姿百态,反正结论都是非上不可,不然有流失KA的风险”,Tom说完突然满脸期待地看着行知问“你这边下周有人可以借调过来支援我吗?”



    “我也希望支援你。可我们的排期表也是满满的。唯一的可能是让两边的业务PK我们下周哪个需求优先级比较低可以往后延才能释放资源出来。”



    听完,Tom两眼发光,赶忙问:“你们下周有哪些需求?”



    行知没正面回答,却说:“但从其他域借调资源不仅增加总成本,风险也大。撇开信息同步的问题不说,先是成本,比如你们评估1天工作量的需求我的人过去要半天了解1天解决,那就浪费了半天的资源。另外我的人就算业务知识面够广能很快熟悉你们的业务,但对你们域的技术实现细节没有由始至终的了解,贸然去做有可能踩中一些历史的坑或是设计的扩展性不够好。还有后面再继续被中断任务的成本,人毕竟不是机器,不能直接在中断的地方点继续就可以。这样对我们都不是最优解。”



    “紧急需求不经常是这么解决吗?明知山有虎,也只能向虎山行。看来你们真的很久没接到紧急需求了”,Tom反倒奇怪地看着行知问,



    行知接过机械手送来的饮料,这是一种补充多种维生素跟矿物质的运动饮料,行知一边打开包装一边问:“说真的,经常碰到你都是问加班到几点,而不是有没有加班?”



    “有啥办法呢,需求压下来又没法推”



    “我去年看过一本叫《稀缺》的书,里面描述的稀缺陷阱跟我们的现状一模一样,强烈推荐你去看看”



    “技术类还是管理类的?”



    “都不是,研究行为心理学的”



    “我哪里还有时间去看心理学的书。我每周只有周日的时间陪家人,每天醒着不是在上班就是在上班的路上,我连午休都省了,靠咖啡续命”,说完Tom低头扒了一口饭,夹起一片牛肉重重地嚼着。



    “就因为无休止的加班,太忙,烦透了,更需要审视现状破局呀。不然很容易在稀缺陷阱中越陷越深”,行知大口灌进一口运动饮料后说。



    “怎么说?”,Tom抬头看了行知一眼问。



    “稀缺顾名思义就是拥有比需要的少,比如你加班就是因为办公时间跟人力资源不够。面临稀缺时大家往往会通过借用相应的资源来应对突发事件。对应到你是加班或是从其他组借调资源。”



    “对呀”,Tom不以为意地接话。



    “但长远来看借用会进一步加剧稀缺。因为在解决当前问题的时候不够精力去关注未来的稀缺,导致稀缺不断延续。比如你今天的任务T1被插入需求影响没完成,那你就需要借用明天的时间来继续执行T1,可是这导致明天的任务T2也完成不了,你不得不继续借用后天的时间来完成T2,以此类推,就产生无数个往后延的Tx,也就相当于陷入了无底洞。”



    “不对,我们往往是在周末加班的时候就得完成所有的任务,不会一直拖下去”,Tom摇摇头反驳。



    “确实,因为项目是有时间限制,时间借用在项目完成的一刻就终止了。但还有其他问题,稀缺必然会产生管窥,也就是我们不自觉地专注在出现稀缺的事情上,减少投入在其他事情上的精力。当然专注可以提高工作效率是好事,然而这也导致人产生权衡式思维,忽视掉其他非紧急的问题,只局部或短暂地解决问题,而这些被忽视的问题在下一个阶段又变成紧急问题继续侵占时间。就像我们在资源不够时处理紧急问题时往往会牺牲一些非核心功能、性能、易用性等,让需求带着已知的瑕疵上线,而这些历史债最后又变成紧急需求来解决,也就进一步加大后面的稀缺。”



    “这没办法呀,有限的资源只能集中解决主要的问题。不过确实有时候遇到客户试用后又让我们紧急补上其他功能,不然客户不愿意继续使用,唉”,Tom似乎是想起不开心的往事停下筷子,伸手去拿旁边的无糖饮料。



    “我们的工作还好,不是性命攸关的。书中的例子就很震撼人心。书中总结了美国2000年前15年机动车事故,其中消防员的死亡占据20%到25%,而这些事故中有79%的消防员死于没系安全带。为什么随手系安全带这么小的事情都忘记,有一种可靠的说法是消防员在赶赴火灾现场前需要高度专注研究起火的建筑结构来制定进出火灾现场的线路、灭火方案等等,所以他们无暇顾及安全带,但凡他们有一点闲余的精力都不至于这么疏忽大意,我想没人愿意拿自己的生命来冒险”,说完,行知又喝下一口饮料。



    “我不是不觉得这种现象不可怕,而是有限的资源下只能做出取舍。”



    “我明白你的无奈。我们都经历过这种。你还记得这两年咱们公司动物医疗监控系统这个项目对产品质量的要求吗?”



    “第一年够用,第二年好用,第三年卓越”,Tom漫不经心地回答。



    “对,第一年只要求够用。这种策略可能是源于对市场的不确定性评估及面临竞品的压力,所以公司希望尽早把产品推上市看市场的反应以及占领更多的市场份额。于是各个域产品的市场调研时间、编写PRD、UI交互稿,研发测试时间每个环节都被挤压到不能再短,结果业务述求不够明确;设计稿粗糙,很多细节靠PRD评审会上的讨论补充;操作文档简陋;UI稿只有主流程的交互图;很多运维配置都没有文档记录;测试机器人根据操作文档只能覆盖大部分的流程。在产品推到Preview环境让业务验收时遇到的问题多到不堪回想,于是我们又得马不停蹄地修修补补。最后炼狱般研发出来的东西终于上线,虽然是够用,可却埋了很多的坑,在用户陆陆续续入场后线上问题层出不穷。导致我们在处理新需求的时候经常被线上问题打断,我那时最惨的一次协助组里同学发hotfix一直到凌晨3点才结束”,说完行知依然心有余悸,连喝两口饮料压压惊。



    “你就别卖惨了,那一年我通宵那都是家常便饭”,Tom放下饮料右手撑在桌子上揉了揉太阳穴。



    “不仅你,我也经常听其他leader吐槽,回想起来都觉得后怕。好在守得乌云见明月,我这边半年后历史遗留比问题终究被消灭得差不多才能松一口气。”



    看着继续扒饭的Tom,行知又说:“上个月系统崩溃导致网站故障2个小时的问题,你听说原因吗?”



    “据说是网络抖动的问题?”,Tom含糊不清地答着。



    “网络抖动是官方解释,对外的话术一般是越抽象越好。网络抖动只是诱发因素,具体原因是有个域的配置服务布置在国内机房,那天发版时碰上网络抖动导致海外机房的应用无法访问配置服务拿不到配置,海外应用起不来,当时发版跟值班的同学都不清楚配置服务的部署情况定位半个钟没找到问题就贸然重启,重启应用时顺序又有问题导致更多服务起不来,于是统一回滚,可是回滚后部分域又得刷数才能恢复正常。描述起来仅短短几句,但那天在群里观战心惊肉跳,整个过程一波未平一波又起,唉声叹气、质疑怒骂此起彼伏。”



    “难怪第二天早上我碰到Ken一脸憔悴。”



    “第二天复盘的时候才发现配置服务没跟其他服务做全球化的部署。一来配置服务初始设计就没有规范的文档记录导致后面负责全球化部署的同学梳理漏了。二来应用起来后就不再请求它,它的存在感很弱,没有人注意到它。于是悲剧就发生了。”



    “是呀,没有一步到位就后患无穷。生物技术应用方面我们都预留充足的时间来观察产品倒还好,可是互联网的部分很难一步到位,这也是互联网的历史通病”,说完,Tom把喝完的饮料放到旁边,无奈地叹了口气。



    “稀缺还有个更可怕的问题是稀缺占据大脑的带宽,导致人的认知跟执行能力下降。比如,在负责紧急需求时一线同学对遇到的问题未必都能准确判断到它的严重性,加上不够时间跟上级汇报问题就上线,导致爆发严重的问题。”



    “好了,都听得我毛骨悚然了,你上面说的我深有体会,陷进去真的难以自拔”,说着,Tom往后倒,靠在椅背上,撇着嘴看向窗外的灯红酒绿。



    “这些状况根源于市场的不确定性,所以前期确实没办法,只能先把够用的产品推到市场观察响应。如果有问题必须及时调整方向或是止损。但这两年的数据证明我们已经被市场接受,所以CTO对我们的要求也从够用提好用提前转入追求卓越。这个阶段我们是可以做出一些改变的。何况陷入稀缺这么难受。”



    “别卖关子了,快说有什么办法?”



    “书中说解决稀缺的方法是创造余闲,让闲余的资源来应对突发事件。但明面上这点不容易实现,一是公司要降本增效,甚至出现既要马儿跑得好,又要马儿不吃草的情况,太过精简的组织结构削弱了余闲资源。二是就算有的老板愿意保留有用的余闲,但有用跟无用余闲很难界定清晰,所以干脆一刀切,宁可杀错不可放过,反正下属们最终一定会想方设法解决问题。”



    “明面上不行,那就暗箱操作?”



    行知吃惊地扫了Tom一眼说:“暗箱操作说得好难听呀。是在我们力所能及的地方创造适当的余闲。”



    Tom看回行知思考了一会,试着问:“你是指,排期?”



    行知笑着给他送出大拇哥:“聪明,一点即通”



    Tom半信半疑地问:“这不会影响团队的吞吐量吗?”



    行知微笑着说:“基本不会。这时的排期要比常规的做多一些事情,创造余闲并非简单的预留空挡,而是要评估意外,包括时机、影响范围、严重程度、应对措施、执行人、合作对象等因素的考虑,另外是有多套备份方案,没有突发事件时将余闲投入哪些项目上。”



    “难怪你都是自己排期,而不是交给虚线”,Tom一副恍然大悟的样子说。



    “如果只是分配任务甚至是根据不同同学的培养方向调整任务虚线同学完全可以胜任。但虚线更多还是侧重在做事方面,他没有足够的时间跟资源从宏观上去了解产品、趋势、合作团队,也未必有资历去应对突发事件的解决。不可否认不同职级的视野、认知、阅历、专业度、敏感度都不同,何况还存在一定的信息差。如果对虚线同学的排期提上面的要求未免强人所难。很现实的一个例子,公司每年组织管理层培训又没有虚线的份。当然Leader可以在学会后把方法跟大家同步,这是后话”,行知解释道。



    “倒是个可以考虑的方法。但我的排期都到下个月底了,要试也只能以后再说。现在的问题还是难解。”



    行知一边在桌子上转动饮料瓶盖,一边试探着问:“Jimmy上午不是对插入需求义愤填膺,让我们严控,有试过让Jimmy介入吗?”



    “找过了,没用。我下午把Jimmy哥跟业务、产品都拉到一个群里聊,我跟业务争论的过程他一言不发,我吵不过业务时他才来一句让我确保这些插入需求如期上线,最后反倒是我落下得罪业务的下场”,说完,Tom像是哑巴吃了黄连,一副心酸又无奈的模样。



    听到这行知惊讶得睁得圆溜溜的眼睛上双眼皮都跑出来了,略带尴尬地说:“我以为是你心软才让业务加塞的紧急需求。毕竟上个月CTO强调了,早上周会Jimmy也表现得对插入需求深恶痛绝。我上午当真觉得就算不能杜绝,起码可以理直气壮地拒绝大部分呢。”



    Tom不语,看了行知一眼又低下头看着吃得七七八八的饭,眼神黯淡。



    “技术是为业务服务,可能Jimmy也有难处。也许他过段时间出具体的应对措施会好一些”,行知补充一句安慰Tom。



    听到这Tom灵光一闪,突然兴致勃勃地问:“我怎么想起差不多一年都没怎么看到你们加班,跟我分享几招?”



    “阿,是我们业务跟产品团队比较厉害啦”,行知笑着说。



    “你这是内涵我们的业务不够好?”



    “哇,当然不是,求放过”,行知脸上闪过一丝惊愕,求饶道。



    “说说看嘛,我也学习学习。”



    行知喝下一口饮料后说:“大家的情况未必都一样,你可以听听看,遇到我没处理好的也好提醒我。其实跟业务还是外部因素,要先看我们团队内部的工作效率有没有得提升。我们的团队不一样我就不细说了,方向是从我们的效率方面着手。”



    “你是指提高会议效率?”



    “提高会议效率要做,但还有点不一样的。日常工作最占时间的是会议,然而安排会议的同学未必就考虑清楚是不是必须都让这些与会者参加;还有一点是在会议中讨论很多不是跟所有与会者都相关的事项,大大耗费大家的时间。实际这两点在开会前沟通了解很大程度上是可以解决的。你可以换一种角度看会议,它是在占用所有与会者的时间跟精力,对与会者来讲这应该是一种有偿行为。”



    Tom略微惊讶地重复:“有偿,怎么偿?给参加会议最多的同学颁一个奖,奖金从活动经费中出?”



    行知摇摇头说:“不是金钱啦,是组里面的积分制度。积分从组织会议的同学一侧划到与会者一侧。不过这些是跟会议类型有关的。分享类型的会议积分变动是从与会者划向分享者。积分的数量跟会议质量有关,具体需要你实际推行的过程中跟组里所有同学一起讨论并磨合的。而积分制度不仅可以覆盖会议,团队其他的管理事项也可以运用。”



    “我们组也有分数统计这项。不过你这倒是新奇的想法。之前有的同学邀请与会人不管三七二十一,但凡有点关系都拉上,生怕漏掉一个最后信息同步不到位变成自己的责任”,Tom摸摸下巴说。



    行知接着说:“第二点目前为止是我们真的沉淀了太多文档,条条框框相当繁重。如果让每个同学做事时关注所有规则相当于都不关注,因为太多了,不现实。所以我让每个组员都拷贝一份自己的文档,在里面提取他需要关注的点。因为每个人的特长跟缺点、岗位不同,需要关注的点也因人而异。”



    “你有没有遇到过一线同学工时评估比预期长很多的情况?”,Tom突然打断行知问。



    “你是指他的评估跟你预期的不一样?肯定有,这很普遍。你可以请这个同学把具体每一项工作内容的评估罗列出来,就从任务内容和类型两个维度拆分,这时候时间都花在哪里就很直观,那就可以指导问题出现在哪里。不过我还是想提多一句,我们也要相信有时候一线同学对产品功能细节确实比我们更了解,毕竟我们早就不是一线执行层了”,行知耐心的说着。



    然而Tom摸摸鼻子,继续问:“我是指故意把工时估长的?”



    “那最好先了解他特意这么做的缘由。因为我们是结果导向,产出的质量跟数量与他们的绩效相关,大部分同学都是很积极向上的。怎么解决下属执行力不佳的课程我们不是有学过吗?”



    “你是指4C的方法?”



    “嗯,执行力不佳分为做不来跟不去做。这就不展开聊了吧,不然大半天都讲不完。如果你只是想解决工时的问题,可以参考囚徒困境,让多个同学对同一个任务进行评估,只是你要巧妙点运用。”



    “哇塞,你连博弈论都运用上了。可以具体讲讲吗?”



    看着Tom兴奋的眼睛,行知环顾逐渐空荡的四周,说:“没有你说的这么夸张啦,我现在没在用了。要不我给你简单介绍我现在的方法,我是把工时评估跟任务指派拆开的,也就是评估工时的人未必是负责这个需求的同学。但有个前提是我们提前梳理了评估工时的模板,模板里涵括评估不同类型需求必须考虑的各类事情,这样不管谁评估的工时,最后负责的第二个人也很少出现差异。这么做有两个优点,一是每个需求除了负责人,可能还有另一个同学对它比较了解;二是增加了同学们之间的合作、互相学习的机会,这是最重要的点,一定程度上可以减少思维定势带来的风险。”



    “这倒是一举两得的好办法”,Tom托着下巴附和道。



    “再来就是跟业务的磨合了。之前我连续每个月都找业务强调插入需求影响产品质量,导致我们的工作效率下降,可无法引起他们的重视。我不知道你有没有遇到?”,行知看向Tom问。



    “都一样,但我倒没有你频繁,因为投诉完都没用”,Tom苦笑着说。



    “我觉得没用的原因是这些不直接涉及他们的利益。虽然大家都在一条船上,假设他们主动替我们着想其实不现实,因为他们的绩效考核跟我们是独立的。于是我想到一个办法是让他们知道配合我能给他们带来什么样的好处,紧急需求其实也会打乱了他们的计划。所以我去年9月份整理了我这条线有史以来所有的紧急需求,重点放在归类并分析紧急需求中BRD、PRD质量跟常规需求的差别在哪里、这些需求分别优化了多少次、他们当时为何没能提前发现这个需求,以后做哪些事情能提前解决这些问题,尽量减少紧急需求等。”



    “我感觉你做了产品业务的活”



    “当然不是,我这门外汉的意见不过是引玉之砖。关键还是我们产品大佬厉害,雷厉风行,我找他讨论完后他立刻组织组里的产品同学通过头脑风暴举一反三、挖掘更多的问题并刨根问底,然后整理出相应的措施严厉推行,所以我是真的很幸运碰到执行力这么强的业务团队。在跟他们讨论的过程中我也学到了不少东西,开阔了视野,这份尝试非常值得”,说着,行知喝完最后一口饮料抿着嘴笑,脸上露出浅浅的两颗小酒窝。



    “都是一条线的蚂蚱,向上解决了他们的问题,一定程度上就可以减少我们的紧急需求。嗯,不错不错,我挺好奇你这脑袋瓜子怎么会想到这些?”



    “别笑话我了。我也是失败很多次后才摸索出来的方法。我相信你也有自己的一套方法。下次有时间换你来跟我分享下你的方法?”



    “好呀,你回去了吗?”



    “是呀,我有约。下周见”,跟Tom道别后行知把饮料空瓶放到回收盘就往电梯口跑去。