为什么需要效率督查团队

前言

上周和杭州某司同学面基,发现我们两同一年毕业,同一年出生,还是老乡,真是颇感意外。本来约好了是聊技术的,结果硬生生的聊成了如何提高团队效率的心得交流会。

最后得到的结论也非常一致,无论我们如何努力,最核心的优化目标就是【效率,能用最快的的时间响应和解决需求】,无论是支撑业务,还是努力发展创新,帮助公司一起寻找新的增长点。

人员扩充和平台建设的副作用

团队发展,很大的一个问题就是会变大,变大的副作用是什么呢?

  1. 小组自成一系,开始形成孤岛,同一问题反复在多个小组重复解决,信息闭塞
  2. 小组开始变多,协作成本开始剧烈提升
  3. 人员增多后,隐藏问题有了更好的生存空间,各个小组容易进入佛系状态,按部就班,不思进取。
  4. 原来的管理者已经难以细节化管理,对很多组的很工作流程细节已经失去掌控力。

其实如果你仔细去看看各个组,你会发现,有惊人多的工作流程是可以优化的。这里我们举一个案例:

G君每日会统计一个表格,然后运营每天会向G君要,G君写好了一个程序,只要点击一下,几秒就算好了,接着他需要手动下载这个生成好的文件,然后邮件发送给运营。

这个流程大概会耗时多久呢? 可能五分钟吧?然后运营可能每天要花几秒想到这事,然后开始问G君,然后心里一直需要记挂着这事,等着G君给,对运营也是一个损耗。G君如果有很多类似的这种小任务,可能一天会被占去1小时。假设一个部门有50人,大家的状态都差不多,那么一天被消耗的工作时间就非常可观了。而且这个过程,其实是没有人满意的。

那为什么G君不做成自动化的呢?比如定时发送邮件给运营。G君是个资深程序员,他当然考虑到了。大家往往会忽略一个问题,平台化是很多程序的致力的方向,但是平台化带来的副作用也是相当可观的,*** 就是平台化很大的制约程序员的灵活性 ***。如果G君无法在现有平台功能的基础上顺利解决这个问题,那么就意味着它要开发一个定时程序去调用平台得到结果,然后生成一个下载链接,最后把下载地址发送邮件出去。G君完成这个程序可能只要半小时,但是为了能让这个程序真的Run起来,他要接入到jekins流程,他需要向运维申请资源,他还需要申请授权访问平台接口,他还要去问邮件系统相关的事情。这期间的任何一个都可能会消耗掉他一天或者半天的时间。当然他也可以去推动平台帮他完成这件事情,但是排期可能就到下个月去了。 G君可能会权衡再三,选择这个对他来说最快的方式,但长远角度可能会难以为继极度影响他价值发挥的方式去做这件事。

我们仔细分析下这件事情,痛点在这么几个点:

  1. 研发觉得跨组协作和推动太难,而且他们其实真的不愿意做这件事情。
  2. 平台化会在其覆盖范围内提高效率,但是一旦平台无法满足的地方,反倒会阻碍效率。
  3. 不同组的孤岛,以及各组的平行角色导致他们无法更好的协作,虽然对于管理者而言,天天强调的就是协作,协作,高效协作。

解决方案

说白了上面的问题核心是陷入了局部最优解,那么就一定需要有个全局的组去负责连接。而负责连接的角色,就是我这篇文章提到的【效率督查组】。

效率督察团队核心能力是推动,连接,同时具备撸起袖子帮忙干的能力。
日常工作时看哪里不顺眼,抽象总结捋顺流程,并且平台化
这里一定要注意一个误区,不是看到问题就开发新工具,而是帮助有问题的团队剖析问题,梳理流程,提出长短期解决方案更重要。

比如对于前面提到的问题,我们怎么解决呢?因为效率督查组的人知道全局的信息,当他看到G君的这个情况时,很快就在脑海里复盘了各个团队已经有的功能,这些功能如何整合解决G君的问题,同时可能还欠缺哪些功能需要去开发,以及哪些团队可以从他们解决了G君的问题流程中同时也会受益。

最后方案如下:

G君已经在平台实现了点击一下,就能算出结果的能力。但是无法把结果投递出去。效率督查团队发现 :

  1. 研发组已经有一个根据文件目录生成下载链接的功能,并且具备时效性等多种功能,同时研发组还把这个功能集成到了平台上。
  2. 平台组有定时任务调度系统,并且也已经集成到了平台上。
  3. 运维组已经有发送邮件服务的Server,只要通过smtp协议就行。

现在,G君其实已经能产生结果,并且生成下载链接了,就差如何往运维组的邮件server发送了。
找来平台组的同事,让其在平台上开发一个模块发送邮件。效率督查组已经评估了这个模块的开发难度,要求下午就需要提供该功能。

