58 到家技術總監常柱:從組織到個人的提效建設 時間精力投資法 組織提效的持續建設 產品、設計、研發如何高效協作? 給開發者的高效工作建議

本期大咖:常柱

58 到家技術總監

從事互聯網技術研發和管理 10 餘年,負責業務&技術中臺能力體系的建設和技術團隊的管理。


行業競爭激烈,組織效能成核心競爭力。產品經理、設計師、開發工程師是組織執行關鍵角色,三者的工作及協作效率直接影響組織完成項目的效率。

本期【藍湖大咖訪談】,有幸邀請到 58 到家的技術總監常柱老師,爲大家分享產品、設計、開發如何高效協作,以及高效開發者的工作建議。

時間精力投資法

大家好,我是常柱,現在負責 58 到家業務 & 技術中臺的技術團隊管理工作。我每天的工作內容包括:

👉 處理團隊內外事務性工作

👉 參與各種溝通會議

👉 處理各種突發事項等

除了工作,我還運營個人公衆號,堅持周更。我總能按時完成所有計劃,是如何做到有條不紊的呢?

在事多的情況下,高效做事是基本。其次是,合理的分配、利用時間。我實踐比較有效的方法是時間精力投資法:將精力投資在關鍵要務之上。

具體的一些策略如下:

✅  會授權

技術管理每天會接到海量需求,凡事親力親爲,需求很難按期完成。工作需求要授權給團隊內合適的人,重點關注在梯隊、通道、流程、原則上,讓團隊自主運轉迭代,依賴團隊的力量來成事。

✅  批處理

分類記錄事項,非緊急的小事批量處理,管理好乾系人的預期。

✅  做減法

精力聚焦在覈心要務上,不貪多,集中精力做高價值的事情。

我們一天要處理的事情很多,有時還會新增工作,容易擾亂當前計劃。真正高效的人,對自身要做的事情都有掌控感,有適合自己的工作系統,高效完成計劃。比如,          

組織提效的持續建設

個人高效能把事做好,組織也同樣。效率是衡量組織價值的一個重要指標,提升組織的效能是每一個負責人最重要的工作。

效能提升是一個系統工程,不可能一蹴而就,需要持續的建設。個人對此的主要思考有以下三點:

✅ 首先,在競爭越來越激烈的這個時代,一定是高效的組織,高效的業務模式,在不斷的替代和淘汰低效的組織和模式。組織要跟上時代的步伐發展,需要持續關注效率的提升。

✅ 其次,效率提升是一個系統化的工程,需要結合組織內外兩個視角整體思考和行動,纔能有效的提升組織效率。

✅ 第三,效率提升需要從內做出改變。改變是反人性的,大部分人都不太願意接受。管理者需要從組織、績效,管理等多個維度採取有效的策略,一步步改變組織環境,保障組織的價值和輸出效率。

總之,效率提升是組織的核心課題,需要組織內所有角色的關注。上到管理者,下到普通員工,羣策羣力才能提升組織整體的效率。組織要在做正確的事並將事情做好的基礎上,提高效率,更好、更快的達到目標。     

產品、設計、研發如何高效協作?

我們的技術團隊主要由後端 RD,前端 FE,測試 QA 等專業人員組成,技術團隊的上游是產品經理 PM,下游是運維 OP 等。每個角色的工作內容、工作習慣、思維模式都有差異,如何才能高效協作呢?

我們首先要理解分工和協作的本質:分工是提升個體的效能,協作是提升系統的效能。如何提升整個產研系統的效能,個人經驗總結爲以下四點:

1. 信任爲本

信任是打造團隊效能的基石,缺乏信任的團隊,是無法建立起一個王國的。靠得住的個人成就充滿信任的團隊,互聯網行業節奏快,把精力花在解決問題上而不是形式主義上的靠譜之人,更容易得到團隊夥伴的信任。產品、設計、研發之間需要維護彼此的信任賬戶,通過一次次的成功合作來夯實。

2. 目標一致

團隊成員之間要有統一的目標,例如,一體的 OKR( 即目標與關鍵成果法,是一套明確和跟蹤目標及其完成情況的管理工具和方法),項目制度等。

由目標一致的成員組成的團隊,在項目執行、落地時,表現出向心力,極大提升協作效率。

3. 邊界清晰

產品、設計、研發的工作都有極強的專業性,專業合作需要有清晰的工作邊界,成員要做好自己的工作,不要越界、濫下定論等。

❎  舉個反例:

PM 只提一句話需求:滴滴的這個功能,你照着做一個,會不會?

RD 回覆:這個需求太複雜做不了。

此處正確的做法是:

✅ PM 輸出有質量的需求,記錄在案;

✅ RD 要給出合理的解決方案;

✅ QA 要輸出測試用例和報告等。

每個角色做好分內之事,而不是過度干涉他人工作。

4. 標準統一

管理者要明確各個工種的工作產出標準,讓上下游對結果有合理的預期,標準之外的非專業人士只能給建議。

