王辉的博客

是什么让我对未知世界始终充满热情?

你是团队的技术负责人,肩上扛了一个,销售催得紧,客户等不及,可行性模糊的项目。你对你的老板说,这个项目我规划不了,未知的东西太多了。当初我就是这么干的。如今,大大小小的项目经历了十几个,技术负责人做了快三年,学会了几个和未知相处的方法:分开已知和未知,拿替代方案减少未知,提前遇见未知,和最美的迭代未知。

分出已知和未知

分出已知和未知首先会让你成为一个思维有逻辑,表达清晰的人。如果你是老板,你听下属汇报的时候,到处模棱两可,恐怕你很难给这个下属委以重任。很多时候,未知只占很少的一部分,一颗老鼠屎,坏了整锅汤,未免太可惜了。与其说,这个项目有未知的部分,我规划不了。你可以说,这个项目里,有一部分需求清楚,方案可行,需要三十天,另外一部分,我们需要进一步的探索,目前规划起来难度大。这样一来,老板不仅知道你做了有效的工作,还会增加对你的信任。

第二个好处是客户可能暂时根本不需要那些未知的部分。很多时候,你只开发20%的功能,就能满足80%的需求,这是著名的帕累托的八二法则。一个项目,不会因为存在部分的未知就会让整体失去意义。如果你项目中,恰巧已知的部分,可以满足大部分需求,就可以先把未知的部分暂时搁置。

最后,就是你可以管理利益相关者的预期。作为技术负责人,在大家着急的时候,会让你说一个发布日期。你迫于压力,也出于对团队的保护,很可能说一个足够遥远的日子。这样做,其实是你给自己挖了一个坑。一是你很难解释这个日子为什么这么遥远,二是看似遥远的日子,在处理一些复杂度高的任务的时候,你实际需要的时间会比预期的多。所以,分开已知和未知,只在已知的部分承诺交付日期,在未知的部分一定不要做没把握的承诺,不管压力有多大。清晰的解释未知的部分,会让利益相关者感受到项目所存在的风险,神奇的是,他们会和你一起找办法。

拿出替代方案减少未知

如果未知的部分是项目成败的关键,为了避免在一棵树上活活的吊死,你可以找一些替代方案。这些替代方案,如果找的精妙,可以快速的产出部分有价值的东西,也可以为你们争取更多的时间做更加完美的方案。最为惊喜的是,在寻找替代方案的过程中,你们会更加深刻的认识到,那些是可以砍的,那些是必需留的。

但是这么做也有一个陷阱。如果你的替代方案像秋后的蚂蚱,活不了几天,千万不要在它们身上浪费时间,这只会给你们团队造成更多的麻烦。很多时候,你认为火烧眉毛的事,很有可能是有人为了倒逼你们出成果而采用的心里战术。到目前为止,我还没有见过哪个项目是真正的一天两天等不及,却见多了因为赶工而让整个团队深陷的维护陷阱,返工,以及可悲的人员流失。

找替代方案既有好处也有缺陷,如何衡量?我会问自己一个问题,这是从《逃脱构建陷阱》得到的灵感,我们是为了交付而交付,还是为了产生价值而交付?

提早探索下个未知

当项目中都是已知的时候,不要高兴的太早,等你已知的都做完的时候,一旦遇到未知,你们就会被卡主。项目进展顺利时,大部分人要低头拉车,一定要有人抬头看路,作为技术负责人,你就是那个必须要看路的人。

看路的时候,你不能只自己看。带上产品经理,毕竟路都是他指的;带上某些队员,要不然低头拉车久了,缺乏参与感。看路的目的,就是在稳步推进已知的同时,提前探索下一个未知,这样一来,你们会进入一个良性循环。当下一个阶段开始的时候,如果你按照开头说的分开已知和未知,你会发现,有不少东西都有了眉目,团队可以立马撸起袖子干。

迭代未知

我相信上面的几个办法,熟练掌握后,你可以很从容的去处理项目中的未知。但真正的能去拥抱未知,把未知转化成优势,还得在团队上下,培养迭代未知的能力。有未知的项目,就像摸着石头过河,你不知道深浅,就去摸石头,摸完就知道前面可不可以走,需不需要调整方向。普通的人,一小时摸十个,优秀的人,几百个。河都是同一条河,有的人摸索的慢,有的快。

天下武功,唯快不破。什么是快速迭代?从技术层面讲,你们一个程序员从代码提交到功能上线要用多久的时间?你们一天能交付多少次代码?交付完之后有多少原有功能照样好用?如果交付的不好,你们用多长时间修复它?从产品层面讲,有多功能你们不用开发,就能测出来他们是否真的有用?你有多少用户愿意尝试最新鲜出炉的功能并且给你们反馈?

