產品研發組織的三個頑疾及破解

• 2019 年 12 月 11 日
• 筆記

本文起源於一次部門周例會，在這次例會中，我們可愛的產品經理和研發經理，在工作彙報過程中，清晰地「演示」了互聯網公司中產品研發工作的常見問題，也是嚴重且根深蒂固的三個問題。

本文通過對這幾個問題的探討，希望能對今後的工作有所啟發和指導。針對每個問題，通過四步闡述：現象(問題表象)、導致(的後果)、分析(原因）、建議(方案）。

技術架構邊界不清導致複雜性和風險性

現象

l 變更很小但與許多場景關聯，需要大量人工回歸測試。

l 變更很小但業務邏輯糾纏在一起導致程式碼很複雜，難於修改和判斷正確性，需要大量時間且風險很高，建議重寫程式碼。

l 系統功能經常因依賴系統/模組問題導致不工作，且不能降級提供服務 和 直觀定位問題，立即告訴使用方問題原因和建議行為，或者立即通知系統方發生什麼故障，指導人工干預。

導致

複雜性導致小變更需要慢修改和大測試，工作受困於技術的歷史負債，無法輕裝上陣，嚴重降低研發團隊的生產率和產品品質。

系統故障無論是系統自身引起還是依賴服務引起，用戶都會認為是所用系統的問題，時常要為依賴服務的故障背鍋。當然事後解釋有些用處，但總是太被動且效果有限。

分析

這些問題的直觀原因就是程式碼複雜，程式碼複雜的直觀原因就是各類元素多、元素之間的關係多、程式碼行多，要知道普通人舒服處理要素的數量在3~7個，更多就會蒙圈。

元素及關係多因為沒有很好地抽象和封裝為高內聚低耦合的模組/組件/對象/服務等。另外一種常見原因就是思考問題的方法和模型不當。傅盛說過：複雜性往往來自高維簡單問題到低維的映射。舉個例子是以地球為中心，太陽系各個行星的軌跡很複雜，如果以太陽為中心，軌跡簡單明了。

另一個問題是回歸測試需要投入大量人工進行，正確做法是通過積累自動化測試案例，保障回歸測試自動進行。不過要做好自動化回歸測試同樣依賴一個好的設計，便於測試案例針對介面契約進行。

建議

解決複雜性並不容易，軟體架構與設計是一個很專業和很龐大的領域，這裡簡單提一些方法。

如何才能減少系統元素數量？通過抽象技術和封裝技術，隱藏複雜性到組件之內，組件通過穩定的介面契約交互，而不用關心介面內的行為（組件邊界內部的實現行為）；通過分層技術，可以逐層進行封裝，逐步逐層把大系統複雜性限制在可控範圍內。

抽象及封裝技術不僅僅是降低複雜度，更是組件/服務獨自演進的基礎，邊界清楚了就能各自行動，糾纏在一起大家誰都動不了。

系統邊界要隔離，弄一個防護的安全地帶，依賴的系統外服務出了問題，要及時能監控到、把故障隔離到局部範圍、避免連帶問題、能進行降級服務。

自動化回歸測試是很重要的手段，核心還不是自動化測試工具，而是積累足夠多、覆蓋完全的自動化測試案例，它保護對系統的修改沒有引起新問題。

工作邊界不清導致大量串列和同步工作

現象

l 其他團隊沒有空檔能配合我們排期，暫停當前的需求設計開發等工作。

l 缺少配套要素支援工作開展，如設備沒到位則不上線，測試環境不具備則不驗證等。

l 業務方還沒有提交我們需求文檔，後續工作還沒法開展。

l 研發都在忙於某某項目，沒時間開發這個需求，所以沒有對這個需求進行詳細設計。

導致

被依賴工作不能開展阻礙依賴的工作的開展，相互依賴的各方越多，互相阻礙的概率越大，影響也越大。

此時，更多的合作夥伴沒有成為工作的加速器，反而成為工作的障礙。

串列方式在上游工作未完成之前，阻礙下游工作開展；同步工作在任意一方沒有準備好則無法開展。這兩種類型的工作比較多時，會大幅度降低資源利用率和靈活性，進一步影響效率、工期、成本等。

從精力管理視角來看，這會干擾甚至打亂自己和團隊的工作節奏，節奏不整齊，效率自然低。

分析

這些問題是由上游、下游、供應商、同級夥伴、所需資源之間的依賴性導致。實際上依賴是天然存在的，否則大家就沒關係了，實際做的方法是降低依賴程度。

互聯網公司出現此問題更多是組織管理問題，主要情景有：

l 事情很多做不完，既然有好理由放一放就先忙那些推脫不掉的事情。

l 自己先行做完自己的事情後，其他事情後續未必跟的上來，這樣白白浪費自己工作，畢竟互聯網公司的很多需求一旦停下來就可能永遠沒機會再做了。

l 邊界的定義未必到位，基於定義的邊界先行開展工作，後期難免要修改，浪費自己精力。

l 還有些工作，雙方都認為應該對方做更好，這樣子誰先做工作就有更大可能承擔那些模糊地帶的工作。

建議

降低依賴的重要方法還是界定清楚邊界，大家按照之間的約定完成各自工作，然後交由下游或者需求方，降低自己工作節奏受外部因素的影響。例如產品經理的輸出是經過評審的產品需求文檔，無關目前是否有研發開發；測試人員設計測試案例的輸入是需求文檔、輸出是測試案例，不需要系統已經開發完成；開發工作按照介面完成和驗證，無需其他相關模組是否完成。

降低依賴的另一個方法是拆分工作，依賴程度不同的部分拆分開來，那些不依賴的部分就可以先做起來，例如設計的/幹活的/檢查的/簽字的等分開。

以「巧婦難為無米之炊」為例，沒有米時也可以先把鍋、水、柴等準備好。沒有足夠的生產機器就可以先部署在少量機器上，進行試用、支援早期少量業務，業務量提高後再進行擴容。即使業務方沒有提交需求，產品也可以基於理解做部分產品設計，業務方提交需求後再進行補充修正。

業務流程優化的許多方法有助於依賴降低，有許多這方面的資料，從流程視角看，儘可能縮短關鍵路徑，減少那些串列和同步進行的工作，增加獨立的自由開展的工作。工作之間關係不應該是串列和同步，而是疊加和輪動。

如果是組織管理導致的問題，由於合理原因和不合理原因都可能存在（借口推脫和怕浪費自己工作兩種情況更常見），管理者需要清楚實際緣由，針對性應對，不能簡單地統一處理。如果是借口，指導團隊降低依賴性讓工作正常開展。

工作缺少規劃和重點，開展起來忙閑不均、效率低下

現象

l 對業務方(上游)需求以被動響應式方式接收，也就是完全由業務方提需求、提啥就是啥、不提就沒有。

l 開展哪些重點工作由業務方(上游)要求什麼決定，也就是工作重點挑選完全由業務主導。

l 工作的節奏主要由(上游)給予的壓力決定。也就是工作的緊急程度完全由業務方說了算。

導致

產品團隊不能主動挖掘、引導、完善合理需求，以及難以拒絕不合理需求。

難以在業務方要求基礎上，主動結合產品規劃、演進路線、需求關聯關係、技術難度、開發工作量、割接風險等對業務方進行影響，做出更合理的建設計劃和步調。由於接收的需求都是眼前要做的，很少有機會從一大堆中挑選更合適的去做。

業務方催的緊就忙死，催的不緊就閑會，這種重點失衡、節奏失衡自然導致效率低下。

分析

被動響應式的工作基本上是"腳踩西瓜皮、滑到哪裡算哪裡"，也就不會有什麼清晰的整體規劃和有效的中長期工作計劃。

實際工作中總會有做不完的需求，不會無事可做。但整體規劃和重點工作挑選的不足，會嚴重影響工作的組織安排。可能工作特別忙但沒有做到重點，導致最終結果(績效)一般。可能工作不怎麼忙，所做事情重要性也不夠，結果就更糟糕。多數情況下，會有選擇地做「重點」需求，拒絕一部分「不重要」需求。但由於整體規劃和重點內容缺乏且達成共識，本能的擇優缺乏有效支撐，準確度有限，總體效率自然也就低了。另外，這種情況下需求方頻繁感受到的是"被拒絕"，抱怨自然難免。

缺少整體規劃必然缺少重點，重點是從整體工作或一組工作中挑選出來的，缺乏整體就難以有效地挑選重點。

陷入日常的瑣碎需求，就缺少大塊時間和充分準備(緊急事務會撕碎大塊時間)，解決那些高難度的重要問題和重點需求，業績自然就不會好；日常瑣碎需求，數量繁多導致思考和準備倉促，風險和故障卻並不見少。

業務方由於缺乏對技術的深入理解和關注，所提要求不會結合技術實際情況。雖然雙方均難於成為對方領域專家，但業務人員理解技術相對技術人員理解業務更困難一些。缺少對產品建設理解的業務方，提出的要求必然具有不合理成分，無法讓雙發利益最大化。

建議

業務團隊和研發團隊本質關係還是甲方和乙方的關係。如果定位錯誤，例如是平等關係、業務方有求於研發團隊，後續的一系列工作都會出現問題。但在一個公司內部，清晰做出恰當定位且能有效貫徹執行動作不變形，其實並不容易，畢竟人性使然。

看看業界這種關係乙方都是怎麼做的：

l 主動、深入理解甲方(業務方)需求（否則憑啥讓你干），深入挖掘甲方進一步需求（不能做完一單就丟了）。

l 維護好雙方關係，腿要快、嘴要甜、腦要靈、能自己乾的就不要麻煩對方，能替對方乾的就不要對方自己干（拓展服務內容）。

l 不刷滑頭但要聰明做事，收錢時不要手軟。

公司內部業務方和研發團隊不是市場上的甲方乙方。基本規則還是乙方服務要專業，甲方回報要足夠。研發團隊的專業性表現在洞察業務需求、主動積極服務、維護良好關係；業務團隊的回報足夠體現在充分配合研發工作、努力爭取研發資源、積極宣揚研發工作價值。

研發團隊能力成熟度重要標識是：與業務方一起建立產品整體規劃和重點事項，能在多長時間內讓實際工作內容與規劃內容保持一致，當然是時間更長更一致的能力更高。

最後再多嘮叨一句：堅持「要事第一」的原則。此原則順利執行的前提是具備全局觀和前瞻性，否則就無法從一堆事中挑選出重要的事。