提升心力：摆脱拿着锤子看啥都是钉子

Mon, 30 Aug 2021 08:05:00 +0800

从程序员到一个团队的管理者，这中间需要经过一次又一次的蜕变，最终才能变得处理任何事情都得心应手。

韩非子曾说：下君用己之力、中君用人之力、上君用人之智。大部分的管理者可能都处在用人之力的阶段，并向着用人之智前进。最近看了一些关于管理的视频，提到了更高维度的用人之心和用人之愿，如果能做到，那必定会是一支战无不胜的团队。

关于增效，需要做好这两点

Tue, 06 Apr 2021 08:05:00 +0800

最近两会上都谈论到 996 的问题了，那我们实行 996 ，每个人每天都非常忙碌，是不是就效率很高呢？是不是很多时候都在做一些无价值的事情呢？是不是都在加着班写着 Bug 呢？我认为真相远没有我们想象的那么乐观。

春节后的几次公司会议上都在提「增效」，随着公司的发展，人数变多，各种成本也随之增高，所以通过各种方式来增效，才能有正向的发展。以目前我的观察来看，我觉得可以从两个方面入手：沟通和抓住关键点。

在《怎样提高开发效率》一文中主要说的是开发人员硬技能方面的提升，在上面提到的各种成本中，沟通成本是非常重要的一块，这属于软技能的范畴，也是最容易被忽视的。

沟通体现在很多个方面，这里主要想说下提问和 Bug 描述。

前不久，有项目团队同事在企业微信上问我：怎样拉取镜像来进行测试环境的更新？如果考虑到部门之间应该有良好的沟通的协作，我应该告诉他怎么操作，但为什么有这么低级的问题能被问出来，是一个值得思考的问题：

所有有章可循的、都应该形成规范，进行培训、然后考核，保证不同的人按照文档进行操作能够得出相同的结果，如果有开发人员能主动去探究其中的原理并举一反三，那便是锦上添花了。

对于 Bug 描述经常会出现这样的场景：

实施人员：表单上的选人控件加载部门树很慢；

开发：经过一系列的代码检查、运行调试后回复，我本地很快啊；

开发人员时间花了，但并没有解决问题，在描述 Bug 的时候，需要有更详细的场景和上下文信息，比如：

有了更多的信息，开发人员就能有针对性地进行排查，也能更容易解决问题。

Bug 只要能重现，处理起来还比较容易，当遇到偶发 Bug 的时候，更是要尽量提供足够的信息，但很多时候描述却是这样的：

实施人员：客户点击某某操作时，会出现系统异常，我们有时操作也会出现，但不是每次都出现；

开发：不能重现，我怎么排查呢？

实施人员在一线，离现场更近，能知道更多的信息，所以在出现问题时需要尽可能多地提供信息：

如果每个一线实施人员都能够去收集一些有用信息，做下初步的分析，然后将整个过程形成文字内容提交给开发，相信会大大提升解决问题的效率。

至于收集哪些有用信息，怎样来做初步分析，随着慢慢地沉淀，也一样可以形成标准的文档和操作手册。

除了沟通，另一个能提高效率的地方就是在工作中能抓住关键点，根据二八法则，抓住 20% 的关键点就能解决 80% 的问题。

下面是最近团队中发生的两个个事情，正好说明了关键点的重要：

产品代码做重构优化，让开发人员按照思路写出类以及空方法，然后进行评审，但开发人员会比较容易关注细节，一动手就想着对象怎样映射，依赖注入应该怎么进行设置等等，浪费了时间；
让开发排查一个 Bug，我便开会去了，一个多小时回来询问情况，得知还没有解决，还在继续调试代码分析原因，最后发现是一个配置项没有添加导致。

第一件事情的关键点是代码的思路，而不是实现，开发人员和产品负责人的目标和思想需要一致，也就是华为管理哲学中所说的「力出一孔」，如果方向偏了，努力越多，错的越远。

第二件事情的关键点是遇到问题的思考，想清楚之后再动手做，最终的做可能是检查配置、寻求其他人员帮助、或者代码调试。而不是任何问题一上来就进行代码调试。

最后总结下：

1、沟通在工作和生活中无处不在，想想沟通的目的，多换位思考；

2、除了上面说的提问和 Bug 描述，还有代码注释、代码提交备注、技术规范文档等等都属于沟通；

3、方向一致、目标明确做起事来才能最高效；

4、多思考、总结、复盘才能慢慢积累经验，经验丰富了才更容易找到关键点。

希望本文能对您有所启发和帮助！

Sun, 28 Jun 2020 12:06:25 +0800

每个技术人员最终可能都会走上管理岗位，从最初的开发 Leader、到部门负责人、甚至到 CTO,这每一个角色的转变，都需要付出巨大的努力去进行思维的转变。最近读的《授权》这本书可以让我们更好地胜任管理这个岗位。

Thu, 31 Oct 2019 06:47:16 +0800

近几年面试了不少新人，当问到职业规划时，大多都会说先积累技术，然后往架构师的方向发展。这可能是技术人的一个特质，喜欢跟机器相处，沉浸在代码之中，而不喜欢跟人打交道。