之前的三个办法,可能会因为个别人的努力而得以解决未知带来的困扰,快速迭代的功夫,一天修不来,一个人也修不来,它需要整个组织的努力。这样的组织,一定是一个学习型的组织。

你带领的团队扩张,项目增加,你追求什么都做好,可时间有限,分身乏术怎么办?我总结出来的办法是聚焦关键,关注那些能让你们和他人变得不一样的元素。接下来从架构设计,项目管理,人员加薪几个例子中说说聚焦关键的功效。

只有最核心的领域才需要最精细的设计,这是我在《领域驱动设计》中学到的最重要的一课。当你设计一个软件系统的时候,这其中有关乎你业务成败的核心领域,这是你和别人区别开来的地方。还有很多普通领域,你的系统中需要,别人的系统中也需要。作者埃文斯很坦诚的让我们接受一个现实:那就是你的时间和精力是有限的,你不可能在所有的领域中都注入同样的心血。如果背道而驰,就是忽略了核心领域的所应得的重要位置。拿测试来讲,在核心领域,我们要尽量的多写测试,来覆盖核心逻辑,测试的数量要多,种类也要多样,单元测试,整合测试,功能测试,都得配套。而针对普通领域,比如写消息到Kafka里,测试可以少,或者都可以没有,因为他们复杂度低,出错的风险低,如果出错了,被及时发现的可能性也大。

管理项目也需要聚焦关键。当大小项目有七八个的时候,我们已经很难近距离的计划追踪每个项目。如果非得这样做,你的精力会被耗费在永不终止的上下文切换中。在计算中我们都知道,如果操作系统在不停的做上下文切换,那么就不可能执行实质性的计算任务。人也一样,我们的大脑在不同的任务中来回切换,也会降低效率。当你正深入思考某个东西的时候,被人打断甚至会让你变得心情暴躁。聚焦关键项目最重要的是识别关键。宽泛的说,关键项目一般都时间紧,不确定,复杂。一个时间宽松的项目,你大可拿出让子弹飞一会的魄力。不过要特别注意,关键项目会变,在一个阶段关键的项目,经过精心的打理之后可以变得稳定独立,而放手太久的项目,可能变得关键起来。

最后说说团队加薪。带了团队之后才发现,一个经理不可能在每个人身上都花费同样的经历来研讨应该加薪多少。如果这样做,这意味着你要深挖每个人的贡献,分析他们的成长潜力,揣测他们可以接受的增幅。分身乏术,同样的技巧,要把精力聚焦在那些去留可以在团队上产生大的变化的人。这些人,你必须细致的照顾,因为如果他们走了,你的团队就会少了锐意进取的冲劲,少了攻克难关的扎实本领。

总结下来,聚焦关键,看似是取舍,是不得已而为,其实是一种能有所成就的做事方式,这种行事方法里,你有了策略,有了重心,有了高度,有了眺望。

研发经理,有的抓产品研发,有的扛系统运维。如果你负责研发,那么产品经理将是你的关键合作伙伴。你们工作虽然有交集,却隔行如隔山,扮演的角色不同,思维方式就不同,所需的技能也不同。能够充分了解你的产品经理,与他优势互补,是你们合作构造成功产品的助推器。

产品经理是你的合作伙伴,我们可以从如何了解一个合作伙伴开始,然后再把这种办法具体应用到产品经理上。了解一个合作伙伴,我有一个框架可以用,具体分三步走。

首先是认清你们的共同目标,这是最为关键的一步。因为只有认清你们要往哪里走,才能力往一处使。倘若大家对目标的理解不同,所做的一切都将成为对方前往目标的阻力。

其次是搞明白达成此目标,不同的合作者,如何贡献他们的能力。这也是团队合作的魅力,每个人的优势都不一样,一个人很难十八般武艺,样样精通,只有拧在一起,才能完成个人无法完成的事。

最后,通过分析不同合作者,能力的共同点和差异点,来更好的认识你的合作者。共同点一般比较好理解,因为你们有共同的语言,这里要想充分的理解一个人,要把重点放在差异点上。

框架勾勒出来了,现在把问题具体到研发经理和产品经理上。你们的共同目标是什么?一般情况下,你们是想开发出一款用户爱用,愿意花钱买,能解决他们问题的产品。这个产品小到可以是一个闹钟应用,大到是一个搜索引擎。可不管是什么样的产品,它都得必须能解决一个实际问题。团队中,不论是程序员,测试员,还是产品经理,没有一个人乐意去做一个没人用的东西。

确定目标是最关键的一步,也是最难的一步。有一个小技巧,可以帮助你们找到共同的目标,就是多追问几下,追问的过程,其实一个追根溯源的过程,看似不相关的东西,往根上挖一挖,就有了联系。这个技巧有一个陷阱,就是不要挖的太深,太深了就开始虚了,别到最后,发现你们的目标是改变世界。

