組織結構圍繞產品來構建，負責整個工作過程。反轉康威定律，圍繞產品建立長期團隊，保證穩定性，簡化管理和工作優先順序制定。回顧是乙個強大的產品管理工具；它們可以提供繼續工作的信心，並能幫助你在組織可能面臨風險或損失的情況下快速調整方向。
\u0026#xd;\n\u0026#xd;\n
在experience敏捷2018大會上，敏捷教練、培訓師、演講者兼顧問ardita karaj會做一場題為「我的產品是什麼」的演講。此次大會將於10月1日到2日在葡萄牙里斯本舉行。
\u0026#xd;\n\u0026#xd;\n
infoq將以q\u0026amp;a、概述和文章的形式對experience敏捷大會進行追蹤報道。今年的會議主題是「借人改善（improving through people）」：
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n發現全世界行業領導者最新的敏捷實踐。experience敏捷大會不止是另外乙個敏捷大會。這項活動將帶來現如今最具創新性的敏捷應用。
\u0026#xd;\n
infoq採訪了karaj，內容涉及為什麼組織中的人採用專案思維以及導致的問題，產品思維如何幫助我們找到更好的工作方式並持續改進，如何把敏捷回顧與產品思維聯絡起來，組織要想從專案思維轉變到產品思維需要做什麼。
\u0026#xd;\n\u0026#xd;\n
infoq：您將會為大會帶來什麼？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nardita karaj：在此次大會上，我會參加兩場會議。第一場是乙個研討會，幫助沒有經驗的團隊啟動乙個敏捷專案，關注價值、客戶和協作。第二場是第一場的延續。通常，我們看到第乙個敏捷專案取得成果後，我們會照例重複同樣的事情，乙個專案又乙個專案，期望獲得更好的結果。我們忘了敏捷的基礎之一「檢查\u0026amp;調整」。我認為，組織應該利用最初的敏捷專案學習，然後需要檢查並調整到更好的方式，這是產品/服務/客戶之旅的基礎。
\u0026#xd;\n
infoq：為什麼組織中的人仍然使用專案思維？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nkaraj：不使用專案思維的難度是簡單、困難，還是非常困難，取決於組織。這是因為長期以來，這些組織一直採用這種模式，並建立了一種支援和保護這種模型的結構。撥款是根據專案來的，人是按專案分配的，**和目標也是按專案設定的。乙個組織要切換到不同的運營模式，許多結構都需要調整，像財務、人力、業務交付團隊、設施、運營、市場、銷售等等。我們需要變革業務和開發/it/運營的關係，我們認為，同一組織的不同領域構成了「成本中心」，而不是合作夥伴關係。
\u0026#xd;\n\u0026#xd;\n
這些變革並不容易，需要有影響力的、受過良好訓練的領導者。我見過有的高層領導者，雖然他們知道變革的主要價值，但是，他們承擔這些角色的時候，無法在短期內執行。那需要大量的工作、忘我精神、政治容忍度低、時間投入。這些通常是組織面臨的巨大挑戰。因此，他們採取的措施是，在專案的後續工作中小幅改進（最好的情況下使用了敏捷），並且知道，他們沒有發揮出自己的最大潛能。
\u0026#xd;\n
infoq：這導致了什麼問題？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nkaraj：從比較高的層面上說，專案是區域性優化工作。我們讓一組人為客戶建立（或改進已有的）功能，然後交給乙個不知道為什麼變更、也不知道這個變更如何實現的團隊。通常，質量很低，而運維團隊需要處理問題。這就形成了一種容忍低質量的文化，接受運維團隊處理交付團隊造成的問題的現實，使得交付團隊不能從錯誤中學習，導致他們會重複犯錯，使得預算制定缺少恰當的資料，把人看成是很容易替換的物件，等等。這種文化下，人們的期望比較低，往往會帶來多方面的債務，如技術、產品、人才、創新等等。同樣地，這些組織經常執行在反應模式下，不斷追趕競爭對手推向市場的東西。變革的成本很高，需要花很長時間才能交到客戶手中。
\u0026#xd;\n\u0026#xd;\n
不知道你有何感想，在我看來，我們不希望成為這種組織的一員:)我不會為自己幹的事情感到自豪，我會擔心組織的命運。
\u0026#xd;\n
infoq：產品思維如何幫助我們找到更好的工作方式並持續改進？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nkaraj：圍繞產品（或服務）構建的組織有優勢，因為他們的組織結構可以監督整個工作過程，就是說，從想法到客戶，並基於客戶的反饋或反應想出新點子，形成閉環。我這樣說，是因為團隊為自己負責，對所提供的方案、交付質量、客戶體驗和滿意度有主人翁精神。
\u0026#xd;\n\u0026#xd;\n
把價值交付的所有方面都視覺化，我們就可以理解產品和交付過程，找出瓶頸，傾聽客戶的聲音，收集資料，並隨著時間推移做出更好、更明智的決策。企業就能夠知道投資的錢去了**，更好地**對銷售的預期影響。市場和產品管理部門對組織的能力就有更好的把握，做出明智的優先順序決策，轉向特性和服務試驗。這樣，我們就可以減少向客戶交付低價值或無價值產品的風險。
\u0026#xd;\n\u0026#xd;\n
在這些結構中，還有另外乙個積極的因素，就是感覺到團隊很長久。這些團隊會給目標不斷變化、需要做許多決策的商業世界帶來穩定因素。我們知道每個團隊每個月的成本，我們知道保持組織執行所需的資源（我指的不是人）成本，這樣，我們就可以把注意力更多地放在管理和安排工作的優先順序。長期團隊有機會測試和學習，檢查和調整，創新和顛覆，從而創造出更好的產品和結構。
\u0026#xd;\n
infoq：如何把敏捷回顧與產品思維聯絡起來？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nkaraj：回顧是「檢查和調整」、「持續改進」、「持續學習」及其他類似實踐的核心，而這些實踐是產品在市場中保持良好表現和強大競爭力的重要因素。如果產品管理團隊不停下來評估一下，客戶價值是什麼或不喜歡什麼，特性和服務如何引領市場或者如何在競爭中獲得成功，有多少客戶希望為特定的特性付費，其他的一些特性怎麼僅僅是增加交付和維護成本，那麼他就會盲目地管理產品。如果沒有空間停下來並檢查下這些因素，如果沒有勇氣面對挑戰和無效的東西，如果沒有紀律性，不適當關注產品和服務的狀況，那麼就很難創造出客戶願意購買的產品，最終使組織在市場中保持雄厚的經濟實力。
\u0026#xd;\n\u0026#xd;\n
能夠獲得繼續當前工作的信心，或者能夠在組織可能面臨風險或損失的情況下快速調整方向，這是產品管理團隊最強大的工具之一。
\u0026#xd;\n
infoq：對於要想從專案思維轉變到產品思維的組織，您有什麼建議？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nkaraj：一些在這方面做得比較好的產品組織會有意識地參考康威定律，把軟體的「樣子」和組織結構的樣子聯絡起來。反轉這一定律幫助這些組織採用一種更關注客戶體驗的方式定義團隊結構。
\u0026#xd;\n\u0026#xd;\n
任何重專案而又無法清晰回答他們的產品是什麼的團隊都可以使用反轉的康威定律，開始向產品思維轉變。關注客戶，理解他們的需要、痛點和利益所在。同時，要了解市場趨勢，以及除了你提供的產品外，你的客戶正在並行使用或測試什麼。由此，開始給你的服務和特性賦予意義，開始建立全程支援這些特性或服務的團隊。測試組織中所有與交付這些特性/服務相關的方面，進行看上去也許很小的變革，但是要允許想法快速地傳遞到客戶手中。傾聽你的人給出的改進想法，在變革過程中為他們提供學習的空間。你需要來自組織內許多方面的支援與合作。就像我上面提到的那樣，這不容易，但可以實現。一旦你有了乙個好的案例，你就可以反覆改進了。如果你六個月中都在做同樣的事情，那麼你就做錯了，是時候停下來檢查和調整了。
\u0026#xd;\n
檢視英文原文：think in products, not projects
設計和開發時，產品思維vs專案思維
專案思維 專案思維相當普遍。特別是對於從事軟體開發的工作人員，他們職業生涯的大部分時間都專注於專案執行以及專案管理。大型組織通常有pmo部門 專案管理辦公室，專注於專案管理。這並不奇怪，因為專案管理已經存在了很長時間。且我們人類傾向於從專案角度思考 依次做完那些需要我們完成的事情即可。那麼專案思維是...
產品思維（一）
越來越覺得作為乙個技術開發人員，如果不懂產品，就根本是乙個碼農。產品思維 這是一段摘自王興的講話 產品的第一作用是解決需求，這些需求 於使用者，產品經理要做的是發現需求，解決問題。有這個需求的人夠不夠多，問題的嚴重程度等等，產品經理需要將需求進行優先順序排序，只要需求足夠強烈，那產品一定有市場。但發...
產品經理思維
1.1 得屌絲者得天下 1.2 兜售與感 1.3 使用者體驗至上 2.1 專注，少即是多 2.2 簡約即是美 3.1 打造讓使用者尖叫的產品 3.1.1 痛點 使用者需求必須是剛需，使使用者急需解決的問題 3.1.2 癢點 工作和生活中有彆扭之處，即乏力又欲罷不能 3.1.3 興奮點 給使用者帶來 ...