「闲」到停不下来，「忙」到无事可做！
01
年后开端，研制团队一向「单人单岗」；
为什么？
便是所谓的追求降本，无非裁人的手法，终究的目的便是让团队的人员结构简化到极致；
尽管契合公司预期，可是与打工人的预期强烈不符；
可是，这不重要；
打工人的难处，老板不一定关怀；可是老板的难处，打工人必定被关怀；
这，才是要害，才是社会；
底线，假如还有一点；
即使企业在承担营收压力之时，还能保持团队的单人单岗结构；
底线，假如没有的话；
还能够玩一手「单人多岗」，比方常说的：人人都是产品，人人都是测验；
为啥没听过人人都是开发，人人都是运维？
专业可替代性的说法，尽管是无脑的舆论，但处处透着精明和算计；
其实，在今年元旦之后；
和职场上的「十多个」朋友聊过，得到一个共通的结论；
上半年，部分中小厂比较遍及的预期都是简化人员结构，然后下降成本预算；
为何是「上半年」？
这儿说一句题外话；
特意咨询过安排内的「专业」大佬，听懂的一句话是：等上半年「复苏」的数据和确定性的效果呈现；
遍及的趋势和预期下；
关于成熟期或衰退期的事务团队，单人单岗的形式，天然会成为公司的首选计划；
至于其他状况，与公司的生计压力有极大的关系；
关于产品研制部分来说，安排裁人降本的首刀团队，也是最可能被单人单岗化的部分；
大部分「非技能型」的公司，研制就意味着继续投入；
在诸多不确定因素的加持下，非必要的投入就意味着「危险」；
02
从「安排内部」来看，单人单岗多少会引起人物和战略的调整；
自己地点的团队，今年一季度实行单人单岗过程中；
相当长一段时间都是「鸡犬不宁」的状况，之后才慢慢回归到平稳的节奏；
年初终究一轮裁人之后；
团队刚开端单人单岗，随之而来的便是紊乱的办理；
原本「独立」的项目经理人物，被加持在各个事务线的担任人身上，而有些人又好巧不巧的担任多个事务线；
职责越大，才能也会被迫扩大；
不免有人会问：人物没了就没了，为何要给单人刻意赋多个人物？
这就不得不说一个中心问题：安排的流程与机制；
在流程规划上，许多工作都围绕项目展开的；
即工作的各个阶段，从流程上都要找到对应的担任人，以及整个流程的推进者；
这样，下降单人单岗对安排流程的影响；
而且项目经理的人物鼓励制度，也会推进相关担任人的积极性；
从公司层面看；
下降人力成本，从事务执行来说，也没发生比较明显的影响；
关于团队的办理战略；
则尽量「弱化」人和流程的办理，重心转向对事务的推进落实；
单人单岗的形式中；
每个人面对的工作会更加繁琐，除了正常节奏推进的事项，还有诸多突发的问题要处理；
必定会对「心态」和「情绪」发生负面影响；
作为一个打工人；
这种状况下，无非就想把工作快速稳妥的结束，从紊乱的状况中出来；
假如还追着「人」和「流程」的强办理；
那终究「崩塌」的，可能就不单是「事务」自身了；
03
从「产品和事务」来说；
单人单岗的团队，产品体系比较稳定，事务多数是处于成熟期或衰退期；
怎么迭代需求？
是产品的最大难题；
惯例的团队中：主线研制保证事务开展，辅线支撑产品运营的问题处理，架构人物推进体系级的结构迭代；
在单人单岗的形式中，显然不太可能存在所谓的辅线和架构线；
目标很明确，支撑主线需求落地，其他的工作不到「万不得已」不会考虑；
可是现实状况是：团队会「常常」万不得已；
线上的BUG要处理吧？客户的问题要处理吧？各种暂时性的需求要应对吧？
这种状况下，必定会影响主线事务的开发；
团队常常处理「万不得已」的状况，就会常常引起各种版别排期的问题，整体节奏就会紊乱乃至失控；
该怎么处理？
天然要产品从版别需求自身入手，需求拆分的满足小，排期天然满足短；
即便在排期中预留各种突发问题的处理时间，整体的周期也在一个可控的范围内；
相应也就能够保持一定的迭代节奏；
需求的拆分是一个中心手法，需求的优先级相同应该把控好；
能够不用研制排期的方法，尽量不用，或许功用正常但存在优化空间的，尽量拉低优先级；
这种节奏下；
即能够保证惯例事务的处理，又推进需求高质量的继续落地；
关于公司而言，何乐而不为？
04
从一个「季度的实践」来看，安排必定要接受单人单岗带来的危险；
在公司事务最忙的三月下旬；
离谱的是：有人请假，时长一周的那种；
更离谱的是：请假的人员不止一个；
最离谱的是：我没有请假；
本人，竟然成为单人单岗制度下的第一个大冤种，冤到空气都想替我叫声屈；
团队缺失三位人员：产品、项目、运维，测验处在走离任的阶段；
所以，留两位开发在公司，相顾无言泪两行；
其实，单人单岗的机制下，忽然有人请假并不可怕；
真正可怕的点在于，在请假的时候，突然冒出一连串需求协作的工作；
日子往往便是这个样，怕什么就简单来什么；
原本惯例流程下；
问题会经过项目经理，依据性质进行衡量，是否需求即时处理，终究由测验和产品人员进行和谐研制处理；
当和谐问题的中心人员不在，天然就会抛到常常处理问题的人员这儿；
哪个人物常常处理问题？
毫无疑问：服务端研制，似乎处理什么问题，都能够拉上后端人员，妥妥的跳坑天选之人；
这个怪象其实很好理解；
在安排中，与事务关系越亲近的人物，需求面对和处理的问题就越多；
产品技能部分，当和谐问题的项目或产品经理不在时，问题会自带指向后端研制导航仪；
05
既然，问题来了；
躲是「躲不掉」的，情绪化的「内讧」更没必要；
基于某种古怪的常识来说，越是怕什么越简单来什么；
浅显的说：屋漏偏逢连阴雨，问题不单行；
事务的高峰期；
天然也是问题的并发期，短短几天呈现的问题，绕园区一圈应该不在话下；
自己则有一种被问题围住的错觉；
产品、运维、项目、事务、技能、网络、软件装置等各种问题；
很显然，「能处理」的问题并「不多」，但并不阻碍问题继续不断的抛过来；
这儿说句题外话；
以前传闻，程序员会修电脑，我是不信的；
现在的话，自己信不信不重要，身边的亲友和搭档坚定的信任；
这些爆发性的问题怎么处理？
【1】树立一个暂时的问题收集文档，把各种问题的描绘和截图先记录下来；
【2】跟进问题，优先选择事务属性高的处理，其次处理影响流程的问题；
【3】假如是当时非必须处理的事，或许团队暂时处理不了的，正面回复即可；
其实，单人单岗形式在缺人的状况下，许多工作的处理都需求暂时的「思路转化」；
从心态上来说；
不要以缺人为由，将问题打个「死结」；
优先给一个完好的暂时处理方法，而且尽量防止多人协作，扩大问题；
以这种情绪，支撑了一周；
大部分事务问题都得到了处理，当然这也很依赖于团队精细的「文档」积累；
至于其他的问题；
摆烂，心宽；
06
个人的职场准则；
该做的事，能做的事，都尽力做好，做不了的工作，天然也「拒绝」的很果断；
做个「45度」的打工人；
比方短短一周，所遇到的各种古怪「要求」；
某个路由器的网络检修，拒绝了；
新人入职电脑装置体系和软件，拒绝了；
某个外包项目做验收，拒绝了；
在那一周过后，公司撒播一句话：研制部那个谁「好菜」啊，什么都不会；
终究，部分老迈开玩笑的说；
团队内部，任何岗位你想转去玩几天，都批；
我认真想了想，这两天打扫卫生的阿姨没来，想代替几天，「被拒绝了」；
这个魔幻的职场，爱了；
