LeSS案例之Sys商店（上）

前言

業務敏捷可以定義為一個組織重塑自我并快速適應環境變化的能力。克勞斯.利奧波德在他的書《Rethinking Agile》中提出，人們需要優化交付客戶價值的流來實現業務敏捷。通過優化流，你遲早會注意到需要組織結構做什么樣的調整來加以支持。

首先，關鍵是理解敏捷的真正含義，就像敏捷宣言中構想的那樣，它并不是組織交付客戶價值的速度，而是組織以低成本快速響應變更的適應性。（參閱《Scaling Lean & Agile Development》中?Be Agile_一章）。利奧波德對于組織變革還有這樣一個觀點：在持續地關注系統優化目標時，人們會注意到那些阻礙改進的因素。然而通過系統思考，長時間在實地的觀察和實踐，對現存系統動態的反思，人們也可以預見到那些阻礙快速適應能力的相對明顯的現存組織障礙。在這個故事中，一個組織學習并最終看到影響大規模適應性的組織障礙，它經歷了漫長而痛苦的過程。更糟糕的是，很多管理層試圖保持傳統管理現狀而僅僅將事物標記為"敏捷”，而不是去預見 - 或者愿意去預見 - 相對明顯的障礙并在一開始就進行必要的變革。簡而言之，這個過程恰恰反證了less中的關鍵導入原則（“對于產品團隊，要在一開始就建立less的組織架構，這對導入LeSS非常關鍵”_）以及由此帶來的后果。

所以，接下來的案例說明了，如果組織沒有在一開始進行合適的組織設計，會發生什么情況。從開始的傳統組織架構和管理方式入手，可能混有一點偽Scrum元素，LeSS要求的組織設計也許會浮現。但這將會是一個更長、更危險的旅程，因為它可能不會帶來導入LeSS所預想的好處。為什么？因為一旦沒有立即采用新的組織架構，那股保持組織現狀的強大力量極有可能會獲勝（參閱拉曼組織行為定律）。

本案例的關鍵"反事實"洞察：如果你想開始業務敏捷的旅程，期望減少過程中的許多痛苦，并快速獲得LeSS所預期帶來的適應性上的提升，一定要在導入LeSS的開始階段就建立合適的組織結構，就象LeSS規則所倡導的那樣。

開始之前的評注

LeSS就是（多團隊的）Scrum，Scrum就是單一團隊的LeSS。（參閱原則：大規模Scrum也是Scrum）。為了讓本案例中的描述更加準確，我還是會澄清哪些是Scrum指南中的規則，哪些是LeSS指導方略中的規則。在參與這個案例的過程中，我受到less.works網站的積極影響，參加了Bas Vodde和Craig Larman的LeSS實踐者課程，并花費了大量時間閱讀最初出版的兩本LeSS書籍。可惜的是那時第三本書還沒有出版。在這個案例中，我闡述了我們嘗試過的LeSS實驗，并且也會關聯我們遵循的LeSS原則、規則和指南，盡管那時并不知曉。

簡介

下面的案例涵蓋了我從2015年2月到2016年9月在一家公司Sys的IT組織做外部教練的時光。Sys是一家來自德國的從事軟件行業的跨國公司。因為我已簽署保密協議，所以不能在此公布公司的真名和其他相關的公司信息。時間回到2014年底，Sys著手用一個平臺來變革公司軟件銷售方式，取代現有各種外部合作伙伴平臺。這個平臺的誕生標志著Sys邁入電子商務新途徑的里程碑，不僅重新思考了如何直接地向客戶銷售軟件，還重新定義了賣什么（例如，除軟件以外的數據）和怎么收費。

這背后的想法是創建一個網上商城，客戶可以通過最小的交互，從Sys或是其他第三方軟件發現、嘗試和購買軟件、內容和數據。目標是通過電子商務產品"SAP Hybris Commerce"來提供像亞馬遜一樣的簡單流程，同時涵蓋多樣的產品部署（就地部署和云解決方案），支持不同的支付方式（信用卡和PayPal）。

