职能资源池的经历分享

前言

相信很多公司有曾经一段时期甚至本来就是公司的组织以资源池的形式存在,当然目前更多的是以项目团队的单位或者业务存在。

曾经我也找几个比较资深的大佬讨论过类似的问题,基本是基于业务分团队比较具有优势的。但这并不意味着,生活中或者任何团体都是以业务线划分的,更多的是两种的混合体。而我们见到的最多的还是以资源池的形式存在的,也是以资源池的形式进行上行和下行的管。

概念

当某一个资源使用完后,资源池把相关的资源的忙标示清除掉,以示该资源可以再被下一个请求使用。

基本了解

资源池引入的目的

提高性能

资源池运作机制

由资源池管理器提供一定数目的目标资源,当有请求该资源时,资源池分配给一个,然后给该资源标识为忙,标示为忙的资源不能再被分配使用,

资源池常有的参数

1.初始资源的数目:资源池启动时,一次建立的资源数目,资源池最少要保证在这个数目上
2.最大资源的数目:当请求的资源超出这个数目,就等待
3.常见的资源池:数据库资源池,web容器中的对象池,web容器中的线程池

人员的资源池

那么类似其他资源的资源池,对于以职能为划分的公司或者部门也可以看为一个资源池,那么如何有效的发挥一个资源池的最大机制,避免人员浪费成为了一个很多管理者必须重点考虑的问题。

资源池的优势

成长优势

资源池的优势更确切的说是聚合的优势,当同一职能的人聚集在一起时,会有更多的理解与共识,能形成互相的专业知识的、职业成长的各方面的互补、成长关系。也可以通过通过同一个主管、同一套成长激励体制得到更好的成长。

很多人也许会说,如果说互补,不应该是不同职能的互补更多么?肯定是不同职能的互补更多,但我想说明的一点是,在我们职业成长的初期,对自己专业技能的学习和提升要比其他周边技能的提升更为重要。所以我个人观点是,如果刚进入职场,最好是先通过同职能的团队或者大咖环境中,先把专业的技能提升到最佳,因为如果连自己的专业技能都无法通过一定的方式得到很好的提升和巩固,那其他职能的更是只能得到皮毛的认识了。

资源池优势

与项目周期绑定相比,资源池具有更高的机动性,对比在以下方面。
– 资源利用率高。项目周期不一定实时都是忙碌的,那么在项目周期的空档时,如果资源挂在项目下,其实资源是浪费的,但这时明明可以安排其他任务。
– 提供更为完整、统一、正确的职能解决方案。人员挂靠在项目或者团队下,久而久之会与其他的同职能人员疏远,对于专业的技术技能以及基本观点存在不同步甚至严重的落后,而如果是落后的话,不但影响个人的发展,也会因此导致不同团队或者业务的完整质量不同,导致的对外不一致性,严重的会出现质量问题。而如果挂靠在资源池下,大家就会统一认知,有比较统一的解决方案和认识,对于团队中每个人的技术长处和积累可以达到吸取群体智慧。
– 职能部门级别的解决方案。针对很多共性问题,耗时的问题,职能部门可以给出更为完善的解决方案,而非仅靠一人之力给出相关的建议。

资源池短板

  • 业务熟悉不够,容易经常被调动,成为救火人员
  • 对其他职能或者经常被调动的团队成员找不到互补、分享提升的有效途径
  • 不能对某个业务需求形成更为完整的方案

我的经验和观点

按照人员的项目经历优先分配

原则:
1.项目的二期或者bug或者优化,大家都觉得应该是交给原来的人继续去完成;
2.新项目或者完整的新需求,需要界定需求的总体工作量以及难度,分给对应能力的人完成。
那么这里面的原因主要是:
– 对于默认的代码,包括业务熟悉、代码风格熟悉、代码设计的程度等不同人都是不一样的。如果一个其他人重度设计、并且是重业务的功能交给一个完全不了解这块的人,其在没有开始写代码之前需要耗费最少20%的时间去熟悉代码,熟悉原先的功能,然后了解代码改动对原来的部分造成的影响,然后确定好这次要具体修改的代码是什么,所以这种情况下,大家觉得这种原先是某人完成的工作还是最好固定到某人继续完成。
– 而针对新需求,也需要大家形成统一的建议,由主管还有大家统一开会确定每个需求需要的工作时间,难度以及由谁完整最为合适,而不是随机分配,无视每个人的能力差别、经历差别、主管意愿。