目标清晰了,开发出一个款解决用户痛点的产品。这需要什么样的能力?我们可以概括为发现问题,选择问题,解决问题的能力。除此之外,还包括敏捷循环使用这些能力的迭代能力。

首先要发现问题,得有人去和客户打交道,摸清出他们的需求,搞明白什么东西能给他们带来价值,以至于他们愿意去花钱买你的产品和服务。然而很多情况下,用户的需求不是单一的,而是复杂的,系统性的,有时还会受到外部因素的影响,如何从众多需求中找到最关键的?这就是第二步,选择问题,做出好的选择需要多方面的权衡,这包括竞争对手走到了哪一步,公司需要生存下来是否需要做出短期的牺牲来赢取更多的时间,某一需求的投资回报率是多少有没有快速收益的方案。经过多方权衡,需要解决的问题定下来之后。第三种能力就该派上用场,这就是解决问题的能力。通常办法是团队开发完整解决方案。验证能力强的人,会争取把这个过程缩到最短,他会找到最短路径。这一套走下来,有不得已的权衡,有为了省时而走的捷径,并非解决了所有问题,所以还要很多轮的迭代。

目标清晰,达成目标所需要的能力列举的明明白白,接下来就看这些能力都有谁贡献。作为研发经理,我们最擅长的解决问题的能力。产品经理,最擅长的则是敏锐的发现问题的能力,以及在商业,竞争对手,内部资源各种掣肘限制下的选择问题的能力。这里所说的能力,是高度概括出来的,还可以细分。比如说发现问题的能力,这要求拥有此能力的人,能够非常有效的和人沟通,通过交流,洞察并归纳出问题的本质。选择问题的能力,必定有大局观的支撑,如果只能片面的看到一方的限制因素而忽略了其他,则无法做出好的决定。

在这个框架之下,我们可以总结一下一个优秀的产品经理应该有哪些可以和你互补的优势?他深刻理解企业的商业目的,并且能通过解决客户的问题来达成此目的。他有高效的沟通能力,同理心,观察能力,能准确抓住用户的痛点。他还有足够大的大局观,能看到客户,竞争对手,企业内部运营给他框定的各种限制。他还要有影响力,能够让人看到他勾勒的愿景,并愿意为此去奋斗。

以上的思考有受到Melissa Perri的Escaping the Build Trap: How Effective Product Management Creates Real Value的启发,强烈推荐给对产品管理有浓厚兴趣的研发经理和产品经理们。

当我读马利克的《管理,成就,生活》系统学习管理的时候,受到的最大启发,是学会发扬别人的优点。接下来的管理工作中,我就开始留意一个人的优点,并且在做绩效评估的时候,表扬他们的这些优点,对于大部分下属,他们都很开心经理能看到他们的闪光点,并因此更高效的工作。可是有一个下属,在我表扬他的时候,发出了一些怀疑的声音。

当时这个下属拿到了另外一家公司的Offer,正在徘徊是否跳槽。由于他的确很优秀,我试图挽留他,说在他身上发现了不少优点,别的同事也说他工作出色。下属反问我,“我很高兴大家觉得我不错,可能具体说明一下我不错在哪里吗?”。他之所以这么问,一种可能是以为我在搪塞他,另外一种,是真的没觉得自己有那么优秀。从和这个的同事的相处中,我相信他是真的想通过更多的例子来确认自己的优秀。毕竟费工夫留一个不该留的人是不科学的。

我事先并没有准备,可我并非胡乱夸他,随机应变,找出了几个具体例子。可事后,我仍认真思考了这个问题,表扬一个人也是有风险的。如果你显得不够真诚,对方很容易理解为,你为了激励他而使用的伎俩,结果适得其反。心善的管理者断然不会为了操控别人而表扬,可怎样做才能让对方不误解你的真诚?

一直以来,我心中有一个朴素的答案:日久见人心。可在读完马歇尔的《非暴力沟通》后,我发现我们可以更加主动的让对方感受到自己的真诚。在表扬别人的时候,要说明三点:对方做了什么?你的感受是什么?你的哪些需求得到了满足?

感受和需求是达到至诚至爱沟通的两个关键因素,因为它们把你们对话的重点转移到更容易使大家互帮互助的需求上,而不是指责对方或苛求自己。运用这个方法,回到和同事上一次对话中,我会这样说:“我一直以来很满意你的工作(我的感受),这其中有你在之前项目上用Scala贡献的产品新功能,还有在当前项目里通过快速掌握Go语言对团队工作效率的提高(对方做了什么)。你出色的开发效率和学习速度,让我们的团队能承担更艰巨的任务(满足了我建设团队的需求)。”