2011年，我曾在負責所有內外部平臺的Sys IT部門工作過，這些平臺跟Sys商店很像，那時我們整個部門開始將瀑布模式替換成Scrum。在用（單團隊）Scrum的方式搭建了兩個平臺之后，我離開了這家公司，去支援其他客戶的敏捷之旅；在2015年的早期，我又重新加入Sys來支持這次重要的旅程。

變革之前

系統架構

在我加入的時候，有四個團隊并行工作，研發新功能或者增強現有平臺，并用固定的時間表合并代碼，然后進行好幾周的集成測試和驗收測試。系統格局是一個復雜的三層結構，包含基于Spring框架的主要J2EE應用程序平臺SAP Hybris Commerce，用于存儲數據的SAP Hana 數據庫，基于SAP PI服務器與SAP ERP和SAP CRM的同步，還有額外的第三方服務用作分析、處理信用卡支付或用戶生成內容的集成。

變革之前的組織結構

圖3是組織結構。有三個開發團隊，兩個在歐洲一個在美國，并行工作在系統的不同部分。還有一個架構團隊，負責新特性的軟件整體設計，以及一個測試團隊，在不同團隊的代碼合并之后進行集成測試。此外，另有一些后臺開發（SAP ERP/CRM）專家、DevOps專員和UI專家，他們沒有加入任何研發團隊，而是建立了自己的團隊。歐洲的團隊成員（隨機地）分布在德國、波蘭、西班牙、愛爾蘭和保加利亞。這是因為Sys只有六名公司正式員工，其他所有團隊成員均來自于專門從事SAP Hybris研發的第三方供應商。

除了技術團隊，還有一個超大的業務組織來支持軟件的研發和運營。在第一層，經理們帶領一個小團隊來進行特性的優先級排序、編寫藍圖、執行用戶驗收測試并啟用功能。在第二層，又有一個團隊專門負責整個產品組合、需求排序以及業務方用戶驗收。在第三層，是由三個項目集經理組成的項目集管理，一個來自業務（Sys Digital），一個來自Sys IT，還有一個來自Sys Education的項目總負責人。另外，還有一個支持項目集管理的項目和質量管理辦公室。為了跟蹤研發和業務的進度，每周還有工作流周會，干系人狀態周報，以及從項目辦公室匯集到管理團隊的書面項目集更新。

痛苦的最后期限和變革的必要

當我在2015年2月底加入時，平臺基本上已經可以使用，只差正式宣布。各團隊還在沖刺最終官方發布日期：2015年5月5日。到時候公司會在美國舉行有史以來最大的會議，首席數字官會當場向公眾演示這個平臺。所有正在研發的功能都是官方需要發布的功能，所以，項目辦公室制定了一個看起來能在5月2號發布所有功能的嚴格的項目計劃。該計劃包含了研發階段、系統集成階段，用戶驗收測試以及回歸測試，就像我們通常說的瀑布模式。

在三月的最后兩周和整個四月項目進入一個動蕩期。時間表正漸漸延期。當并行工作在不同功能的團隊將他們的代碼合并到主代碼倉庫后，很多之前已經測試通過的功能不再能使用或者表現異常。不停修復這些問題又帶來新的問題，并且還經常突然接到必須立刻實現的新需求。在此之上，之前從未考慮過的安全問題和負載測試現在也必須解決。管理層變得十分焦慮，每個人不得不工作更長的時間來盡量滿足計劃。在四月的最后兩周，還建立了一個"作戰室”，所有的經理、團隊負責人和架構師都在這個房間從早到晚不停的清理障礙以保證發布的所有準備工作都做好。最后，開完數不清的升級會議和成百上千小時的加班之后，團隊終于能夠在大會的第一天發布平臺的新版本。

