> 「**閒**」到停不下來，「**忙**」到無事可做！

# 01

年後開始，研發團隊一直「**單人單崗**」；

**為什麼**？

就是所謂的追求降本，無非裁員的手段，最終的目的就是讓團隊的人員結構簡化到單人單崗；

雖然符合公司預期，但是與打工人的預期強烈不符；

然而，**這不重要**；

打工人的難處，老闆不一定關心；但是老闆的難處，打工人必然被關心；

這，才是關鍵，才是社會；

**底線，如果還有**一點；

即使企業在承擔營收壓力之時，還能保持團隊的單人單崗結構；

**底線，如果沒有**的話；

還可以玩一手「**單人多崗**」，比如常說的：人人都是產品，人人都是測試；

為啥沒聽過人人都是開發，人人都是運維？

專業可替代性的說法，雖然是**無腦**的輿論，但處處透著精明和算計；

其實，在今年元旦之後；

和職場上的「十多個」朋友聊過，得到一個共通的結論；

上半年，部分中小廠比較普遍的預期都是簡化人員結構，從而降低成本預算；

為何是「**上半年**」？

這裡說一句題外話；

特意諮詢過組織內的「**專業**」大佬，聽懂的一句話是：等上半年「**復甦**」的資料和確定性的效果出現；

普遍的趨勢和預期下；

對於**成熟期或衰退期**的業務團隊，單人單崗的模式，自然會成為公司的方案；

至於其他情況，與公司的生存壓力有極大的關係；

對於產品研發部門來說，組織裁員降本的首刀團隊，也是最可能被單人單崗化的部門；

大部分「非技術型」的公司，研發就意味著持續投入；

在諸多不確定因素的加持下，非必要的投入就意味著「**風險**」；

# 02

從「**組織內部**」來看，單人單崗多少會引起角色和策略的調整；

自己所在的團隊，今年一季度實行單人單崗過程中；

相當長一段時間都是「**雞飛狗跳**」的狀態，之後才慢慢迴歸到平穩的節奏；

年初最後一輪裁員之後；

團隊剛開始單人單崗，隨之而來的就是混亂的管理；

原本「**獨立**」的專案經理角色，被加持在各個業務線的負責人身上，而有些人又好巧不巧的負責多個業務線；

**責任越大，能力也會被動放大；**

不免有人會問：角色沒了就沒了，為何要給單人刻意賦多個角色？

這就不得不說一個核心問題：**組織的流程與機制；**

在流程設計上，很多事情都圍繞專案展開的；

即事情的各個階段，從流程上都要找到對應的負責人，以及整個流程的推動者；

這樣，**降低**單人單崗對組織流程的影響；

並且專案經理的角色激勵制度，也會推動相關負責人的積極性；

從公司層面看；

降低人力成本，從事務執行來說，也沒產生比較明顯的影響；

對於團隊的管理策略；

則儘量「**弱化**」人和流程的管理，重心轉向對事務的推動落實；

單人單崗的模式中；

每個人面對的事情會更加繁瑣，除了正常節奏推進的事項，還有諸多突發的問題要處理；

必然會對「**心態**」和「**情緒**」產生負面影響；

作為一個打工人；

這種狀態下，無非就想把事情快速穩妥的結束，從混亂的狀態中出來；

如果還追著「**人**」和「**流程**」的強管理；

那最後「**崩塌**」的，可能就不單是「**事務**」本身了；

# 03

從「**產品和業務**」來說；

單人單崗的團隊，產品體系比較穩定，業務多數是處於成熟期或衰退期；

如何迭代需求？

是產品的最大難題；

常規的團隊中：主線研發確保業務發展，輔線支撐產品運營的問題處理，架構角色推動系統級的框架迭代；

在單人單崗的模式中，顯然不太可能存在所謂的輔線和架構線；

目標很明確，支撐主線需求落地，其他的事情不到「**萬不得已**」不會考慮；

然而事實情況是：團隊會「**經常**」萬不得已；

線上的BUG要處理吧？客戶的問題要解決吧？各種臨時性的需求要應對吧？

這種狀態下，必然會影響主線業務的開發；

團隊經常處理「**萬不得已**」的情況，就會經常引起各種版本排期的問題，整體節奏就會混亂甚至失控；

**該如何解決？**

自然要產品從版本需求自身入手，需求拆分的**足夠小**，排期自然**足夠短**；