按照业务线划分

经过长期的业务稳定以及团队稳定,相信大多数公司都能形成自己的业务线或者开发团队,那么这种时候我个人建议是弱化的资源池形态。具体操作如下:
0 列出职能团队下,部门内的人员分布以及技术储备,也就是上面提到的资源初始数目,以及最大的资源数
1 人员常态情况下都是驻扎在具体的业务部门或者开发团队下,方便业务或者团队需要时,随时准备。
2 资源池形式的存在仍然是必要的,主要是向职能主管汇报其业务线内的工作情况,包括收获、反馈以及跨职能的协作情况,并且完成职能内的统一的培训、指导、团建等。
3 同一业务线内的要善于积累经验,针对业务的定向经验,这样可以避免来回调整带来的经验无法沉淀的问题。另外,如果资源允许的情况下,建议每个业务线设置小组长,然后形成AB角色的互补关系,互通有无,也可以在个别人请假的时候完成紧急的一些需求。
4 整个职能内的经验互通。基于第3条,我会安排部分成员在某个业务线,或者某个端比如说小程序或者网站端觉得已经没有什么提高的必要时,让其进行完整的分享,然后到另一个业务线完成对应的学习和提升,来帮助大家更快更全面的成长,也能给自己在不换公司的情况下,更多的适应一些业务和团队,得到更多的成长。

划定边界

进行过项目开发的人,大多都知道在一些初步搭建的团队,很多开发周期都无法准确的保证,其实不仅仅是开发周期,就连开发上线的需求总数、需求完成的质量也无法量化。那么,在整个开发团队无法完整时的过渡时期,职能团队可以在主管的带领下完成对所有需求的定量、定性分析,针对需求总量的所需时间、开发所需的难度进行更为准确的边界以及变化范围,那么在这种情况下,在某个职能的范围内,最少给出的回复以及成果是可度量的。

那么划定的边界到底是指那些内容呢?

开始边界

  • 提供到该职能下的需求需要符合什么样的标准才算合格的,可以开始安排具体的工作
  • 与该需求相关的人员以及相应的节点分别是什么,是否确定
  • 与该需求相关的期望节点,期望需求,可变动需求谁负责,项目经理还是产品还是测试
  • 目前资源池内的资源谁是空余的,可以在什么时间开始这项工作
  • 针对过多的需求变更,需求细化,不保证量和时间同时达标

工作内容边界

  • 基于确定的可度量的需求,给出职能内能够给出的成果案例,达成初步协议
  • 对于可能出现的差别、风险预先告知
  • 对于协议的内容,保证在规定的时间内给与交付和通知
  • 如果工作内有风险和变数,随时通知,能得到团队的进一步的方案
  • 针对不确定的内容,提供可能的方案,替代方案等

重要时间节点

  • 开始的时间节点,进一步需求确认的节点,项目立会
  • 开发中几个重要的里程碑节点的时间节点
  • 联调节点,各个职能完成对应工作时的协作
  • 提测节点,功能完成时,提交需求职能或者业务方验收
  • 预发布节点,发布节点,功能基本完成,可以达到发布质量的节点
  • 发布节点,运营节点, 功能正常开始之后,后续的一些问题或者优化,进入短期的观察运营时间段。

文档、协作

无论我们多么强调主动性,文档对大家的重要性,其实大多数人还是做不到积极主动的去做,但大家能达成一个统一的认识就是:都认为这个是有意义的,并且愿意通过一定的习惯让我们这部分的效率变高。

