3

前言

可能大家看到【工作效率】,第一时间会想到是编码技巧、开发环境、效率软件、vscode 插件或者开发环境、CI/CD。

不不不!

以上那些确实可以提高业务的生产效率,应该说是每个程序员的必备本领,属于技术能力范畴,也叫硬实力。(这块有时间另开一篇分享

不少程序员,特别是初中级的常有个误区,就是只要技术牛逼就行了。其实不然,但业务越复杂牵扯的人越多,软实力就关键。

本篇分享是有来由的,故事要从前些天的需求方找我诉苦说起。

简单介绍下本团队,大概十几人,初级前端较多,采用梯队管理设立两个小组长分别管理他们

前些天,A B 两个项目的需求方先后跟我投诉某个小组长项目进度延期。按说对应的需求技术难度并不高,没理由延期太久的。

于是我拉上了需求方、前端开发负责人、服务端、原始数据供应方等相关人员开了个复盘会。 在复盘后发现,其实影响进度的不是技术,而且跨组协作上的问题,

**总结了以下几点:

  1. 开发对业务理解不足,部分功能实现后返工修改
  2. 沟通能力不足,造成误会和无效等待
  3. 小组长任务分解和管理能力不足,资源调度不合理
  4. 个别成员责任心不强,抱着 xxx 不是我负责,我不管的心态**

提炼出关键字后,是【业务理解能力】【沟通能力】【管理能力】【主人翁意识】。这些都是软实力,并不容易量化考核。

作为团队 leader 显然不能对这些问题坐视不管,那怎么去提升这些能力呢?

有句话叫老生常谈,很多理念和方法论大家可能都听过,但并没有真的认可和执行它们。

所以我要做的就是通过集体培训、单聊、设定相关目标、推荐工具和方法论等形式,去不断强化大家的思维。

抛砖引玉,以下是我做培训的思考总结:

提升对象 / 能力纬度:

小组长组员
业务理解能力业务理解能力
管理能力执行能力
沟通能力沟通能力
总结能力总结能力
主人翁意识主人翁意识
任务推进能力

提升方案

-对组长 - 单独交流
在平常的工作中刻意化强调这些思维,传输思想认识

-对组员 - 集体培训
对组员其实也可以一对一交流,不过高频率会占用很多时间,培训、分享会的时候去讲这些也是不错的方案

-制定要求及任务
分析和总结能力,可以一定程度反应在需求文档和技术总结上。

-验收任务完成情况,作为绩效一部分
加入奖惩制度,可以提高大家的积极性。软实力考核可以依据需求技术等文档、需求方投诉、任务质量和进度等方面

提升方法论

业务分析能力提升

如果没法清晰理解需求/bug 的时候,可以试试 5W1H 分析法 ,问问自己下面这些问题,逐个寻求答案后再连串起来

5W1H 分析法
bug需求
what什么问题,影响如何什么需求,价值在哪
where哪个环境,哪个模块哪里需要
when何时发生,触发条件何时需要
who相关人员是谁相关人员是谁
why原因是什么为了什么
how如何解决如何实现

目标管理能力

人脑不靠谱,请及时记录信息
当然每个人的习惯不一样,有的人喜欢用文档,有的人喜欢写纸张上。而我喜欢纸张打草稿,然后关键信息记录到文档里。

草稿也不是胡乱涂画,这里我推荐一页纸工作法,辅助刻意化培养思维逻辑。

一页纸工作法


(图片来自网络)

当然,不需要画的这么漂亮 :)

Notebook 便签

便签用于记录一些事项的概要,个人的 todolist,可以时不时看一眼。

提高沟通能力

推进事项、减少误会

沟通的本质交换信息并达成共识

沟通通常来说,有两个场景,即发起沟通方接收沟通方

发起沟通方

【提前梳理好内容】

  1. 明确自己的意图和期望
  2. 信息完整,需具备时间、地点、人物等要素
  3. 组织好语言通顺性
  4. 考虑好对方可能的提问,并做好回答准备
发起沟通方接收沟通方
直接对话【提前梳理好内容】
1. 明确自己的意图和期望
2. 信息完整,需具备时间、地点、人物等要素
3. 组织好语言通顺性
4. 考虑好对方可能的提问,并做好回答准备
【提取重点】
1.对方意图和期望
2.时间、地点、人物等要素
3.不可自己猜测对方意图
4.不做没把握的承诺
5.不替他人回答情况,除非你真的了解
文字沟通【同上】
关注回答情况,如果对方长时间未响应,及时跟进
【同上】
避免已读不回

项目管理平台

诸如禅道、ones、tapd 之类的项目管理平台,做好以下几点,也有利于减少沟通和团队管理成本(每个团队都有对应的规范,这里就不展开讲了):

  • 迭代管理做好分类
  • 需求、缺陷描述要清晰
  • 进度、状态及时更新


ccfnever
377 声望22 粉丝