当前位置: 首页 > 工程能力, 技术管理 > 正文

谈谈我对研发文化的思考与认知

转眼从2020年8月创业以来,也快一年时间了。这一年里,有很多艰辛与不易,但更多的是成长和认知的收获。我所管理的产品研发研发团队也从最初的3个人发展到了15人的规模,团队里面有各种角色从无到有:产品经理、项目经理、后端开发、大数据开发、前端开发、UI设计、测试和集成&交付的同学。在产品从0到1不断打磨的同时,我的研发团队也是在不断经受考验,不断向前发展和壮大。在研发团队不断发展的过程中,往往因为团队各同学的认知差异,个性差异等导致存在着团队磨合的成本。特别是在新同学进来或老同学离开的时候,研发团队价值观的有效传递对于任何一个团队都存在着不小的考验,而对于创业初创团队尤其如此。

这篇文章将结合我个人带队做产品研发的一些经验与教训,总结我做理解的研发价值观。只有把研发的价值观有效的传递才能保证整个研发团队朝着正确的方向做正确的事情,才能培养出更加优秀的工程师以及吸引更多外部的技术人才加入。在这一年的不断地总结与反思中,我总结出了下面七条我所思考后的研发团队文化。

 

1.以结果为导向,关注个人成长

更确切的讲,上半句“以结果为导向”是我在实习那会儿起,从我的导师也是研发总监那里学到的。在我的第一份工作中,通过近3年的产品研发实践,使我对导师的“以结果为导向”深信不疑。想必这也是导师从BAT等一线互联网公司带来的研发价值观。以结果为导向,看中的是对结果的交付。可能你历经千辛万苦,做了很多设计、规划,加了很多班,写了很多代码,但最终上线交付的却是个不可用的产品,那对于公司、团队和你个人来讲,无疑是巨大牺牲,浪费了很多财力物力。也有可能你经过许多分析、多轮讨论、众多架构设计,最终交付,但也只是做到了90分,离客户满意的95分就差一点点,但对客户来讲,就是没达到标准(而且很有可能客户期待的功能刚好存在缺陷)……凡此种种,失败的理由千千万万种,如果研发团队交付不了产品,那说再多也没有用的。

笔者曾讲过,“研发要对交付负责,产品要对商业化负责。” 研发团队,要以产品的交付为目标,通过各种技术、组织、管理等方面的优化手段,提升整体产出效率,在有限的条件下做出最迅速的产品交付。

既然整个研发团队的目标是产品交付,那作为团队一份子的研发同学,如何才能最大化个人产出呢?我的理解是“关注个人成长”。记得在默安的前老板老聂曾在2016年的年会上大概这么说过,“企业是在不断成长的,企业的成长速度是远大于个人的,而如果个人的成长速度跟不上企业成长的步伐就可能会存在危险。”,无疑,这句话很冰冷残酷,但笔者认为还有另外一层意思,那就是:只有企业中的每个人都在成长时,企业才能成长;企业的成长是每个人成长的叠加效应。

所以,结合我个人这几年摸爬滚打的成长经历,虽然是头一次带十几号人的团队,但我依然认为:只有关注个人成长,才能给企业创造更多价值。这不是一句口号,也应该是研发团队尤其是研发leader深入人心的实践理念。在如常的产品开发中,我们应该建立标准的研发体系,健全研发流程,做到目标管理,帮助每一个人进行自我进化。

 

2.Owner意识,不要对自己设限

这里的Owner意识非常的重要。在我的观念里,研发团队从来不是做项目,而是做产品,给自己做产品。把产品当作自己的孩子一样细心的呵护,培育成长。在笔者两段创业公司对经历中,无一不是把产品当作自己的作品,不断打磨,细心雕琢,才创造出伟大的产品。在产品初创团队中,产品从0到1的创造需要团队中每一位同学都发挥自己的聪明才智,用智慧与真心去创作。而从1到N的过程,更应该如此,在产品的骨架和所有组件都“有了”后,需要做的就是把每一个模块都做到更好,这需要团队中的每个角色都对自己提出更高的标准。所以,从0到1,强调的是“有”,什么功能都已经具备;而从1到N,强调的是“可用”。

