打工人逃不开「单人单岗」

」到停不下来,「」到无事可做!


01


年后开始,研发团队一直「单人单岗」;

为什么

就是所谓的追求降本,无非裁员的手段,最终的目的就是让团队的人员结构简化到极致;

虽然符合公司预期,但是与打工人的预期强烈不符;

然而,这不重要

打工人的难处,老板不一定关心;但是老板的难处,打工人必然被关心;

这,才是关键,才是社会;

底线,如果还有一点;

即使企业在承担营收压力之时,还能保持团队的单人单岗结构;

底线,如果没有的话;

还可以玩一手「单人多岗」,比如常说的:人人都是产品,人人都是测试;

为啥没听过人人都是开发,人人都是运维?

专业可替代性的说法,虽然是无脑的舆论,但处处透着精明和算计;

其实,在今年元旦之后;

和职场上的「十多个」朋友聊过,得到一个共通的结论;

上半年,部分中小厂比较普遍的预期都是简化人员结构,从而降低成本预算;

为何是「上半年」?

这里说一句题外话;

特意咨询过组织内的「专业」大佬,听懂的一句话是:等上半年「复苏」的数据和确定性的效果出现;

普遍的趋势和预期下;

对于成熟期或衰退期的业务团队,单人单岗的模式,自然会成为公司的首选方案;

至于其他情况,与公司的生存压力有极大的关系;

对于产品研发部门来说,组织裁员降本的首刀团队,也是最可能被单人单岗化的部门;

大部分「非技术型」的公司,研发就意味着持续投入;

在诸多不确定因素的加持下,非必要的投入就意味着「风险」;


02


从「组织内部」来看,单人单岗多少会引起角色和策略的调整;

自己所在的团队,今年一季度实行单人单岗过程中;

相当长一段时间都是「鸡飞狗跳」的状态,之后才慢慢回归到平稳的节奏;

年初最后一轮裁员之后;

团队刚开始单人单岗,随之而来的就是混乱的管理;

原本「独立」的项目经理角色,被加持在各个业务线的负责人身上,而有些人又好巧不巧的负责多个业务线;

责任越大,能力也会被动放大;

不免有人会问:角色没了就没了,为何要给单人刻意赋多个角色?

这就不得不说一个核心问题:组织的流程与机制;

在流程设计上,很多事情都围绕项目展开的;

即事情的各个阶段,从流程上都要找到对应的负责人,以及整个流程的推动者;

这样,降低单人单岗对组织流程的影响;

并且项目经理的角色激励制度,也会推动相关负责人的积极性;

从公司层面看;

降低人力成本,从事务执行来说,也没产生比较明显的影响;

对于团队的管理策略;

则尽量「弱化」人和流程的管理,重心转向对事务的推动落实;

单人单岗的模式中;

每个人面对的事情会更加繁琐,除了正常节奏推进的事项,还有诸多突发的问题要处理;

必然会对「心态」和「情绪」产生负面影响;

作为一个打工人;

这种状态下,无非就想把事情快速稳妥的结束,从混乱的状态中出来;

如果还追着「」和「流程」的强管理;

那最后「崩塌」的,可能就不单是「事务」本身了;


03


从「产品和业务」来说;

单人单岗的团队,产品体系比较稳定,业务多数是处于成熟期或衰退期;

如何迭代需求?

是产品的最大难题;

常规的团队中:主线研发确保业务发展,辅线支撑产品运营的问题处理,架构角色推动系统级的框架迭代;

在单人单岗的模式中,显然不太可能存在所谓的辅线和架构线;

目标很明确,支撑主线需求落地,其他的事情不到「万不得已」不会考虑;

然而事实情况是:团队会「经常」万不得已;

线上的BUG要处理吧?客户的问题要解决吧?各种临时性的需求要应对吧?

这种状态下,必然会影响主线业务的开发;

团队经常处理「万不得已」的情况,就会经常引起各种版本排期的问题,整体节奏就会混乱甚至失控;

该如何解决?

自然要产品从版本需求自身入手,需求拆分的足够小,排期自然足够短

