「闲」到停不下来，「忙」到无事可做！

01

年后开始，研发团队一直「单人单岗」；

为什么？

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

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

然而，这不重要；

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

这，才是关键，才是社会；

底线，如果还有一点；

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

底线，如果没有的话；

还可以玩一手「单人多岗」，比如常说的：人人都是产品，人人都是测试；

为啥没听过人人都是开发，人人都是运维？

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

其实，在今年元旦之后；

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

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

为何是「上半年」？

这里说一句题外话；

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

普遍的趋势和预期下；

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

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

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

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

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

02

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

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

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

年初最后一轮裁员之后；

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

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

责任越大，能力也会被动放大；

不免有人会问：角色没了就没了，为何要给单人刻意赋多个角色？

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

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

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

这样，降低单人单岗对组织流程的影响；

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

从公司层面看；

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

对于团队的管理策略；

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

单人单岗的模式中；

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

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

作为一个打工人；

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

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

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

03

从「产品和业务」来说；

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

如何迭代需求？

是产品的最大难题；

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

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

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

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

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

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

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

该如何解决？

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

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

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

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

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

这种节奏下；

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

对于公司而言，何乐而不为？

04

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

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

离谱的是：有人请假，时长一周的那种；

更离谱的是：请假的人员不止一个；

最离谱的是：我没有请假；

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

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

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

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

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

生活往往就是这个样，怕什么就容易来什么；

本来常规流程下；

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

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

哪个角色经常解决问题？

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

这个怪象其实很好理解；

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

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

05

既然，问题来了；

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

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

通俗的说：屋漏偏逢连阴雨，问题不单行；

业务的高峰期；

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

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

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

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

这里说句题外话；

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

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

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

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

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

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

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

从心态上来说；

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

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

以这种态度，支撑了一周；

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

至于其他的问题；

摆烂，心宽；

06

个人的职场原则；

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

做个「45 度」的打工人；

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

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

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

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

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

最后，部门老大开玩笑的说；

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

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

这个魔幻的职场，爱了；