至此,G君基本以0成本模式完成了原先在他看来遥不可及的诉求,效率督查组也顺利的优化了G君的问题,让G君可以完整的空出这个五分钟。同时,效率督查组也发现另外一个团队也经常有执行脚本,然后将结果转化成下载链接,通过邮件或者其他信息手段发送出去的诉求,从而实现复用。

结束语

效率督查团队可以有效的解决前面提到的四个问题:

  1. 小组自成一系,开始形成孤岛,同一问题反复在多个小组重复解决,信息闭塞
  2. 小组开始变多,协作成本开始剧烈提升
  3. 人员增多后,隐藏问题有了更好的生存空间,各个小组容易进入佛系状态,按部就班,不思进取。
  4. 原来的管理者已经难以细节化管理,对很多组的很工作流程细节已经失去掌控力。

唯一的缺点是,效率督查团队的要求太高了,他需要一两个组员就能cover住整个部门的一些细枝末节,而且具备足够的经验,能将这些细枝末节拼接成一个完整的拼图,解决痛点,进一步加速实现:

提升研发团队效率,能让他们用最快的的时间响应和解决需求

下载方式:https://pan.quark.cn/s/a4b39357ea24 布线问题(分支限界算法)是计算机科学和电子工程领域中一个广为人知的议题,它主要探讨如何在印刷电路板上定位两个节点间最短的连接路径。 在这一议题中,电路板被构建为一个包含 n×m 个方格的矩阵,每个方格能够被界定为可通行或不可通行,其核心任务是定位从初始点到最终点的最短路径。 分支限界算法是处理布线问题的一种常用策略。 该算法与回溯法有相似之处,但存在差异,分支限界法仅需获取满足约束条件的一个最优路径,并按照广度优先或最小成本优先的原则来探索解空间树。 树 T 被构建为子集树或排列树,在探索过程中,每个节点仅被赋予一次成为扩展节点的机会,且会一次性生成其全部子节点。 针对布线问题的解决,队列式分支限界法可以被采用。 从起始位置 a 出发,将其设定为首个扩展节点,并将与该扩展节点相邻且可通行的方格加入至活跃节点队列中,将这些方格标记为 1,即从起始方格 a 到这些方格的距离为 1。 随后,从活跃节点队列中提取队首节点作为下一个扩展节点,并将与当前扩展节点相邻且未标记的方格标记为 2,随后将这些方格存入活跃节点队列。 这一过程将持续进行,直至算法探测到目标方格 b 或活跃节点队列为空。 在实现上述算法时,必须定义一个类 Position 来表征电路板上方格的位置,其成员 row 和 col 分别指示方格所在的行和列。 在方格位置上,布线能够沿右、下、左、上四个方向展开。 这四个方向的移动分别被记为 0、1、2、3。 下述表格中,offset[i].row 和 offset[i].col(i=0,1,2,3)分别提供了沿这四个方向前进 1 步相对于当前方格的相对位移。 在 Java 编程语言中,可以使用二维数组...
源码来自:https://pan.quark.cn/s/a4b39357ea24 在VC++开发过程中,对话框(CDialog)作为典型的用户界面组件,承担着与用户进行信息交互的重要角色。 在VS2008SP1的开发环境中,常常需要满足为对话框配置个性化背景图片的需求,以此来优化用户的操作体验。 本案例将系统性地阐述在CDialog框架下如何达成这一功能。 首先,需要在资源设计工具中构建一个新的对话框资源。 具体操作是在Visual Studio平台中,进入资源视图(Resource View)界面,定位到对话框(Dialog)分支,通过右键选择“插入对话框”(Insert Dialog)选项。 完成对话框内控件的布局设计后,对对话框资源进行保存。 随后,将着手进行背景图片的载入工作。 通常有两种主要的技术路径:1. **运用位图控件(CStatic)**:在对话框界面中嵌入一个CStatic控件,并将其属性设置为BST_OWNERDRAW,从而具备自主控制绘制过程的权限。 在对话框的类定义中,需要重写OnPaint()函数,负责调用图片资源并借助CDC对象将其渲染到对话框表面。 此外,必须合理处理WM_CTLCOLORSTATIC消息,确保背景图片的展示不会受到其他界面元素的干扰。 ```cppvoid CMyDialog::OnPaint(){ CPaintDC dc(this); // 生成设备上下文对象 CBitmap bitmap; bitmap.LoadBitmap(IDC_BITMAP_BACKGROUND); // 获取背景图片资源 CDC memDC; memDC.CreateCompatibleDC(&dc); CBitmap* pOldBitmap = m...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值