即便在排期中预留各种突发问题的处理时间,整体的周期也在一个可控的范围内;

相应也就可以保持一定的迭代节奏

需求的拆分是一个核心手段,需求的优先级同样应该把控好;

可以不用研发排期的方式,尽量不用,或者功能正常但存在优化空间的,尽量拉低优先级;

这种节奏下;

即可以保障常规事务的处理,又推动需求高质量的持续落地;

对于公司而言,何乐而不为?


04


从一个「季度的实践」来看,组织必然要承受单人单岗带来的风险

在公司业务最忙的三月下旬;

离谱的是:有人请假,时长一周的那种;

更离谱的是:请假的人员不止一个;

最离谱的是:我没有请假;

本人,居然成为单人单岗制度下的第一个大冤种,冤到空气都想替我叫声屈;

团队缺失三位人员:产品、项目、运维,测试处在走离职的阶段;

所以,留两位开发在公司,相顾无言泪两行;

其实,单人单岗的机制下,忽然有人请假并不可怕;

真正可怕的点在于,在请假的时候,突然冒出一连串需要协作的事情;

生活往往就是这个样,怕什么就容易来什么;

本来常规流程下;

问题会经过项目经理,根据性质进行衡量,是否需要即时处理,最终由测试和产品人员进行协调研发解决;

当协调问题的核心人员不在,自然就会抛到经常解决问题的人员这里;

哪个角色经常解决问题?

毫无疑问:服务端研发,似乎解决什么问题,都可以拉上后端人员,妥妥的跳坑天选之人;

这个怪象其实很好理解;

在组织中,与业务关系越密切的角色,需要面对和解决的问题就越多;

产品技术部门,当协调问题的项目或产品经理不在时,问题会自带指向后端研发导航仪


05


既然,问题来了;

躲是「躲不掉」的,情绪化的「内耗」更没必要;

基于某种奇怪的知识来说,越是怕什么越容易来什么;

通俗的说:屋漏偏逢连阴雨,问题不单行;

业务的高峰期;

自然也是问题的并发期,短短几天出现的问题,绕园区一圈应该不在话下;

自己则有一种被问题包围的错觉;

产品、运维、项目、业务、技术、网络、软件安装等各种问题;

很显然,「能解决」的问题并「不多」,但并不妨碍问题持续不断的抛过来;

这里说句题外话;

以前听说,程序员会修电脑,我是不信的;

现在的话,自己信不信不重要,身边的亲友和同事坚定的相信;

这些爆发性的问题如何解决?

【1】建立一个临时的问题收集文档,把各种问题的描述和截图先记录下来;

【2】跟进问题,优先选择业务属性高的解决,其次处理影响流程的问题;

【3】如果是当前非必须处理的事,或者团队暂时解决不了的,正面回复即可;

其实,单人单岗模式在缺人的情况下,很多事情的处理都需要临时的「思路转换」;

从心态上来说;

不要以缺人为由,将问题打个「死结」;

优先给一个完整的临时解决方式,并且尽量避免多人协作,放大问题;

以这种态度,支撑了一周;

大部分业务问题都得到了解决,当然这也很依赖于团队精细的「文档」积累;

至于其他的问题;

摆烂,心宽;


06


个人的职场原则;

该做的事,能做的事,都尽力做好,做不了的事情,自然也「拒绝」的很果断;

做个「45度」的打工人;

比如短短一周,所遇到的各种奇怪「要求」;

某个路由器的网络检修,拒绝了

新人入职电脑安装系统和软件,拒绝了

某个外包项目做验收,拒绝了

在那一周过后,公司流传一句话:研发部那个谁「好菜」啊,什么都不会;

最后,部门老大开玩笑的说;

团队内部,任何岗位你想转去玩几天,都批;

我认真想了想,这两天打扫卫生的阿姨没来,想代替几天,「被拒绝了」;

这个魔幻的职场,爱了;

热门相关:斗神战帝   大神你人设崩了   横行霸道   惊世毒妃:轻狂大小姐   夫人你马甲又掉了