即便在排期中預留各種突發問題的處理時間，整體的週期也在一個可控的範圍內；

相應也就可以保持一定的**迭代節奏**；

需求的拆分是一個核心手段，需求的優先順序同樣應該把控好；

可以不用研發排期的方式，儘量不用，或者功能正常但存在最佳化空間的，儘量拉低優先順序；

這種節奏下；

即可以保障常規事務的處理，又推動需求高質量的持續落地；

對於公司而言，何樂而不為？

# 04

從一個「**季度的實踐**」來看，組織必然要承受單人單崗帶來的**風險**；

在公司業務最忙的三月下旬；

離譜的是：有人請假，時長一週的那種；

更離譜的是：請假的人員不止一個；

**最離譜的是：我沒有請假；**

本人，居然成為單人單崗制度下的第一個**大冤種**，冤到空氣都想替我叫聲屈；

團隊缺失三位人員：產品、專案、運維，測試處在走離職的階段；

所以，留兩位開發在公司，相顧無言淚兩行；

其實，單人單崗的機制下，忽然有人請假並不可怕；

真正可怕的點在於，在請假的時候，突然冒出一連串需要協作的事情；

**生活往往就是這個樣，怕什麼就容易來什麼；**

本來常規流程下；

問題會經過專案經理，根據性質進行衡量，是否需要即時處理，最終由測試和產品人員進行協調研發解決；

當協調問題的核心人員不在，自然就會拋到經常解決問題的人員這裡；

**哪個角色經常解決問題？**

毫無疑問：服務端研發，似乎解決什麼問題，都可以拉上後端人員，妥妥的跳坑天選之人；

這個怪象其實很好理解；

在組織中，與業務關係越密切的角色，需要面對和解決的問題就越多；

產品技術部門，當協調問題的專案或產品經理不在時，問題會自帶指向後端研發**導航儀**；

# 05

既然，問題來了；

躲是「**躲不掉**」的，情緒化的「**內耗**」更沒必要；

基於某種奇怪的知識來說，越是怕什麼越容易來什麼；

通俗的說：屋漏偏逢連陰雨，問題不單行；

**業務的高峰期；**

自然也是**問題的併發期**，短短几天出現的問題，繞園區一圈應該不在話下；

自己則有一種被問題包圍的錯覺；

產品、運維、專案、業務、技術、網路、軟體安裝等各種問題；

很顯然，「**能解決**」的問題並「**不多**」，但並不妨礙問題持續不斷的拋過來；

這裡說句題外話；

以前聽說，程式設計師會修電腦，我是不信的；

現在的話，自己信不信不重要，身邊的親友和同事堅定的相信；

這些**爆發性**的問題如何解決？

【1】建立一個臨時的問題收集文件，把各種問題的描述和截圖先記錄下來；

【2】跟進問題，優先選擇業務屬性高的解決，其次處理影響流程的問題；

【3】如果是當前非必須處理的事，或者團隊暫時解決不了的，正面回覆即可；

其實，單人單崗模式在缺人的情況下，很多事情的處理都需要臨時的「**思路轉換**」；

**從心態上來說；**

不要以缺人為由，將問題打個「**死結**」；

優先給一個完整的臨時解決方式，並且儘量避免多人協作，放大問題；

以這種態度，支撐了一週；

大部分業務問題都得到了解決，當然這也很依賴於團隊精細的「文件」積累；

至於其他的問題；

擺爛，心寬；

# 06

個人的職場原則；

該做的事，能做的事，都盡力做好，做不了的事情，自然也「**拒絕**」的很果斷；

做個「**45度**」的打工人；

比如短短一週，所遇到的各種奇怪「**要求**」；

某個路由器的網路檢修，**拒絕了**；

新人入職電腦安裝系統和軟體，**拒絕了**；

某個外包專案做驗收，**拒絕了**；

在那一週過後，公司流傳一句話：研發部那個誰「**好菜**」啊，什麼都不會；

最後，部門老大開玩笑的說；

團隊內部，任何崗位你想轉去玩幾天，都批；

我認真想了想，這兩天打掃衛生的阿姨沒來，想代替幾天，「**被拒絕了**」；

這個魔幻的職場，愛了；

**Gitee主頁**： https://gitee.com/cicadasmile/butte-java-note

![](http://img.blog.itpub.net/blog/2023/04/26/c91ed6f1a8565908.png?x-oss-process=style/bb)

打工人逃不開「單人單崗」

相關文章