例如:

👉 PM 的需求輸出標準是什麼?

👉 達到什麼樣的標準纔可以讓 RD 去做需求評審?

👉 RD 的方案設計達到什麼標準才能進入開發階段?

明確的標準,可以減少團隊內很多衝突。

協作是期望達到 1+1>2 的效果,我們需要抓住本質,根據團隊具體的情況,採取有效的行動。比如說,產研團隊可以藉助藍湖解決溝通、標註。切圖難題,讓協作更高效。

除了協作效率,影響項目成功的因素還有很多。在項目生命週期中,越往前階段的輸出結果的正確性越重要,要在關鍵節點上做好控制,提升決策質量。

例如,產品需求的價值和方案評估,技術概要設計評估,發佈方案評估等關鍵節點,我們都要重點關注。

給開發者的高效工作建議

1. 從信息系統思維到業務中臺思維

信息系統思維是開發工程師最典型的做事方式,缺點是在迭代較快的系統下,做事效率低,效果差。我建議開發工程師們轉至業務中臺思維,靈活快速的迭代需求。

什麼是業務中臺思維呢?

是工程師和架構師思維,重點關注點從數據轉向業務領域模型。開發接到需求後,第一件事是抽象業務領域模型和業務的標準流程,再考慮數據的儲存和接口設計。

中臺思維的核心是閉環和複用。將業務能力 SOP(標準操作程序)化,且能自我閉環。閉環後的 SOP 能力模型才能最大的複用,複用才能降低邊界成本,才能產生更大的價值。

例如你和老友聚餐,點了幾個美味小菜,下單後,就可以開心聊天啦。餐廳後廚會按其 SOP 的能力,按時交付美食給你享用,而不是上一堆半成品原料,讓你自己來動手。

對應業務中臺,中臺輸出給業務的一定是一個極簡的可運營的能力,可以快速配置上線運營。而不只是提供一堆 API 給上游業務團隊,再由業務研發團隊開發系統。

中臺思維需要我們有用戶思維、系統思維、抽象建模的多種思維模式。對開發者來說,無法解決問題時,不侷限於代碼層面,從多個維度思考方案。站在用戶的立場上,多思考和實踐,不斷構建和豐富業務模型。

對於個人能力體系,也可以按照中臺思維來構建。豐富能力工具箱,就可以做到一個人活成一個團隊,高效完成任務。

2. 堅持流程和原則

技術團隊經常遇到需求變更的情況,導致項目上線時間延遲,開發作爲落地環節,不僅要加班趕工,還要背鍋。因此,開發工程師堅持流程和原則很重要。

對於技術團隊來說,需求變更是很正常的事情,出問題也很正常。面對問題的處理方式能體現一個團隊或個人的擔當,是積極的解決問題呢,還是忙着甩鍋,這是本質的區別。

作爲開發,首先要堅持跟其他部門同事的合作原則:

✅  承諾即負責,確認、承諾過的需求,就要負責到底。無論過程中出任何問題,都要優先負責解決,而不是忙着去甩鍋。

✅  將事做到明處,如果確定需要變更需求,要全團隊一起評估,根據實際情況調整計劃。

✅  對於不合理的需求要學會說不,儘可能的不做需求變更,非核心的需求一律到下個版本迭代。

一個真正好的流程和原則,會明確做事的責、權、利。通過系統規則方式,減少團隊之間的摩擦。堅持這些原則,開發環境更好,開發更高效。

3. 避免壞習慣

一個優秀的開發者,首先是一個優秀的合作者和優秀的問題解決者,我們要避免三種不好的習慣,具體如下:

❎  反饋黑洞

有效的交流是雙向的。沒理解要及時問,有問題要及時溝通,不能等到最後自己兜不住了再說。職場中提問題不可怕,總成爲問題製造者纔可怕。

❎  孤狼

一個人一條槍就能做成事的時代已經過去了,現在要成大事需要與不同的人合作,能整合資源和力量者纔是這個時代最厲害的人。技術需要拋開個人英雄主義的幻覺,成爲一個優秀的合作者。

❎  老油條

油膩會傷人害己。年輕人和中年人要避免職場油膩。不喜歡可以選擇離開等。

我近兩年讀書比較雜,從團隊管理,思維認知,到心理學都有涉及。最近讀到一本有收穫的書是迪士尼 CEO 的《一生的旅程:迪士尼 CEO 自述批量打造超級 IP 的經營哲學》,書中有大量關於個人職場成長和公司團隊經營等多個維度的原則和經驗總結,值得我們每一個人參考學習。

👏👏👏 本期【藍湖大咖訪談】就到這裏了,感謝常柱老師的傾情分享。湖湖受益匪淺,你呢?

你有什麼問題想請教大咖?歡迎在文章評論區留言~~

用藍湖,不加班!

藍湖網址:LanhuApp.com

藍湖,高效的產品設計協作平臺

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章