經過了如此痛苦的發布，對管理層來說，毫無疑問現有的研發方式已經不能支撐公司的雄偉目標，那就是銷售指數級增長，能快速嘗試新的商業模式和推出完全不同的產品。Scrum作為一個敏捷研發框架，專注于首先交付最高業務價值，持續關注透明性、檢視和調整，這些都建立在基于經驗過程控制的理論之上，它成了一個自然而然的選擇。然而要導入Scrum或者LeSS都被認為極其困難，不僅僅是因為組織層級設置和對分散在不同地方的各種技術專家的依賴，還受到巨大營銷渠道的影響，即每年有兩次不可更改的作為大里程碑的重要峰會。

引入變革

作為一個偏好大規模Scrum的經驗豐富的敏捷和Scrum教練，我被要求建議"研發部門"應該如何改變工作方式以應對當前的挑戰。 我的挑戰因此是（1）讓所有人都意識到為了應對挑戰_不只是研發部門而是整個組織要改變_；（2）幫助參與者_通過理解為什么_來**_擁有_**變革背后的想法，而不只是跟隨我的想法遵循我的建議而已。 在一次上層管理者（包含Sys首席數字官）的會議中，我展示了從和業務和研發代表的對話中收集到的關于挑戰的總結。它包括：

業務挑戰（摘錄）

單個特性和產品能力的優先級不明確

明確標注_已完成的工作在后期出現問題

技術挑戰（摘錄）

可用性和基礎設施問題（性能，端口關閉等）妨礙了日常運行

整個部署流程耗時太長。常常缺少某些部分（模版，后處理等）

“架構師"們忙于做構建流程、合并代碼、以及基礎設施的建立/配置這樣的手動任務

使用各種分支而不是基于主干的開發，導致代碼合并的工作量巨大；并且質量很低，有許多缺陷/問題

測試數據的的創建是一個非常耗時的過程并深受知識缺口的影響

在準備這個會議的過程中，我還收集了管理層的整體改革目標。基于與管理團隊成員一對一談話和訪問，我總結了如下幾點：

通過清除浪費來優化系統以更快地向客戶交付價值

給組織賦能以使其更加理解客戶并更快響應新的需求，還能從已發布的不足中學習和調整

改進交付代碼質量并減少缺陷/問題的數量

關注整體產品，對以客戶為中心的需求優先順序可視化

增加各團隊正在進行的工作的可見性

第二個目標跟LeSS中的整體系統優化目標是一致的，即學習并交付給付費客戶最大"價值"所需的最高適應性。其他目標可以通過對LeSS原則的特別關注而實現（例如：第一個可以用排隊論和精益思想）。所以我非常高興地看到研發團隊和管理層都喜歡應用Scrum，把它作為一個軟件研發框架并緊貼敏捷價值觀和敏捷原則。我個人覺得，為了成功，我們不僅要激勵那些有著清晰目標的個人，還需要得到組織高層的支持來移除障礙并賦能變革。這已在_LeSS指南三個導入原則（自上而下&自下而上）_中體現。

然而，我也注意到這里并沒有對Scrum的理解形成共識，需要一個工作坊來培訓所有人并對組織變革達成一致。這也體現在_LeSS指南：開始_中。

我在管理層會議中的總結報告中提出，在開始變革之前需要一些前提條件：

業務和研發需要對工作模式達成一致，才能幫助達成上述目標

我們需要（1）自組織的（2）跨職能的（3）同在一地的（4）長期的 團隊 （見LeSS結構規則）

團隊需要Scrum培訓，創建工作約定并對于完成的定義達成一致

建立產品待辦列表，包含技術項和業務項

管理層一致同意上述幾點，給了一個月的時間來準備過渡到新的工作方式。

開始

下面幾段描述了我們當時對組織變革還認知有限的情況下所做的幾個啟動步驟。我會將它們關聯到LeSS的指南和規則 - 我們遵循了哪些；更重要的是強調了那些我們本應做得不一樣的部分。