但是在实际的开发过程中,可能是因为认知的差异,还是有部分同学没有这种Owner意识(尤其是在创业公司,成员的专业素质和认知能力还有待提升)。他们经常抱着:做好自己的本职工作就行,事不关己高高挂起的想法。他们一旦认为这不是自己的工作,就觉得与自己无关,不要管就行。尤其是那些出来两个环节界定的工作,其实谁做都行,但必须得有人去做。对于创业公司,这种活儿多的不能再多。产品的边边角角、无论是一份文档、一条反馈、一行日志还是一条群消息,都需要有人用“Owner”的心态主动地踏实做好。

笔者始终认为:一个优秀的工程师应该具备很强的“Owner意识”,并以主人公的心态去主动接收新任务、新挑战。用张一鸣的话讲,就是“不要给自己设限”。这句话对我真是太受用了,我们经常困在自己的舒适区,用以往的经验和习惯来思考当下的问题,从而做出不正确的选择。生活中,我们经常听到有人说“这个超出我的认知范围了所以我不行,我做不到”。其实,更多的时候,我们往往给自己画个圈,一旦触及到圈边的东西就习惯性地缩回来,从未让自己变得安全、稳定。人都是善于将自身处境合理化的动物。

所以,饱含热情,积极乐观,并具有强烈的Owner意识,保持开放的心态,不要给自己设限,应该是优秀年轻人的品格。

 

3.理解业务,做好产品

笔者在面试过程中喜欢问候选人一个问题:你是怎么理解技术、业务和产品的?作为一个后端开发工程师,我们每天几乎都在讨论需求、分析业务,并通过技术开发,实现产品交付。那技术、业务和产品这三者之间到底存在着什么样的联系呢?这应该是咱们开发者应该思考的问题。

笔者认为,业务应该是技术与产品之间的桥梁。工程师利用手中的技术,通过分析需求,将需求转化为开发者能够理解的逻辑实现,并利用计算机创造出(软件)产品。

一般而言,一到两年的初级工程师在经过几个研发项目的实践落地后,基本就可以认为达到“理解业务”的水平了。但这并不意味着就已经掌握了理解业务的能力,笔者认为,深入地掌握“理解业务”得再经历3-5年的业务开发与实现,在成为架构师级别后才算是对业务有深入的理解。当然,笔者也是在这条大路上求索。那除了研发工程师外,其他的同学需要理解业务吗?比如产品同学、UI设计同学、测试同学和集成&交付的同学。笔者认为,对于研发团队的所有成员,都需要有理解业务的能力。这也是笔者对新入职同学转正的考核标准之一。在软件研发的整个流程中,都需要各种不同的角色对产品的需求保持高度一致的认知。也理解业务,就是将产品的需求转化为各自不同角色的“业务形态”。比如产品的同学理解了业务之后,才能提出出符合逻辑的设计;UI设计的同学在理解了业务之后,才能选择所处情境、所处行业的设计风格和样式;而测试的同学,在通过需求理解了业务之后才能写出合理、完善的测试case;交付的同学虽然不一定懂产品、懂代码,但如果理解产品的业务逻辑的话,就能够梳理出产品各模块的联系,进而能够科学、合理的部署软件,快速的定位线上的问题,有效地协助研发同学排出问题。

那“做好产品”该如何理解呢?笔者一直强调,研发团队是做产品的,不知做项目的(为了“感化”各位组员,笔者将研发部改名叫“产品研发部”),我们产出的是产品。在《俞军产品方法论》中,作者讲到:企业以产品为媒介与用户进行价值交换。研发团队应该把做产品的理念当作自己的目标,当作是团队的目标,而不是技术,也不是设计、业务或代码之类的其他东西。所以,作为一个开发工程师,我们需要具备产品思维,用做产品的视角,全力、用心地去观察产品的每一个地方,去优化和完善。关于产品思维,可以参考笔者之前写的《谈谈什么是产品思维》这篇文章,这里不再展开叙述。

 

4.暴露问题,及时同步

项目管理的核心是风险控制。作为项目leader,要做到风险控制,就必须要尽早地暴露出可能存在的缺陷。这是一个合格的项目Leader的基本认知。

由于项目开发过程中涉及到众多的角色以及不同的流程阶段,加之需求、技术以及人的不可控性因素,往往很难有效地控制研发流程,即使在项目开发之前做出严密的项目规划。所以,如何在可变环境下保障产品保质保量的高质量交付,应该是一名项目Leader的必修课。而暴露问题,就是在动态变化的流程中,把握“不变”的要素,可谓“以不变应万变”。这里的“不变”就是“问题”。毕竟问题的数量是有限的,尽可能早地找出当前或未来可能存在的问题,就多一分交付的保障。

