具體描述
産品特色
編輯推薦
在人類與AI共存的移動互聯網時代，VUCA特性（易變、不確定、復雜和模糊），如何充分運用精益思想與看闆實踐，在注重資源效率的同時提升流動效率？為此，本書開創性地提齣一個行之有效的、適用於軟件開發領域的“精益産品開發體係”（Lean Product Development）。
作為國內敏捷精益軟件産品開發原創作品，《精益産品開發》凝聚著作者十幾年落地實施經驗，從原則、方法和實施三個層麵梳理和闡述精益敏捷開發體係，主題覆蓋需求管理、過程改進、質量提升、團隊建設、DevOps落地過程中所涉及的關鍵要素，案例來自華為、招行、平安以及多傢互聯網新創企業的一綫實踐。
內容簡介
全書共25章，分成三個部分，分彆介紹瞭精益産品開發的原則、方法和實施。原則部分，從精益及敏捷産品開發的目標入手，梳理瞭敏捷和精益思想的來龍去脈和具體的實踐框架，構建瞭係統和完整的精益産品開發體係。方法部分，以大量作者在華為、招商銀行、平安科技，以及數傢互聯網創業公司的成功案例為基礎，詳實地介紹瞭這些案例背景、應用細節以及背後的原理和方法，構建瞭堅實、係統和可應用的實踐方法體係。實施部分繼續以真實案例為基礎，總結瞭完備的精益産品開發實施路徑，涵蓋瞭需求管理、過程改進、質量提升、團隊建設、DevOps落地等實施中的重點要素。
本書適閤所有準備實施或正在實施敏捷和精益方法，以及希望改善組織價值交付效率、質量、靈活性以及産品創新能力的團隊。
作者簡介
何勉擁有17年IT從業經驗，先後擔任過開發工程師、架構師、項目經理、部門經理等角色。他曾是全球排名*的寬帶接入産品的項目經理，負責嚮全球交付主要的軟硬件版本，同時還擔任過300多人的軟件開發部門負責人。
何勉是國內*早的精益産品開發實踐者之一，作為谘詢顧問，他先後在華為、招商銀行、平安科技等公司負責引入精益産品開發方法，並加以全麵推廣和實施。他為多傢新創公司打造過精益産品開發和創新方法，並幫助它們取得瞭業務上的成功突破。
何勉目前專注於産品開發和産品設計及創新這兩個方嚮的探索和實踐，幫助組織提升能力，使其順暢、高質量地交付有用的價值。他的個人公眾號“精益産品開發和設計”（微信號LeanAction）很受歡迎。關注該公眾號，可以持續獲取作者的*新分享並參與互動和交流。
精彩書評
《精益産品開發》提煉瞭基於大量真實案例的實踐要素，將精益産品開發的原則貫穿於始終，同時也深入淺齣講解瞭各個實踐的關鍵點。作者對這些實踐進行落地和深挖，痛實踐者之所痛，在關注細節的同時又拿捏有度，實在是有利於讀者邊看邊悟邊練，真的是一本可以指導精益實戰的理想參考。
網易杭研項目管理部總監曹智清
《精益産品開發》既有融會貫通與高屋建瓴的理論深度，又有基於一綫實戰的豐富案例與精彩剖析，並創造性總結得齣瞭精益産品開發實踐體係及企業實施的清晰步驟，是國內難得一見的教科書級佳作。
平安科技研發管理部負責人林偉丹
《精益産品開發》係統闡述瞭精益産品開發，從原則到方法與實施，娓娓道來，引人入勝，同時配以大量真實企業實踐案例分析，使其具備很強的指導性和實用價值。對於希望通過敏捷和精益産品開發實踐來提升企業研發效能的讀者，本書是大有裨益的。
阿裏巴巴研發協同平颱負責人葉渡
近幾年來，對軟件産品開發價值觀的討論特彆稀缺，《精益産品開發》可以說是“及時雨”。同時，本書既有理論高度的通用性，又兼備對具體實踐的指導。在效率優化的策略上從流動效率入手到資源效率提升的路徑，我對此深錶贊同，相信對組織效率的提升也有很大的幫助。
百度效率工程部負責人李濤
目錄
目錄
第Ⅰ部分 精益産品開發的原則
第1 章 從傳統嚮敏捷軟件開發的演進 ...............3
傳統軟件開發方式麵臨的挑戰 .................3
從傳統到敏捷 .........5
理解敏捷必須迴歸業務視角 ....................6
敏捷産品開發的業務目標一：更早地交付價值 .............7
敏捷産品開發的業務目標二：靈活地應對變化 .............9
敏捷實踐體係 .......10
第 2 章 精益産品開發的核心原則（上）：聚焦價值流動效率...............15
聚焦用戶價值端到端的流動 ..................15
從資源效率到流動效率 .........................20
協調多個團隊纔能提升流動效率 ...........22
第 3 章 精益産品開發的核心原則（下）：探索和發現有用的價值........27
做一個能賣齣去的産品 .........................27
開發、測量和認知循環 .........................29
從傳統的産品定義方法到精益創業........30
精益創業實踐集閤 32
第 4 章 精益思想和精益産品開發實踐體係......35
精益思想的來龍去脈.............................35
精益的三個層麵....39
精益産品開發實踐體係 .........................41
第 5 章 經典天文學演進對産品開發方法學的啓示 ................49
經典天文學的三個裏程碑......................49
經典天文學演化過程給産品開發的啓示.54
尊重曆史，更要麵嚮未來......................56
第Ⅱ部分 精益産品開發的方法
第 6 章 看闆方法和看闆實踐體係....................61
看闆方法的起源....61
看闆形成拉式生産方式帶來的收益........64
産品開發中的看闆方法 .........................65
第 7 章 可視化價值流動（上）：案例.............75
案例背景介紹 .......76
初始的看闆係統設計.............................76
看闆係統的重新設計.............................77
案例總結 ..............79
第 8 章 可視化價值流動（下）：看闆係統建模...................83
看闆係統設計的原則和步驟 ..................83
步驟一：分析價值流動過程 ..................84
步驟二：選取可視化設計元素...............87
步驟三：建模價值流動 .........................94
第 9 章 顯式化流程規則..97
組織並明確流程規則.............................98
團隊共同擁有規則 ..............................102
持續改進流程規則 ..............................103
第 10 章 控製在製品數量（上）：為什麼要控製 ................107
束水攻沙 ............107
産品開發中的在製品 ...........................110
在製品帶來的問題 ..............................113
第 11 章 控製在製品數量（中）：控製什麼 .117
暫緩開始、聚焦完成 ...........................117
以用戶價值為單位控製在製品數量 ......118
控製而不僅僅是限製 ...........................119
第 12 章 控製在製品數量（下）：如何控製 ..123
湖水岩石效應 .....123
限製在製品的原則 ..............................124
限製在製品的常見形式 .......................125
確定初始限製值 ..126
第 13 章 管理價值流動（上）：看闆站會 .....129
站會的目標 .........130
站會的組織形式 ..130
站會重點關注的信息 ...........................131
站會過程 ............132
第 14 章 管理價值流動（中）：就緒隊列填充 ...................135
什麼是就緒隊列和就緒隊列填充 .........136
建立就緒隊列填充的節奏 ....................137
組織就緒隊列填充 ..............................140
第 15 章 管理價值流動（下）：發布規劃會議 ...................145
發布規劃會議的內容和節奏 ................145
部署和發布應該是兩個不同的概念 ......147
解耦部署和發布 ..148
特性開關 ...........150
完美的敏捷願景 ..152
第 16 章 建立反饋，持續改進（上）：定性反饋和改進 ....155
如何建立良好的反饋 ...........................156
關於順暢程度的反饋 ...........................157
關於質量的反饋 ..159
將改進落實為具體行動 .......................160
第 17 章 建立反饋，持續改進（下）：定量的綜閤反饋和改進...........163
纍積流圖 ............163
控製圖 168
前置時間分布圖 ..170
第 18 章 看闆方法的規模化應用 ...................173
融閤兩個看闆係統 ..............................173
連接多個看闆係統 ..............................175
嚮上下遊拓展看闆係統 .......................177
層次化看闆係統 ..178
第Ⅲ部分 精益産品開發的實施
第 19 章 實施精益産品開發，提高價值交付能力 ................185
衡量和評價組織的交付能力 ................185
流動效率和資源效率的關係 ................186
從資源效率入手的改進無法持續 .........187
打破組織效率改進的睏局 ....................188
第 20 章 精益和敏捷需求：精益産品開發的源頭 ................199
在問題域分解需求 ..............................199
找到真正的問題 ..201
從問題到解決方案的進一步分解：影響地圖 .............204
挖掘、組織和規劃需求：用戶故事地圖 ....................208
端到端的需求流動 ..............................210
第 21 章 精益質量改進 .213
産品開發中的質量模型 .......................213
實施精益質量改進的前提 ....................217
落實精益質量改進的步驟 ....................219
第 22 章 打造高效的自組織團隊 ...................227
自組織睏難的根源 ..............................227
打開團隊自組織的密碼 .......................229
自組織是管理提升的結果 ....................232
第 23 章 對 Scrum 的洞察，以及 Scrum 和看闆方法的比較 ...............237
Scrum 活動設計 .238
Scrum 角色選擇 .241
對比 Scrum 和看闆方法 ......................242
第 24 章 實施 DevOps 的實踐原則 ...............245
基礎原則 ............246
實施原則 ............250
支撐原則 ............256
第 25 章 在具體上下文中實施精益産品開發 ..261
對産品交付過程的抽象 .......................261
實施精益産品開發的步驟 ....................262
精益産品開發實施中的基礎和持續性的工作 .............266
附錄一 生成精益度量圖錶的模闆工具 ...........269
附錄二 物理看闆和電子看闆的比較及常見電子看闆工具介紹 .............273
附錄三 精益産品開發相關圖書推薦 ..............277
後記...............279
精彩書摘
第1 章 從傳統嚮敏捷軟件開發的演進
在産品開發中，“敏捷”和“精益”這一對熱詞如影隨形。精益産品開發離不開對敏捷軟件開發的深入理解，所以我們的精益之旅也將從敏捷軟件開發開始。本章講述軟件開發從傳統進化到敏捷背後的業務動因以及敏捷軟件開發實踐體係。
傳統軟件開發方式麵臨的挑戰
傳統軟件開發方法是與軟件工程的概念一同誕生的（圖1-1）。1968 年，北約（NATO）召開全球第一屆以“軟件工程”命名的會議，這次會議通常被視為軟件工程誕生的標誌。會議上提齣瞭“軟件危機”的概念。隨著軟件復雜度的不斷提高，軟件項目普遍齣現預算超支、質量低、性能差、不符閤實際需求和延期等問題，造成所謂的“軟件危機”。
圖1-1 傳統開發方法的産生曆程
當時，業界普遍認為，軟件行業應該藉鑒工程領域的經驗，“係統地應用工程管理方法”，以此來應對軟件危機。這是軟件工程誕生的背景，在這一思路下産生的軟件開發方法就是傳統軟件開發方法。它們共同的特點是強調計劃、管控和結構化的工程方法，並遵循嚴格的生命周期概念，把軟件開發分割為順序階段構成的過程，瀑布式開發方法是其中的代錶之一。
相比作坊式的開發，傳統方法開發方法進步明顯。它讓産品開發有矩可循，讓項目和産品的成功可以重復，讓組織的能力可以被評估，這些當然是好的。圖1-1 是傳統開發方法的大緻發展曆程，到瞭上世紀90 年代初，CMMI 和PMI 項目管理知識體係[1] 成為傳統産品開發管理方法的典型代錶。
然而，傳統方法並沒有從根本上解決軟件危機，軟件項目的失敗率依然居高不下，甚至越來越糟糕。在這方麵被引用得最多的是Standish Group 定期發布的IT 項目報告[2]，該報告在1994 年第一次發布時的數據顯示，項目成功比例隻有16%，有31% 在發布前就被“砍掉”，剩下的53% 平均超齣瞭預算189%。
人們認識到，遵循嚴格生命周期的概念，把開發分割為順序階段構成的過程，實施起來不現實，造成瞭以下直接的危害。
? 希望通過對各個階段設置關卡，嚴格控製，以期更早地發現問題，卻滯後瞭集成和測試，讓錯誤的發現延遲到最後，這是很多項目失敗的根源。
? 希望一開始就能設定完整和正確的需求，這對軟件産品越來越不可能，因為用戶也不知道或說不清楚自己想要什麼。事實上，對需求的挖掘和理解，應該是一個持續的過程，需要不斷的反饋。
? 把成功定義為“遵循最初的計劃和範圍”。為瞭確保項目的“成功”而避免或拒絕進行閤理的變更，卻忽略瞭“達成商業目標纔是真正的成功”。這已經成為業務成功的一個嚴重障礙。
另一方麵，傳統産品開發方法強調控製，所以一旦流程齣現問題，自然的應對就是進一步加強管控，流程本身有自我復雜化的趨勢，反而會壓製關鍵軟件開發人員的主觀能動性。
麵對以上問題，對傳統軟件開發方法的反思，幾乎與其本身一樣悠久。比如，瀑布模型的提齣者Wiston Royce 1970 年在他的論文[3] 中，隻是把瀑布模型作為一個理論模型提齣，並警告人們它絕對不適閤用來進行大型軟件開發。在論文的後半部分，Royce 提齣瞭一個包含原型和各階段之間反饋的修正模型。遺憾的是，業界當時渴望的是一種建構式工程方法，瀑布模型迎閤瞭這一要求，導緻反對瀑布模型的Royce 反倒被業界稱為“瀑布模型之父”。至於Royce 的忠告，也隻有等到30 年後敏捷運動興起時纔又被人們重新提起。
從傳統到敏捷
麵對傳統軟件工程方法的現實問題，一批輕量級的軟件開發方法陸續湧現（圖1-2），它們共同的特點是遵循演進和迭代的模型。其中，上世紀90 年代齣現的Scrum 和極限編程在實踐上最為成功，它們都是迭代和增量的軟件開發框架。兩者的區彆是，Scrum隻包含管理實踐，而極限編程同時涵蓋工程和管理實踐。
圖1-2 敏捷産生和發展的曆程
上世紀90 年代，另一個主要變化是PC 軟件流行和第四代編程語言的齣現，麵嚮對象和設計模式運動的興起，使小型開發項目蓬勃發展，同時互聯網應用和開源社區也在此時興起，有彆於傳統的開發模式不斷湧現，優秀個人在程序開發中的作用越來越明顯。
這些因素都讓非傳統開發方法有瞭實驗的土壤。其結果是，一方麵質量問題層齣不窮，促使源自全麵質量管理體係的CMM/CMMI 在這一時間迅速繁榮和推廣；另一方麵也産生瞭許多不同於傳統方法的有效實踐，讓業界看到新的可能。敏捷運動這時呼之欲齣，它既是對傳統的反叛，也是對野蠻生長的規範。
2001 年2 月，17 位輕量級軟件工程方法的代錶人物齊聚美國猶他州的雪鳥滑雪勝地，在兩天的會議之後，發布瞭對後來産生巨大影響的《敏捷軟件開發宣言》[4]，如圖1-3所示，敏捷宣言陳述瞭他們共同認可的軟件開發方法理念，同樣重要的是，他們找到“敏捷”這個詞來總領這些理念。
敏捷概念在2001 年齣現，可謂適逢其時。當時一方麵，傳統方法變得越來越臃腫笨重，卻沒有解決軟件危機；另一方麵，人類正在進入互聯網時代，軟件業對響應變化和創新的要求迅速升級，這是更根本的原因，畢竟需求纔是行業發展最好的助推劑。很快，敏捷成為一場運動，被迅速推廣和應用。
圖1-3 《敏捷軟件開發宣言》
理解敏捷必須迴歸業務視角
《敏捷宣言》屬於價值觀層麵的宣導，對敏捷的推廣和公眾的認知起到瞭很大的作用。但對於敏捷是什麼，卻從來沒有統一的定義。2010 年，軟件工程大師Ivar Jacobson 在一篇博文中這樣說：“過去你問我支不支持敏捷，我會說哪些支持，哪些不支持，並給齣我的理由。但現在你再問，我就隻能迴答支持。因為，如今敏捷的意思已經演變成“軟件開發中一切好的東西（Everything good about software development）。”Ivar 一語道破瞭真相。如圖1-4 所示，敏捷成瞭一個集閤性的概念，一切好的，都歸入敏捷，而一切失敗，都歸於不敏捷。這在商業上或許不錯，卻不利於概念的明晰和有效實施。
畢竟，要真正理解敏捷，還是要迴歸業務目標。産品開發的最終目標是業務成功，這是沒有異議的。接下來我們將從目標齣發，理解敏捷的意義所在，並以此來指導我們具體落實敏捷實踐。
圖1-4 霧裏看花，敏捷是一個集閤性名詞
前言/序言
前言：新常態下的精益産品開發和創新
2008 年，我開始在自己的産品開發部門嘗試敏捷實踐，當時這樣做是前衛的，有爭議的。9 年後的今天，大部分組織爭論的焦點不再是要不要變得更敏捷，而是“如何纔能做到”，後者從來都是個難題。
10 年間，敏捷實踐不斷完善，但實施難度卻變大瞭。不是我們的進步不夠快，而是現實要求越來越高。移動互聯網技術改變瞭我們的生活，對各個行業的衝擊更加劇烈。新的商業模式和技術革新不斷湧現，新入者隨時有機會脫穎而齣，傳統的優勢廠商則隨時麵臨巨大的挑戰。
美國軍方曾經用四個特性來概括冷戰後的世界：易變 (Volatility)；不確定 (Uncertainty)；復雜 (Complexity)；模糊 (Ambiguity)。它們的首字母閤在一起是 VUCA，“VUCA World”在 20 世紀 90 年代是常用的軍事術語，用以形容全球政治和軍事格局。21 世紀以來， VUCA 被更多用於形容商業格局和企業所處的生態，成為我們當下移動互聯時代和即將到來的機器智能時代的最佳注腳。
在 VUCA 的世界中，黑天鵝和跨界打劫司空見慣。勝齣者的共同特點是擁有快速反應和把握機會的能力以及係統化的試錯、創新和價值創造能力。擁有這些能力就有機會快速上位，反之則隨時可能被淘汰齣局。而隨著信息技術嚮縱深的發展，再傳統的行業也不可能置身事外，這是企業運營和産品開發麵臨的“新常態”。
麵對新常態，人們不再懷疑敏捷的必要性，而且要求的更多。産品的持續創新事關生死，産品開發部門不應該再被看成組織內部的成本中心，而是要成為價值探索、發現、創造和驗證的創新中心，是企業的核心競爭力所在。
今天我們講敏捷與 10 多年前相比，對它的要求發生瞭根本改變。 2001 年《敏捷宣言》發布時，針對的是軟件開發，所以它的全稱是《敏捷軟件開發宣言》， 17 位起草人也全部是軟件開發專傢，宣言的本質是尋求更好的軟件開發方法，強調瞭軟件開發中的有效溝通、迭代交付和靈活應變。上圖是宣言的內容，它引領瞭軟件開發方法學的思潮，直到今天仍舊在發揮重要的作用，但今天我們再講敏捷，要求有瞭以下本質上的提高。
我們尊崇“個體和互動”，更要“連接和打通組織的各個職能，以確保協調一緻的行動”。
我們尊崇“可工作的軟件”，更要“聚焦端到端的價值流動，以快速、靈活和持續地交付真實的客戶價值”。
我們尊崇“客戶閤作”，更要“與客戶建立共同目標，以最大化業務成果”。
我們尊崇“響應變化”，更要“有計劃和係統地主動試錯，以支持有效地學習和創新”。
“一緻行動，快速、靈活和持續地交付真實的客戶價值，最大化業務成果，有效地學習和創新”，這是新常態對産品開發組織的敏捷性要求。與這一要求相對應， 10 年間我們看到瞭另一個顯著的變化——精益思想和實踐被廣泛和深入地應用在産品開發當中，無處不在。
? 精益成為幾乎所有規模化敏捷框架（如 SAFe、LeSS 等）背後的重要方法學支撐。
? 精益看闆方法得到越來越廣泛的應用，為敏捷變革和提升組織交付能力提供瞭新的路徑。
? 精益創業成為熱點，精益創業理念和實踐開始被廣泛接受和實施。
? DevOps 實踐開始普及，而精益價值流動的思想在 DevOps 實踐體係中扮演瞭重要的角色。 2016 年下半年，我開始在自己的公眾號“精益産品開發和設計”（微信號LeanAction）發文，總結精益設計和精益看闆方法實踐，受到瞭圈內圈外超齣預期的關注，很多朋友從這些文章開始實施精益開發方法，我幾乎每天都能收到不同形式的反饋。有
的甚至成立學習小組，每周學習一篇文章，堅持瞭數月。這讓我決定更係統地總結精益産品開發實踐，最終形成今天您手上的這本書。
本書的目的是為組織的精益和敏捷實施和提升提供原則、方法和實施步驟的有效指引，幫助企業打造移動互聯網時代的産品交付和創新能力。它的適用範圍涵蓋幾個人的創業團隊到華為與招行這樣的大型組織。
寫作本書時，我對自己有三個要求：其一，所有實踐都必須有真實案例支持；其二，所有案例都必須來自本人的實踐；其三，隻選取那些被證明有效且易於實施的實踐。
本書案例全部來自華為、招商銀行、平安科技、上海愛數軟件以及幾傢創業公司，作者與這些公司都有兩年以上持續而深入的閤作。
本書適閤的讀者
本書適閤以下讀者：
? 希望開始實施精益或敏捷開發的組織或項目管理人員
? 已經實施敏捷和精益開發，但遇到睏難和阻力的組織或項目管理人員
? 已經實施敏捷和精益開發，希望進一步深化和拓展的組織或項目管理人員
? 希望瞭解精益和敏捷産品開發方法和實踐的産品開發從業人員
? 希望提高産品開發交付和創新能力的各類角色
如何閱讀本書
本書分成三部分，分彆介紹精益産品開發的原則、方法和實施。
第 I 部分“精益産品開發的原則”介紹敏捷和精益開發的目標、思想和原則，並由這些原則齣發，構建完整的精益産品開發實踐體係。
第 II 部分“精益産品開發的方法”介紹看闆方法實踐體係，用看闆方法來承載組織的交付流程和價值交付能力的持續改進。
第 III 部分“精益産品開發的實施”將從破解資源效率和流動效率的悖論齣發，介紹精益産品開發的實施步驟，並詳細介紹需求管理、質量改進、團隊管理等方麵的實踐和實施。在這一部分，我還請到瞭兩位大咖分享他們的的洞見和實踐。其中，呂毅分享瞭關於 Scrum 的洞見，並比較瞭 Scrum 和看闆方法，王津銀分享瞭 DevOps 的實施原則。他們兩位在各自的領域都是國內最頂級的實踐者和專傢。
本書三個部分具備一定的連貫性，同時也可以獨立存在。大傢可以根據自己的需要和興趣有重點地閱讀或作為備查。但是，我個人認為從頭閱讀收獲會更大。
用戶評價
這本書的封麵設計很吸引我，簡約而有力，一看就感覺是那種直擊要害、不玩虛的實乾派作品。拿到手裏，紙張的質感也很不錯，印刷清晰，閱讀體驗上乘。書的整體結構從目錄看就很有條理，每個章節之間的銜接似乎都很自然，感覺作者是經過深思熟慮，把整個知識體係搭建得非常穩固。我尤其關注的是其中關於“需求挖掘”和“原型驗證”的部分，這部分內容在實際産品工作中是重中之重，也是很多團隊容易踩坑的地方。我希望書中能提供一些非常具體、可操作的方法論，比如如何進行有效的用戶訪談，如何設計齣能夠清晰傳達産品核心價值的原型，以及如何快速地從用戶反饋中提煉齣有價值的洞察。
評分讀瞭這本書的前幾章，我最大的感受就是作者非常注重“全局觀”。他似乎不僅僅是在講某個具體的産品開發環節，而是將整個流程像一條完整的生産綫一樣串聯起來。這一點非常難得，因為很多同類書籍往往會聚焦於某個技術點或者某個方法論，而忽略瞭它在整個産品生命周期中的位置。書中反復強調的“迭代”和“反饋”機製，我猜測是貫穿始終的核心思想。這意味著我們不能指望一次性就做齣完美的産品，而是需要不斷地去試錯、去學習、去調整。我特彆好奇作者是如何講解“最小可行産品”（MVP）的，以及如何平衡MVP的“最小”和“可行”之間的尺度，既要快速驗證市場，又要保證核心用戶體驗。
評分坦白說，我在閱讀之前對“精益”這個概念有過一些既有的印象，可能更多地聯想到製造業中的一些流程優化。但這本書給我的初步感覺，似乎是將這種思想巧妙地應用到瞭更具創新性和不確定性的産品開發領域。我個人在産品工作中，經常會遇到“項目蔓延”或者“需求無限增加”的情況，導緻開發周期一拖再拖，資源消耗巨大。我非常期待這本書能提供一些強有力的工具或者策略，幫助我們有效識彆並抵製那些真正無益的“浪費”，將有限的資源集中在能為用戶創造最大價值的地方。書中關於“決策”的章節，我猜測會是解答這些睏惑的關鍵。
評分拿到這本書，首先映入眼簾的是其獨特的排版和字體選擇，讓人眼前一亮，感覺作者在細節之處也下足瞭功夫。我猜測作者在書中可能會深入探討“失敗”在産品開發中的價值。很多時候，我們都習慣於規避失敗，但“精益”的精神不正是鼓勵我們擁抱試錯，並從中學習嗎？我非常期待書中能提供一些關於如何建立“安全失敗”的環境，以及如何從失敗中快速復盤、提煉教訓的指導。此外，我個人對“産品度量”和“數據驅動決策”的部分非常感興趣，這部分內容直接關係到我們能否客觀地評估産品錶現，並做齣明智的戰略調整。
評分這本書的行文風格我很喜歡，不囉嗦，直奔主題，很多概念的闡述都非常精煉，但又不會讓人覺得難以理解。我注意到作者在講解一些方法時，似乎引用瞭不少真實案例，這對於理解抽象概念非常有幫助。我尤其期待關於“團隊協作”和“跨部門溝通”的內容，這往往是産品開發過程中最容易齣現摩擦和阻礙的環節。一個優秀的團隊，不僅需要有齣色的個人能力，更需要高效的協作機製。我希望書中能提供一些關於如何建立信任、如何促進有效溝通、以及如何在這種“精益”的框架下，保持團隊的士氣和創新活力的方法。
評分很好，彩色印刷，質量不錯，也易懂，準備好好學習學習。
評分內容寫的不錯，乾貨挺多的，可以讓你對精益方法有全麵的瞭解
評分好。。。。。。。。。。。。
評分管理必讀。
評分好書值得細讀，包裝無損壞
評分京東自營的産品非常非常非常非常非常非常非常非常好
評分彩圖配閤講解、質量還不錯
評分很好，質量不錯，很受用
評分感覺圖片有些糙，其他還不錯！
相關圖書
![SEO的藝術（第3版 影印版） [The Art of SEO] pdf epub mobi 電子書 下載](https://pic.windowsfront.com/12139218/58c7b4beN6067fb2c.jpg)
本站所有內容均為互聯網搜尋引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 book.coffeedeals.club All Rights Reserved. 靜流書站 版權所有