首先，我們組織了一個兩天的工作坊，參與者來自研發部和業務部。這個工作坊由我本人負責，并帶了一個助教，主要是做Scrum培訓。這個做法與LeSS的導入指南一致：LeSS指南：開始 0，培訓每個人。

在工作坊結束時，參與者理解到Scrum不是一項實踐或者一個定義好的方法，而是想be agile而非"do agile"所需要的組織設計變革。這個工作坊還在研發和業務之間建立了強有力的紐帶。

**回顧中得出的關鍵教訓是下一次這樣的工作坊要包含所有的高層管理干系人（而不只是幾個）。**通過讓高級管理人員思考LeSS組織設計的含義，例如團隊結構、層級結構、所在地策略、角色、流程和政策，不僅可以獲得對更改組織結構和政策的支持，還可以從一開始就建立正確的結構，這能省去很多麻煩 – 正如我們經歷的那些。

**第二個關鍵教訓是持續關注如何讓參與者探索、理解Scrum和LeSS的意圖、想法和組織設計變革的含義 ，而不是僅僅關注教授Scrum或LeSS的知識。**為了更聚焦在原因上，在LeSS原則（例如：系統思考、精益思想）的支持下，讓參與者從中導出他們自己的工作模式。這樣做使得他們參與更加深入，因為我們更少關注拷貝"最佳實踐"或者一個方法理論，而是理解系統優化目標、現有系統動態是如何符合（或不符合）該目標的，以及系統可以通過怎樣的改變來更加符合目標。

定義"產品”

就像_指南:開始 1. 定義"產品”_ 中說的，產品的定義是"你做出的最重要的決定之一”，因為它決定了導入的范圍、產品待辦列表的內容，以及誰是最合適的產品負責人。在我們的案例中，產品的定義受到產品愿景和已有的組織結構的約束。想了解更多關于約束產品定義的因素，可參見_LeSS指南：你的產品是什么？_

產品的愿景是"創建一個簡單連貫的數字體驗用于尋找、嘗試、購買和消費Sys軟件以及其合作伙伴的解決方案”，并"簡化客戶的數字購買過程和體驗，準確地提供他們想要的東西，在他們想要的時間和地點”。目標是通過這個由當時的CDO（首席數字官）帶領的Sys數字部門負責的電子商務產品來實現。電子商務站點用來提供來自Sys不同部門和其他公司的產品。在理想狀態下，產品的定義會隨著時間擴展（見_LeSS規則：產品的定義應該依照實際情況，盡可能廣泛，并以最終用戶/客戶為中心。隨著時間的推移，產品的定義可能增加。_ **更廣泛的定義是首選**）。然而從開始的角度來說，有限的產品范圍給了我們更清晰的產品定義。

一個非常棘手的已有約束是Sys的IT部門沒有任何研發工程師有SAP Hybris Commerce Suite的經驗。于是他們聘請了一家專長于此的公司，為他們提供了散布在歐洲各個地方的工程師。然而，就像我們將看到的那樣，這極大地影響了團隊的建立。

建立團隊

第三步，我們關注在建立團隊和首次組織變革。

之前提過，最初我們的特定組件團隊（比如SAP CRM后端或SAP Hybris Commerce)與單一職能團隊（比如架構團隊或測試團隊）之間是割裂的。在培訓時期，我們強調如果想要改進我們的能力來交付以客戶為中心的最重要特性的話，就需要建立跨職能、跨組件、穩定并長期存在的特性團隊。這反映了_第二條LeSS組織結構規則_，其背后的原因在_LeSS指南：理解特性團隊_中作為總結出現，其細節可參考第一部出版的LeSS書籍《Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum》。第二部LeSS書籍中的兩個實驗也表明了這一點：_避免單一職能團隊_和_避免組件團隊_。