从公司研发成本的角度考虑,应该在有限条件下,尽可能地降低研发成本。而总所周知,在预定好的规划下降低成本的有效措施之一,就是在项目的早期尽可能地发现问题并解决。通常情况下,如果错误保持到系统架构设计阶段,定位和修复需要要多花成倍的代价,而如果在编码阶段、测试阶段、交付阶段,其花费的代价将成倍增加。

暴露问题的一个重要践行理念就是要做到及时同步和反馈。讲起来容易但在日常开发过程中,真正让每个人都落到实处还是不容易的,尤其是在创业团队或者刚毕业工作的新同学中。除了因专业素养能力而没有发现存在的问题外,大部分情况下,往往是因为害怕犯了错误而受到指责或其他人嘲讽。职场之人,大家往往喜欢伪装自我。尤其是初创研发团队中一些同学的专业技术能力有限,或者新加入的同学彼此不够了解,大家往往害怕暴露出自己的缺点。而刚工作的同学的心理想法也类似,害怕暴露问题,担心因为自己的能力不足而受到指责。在这种害怕犯错误的心理驱使下,即使发现了问题,大家也可能选择掩盖问题或者认为自己可以解决而采用不合理的方法。

所以,及时同步,应该是一名合格职场人的认知准则。记得知乎曾有一个问题「你有什么相见恨晚的知识想推荐给年轻人?」,有答者引用侯小强的话来回答:

在职场里,收到指令要回复,遇到困难要沟通,项目进展要按节点通报,安排要落实。这不是繁文缛节,这是一个公司的基本规范。要尽心尽力,说到做到,有始有终,积极主动,你才能成长,公司也才能成长。不要玻璃心,也不要有惰性,更不要骄横,有多少人,有才华,有远志,不约束自己,最终也不过暴殄天物。

我们经常用“靠谱”来通俗的评价一个职场人的能力。而作为一个团队中的管理者,更希望大家及时沟通与同步,做到“凡事有交代,件件有着落,事事有回音。”那么,作为管理者的我们应该怎么更好的做到这一点呢?笔者认为,管理者应该要鼓励大家暴露问题,及时沟通,多多开导,而不是采用问责的消极方式。更深层的原因,应该从出现问题的“这件事”回归到出现问题的“这个人”身上,做到“借事修人”。

 

5.工程能力,最佳实践

这里讲的工程能力即软件工程能力,也是笔者一直着重关注的(可参考笔者「软件工程能力之思系列」文章)。各大互联网/软件公司对工程能力的重视尤其如此,并且有着自己对工程能力的理解。百度公司在内部《百度软件工程能力定义》中对工程能力的定义为:使用系统化的方法,在保证质量的前提下,更高效率达为客户/用户持续交付有价值的软件或服务的能力。这句话精辟的点明了工程能力的方法论:研发的目的是提供价值和实现价值的持续交付,需使用系统化和科学的方法,强调的是质量第一和持续提升的研发效率。

而华为在全面提升软件工程能力与实践方面,强调的关键是:安全性(Security)、韧性(Resilience)、隐私性(Privacy)和可靠性和可用性(Reliability& Availability)。

对于研发团队而言,在推动落实工程能力之前,需要保证团队内所有成员对上述工程能力的认知保持一致。包括但不限于老板、产品经理、开发、测试、交付和市场的同学,正如华为公司强调的:“全面提升软件工程能力和实践,关乎公司未来的生存和发展,与我们每一个人都息息相关。在此,我希望全体员工、特别是软件工程师们主动参与进来,从自己做起,踏踏实实,共同打造可信的高质量产品。”

作为一名工程师,在使用系统、科学的方法论践行工程能力实践的过程中,我们需要改变行为习惯,追求精品,追求技术的极致之美。古人云:取乎其上,得乎其中;取乎其中,得乎其下;取乎其下,则无所得矣。如果对自己只是中等水平的要求,那做出来的东西必定是下等、基本不可用的。一些大型IT科技公司在用人上也类似的方法,Google公司就是“招上等的人才做中等的事情”。

笔者在做技术方面,始终认为:总有你想不到的更好方法。在时间和能力有限的情况下,或许我们只是按以往经验做出基本符合技术、产品的架构或算法设计,但这一定是最好的方案吗?还有没有更好的方案?如果是顶级专家或顶级公司他们会这么做?在这条技术的求索之路上,唯有追求最佳实践,才能跟上这不断变换的技术浪潮。

 

6.对技术保持敬畏之心