我相信如果我的领导给我说了类似的话,我会很感激他发现了我的才能,并更加努力的为他的团队付出。这个方法之所以行之有效,是因为表扬的人,是在真诚庆祝对方的行为改善了大家的生活品质,不期待任何回报。除了让对方感受到自己的真诚,这种做法也会推动经理去深挖自己的需求,一旦一个经理清楚的知道他需要什么,并且知道各个成员的优势如何搭配起来满足他的这些需求,我相信他一定能带出一个优秀的团队。

刚从程序员转型过来做管理,我希望把事情都做好,即便是面对棘手的下属,也是想尽办法挽留。可一个下属的离开,就一定是管理上的失误吗?作为一个新手,缺乏经验和自信,不禁把问题的矛头指向自己。直到N+2肯定我的处理方式,才恍然大悟,并不是团队壮大才是成功,下属的离开,也可以归功于管理者。团队在变,人心也在变,该走的人走了,说明管理者把对下属的期待讲明白了,分道扬镳是正果。

我的这个下属,他的老板离职后,分配到了我的团队。起初,不顺,但动力十足,后来,他开始拒绝任务。我费劲找适合他的项目,可要么不是公司的重点,要么是已经分配到了比他更胜任的人手里。

持续了一阵子,我苦苦寻觅,他无奈等待,最后我给他摊了牌,对你的期待就是做好团队当下的任务。我已尽力,仍找不到和你胃口的项目。他暂时接受了。

后来公司举办创新大赛,他领头的项目没有获奖,但进入了决赛。他要求继续这个项目。我同意了,可明确的告诉他,此项目非公司当下的重点,团队不会给你强有力的支持。

没出一个月,他告知我新机会妥了,要辞职。这个决定,对他对我都是一种解脱。

他是我第一个离职的下属,给想至善至美的我,一个很大的启发,做管理,看中的不能是人头的数量,而是留下该留的,送走该走的。对留下的,像《绝对坦率》中所说的那样,深深在意但要严格要求,对离开的,打心底祝福他们会更好。

该自学计划的目的是获取商业组织中管理和领导力的专业技能。一是好奇心驱使,二是为了长久之计,在我决定从程序员转型管理后,而准备执行的一个全面系统的学习计划。

此计划三个部分,基础课,技能课,专项课,像金字塔一样底层覆盖面比较宽,越往上越专业化。鉴于时间和资源的限制因素,所有课程均为Coursera在线课程。以后并不排除到学校学习的可能性,毕竟自学起来,在关系和人脉的培养上会大打折扣。

此学习计划主要来源于《Don’t Pay for Your MBA: The Faster, Cheaper, Better Way to Get the Business Education You Need》。

Foundations courses

Skill-building and elective courses

Concentration courses

当你春风得意,把团队越带越大的时候,会遇到新的挑战,面对繁杂的事务感到分身乏术。然而,你的精力是有限的,因为你摄入的卡路里就那么多,作为团队的领导者,在哪些人和事上,避免分配你有限的精力?答案是不要尝试打开一个你尚且没有钥匙的锁。

一个没有钥匙的锁,会白白耗费你的精力,不仅当下的锁打不开,还耽误了你开启那些你已经拥有钥匙的大门。这个钥匙,有可能在别人的手里,也有可能在时间的手里,只是你太着急没有看到。下面通过两个例子说说。

作为程序员们的扛把子,不应该硬钢一个跑了下属的光杆产品总监。与其挑战Ta让Ta通过收集用户反馈解释产品的设计动机,不如给Ta充分的时间,让Ta招到一个得力的助手。Ta一个光杆总监不可能把所有的事都干了,与其你们僵在那里,不如在已有的解决方案上进行一些微调。一是产品仍朝着好的方向上进展,二是为新来的助手争取时间。这里的锁,就是产品的调整方案,你误以为钥匙是督促产品收集用户反馈,其实是你们缺少人手,花费再多的口舌,也还是得等到相关人员到位。

另外一个例子就是问题下属。下属Ta抱怨你给Ta找不到能实现Ta远大抱负的任务。你耗损许多精力,一是和不同的老总找项目,二是苦口婆心的给下属做排解。可是到头来,找到的小项目还是不够挑战。这里的锁,是公司没有适合下属的任务,你以为钥匙是努力的找肯定能找到充满野心的项目,其实是公司做了战略调整,出现了大的人士变动,你的下属正好是因此而落的处境尴尬的人。你在Ta身上花了精力带来不了大的收效,反而耽误了你指导核心位置上的核心下属。

精力不要花费在一把你没有钥匙的锁上。虽然我们未必一下子就能辨得出钥匙在哪里,但是一定要在你大费周折之前看看你的手里,有没有开锁的钥匙。

0%