新建的團隊用特性團隊來組織，包含了擁有不同技能的各類專家。最終我們建立了四個團隊，每個團隊里包含三到四個SAP Hybris研發，一個SAP后端研發，一個UI專家，兩個測試專家，以及一個專長持續發布的架構師。我們解散了專業測試組和架構組（把他們融入特性團隊），并建立了社區，在那里專家們可以定期交流并對齊工作方式。在"社區"部分我會就此詳細說明。盡管很不幸合同需要我們依然有帶著專家頭銜（比如"解決方案架構師"或是"測試專家”）的人，但是我們從一開始就明確團隊成員們"愿意把頭銜放在門外”，學習必要的技能并幫助他人以便能夠在每個Sprint結束時創造一個已集成的產品增量。

開始時每個團隊配備一個專門的Scrum Master，因為絕大部分Scrum Master和團隊都沒有LeSS的經驗。為了以身作則，我在其中一個團隊里擔任Scrum Master。通過我的培訓和輔導，一個前項目經理逐漸可以滿足Scrum Master的要求并在三個月后替代了我的位置。

在第一年，一個Scrum Master只能支持一個團隊，后來有些Scrum Master可以同時支持兩個團隊。他們的關注點從幫助團隊改進工作方式轉移到揭露阻礙團隊提升績效的組織功能障礙上。這反映在_LeSS指南：Scrum Master關注點中。

系統運作

Sys的IT部門曾經經歷過許多項目的實施，系統在幾個月到數年內被構建，但到某個時間點，預算就不再增長而只通過配備離岸團隊對系統持續運作和維護投資。在過去，這種方式會在"實施預算"快耗盡前引入一個"交接"階段。這里也包含了對離岸團隊的知識傳遞。這個"交接"階段總是十分痛苦，關注點常常只在為維護團隊創建"剛剛好"的文檔，而這樣會導致系統惡化，因為維護團隊對每個功能最初背后的原因沒有足夠的理解，而提供的資金也只能增加一些小的功能而不足以改進整個系統。

我們在"培訓工作坊"期間設法解決這個問題，保證有部分"維護預算"來將離岸研發人員一開始就整合到特性團隊中。他們剛開始對SAP Hybris Commerce系統或SAP后端系統一無所知，但通過結對和mob編程，他們逐漸能從"僅僅修復問題"到實現系統新增功能。這對系統的代碼質量產生了巨大的影響，因為（離岸）團隊成員特別關注技術債和必要的文檔隨系統而增長的事實，而他們將是"實施預算"耗盡后的持續負責人，所以常常是他們來提醒其他團隊成員關于系統質量的問題。

開始時未解決的組織挑戰

在團隊最初建立之后，仍有兩個挑戰未得到解決：分散的團隊和與業務人員的集成。雖然這在前期帶來了更大的問題， 它們在后來還是被解決了。

第一個挑戰是我們團隊太分散。之前說過，內部研發部門沒有人懂SAP Hybris，所以必須依賴外面的公司提供懂SAP Hybris的工程師。而這個公司的工程師散布在歐洲各個地方，大部分人在家辦公。在那時，讓所有團隊成員搬到一個地方長時間工作是不可能的事情，也沒有資金，所以我們建議先做兩周的啟動活動, 然后每六個月安排一次現場活動。讓所有人在一起辦公的效果太明顯啦，以至于大家很快都意識到這種差別。而對團隊結構的調整也極大地改善了團隊的績效。不到一年后，團隊就又重新組織，以使大部分成員在一個地方工作。

新的組織結構已經變成了圖六這樣。