于是我们达成了以下的协议,效率得到了质的提升。
– 针对不同项目通过多个同步文档,让每个人可以同步的查看到整个职能团队内的人员负荷情况和时间档期。
– 针对每个个人确定了长期的、短期的成长计划,学习计划,可以通过对应的工作、以及对应的档期安排完成这部分的目标
– 整个前端内共享一系列的文档、技术常识、技术观点
– 形成一带一的成长机制,互帮互助,互相提升
– 针对积极负责的人,无论是否有下属组员,足够放权,能积极完成工作的前提下给其对应的权限,主导并负责相应需求的交付;对于认为自己还不足以负责,或者觉得自己不擅长做沟通的人员,职能上还会给与其沟通、协作等方面的帮助。
– 反馈机制,由于我们达成了高度共识,所以大家在有问题时,可以说是及时的向上反馈、向需求反馈,避免了很多项目到中后期才出现可能会延期的风险。另外针对需要跟踪的同学,我们会给其具体的时间点跟踪,针对每天或者每个小细分的需求,都去跟踪是否完成,是否有问题,然后给出其建议以及方案。
– 准确的时间共享。由于自己实行了准确的番茄工作法,所以在我的带动下,团队内每个人都建立了自己基于工作的时间计划,针对自己每个节点做什么,是否会请假,自己都会严格的记录到上面,这样即使大家什么沟通也不做,也足以明确每个人在做什么,是否有一些个人事务的安排。

更好的利用优先级

相信很多人知道优先级这个概念,但实际上其实很多团队成员是钻了项目档期的空子。我们很多时候会定义需求的优先级,然后按照优先级去对应的按照顺序完成对应的事情,没什么问题。

问题出现在当优先级为1的事情,如果因为某个原因发生了停滞或者一定的空档期,我们的团队成员会如何做?

对于敏捷团队几乎不存在这个问题,即使存在也最多存在一天,因为在每天的例会上,如果基于大家足够透明的汇报机制,基于某个人某个节点正在空档期,我们会安排资源进行立刻的纠正,纠正包括安排资源辅助完整或者调整优先级或者安排做其他事情。

但更多团队是不调整这种情况的,因为很可能是这种情况是大家默认的必然会占用时间的,尤其团队在没有更高效的运行之前,可能无法更新自己的认知。

那么我个人的建议是大家无法短时间革新自己的认识,去变革团队时,可以做到的是:
1 积极的去衡量固化这些空档的时间,吧这些时间积累下来
2 针对自己一段时间内做的事情,进行分类,包括可以独立进行的,以及需要依赖他人的工作。
3 针对自己所做的事情列优先级
4 具体的调整,针对当前正在做的事情,肯定是优先级为1的,那么针对1的档期,可以安排同为1或者2的事情去具体继续,但不建议同时在1的档期安排2件以上的事情,这样真的只是骗自己,最终做成的事也不会超过两件。需要注意的是,在档期做的事情一定要是2里所整理的,可以独立进行的工作,不要在档期其再去安排依赖其他人的工作,这样你会陷入无限等待他人的队列中。
5 针对档期做的事情,做到不保证完成,但要保证进度,可以完成其另外需求的一定具体进度的完成也就是需求燃尽图是有变化的。
6 针对提前完成的优先级为1的时候,要马上主动开始另外的优先级为12的事情,不要等其具体的节点才开始任务,那样就还是存在档期、资源浪费的问题。

资源池管理分配技巧

1. 根据优先级分配,同等优先级先进先出

2.同等优先级,同时进入,找需求方确定具体先后,找有决策能力的人进一步决策

3.资源满的情况下,存入等待队列

4.紧急需求,临时需求,需要抽调人员

联系对应需求的负责人,沟通确认、确定两者的关系,延期风险

5.人员借调

在某需求临时需要多人时,建立合理、完善的资源调整体制,以及对应的总体负责人,谁负责整体的细分任务分配

小结

关于同职能的资源池管理,个人就先分享这些,希望能给大家带来一些有益的帮助。

发布者

Robinson Zhang

热爱前端,热爱分享,坚持高频写作,从小白到大师只是时间问题。