笔者认为,一名具有技术情怀的优秀工程师,应该对技术保持“敬畏之心”。敬畏意味着匠心精神,艺术如此,技术更是如此。面对层出不穷的新概念、遍地开花的新技术,既要以开放的姿态去接纳,还要做到不盲用、不滥用。就如同手握利剑的侠客,应该以正义的价值创造为目标,通过极致的追求,实现自我的技术超越。

敬畏之心,不是畏惧之心。有些技术,或许现在看不懂,不会用,在经历过一段时间的项目磨练之后就“豁然开朗”起来。生理认知学中讲到,学习进展和时间的关系并不是我们想象中的线性关系,而是波浪式上升曲线。几乎任何学习都是在刚开始的时候进步很快,然后变慢进入一个平台期,在平台期,我们可能付出大量的努力但看起来毫无进展。这是因为大脑中的神经元细胞依旧在发生连接,并不断固化,到了某一节点后,就会进入下一个快速上升阶段。所以,那些高深的技术,其底层的都是计算机基础知识。俗话说,高手都在苦练基本功。这也是敬畏之心的隐藏之意。

敬畏之心,也不是傲慢之心。有些人喜欢卖弄技术,整些看起开酷炫实际上并没啥用的东西,或者以“别人不知道的技术”炫耀。正确的认知应该是把技术当作工具,以实现业务的价值当作目标。不应自信过头,想当然的做架构、写代码。笔者向来认为,技术之人,素来谦虚,应对技术保持虔诚之心,既不封闭亦不盲从。

作为技术Leader,应该在研发团队内部建立起对技术保持敬畏之心的工程师文化,深入钻研技术,同时也能让业务、产品认同技术的价值,尤其是认同技术人员的价值,而不仅仅是把技术人员当成是需求实现的工具。让技术团队既能在工程项目中获得成就感,也能跟随公司在业务中获得荣誉感。

 

7.能者居之,能上能下

能者上、庸者下、劣者汰,这一直是大自然的生存法则。在上面的观点中,笔者讲过,公司的成长是每个人成长的叠加效应。而公司为了生存和发展,就必须不断提升内部生产效率。在研发团队中,我们一直崇尚“能者居之”的价值观文化。把合适的人放在合适的位置,才能发挥团队最大的功力。记得吴军老师讲过,团队中往往是一小部分人做出大部分贡献。由此可见,如果靠谱的人没有放到应有的位置,不仅影响团队的产出,还可能导致优秀的人怀才不遇而离开团队。

能上能下这个也很好理解。提拔人,不是因为把那个人放到那个岗位上,他就有那个能力的。而是,因为他具有那个能力,才把他放到那个位置,才展现出了那个能力。“能上能下”的关键在于“能下”。在创业早期团队中,往往因为相应岗位缺人而直接把现有的人放到那个岗位上先“将就应付业务”。而随着架构、业务的不断升级迭代,部分同学因为成长能力有限而无法跟上团队的发展,这个时候应该“能下”。及时调整,让合适的人做合适的事,才能让团队朝着正向的方向上继续发力。

实际项目过程中,这一点还是有些难度。一些人享有“权利”而忽视自己应有的“责任”,导致整个流程阻塞受阻。 所以,需要将“权利”和“责任”画上等号,在产品迭代的整个过程中采用目标管理。营造一种以技术能力为追求目标的价值取向,更容易推动“能者居之,能上能下”的研发价值观发展。

 

笔者认为,所有所谓的研发文化,应当“以人为本”,从关注人的内心需求发展出发。因为,研发文化的背后,是一支优秀的团队。最后,引用笔者所期望的,对优秀团队的价值观定义:

我们是一群勇于创新、执行力超强的年轻人。

我们对技术充满热情,我们相信沟通创造价值,分享带来快乐。

我们不怕失败,我们宽容失败,但我们害怕不作为,乱作为。

我们崇尚克服困难,敢于搞事情,敢于拿结果。

我们热衷于用思想的火花和手下的键盘,做出属于自己的伟大作品。

我们就是那群最耀眼的研发人。

 

 



这篇博文由 s0nnet 于2021年07月24日发表在 工程能力, 技术管理 分类下, 通告目前不可用,你可以至底部留下评论。
如无特别说明,独木の白帆发表的文章均为原创,欢迎大家转载,转载请注明: 谈谈我对研发文化的思考与认知 | 独木の白帆
关键字: ,

谈谈我对研发文化的思考与认知:等您坐沙发呢!

发表评论

快捷键:Ctrl+Enter