第二大挑戰是與業務人員的集成。之前說過，組織里除了真正做市場調研或伙伴關系管理的產品經理們，還有很多在真正的研發人員和真正的業務人員之間的中間人。這些中間人忙于傳統瀑布中定義的任務，比如識別下一步做什么、描繪系統藍圖，或做終端測試。同時，研發部門已經習慣了與他們自己的（偽）產品負責人以Scrum的方式工作，這個產品負責人實際上只是一個中間人項目經理。在過去，這個人作為一個團隊與業務的接口而存在。在研發這邊還常常有一個帶偽中間人"產品負責人"身份的業務分析師，負責編寫需求和為研發部門澄清需求，以及一個帶偽"產品負責人"身份的項目經理充當業務人員和研發之間的唯一橋梁。當我們在"培訓工作坊"中討論這件事情時，大家都清楚這里有管理層的限制和缺乏管理層的支持來從一開始就直接改變組織結構。但是就象在接下來的"唯一的產品負責人"章節所述，這個情況導致了非常多的組織功能障礙。大約八個月之后，我們改變了組織結構，只有一個產品負責人負責整個產品，其他產品經理則對其支持。

啟動

“培訓工作坊"結束兩周后，研發和業務的代表們一起組織了一個大型工作坊，讓所有團隊成員都來參加這個最初的啟動活動。兩周內，所有的團隊成員都有機會相互認識，相互討論、反思并就他們共同希望的工作方式達成共識。

這個大型工作坊還涵蓋了兩天的Scrum培訓（所有人都參加），創建了最初的完成的定義（DoD)，建立了團隊和整體工作公約，最重要的是幫助團隊凝聚在一起。

對于我作為一個教練和其中一個團隊的Scrum Master來說，有一個很重要的事情是讓團隊盡快從"形成"階段過渡到"規范"階段和"高效"階段。當然在兩周內是不能達成的，但是理解了團隊發展動態，讓我們知道在這兩周內我們最主要的關注點應該放在建立一個共同目標和建立團隊成員之間的信任上。因此我們做了非常多的團建活動，取得了巨大的成功。

完成的定義

在這兩周"啟動"會議中，所有人都來到了現場，來建立一個適用于所有團隊的初始"完成的定義”，如_LeSS指南：創建完成的定義_描述的那樣。在這個工作坊，我們與所有成員一起探索為了交付產品（潛在可交付產品增量）我們需要做什么，并將所有團隊那時已能在日常Sprint中做的活動和產品發布所必需的其它活動區分開來。這也是我們第一次深入討論不同類型的測試和文檔，并設法讓大家對于工作方式達成一致的理解。

圖7中劃線的條目是大家一致同意放進初始"完成的定義"中的條目。其他都算作"完成之外的工作”，即不在"完成的定義"中但也是交付產品需要滿足的條件。開始時這個"完成之外的工作"非常多，而我們最終目的是讓所有在"完成之外的工作"中的條目最終都包含在"完成的定義"中。在隨后的"發布Sprint"章節我會解釋我們是怎樣處理這些"完成之外的工作"的。隨著時間的推移，我們通過整體回顧會議漸漸擴展了這個初始"完成的定義”。

唯一的產品待辦列表

對我們而言，重點之一是從一開始就有唯一的產品待辦列表。這也符合_LeSS規則：一個整體交付的產品只有唯一的產品待辦列表_。

業務方原有的組織結構和不同產品經理的職責分配給我們的開始帶來了不少挑戰。不同的產品經理負責在電子商務網站上發布不同的Sys產品，這導致了優先級的沖突。在過去，每個團隊有一份他們自稱的"產品待辦列表”，由一個橫在真實的業務人員和團隊之間的帶偽"產品負責人"身份的項目經理來對團隊待辦列表上的條目進行排序。這導致了局部優化，因為每個團隊的"產品負責人"只關注交付產品的某個部分，而缺乏整體視野。結果就是每個"產品負責人"都在爭取交付更多的功能，而期望"其他團隊"來改進整個產品和發布的流程。當然，這并沒有發生。

