最近团队有两个需求做的比较失败。说失败，主要是项目延期很严重。今天召集产品，研发和测试人员一起做了下复盘。在复盘的过程中，发现导致延期的核心因素并不是技术能力的问题，而是研发能力之外的软能力。下面我和大家一起聊聊想要成为一个合格的研发，都需要哪些软性能力。
01 沟通能力
有人的地方就有江湖，人在江湖哪能独处。虽然研发人员更多的是电脑打交道。但是，研发人员在日常的工作中不可避免要和很多人沟通。比如和产品沟通产品需求，和测试人员沟通测试问题等。要做到有效的沟通是很重要的。否则，鸡同鸭讲，大家都比较痛苦，也无所得。
那么，如何做到有效的沟通呢？
和正确的人沟通。比如，上面提到的需求中，其中一个失败的原因之一就是沟通问题。在这个需求产品是一个刚入职的产品经理，对业务不是很了解。研发人员入职了几个月，对这个需求相关的业务也不是很熟悉。只有测试人员是老员工，对业务比较了解。产品经理为了设计产品方案，找测试人员了解业务逻辑。研发人员根据产品经理的文档搞研发，向产品经理了解业务逻辑。最后，测试人员测试的时候发现业务逻辑不通。研发人员沟通的问题在于没有向正确的人沟通正确的事情。他应该向测试人员了解业务逻辑。而不是按固有流程一味的听从产品经理的讲解。毕竟信息在传播的过程中总必可避免的有些失真。
在一个频道上沟通。经常会有人说，和某某沟通很费劲，根本不在一个频道上。其实，就是两个人沟通的内容不是聚焦在一个问题上，而是各自将自己的事情。比如，测试人员给研发人员反馈一个问题，研发人员很快给测试人员解释这个现场出现的原因。搞得测试人员不知道研发人员是认可这个问题呢？还是感觉这不是一个问题，在辩解呢？另外，在一个频道上沟通，也要见人说人话，见鬼说鬼话。说让对方更容易听懂的话，尽量不要说对方不懂的专业术语。
另外一个沟通的小技巧，就是先说结论，再解释，方便对方很快明白你要表达的观点。经常遇到一些同学，一上来就吧啦吧啦说一通，也不知道他最终想要说明啥。
02 评估能力
我工作十几年，经历过四五家公司，在每家公司都会发现勤勤恳恳干事，而没有得到很好回报的同学。导致这种情况的原因很多，其中一个原因就是这些同学做事不评估，不思考，不分轻重缓急。
要知道事情是永远做不完的。即便是时间充裕，事情也有轻重缓急。二八原则大家应该都听说过。只有百分之二十的事情是重要的事情，而这百分之二十的事情会产生百分之八十的收益。研发人员的价值不是写代码，而是赋能业务，创造业务价值。把精力投入到少量的重要的事情上，会产生更大的价值。因此，也会体现你的价值。
如何做评估呢？事情这么多，我应该先做那件事情呢？时间管理里面有一个“四象限法则”观念，大家可以了解下。四象限法则就是把事情按重要程度和紧急程度分为四类。我们要优先做，重要且紧急，重要不紧急的事情。选择性的做甚至不做紧急不重要，不紧急也不重要的事情。
重要的事情是指能创造更大价值，带来更大收益的事情。有一些收益价值是比较容易评估的。比如，有两个需求，一个是优化用户体验，一个是每天造成资损的 Bug。很显然，应该优先解决每天造成资损的 Bug。但是，如果两个都是优化用户体验的需求，该如何评估呢？如果自己评估不了，就交给产品经理或业务方区评估，尽量量化。上线后验证是否达到预期。
紧急是指事情时间上的紧迫性。如果不处理，可能以后再也没时间处理了。比如，别人组织的一个会议。虽然时间上具有紧迫性，但是并不一定重要。所以，在参加一些会的时候，要先评估下这个会对自己是否有价值，如果没价值，就可以 Pass 掉。
03 业务能力
所谓的业务能力就是基于对业务的了解能做一些合适决策的能力。业务能力的基础是对于现有业务的了解。如果对于业务不了解就很难去做一些决策。相信大家都有过这样的一些经历，接手一个历史悠久的老系统后，都感觉无从下手。无从下手的一个因素就是，老系统有很多的业务逻辑，不了解的情况下，贸然动手去改，可能会导致补了一个窟窿倒了一堵墙。
对于一个研发人员来说，需要掌握的基本业务知识大概包含如下几个方面：
- 系统功能：人的认知都是由表及里的，系统功能就是表。
- 业务流程：系统是业务流程的体现。深入了解业务逻辑，才能更好的设计系统。
- 代码逻辑：代码逻辑就是一张网。只有对这张网更熟悉，才能避免牵一发而动全身。
- 数据结构：此处的数据结构不仅仅指数据表结构，更多的是指数据之间的关系。
掌握上面的几方面知识，就具备了基本的业务能力。如果想有更强的业务能力，就需要了解更多的业务知识。比如，日常的运营数据，行业某一场景下常见策略，友商的系统架构等。
04 自测能力
自测的能力就是要保证自己有产出高质量代码的能力。不能开发一个功能，带来一百 Bug。代码的质量就是研发人员的门面，高质量的代码会带来更多的信任。自测能力其实是研发人员的一个基本能力，只是有些公司有专门的测试团队，对研发的测试能力要求放低了。在我的团队中，我要求所有研发开发的功能都必须自测才能提交到测试人员手里。这样可以减少不必要的沟通，提高整体研发效率。人与人之间的沟通成本是不小的。如果提交的代码 Bug 很多，会导致整个项目的时间拉长，甚至不可控。
如果公司有专门的测试团队，那么研发人员的自测就不是完全代替测试人员的工作。这种情况下，研发人员更重要的是保证业务核心流程是通的，保证核心流程尽量无明显 Bug。而测试人员的精力更重要的是测试一些异常情况，边界条件。测试人员的测试更多的是专注于功能方面的测试。研发人员比测试人员更了解系统的实现，可以在代码测试，数据层面进行测试。比如，使用 IDE 的 Bug 功能可以测试每行代码的执行情况。
网友评论