「閑」到停不下來，「忙」到無事可做！
01
年后開始，研發團隊一直「單人單崗」；
為什么？
就是所謂的追求降本，無非裁員的手段，最終的目的就是讓團隊的人員結構簡化到極致；
雖然符合公司預期，但是與打工人的預期強烈不符；
然而，這不重要；
打工人的難處，老板不一定關心；但是老板的難處，打工人必然被關心；
這，才是關鍵，才是社會；
底線，如果還有一點；
即使企業在承擔營收壓力之時，還能保持團隊的單人單崗結構；
底線，如果沒有的話；
還可以玩一手「單人多崗」，比如常說的：人人都是產品，人人都是測驗；
為啥沒聽過人人都是開發，人人都是運維？
專業可替代性的說法，雖然是無腦的輿論，但處處透著精明和算計；
其實，在今年元旦之后；
和職場上的「十多個」朋友聊過，得到一個共通的結論；
上半年，部分中小廠比較普遍的預期都是簡化人員結構，從而降低成本預算；
為何是「上半年」？
這里說一句題外話；
特意咨詢過組織內的「專業」大佬，聽懂的一句話是：等上半年「復蘇」的資料和確定性的效果出現；
普遍的趨勢和預期下；
對于成熟期或衰退期的業務團隊，單人單崗的模式，自然會成為公司的首選方案；
至于其他情況，與公司的生存壓力有極大的關系；
對于產品研發部門來說，組織裁員降本的首刀團隊，也是最可能被單人單崗化的部門；
大部分「非技術型」的公司，研發就意味著持續投入；
在諸多不確定因素的加持下，非必要的投入就意味著「風險」；
02
從「組織內部」來看，單人單崗多少會引起角色和策略的調整；
自己所在的團隊，今年一季度實行單人單崗程序中；
相當長一段時間都是「雞飛狗跳」的狀態，之后才慢慢回歸到平穩的節奏；
年初最后一輪裁員之后；
團隊剛開始單人單崗，隨之而來的就是混亂的管理；
原本「獨立」的專案經理角色，被加持在各個業務線的負責人身上，而有些人又好巧不巧的負責多個業務線；
責任越大，能力也會被動放大；
不免有人會問：角色沒了就沒了，為何要給單人刻意賦多個角色？
這就不得不說一個核心問題：組織的流程與機制；
在流程設計上，很多事情都圍繞專案展開的；
即事情的各個階段，從流程上都要找到對應的負責人，以及整個流程的推動者；
這樣，降低單人單崗對組織流程的影響；
并且專案經理的角色激勵制度，也會推動相關負責人的積極性；
從公司層面看；
降低人力成本，從事務執行來說，也沒產生比較明顯的影響；
對于團隊的管理策略；
則盡量「榷訓」人和流程的管理，重心轉向對事務的推動落實；
單人單崗的模式中；
每個人面對的事情會更加繁瑣，除了正常節奏推進的事項，還有諸多突發的問題要處理；
必然會對「心態」和「情緒」產生負面影響；
作為一個打工人；
這種狀態下，無非就想把事情快速穩妥的結束，從混亂的狀態中出來；
如果還追著「人」和「流程」的強管理；
那最后「崩塌」的，可能就不單是「事務」本身了；
03
從「產品和業務」來說；
單人單崗的團隊，產品體系比較穩定，業務多數是處于成熟期或衰退期；
如何迭代需求？
是產品的最大難題；
常規的團隊中：主線研發確保業務發展，輔線支撐產品運營的問題處理，架構角色推動系統級的框架迭代；
在單人單崗的模式中，顯然不太可能存在所謂的輔線和架構線；
目標很明確，支撐主線需求落地，其他的事情不到「萬不得已」不會考慮；
然而事實情況是：團隊會「經常」萬不得已；
線上的BUG要處理吧？客戶的問題要解決吧？各種臨時性的需求要應對吧？
這種狀態下，必然會影響主線業務的開發；
團隊經常處理「萬不得已」的情況，就會經常引起各種版本排期的問題，整體節奏就會混亂甚至失控；
該如何解決？
自然要產品從版本需求自身入手，需求拆分的足夠小，排期自然足夠短；
即便在排期中預留各種突發問題的處理時間，整體的周期也在一個可控的范圍內；
相應也就可以保持一定的迭代節奏；
需求的拆分是一個核心手段，需求的優先級同樣應該把控好；
可以不用研發排期的方式，盡量不用，或者功能正常但存在優化空間的，盡量拉低優先級；
這種節奏下；
即可以保障常規事務的處理，又推動需求高質量的持續落地；
對于公司而言，何樂而不為？
04
從一個「季度的實踐」來看，組織必然要承受單人單崗帶來的風險；
在公司業務最忙的三月下旬；
離譜的是：有人請假，時長一周的那種；
更離譜的是：請假的人員不止一個；
最離譜的是：我沒有請假；
本人，居然成為單人單崗制度下的第一個大冤種，冤到空氣都想替我叫聲屈；
團隊缺失三位人員：產品、專案、運維，測驗處在走離職的階段；
所以，留兩位開發在公司，相顧無言淚兩行；
其實，單人單崗的機制下，忽然有人請假并不可怕；
真正可怕的點在于，在請假的時候，突然冒出一連串需要協作的事情；
生活往往就是這個樣，怕什么就容易來什么；
本來常規流程下；
問題會經過專案經理，根據性質進行衡量，是否需要即時處理，最終由測驗和產品人員進行協調研發解決；
當協調問題的核心人員不在，自然就會拋到經常解決問題的人員這里；
哪個角色經常解決問題？
毫無疑問：服務端研發，似乎解決什么問題，都可以拉上后端人員，妥妥的跳坑天選之人；
這個怪象其實很好理解；
在組織中，與業務關系越密切的角色，需要面對和解決的問題就越多；
產品技術部門，當協調問題的專案或產品經理不在時，問題會自帶指向后端研發導航儀；
05
既然，問題來了；
躲是「躲不掉」的，情緒化的「內耗」更沒必要；
基于某種奇怪的知識來說，越是怕什么越容易來什么；
通俗的說：屋漏偏逢連陰雨，問題不單行；
業務的高峰期；
自然也是問題的并發期，短短幾天出現的問題，繞園區一圈應該不在話下；
自己則有一種被問題包圍的錯覺；
產品、運維、專案、業務、技術、網路、軟體安裝等各種問題；
很顯然，「能解決」的問題并「不多」，但并不妨礙問題持續不斷的拋過來；
這里說句題外話；
以前聽說，程式員會修電腦，我是不信的；
現在的話，自己信不信不重要，身邊的親友和同事堅定的相信；
這些爆發性的問題如何解決？
【1】建立一個臨時的問題收集檔案，把各種問題的描述和截圖先記錄下來；
【2】跟進問題，優先選擇業務屬性高的解決，其次處理影響流程的問題；
【3】如果是當前非必須處理的事，或者團隊暫時解決不了的，正面回復即可；
其實，單人單崗模式在缺人的情況下，很多事情的處理都需要臨時的「思路轉換」；
從心態上來說；
不要以缺人為由，將問題打個「死結」；
優先給一個完整的臨時解決方式，并且盡量避免多人協作，放大問題；
以這種態度，支撐了一周；
大部分業務問題都得到了解決，當然這也很依賴于團隊精細的「檔案」積累；
至于其他的問題；
擺爛，心寬；
06
個人的職場原則；
該做的事，能做的事，都盡力做好，做不了的事情，自然也「拒絕」的很果斷；
做個「45度」的打工人；
比如短短一周，所遇到的各種奇怪「要求」；
某個路由器的網路檢修，拒絕了；
新人入職電腦安裝系統和軟體，拒絕了；
某個外包專案做驗收，拒絕了；
在那一周過后，公司流傳一句話：研發部那個誰「好菜」啊，什么都不會；
最后，部門老大開玩笑的說；
團隊內部，任何崗位你想轉去玩幾天，都批；
我認真想了想，這兩天打掃衛生的阿姨沒來，想代替幾天，「被拒絕了」；
這個魔幻的職場，愛了；
Gitee主頁： https://gitee.com/cicadasmile/butte-java-note轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/551319.html
標籤：其他
上一篇：位元組超全學習流程圖流出，100天漲薪10k，從功能測驗到自動化測驗
下一篇：返回列表