我們的目標是讓真正全局重要的（已經確認包含在里程碑中的）條目包含技術條目可見。我們嘗試了用戶故事地圖。想法是在地圖上標注所有的重要條目并重新組織它們以使得我們能夠把所有重要條目放在一起來討論和排序。通常情況下，在產品待辦列表梳理結束幾天之后，在Sprint計劃會議開始的幾天之前，基本上是每兩周，產品經理團隊（包含偽PO們）會花大約兩個小時來展示和討論各個梳理結果，并就要帶到下次Sprint計劃上的產品范圍達成一致。這樣做的優點是為業務方下次里程碑上需要實現的條目創造了可見性，包含了團隊在梳理中對條目所做的估算，以及有多大可能在一個Sprint里能實現這些條目。這樣做的挑戰在于，它引起了許多激烈的討論，因為每個產品經理都有一些"個人目標"要實現，因此幾乎不可能達成共識。這導致了一段時間之后在誰負責排序這個問題上的改變。

唯一的產品負責人

之前說過，開始的時候我們在研發方有一個帶著偽"產品負責人"身份的業務分析師，在真正業務人員與團隊研發人員之間有一個帶著偽"產品負責人"身份的項目經理，我來講講這件事的背景。在2011年早期開始把（單團隊）Scrum作為研發框架導入組織的時候，由于不夠理解Scrum和真正的Scrum Master或產品負責人是什么樣的，來自Sys IT部門的項目經理們被要求選擇是否想把自己變成所謂的"Scrum Master"和所謂的"產品負責人"來滿足新的工作模式，這當然沒有真正改變什么（見拉曼組織行為定律 #1和#2）。一部分前項目經理選擇成為"Scrum Master”，另一部分選擇成為"產品負責人”。這給大多數前項目經理形成了巨大的挑戰。困難的部分并不在于學習新的未知技能（比如個人或團隊輔導），而是與軟件研發團隊工作時放棄原先的信仰和行為模式（比如在自組織不發生的情況下如何做）。這導致事實上在我們團隊里只有一個前項目經理后來保持作為Scrum Master（并且這個人向公仆式領導者的轉變非常快）。因為只有頭銜變更而組織結構和政策都沒有相應變化，并沒有真正的_產品負責人_成為"產品負責人”，而只是重新把項目經理標記為偽"產品負責人”。

這種每個團隊帶有兩個偽"產品負責人"的非常規設置，是基于沒有理解導入Scrum的意圖，在開始的時候感覺還不錯，因為研發團隊有了"業務現在已經靠近研發"的錯覺，并產生有了研發團隊獲得客戶期望的"高效渠道"的假象。然而這導致了兩個主要問題：一是讓團隊"產品負責人"們負責團隊的"產品待辦列表"會導致局部優化，如上所述；二是團隊的"產品負責人"們（業務分析師）逐漸成為團隊理解需求的中介和瓶頸。讓偽產品負責人編寫產品需求說明書，然后遞交給團隊來"實現”，這樣的做法產生了大量的浪費，比如交接問題、延遲、過度處理、在制品和缺陷。

整個產品只有唯一的產品待辦列表，并按時（每個Sprint）討論，我們確保了團隊"產品負責人”/項目經理們可以改變一些條目的優先順序，但還有其他人可以管理團隊正在研發的所有條目的優先順序。有時候，團隊"產品負責人"們所定義的優先順序并沒什么意義，因為團隊最終會工作在其它相對于整體產品更關鍵的條目上。終于到了某個時刻，其他項目管理部門的人在優先順序上花費的時間越來越少，只有唯一的一個非常靠近CDO的人來負責對所有團隊的所有條目排序。

第二個問題的處理（團隊產品負責人是信息瓶頸）更加困難，主要是因為公司本身的約束。事實上，團隊成員對和客戶澄清需求感到不舒服，或是缺乏這方面的技巧，或是相信由一個人來做需求澄清同時其他人專注在研發上會更加（局部）“高效”，亦或是偽產品負責人團隊（項目經理們和業務分析師們）有著不一樣的身份和薪水 – 所有這些都讓它成為一個巨大的挑戰。

由于篇幅限制，后續內容見：LeSS案例之Sys商店（下）

敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。