「闲」到停不下来，「忙」到无事可做！
01
年后开始，研发团队始终「单人单岗」；
为什么？
就是所谓的谋求降本，无非裁员的伎俩，最终的目标就是让团队的人员构造简化到极致；
尽管合乎公司预期，然而与打工人的预期强烈不符；
然而，这不重要；
打工人的难处，老板不肯定关怀；然而老板的难处，打工人必然被关怀；
这，才是要害，才是社会；
底线，如果还有一点；
即便企业在承当营收压力之时，还能放弃团队的单人单岗构造；
底线，如果没有的话；
还能够玩一手「单人多岗」，比方常说的：人人都是产品，人人都是测试；
为啥没听过人人都是开发，人人都是运维？
业余可替代性的说法，尽管是无脑的舆论，但处处透着精明和合计；
其实，在往年除夕之后；
和职场上的「十多个」敌人聊过，失去一个共通的论断；
上半年，局部中小厂比拟广泛的预期都是简化人员构造，从而降低成本估算；
为何是「上半年」？
这里说一句题外话；
特意征询过组织内的「业余」大佬，听懂的一句话是：等上半年「复苏」的数据和确定性的成果呈现；
广泛的趋势和预期下；
对于成熟期或衰退期的业务团队，单人单岗的模式，天然会成为公司的首选计划；
至于其余状况，与公司的生存压力有极大的关系；
对于产品研发部门来说，组织裁员降本的首刀团队，也是最可能被单人单岗化的部门；
大部分「非技术型」的公司，研发就意味着继续投入；
在诸多不确定因素的加持下，非必要的投入就意味着「危险」；
02
从「组织外部」来看，单人单岗多少会引起角色和策略的调整；
本人所在的团队，往年一季度履行单人单岗过程中；
相当长一段时间都是「鸡飞狗跳」的状态，之后才缓缓回归到安稳的节奏；
年初最初一轮裁员之后；
团队刚开始单人单岗，随之而来的就是凌乱的治理；
本来「独立」的项目经理角色，被加持在各个业务线的负责人身上，而有些人又好巧不巧的负责多个业务线；
责任越大，能力也会被动放大；
未免有人会问：角色没了就没了，为何要给单人刻意赋多个角色？
这就不得不说一个外围问题：组织的流程与机制；
在流程设计上，很多事件都围绕我的项目开展的；
即事件的各个阶段，从流程上都要找到对应的负责人，以及整个流程的推动者；
这样，升高单人单岗对组织流程的影响；
并且项目经理的角色激励制度，也会推动相干负责人的积极性；
从公司层面看；
升高人力老本，从事务执行来说，也没产生比拟显著的影响；
对于团队的管理策略；
则尽量「弱化」人和流程的治理，重心转向对事务的推动落实；
单人单岗的模式中；
每个人面对的事件会更加繁琐，除了失常节奏推动的事项，还有诸多突发的问题要解决；
必然会对「心态」和「情绪」产生负面影响；
作为一个打工人；
这种状态下，无非就想把事件疾速稳当的完结，从凌乱的状态中进去；
如果还追着「人」和「流程」的强治理；
那最初「崩塌」的，可能就不单是「事务」自身了；
03
从「产品和业务」来说；
单人单岗的团队，产品体系比较稳定，业务少数是处于成熟期或衰退期；
如何迭代需要？
是产品的最大难题；
惯例的团队中：主线研发确保业务倒退，辅线撑持产品经营的问题解决，架构角色推动零碎级的框架迭代；
在单人单岗的模式中，显然不太可能存在所谓的辅线和架构线；
指标很明确，撑持主线需要落地，其余的事件不到「万不得已」不会思考；
然而事实状况是：团队会「常常」万不得已；
线上的BUG要解决吧？客户的问题要解决吧？各种临时性的需要要应答吧？
这种状态下，必然会影响主线业务的开发；
团队常常解决「万不得已」的状况，就会常常引起各种版本排期的问题，整体节奏就会凌乱甚至失控；
该如何解决？
天然要产品从版本需要本身动手，需要拆分的足够小，排期天然足够短；
即使在排期中预留各种突发问题的解决工夫，整体的周期也在一个可控的范畴内；
相应也就能够放弃肯定的迭代节奏；
需要的拆分是一个外围伎俩，需要的优先级同样应该把控好；
能够不必研发排期的形式，尽量不必，或者性能失常但存在优化空间的，尽量拉低优先级；
这种节奏下；
即能够保障惯例事务的解决，又推动需要高质量的继续落地；
对于公司而言，何乐而不为？
04
从一个「季度的实际」来看，组织必然要接受单人单岗带来的危险；
在公司业务最忙的三月下旬；
离谱的是：有人销假，时长一周的那种；
更离谱的是：销假的人员不止一个；
最离谱的是：我没有销假；
自己，竟然成为单人单岗制度下的第一个大冤种，冤到空气都想替我叫声屈；
团队缺失三位人员：产品、我的项目、运维，测试处在走到职的阶段；
所以，留两位开发在公司，相顾无言泪两行；
其实，单人单岗的机制下，突然有人销假并不可怕；
真正可怕的点在于，在销假的时候，忽然冒出一连串须要合作的事件；
生存往往就是这个样，怕什么就容易来什么；
原本惯例流程下；
问题会通过项目经理，依据性质进行掂量，是否须要即时解决，最终由测试和产品人员进行协调研发解决；
当协调问题的外围人员不在，天然就会抛到常常解决问题的人员这里；
哪个角色常常解决问题？
毫无疑问：服务端研发，仿佛解决什么问题，都能够拉上后端人员，妥妥的跳坑天选之人；
这个怪象其实很好了解；
在组织中，与业务关系越亲密的角色，须要面对和解决的问题就越多；
产品技术部门，当协调问题的我的项目或产品经理不在时，问题会自带指向后端研发导航仪；
05
既然，问题来了；
躲是「躲不掉」的，情绪化的「内耗」更没必要；
基于某种奇怪的常识来说，越是怕什么越容易来什么；
艰深的说：屋漏偏逢连阴雨，问题不单行；
业务的高峰期；
天然也是问题的并发期，短短几天呈现的问题，绕园区一圈应该不在话下；
本人则有一种被问题突围的错觉；
产品、运维、我的项目、业务、技术、网络、软件装置等各种问题；
很显然，「能解决」的问题并「不多」，但并不障碍问题继续一直的抛过去；
这里说句题外话；
以前据说，程序员会修电脑，我是不信的；
当初的话，本人信不信不重要，身边的亲友和共事动摇的置信；
这些爆发性的问题如何解决？
【1】建设一个长期的问题收集文档，把各种问题的形容和截图先记录下来；
【2】跟进问题，优先选择业务属性高的解决，其次解决影响流程的问题；
【3】如果是以后非必须解决的事，或者团队临时解决不了的，侧面回复即可；
其实，单人单岗模式在缺人的状况下，很多事件的解决都须要长期的「思路转换」；
从心态上来说；
不要以缺人为由，将问题打个「死结」；
优先给一个残缺的长期解决形式，并且尽量避免多人合作，放大问题；
以这种态度，撑持了一周；
大部分业务问题都失去了解决，当然这也很依赖于团队精密的「文档」积攒；
至于其余的问题；
摆烂，心宽；
06
集体的职场准则；
该做的事，能做的事，都尽力做好，做不了的事件，天然也「回绝」的很果决；
做个「45度」的打工人；
比方短短一周，所遇到的各种奇怪「要求」；
某个路由器的网络检修，回绝了；
新人入职电脑装置零碎和软件，回绝了；
某个外包我的项目做验收，回绝了；
在那一周过后，公司流传一句话：研发部那个谁「好菜」啊，什么都不会；
最初，部门老大开玩笑的说；
团队外部，任何岗位你想转去玩几天，都批；
我认真想了想，这两天打扫卫生的阿姨没来，想代替几天，「被回绝了」；
这个魔幻的职场，爱了；
Gitee主页： https://gitee.com/cicadasmile/butte-java-note