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

01

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

为什么？

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

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

然而，这不重要；

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

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

底线，如果还有一点；

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

底线，如果没有的话；

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

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

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

其实，在今年元旦之后；

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

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

为何是「上半年」？

这里说一句题外话；

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

普遍的趋势和预期下；

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

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

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

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

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

02

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

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

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

年初最后一轮裁员之后；

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

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

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

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

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

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

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

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

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

从公司层面看；

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

对于团队的管理策略；

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

单人单岗的模式中；

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

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

作为一个打工人；

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

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

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

03

从「产品和业务」来说；

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

如何迭代需求？

是产品的最大难题；

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

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

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

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

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

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

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

该如何解决？

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

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

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

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

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

这种节奏下；

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

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

04

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

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

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

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

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

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

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

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

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

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

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

本来常规流程下；

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

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

哪个角色经常解决问题？

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

这个怪象其实很好理解；

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

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

05

既然，问题来了；

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

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

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

业务的高峰期；

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

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

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

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

这里说句题外话；

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

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

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

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

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

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

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

从心态上来说；

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

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

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

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

至于其他的问题；

摆烂，心宽；

06

个人的职场原则；

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

做个「45度」的打工人；

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

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

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

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

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

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

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

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

这个魔幻的职场，爱了；

g