起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識奶爸哄娃式產品經理需求調研【1】：客戶需求的獲取及分析
編輯導讀：對于產品經理而言，需求的捕獲以及分析能力是最為基本但也是最為重要的能力，這一過程需要耐心、需要技巧等盡可能達成需求調研的目標，這就好比一個奶爸獨自帶娃一樣，需要從寶寶的表達中快速獲知寶寶的需要，從而滿足寶寶的需求。
一、需求調研到底調研分析的是什么
在開始之前我們先回答這個最簡單的問題，可能會有產品經理會認為需求調研分析的任務是分析系統如何實現用戶的需要。這答案不能說是錯誤的，但卻是考慮得不全面的，這就比奶爸帶寶寶時，似乎認為只要寶寶不哭就可以了，實際上作為奶爸，不僅是在寶寶哭時解決寶寶的需求，還要綜合寶寶考慮的其他需求。
因此可能這是關于什么時需求調研分析的問題比較全面的回答，即需求調研分析實際上是業務分析，也就是選擇一種業務導向的線索將零散的需求串起來，形成一個體系完整的、內容清晰的框架，以知道后續的設計、開發工作。總結來說：需求分析就是先分解、再提煉，在這個過程中消除矛盾。
如果單純認為客戶要求就是軟件需求，不注重對業務知識（業務事件、業務實體、業務規則）的捕獲，從不主動問為什么，這樣往往不僅達不到需求調研的目的，反而甚至會給后面的開發造成完全錯誤的方向影響。
二、需求調研需要具備的能力
奶爸不好當，產品經理同樣面對很多難題，對于產品經理而言，想要做好需求調研一般會有哪方面的能力要求呢？
- 溝通能力：能夠清晰表達自己的意思（善于打比方是提高專業溝通效果的好辦法）
- 提問能力：好的提問其實很難，如何“一針見血”，問到點子上，聚焦問題是需要重點鍛煉的
- 談判能力：與客戶爭取籌碼的能力，盡量爭取主動權能夠很好的幫助項目成功
- 理解能力：理解與溝通相輔相成，但良好的理解能力還需要專業的知識甚至心理學知識支撐
- 傾聽能力：耳朵與嘴的比例，多聽少說
- 共情能力：多理解客戶的業務場景、客戶感受甚至心理
三、需求調研需要具備的意識
1. 要有主動意識
產品經理要保持主動的態度和心態，要不怕麻煩，厚臉皮，別指望客戶或需求方可以將需求整理妥當后送上門來。
2. 要有剖析冰山模型的意識
我們常說的“冰山模型”主要是指我們只看到表面而沒看到根本，因此在需求調研中我們就要有破解冰山模型的意識，善于將三層用戶需求都挖掘出來，即：
- 用戶意識到的問題：用戶通常遇到的困擾或者能夠設想到的功能；
- 無意識的需求：充分理解用戶的工作場景，具體的方法就是加強對業務知識的捕獲；
- 未夢想的需求：需要需求分析人員充分理解業務并選擇合適的技術方案，創造出用戶未夢想到的功能
3. 要有聚焦重點意識
產品經理需要具備善于聚焦問題的意識，使得需求訪談重點明確，以主動發問的形式，基于目標把控訪談走向，不要輕易將“話筒”移交，否則極有可能會有“提到需求遠超計劃”的情況。聚焦重點的最簡單方法就是產品經理的問題邏輯，比如：解決某某事情的時候一般如何處理？處理過程需要哪些支持？原來處理時存在什么困難或不便？還有哪些相關的問題是比較棘手的？
4. 要有破除“需求方”作怪心理的意識
與各色需求方打交道難免會遇到各種各樣的人，因此遇到阻礙需求捕獲的“人”的心里就不足為怪，不能受其影響。概括來說，作怪心理會分別有言過其實、越俎代庖、非正事心態、抗拒心理、推卸責任這五種。
1）言過其實
客戶夸夸而談，說出的流程都很理想化、規范化，但實施時卻與實際大相徑庭。通過觀察用戶的說法方式來發現，通常這種“言過其實”的表述都會以非?？隙ǖ恼Z氣，并且講述時十分流暢，沒有什么打斷，因為這個時候只需要創造，而不需要回憶。因此當我們遇到關鍵流程、有懷疑的流程時就需要不同用戶代表訪談并整理結果，在開發前將差異展現給客戶中高層管理人員，就如何解決達成共識。其次當在流程中，發現某個角色或人員過度參與時，就應該針對時間瓶頸、人員瓶頸進行分析，避免流程瓶頸導致系統無法順利運轉。
2）越俎代庖
這種情況主要發生在對業務不是很熟悉的客戶身上，所以如何引起用戶對系統建設的重視，認識到系統建設帶來的價值是個難題。
這類型客戶不管是不是自己負責或熟悉的業務，都喜歡侃侃而談，并根據自己的理解和想象進行肯定的描述。解決這種問題，關鍵還是要識別并找到合適的被訪談者，也就是回答問題的最佳人選。
這里所說的“最佳”人選有兩層含義：第一是問題的層次要正確，高層解決宏觀問題、中層解決脈絡（業務流程）問題，基層解決細節（活動）問題；第二是被訪談者是否合適，執行者往往就是最佳人選，所以有效識別該問題所針對的業務環境是由誰負責處理的。
3）非正事心態
被訪談者沒有將訪談當作一件優先級很高的事情，有主觀與客觀兩類因素：客觀因素是訪談時在辦公室等環境容易被打斷，影響訪談效果；主觀因素是非計劃內的事情通常都會被認為是優先級低的事情。這種心理是由于客觀與主觀因素導致的，所以要解決這兩個因素：提前做計劃，與客戶約好時間并明確主題；客觀因素：盡量避開辦公室類的環境，會議室最好。
4）抗拒心理
抗拒心理在基層比較常見，因為信息化系統對操作層而言效益并不那么明顯，且經常使得工作量增加。這就使得操作層用戶代表在需求捕獲過程中會將對信息化系統的敵對轉化為對產品經理的敵對。敵對狀態下是無法有效溝通的。
5）推卸責任
在需求調研中會經常遇到“你找中層，中層讓你找基層；找基層，基層說我們沒需求，這事你要找領導”這種情況，中層回應體現了項目目標不夠明確，操作層的回應則體現了推卸責任的心理系統化系統對基層的效益并不明顯，所以就會有“事不關己高高掛起”的心理萌生。針對這種情況，首先考慮為什么項目目標不明確，是客戶的原因還是產品經理前期在目標分析時存在問題；然后針對基層，最簡單有效的策略讓被訪談者介紹工作場景：先從工作場景開始，問客戶從事哪些工作，工作是如何進行的？工作中存在什么障礙，有什么困難等。
5. 挖掘需求變更可能意識
要求關注變更可能的捕獲意識，在需求捕獲過程中要加強這么方面的意識，畢竟用戶不會把所有的變更可能告訴你。
6. 需求協商意識
經常會遇到需要協商的情況，需要靈活應對各種場景，如何和客戶談判爭取主動權？對于這一重要環節，產品經理可以從以下方面處理需求協商問題：
1）需求范圍明確
從業務流程梳理業務場景時，客戶代表常會提出將與業務流程相關、但超出業務目的的業務活動納入范圍，對于項目而言就需要和用戶代表進行協商，根據“目標分析”中的目標來明確邊界。造成這樣的原因是因為業務流程捕獲時，為避免在分析、設計階段斷章取義，并沒有考慮系統邊界。因此客戶代表很容易從業務流程的“服務請求”開始要求實現，但“目標決定范圍”，與目標無關或者無直接貢獻的應移除。與客戶代表協商時，以客戶方高層領導“目標”劃分即可。
2）撥開立場，尋找客戶利益訴求
產品經理在需求調研中遇到的典型場景：客戶提出的需求或變更會導致需求蔓延或較大幅度增加工作量。當我們與客戶立場發生對立時，核心技巧在于問出客戶的立場，當真正了解客戶的利益訴求時，就可能找到很多折中的辦法，而問出客戶立場最簡單的辦法：多問為什么!
3）需求優先級的確定
當客戶將所有需求都定義為高優先級或有意無意不指定優先級時，就會對項目計劃造成影響甚至導致需求蔓延。
相對重要→相對次要：選擇一個其上級領導提出的、他也知道的需求來比較，告訴他實現他提出的需求就會影響領導關心的需求。如果需求不是很緊急，一般他就會放棄。但如果他還堅持，就要重點審視需求的不可或缺性了。
7. 打比喻意識
由于信息的不對稱，導致客戶無法理解技術領域，這時候就適合利用對方熟悉領域的事物來解釋深奧的問題。
1）敢于拋棄細節，不奢望一次成型的意識
在業務流程的識別與分析過程中，第一是善于、敢于拋棄細節，不要過早地鉆研到業務活動的具體步驟中，這樣必然會導致流程圖的規模被擴大了，也就破壞了此目標的達成。第二個是拋棄一次成型的思路，不要精雕細琢，而是出草稿、談問題、修正草稿、再討論、再修正……最終達成共識，這才是合理的過程。
2）需求改進意識
對于客戶提出的需求，除了“線下到線上”的實現外，對原有業務流程的優化與改進至關重要。
四、需求調研中獲取客戶需求信息的方法及途徑
需求調研獲取客戶需求信息的方法和途徑有很多，但基本主要是以下六種，這六種未必需要全部使用得到，具體使用哪種方式還需根據實際的項目需求進行選擇。
1. 用戶訪談
1）確定用戶訪談人群
面對人群及對應的目標，比如高層決策人員、中層管理人員、操作人員、技術團隊等；
2）確定計劃時間以及內容
根據訪談面對人群的不同，就他們關心的“話題中心、目標”準備問題。如果產品經理帶著空白的紙張、空白的大腦展開需求捕獲活動的，這樣必將導致用戶訪談效率低、針對性不強的結果，要解決這個問題，就必然在訪談展開之前先計劃要訪談的內容，并且在有可能的情況下將其事先發給被訪談者，以便他在訪談前做好相關的準備工作。
3）訪談時間安排
心理學研究顯示，一個成年人可以聚精會神地專注于某一件事的時間大約在50~70分鐘，因此建議訪談時間控制在1小時以內。
4）訪談地點安排
盡可能選擇會議室、洽談室等封閉、不易被打擾的地方（參照“非正事心理”）。同時會議記錄建議采用“做筆記+錄音”的組合形式，且在訪談者每陳述完一段話后進行復述，以確保雙方達成共識。
5）訪談的溝通技巧
訪談對溝通技能要求很高，要求訪談者善于傾聽、善于表達（記住“兩耳一嘴”的原則，表達能力強不代表要話多）。
以業務為中心：訪談過程中要注意談話中心是“業務”而非“技術”。
多聽少說：訪談的信息流是被訪談者→訪談者，因此要切記喧賓奪主，導致信息獲取不足?！叭苏f話和傾聽的比例就是嘴巴個數與耳朵個數的比例”，訪談者說話的總時間應該控制在三分之一以內。
言簡意賅：盡量使用短句（主謂賓結構），少用“定狀補”；不使用“被動句、雙重否定”等容易歧義的句式；不要采用過多修辭手法。
提問有層次感：將長問題盡量拆解問多個遞進性的子問題，避免一次性提問
6）合理搭配問題類型
開放式問題（簡答題），這種的優勢在于被訪談者更自主，能反饋更豐富的信息，壓迫感最低（被訪談者感到更自在）；劣勢則是容易跑偏、產生太多不相關細節，導致訪談失控；信息量較大，需要花費較長時間才能獲取有效信息；會使得訪談目標顯的不那么明確。
半封閉式問題（選擇題）/封閉式問題（判斷題），這種優勢在于節省時間、容易直擊要點，可得到準確的數據，易對不同被訪談者回答進行比較；適合大范圍訪談；劣勢則是無法得到細節（還會誘導被訪談者），可能導致信息遺漏；壓迫感較重，且訪談效果過分依賴產品經理人員水平。
盡量使用開放式問題；當訪談開場或出現僵局時使用封閉式/半封閉式緩解；在需要使用封閉式問題時，盡量轉化為半封閉式（降低過強的誘導性）。
7）擅長使用模型
一圖勝千言：擅長使用模型、草圖表達，更容易達成一致
8）善于消除行業帶來的隔閡
產品經理與客戶常來自不同的行業或專業背景，所以交流過程中一定存在“術語”。在訪談過程中要勇于問客戶的“術語”，盡量用通俗的語言表達技術術語，讓雙方在溝通時對“術語”的理解盡量一致。
2. 用戶調查
能有效的消除“用戶訪談”帶來的信息片面性。優點在于調查面廣，是對用戶訪談技術的有效補充，能克服片面性，而缺點則是容易形而上學，不易深入。因此在需求捕獲過程中，先訪談再調查是更合理的方式。
用戶調查的調研方式最重要的在于問券的設計，那如何設計用戶調查問卷？
篇幅：問卷填寫時間不超過20分鐘或保持在1~3頁以內
布局：問題盡量按照從易到難排列：先易后難至少保證用戶以良好的心態回答更多的問題
邏輯性：盡量將邏輯相關的問題按照業務邏輯順序排列，跳躍性太大會干擾到被調查人的思路
避免封閉式問題：封閉式問題盡量使用半封閉式問題代替
開放式跟隨：盡量讓開放式問題跟隨在相關封閉式、半封閉式問題之后；因為這時用戶在腦海中有一些答案，填寫出來的可能性就會大大增加。
比如：你喜歡什么運動？（可多選） □足球 □籃球 □圍棋 □器械 □其他（請寫出）_______
保持簡單：對于開放性問題留給用戶回答的空間不宜太長，否則會使被調查者產生壓力，不敢以簡單的方式回答，最終導致干脆不回答的結果，因此通常建議只留1~2行的空間。
另外需特別注意問卷調查方式的誤區，當我們辛辛苦苦地完成需求調查之后，如果不能夠有效地對其進行分析的話，其效果也會大打折扣。但很多人只是簡單地統計每個選項的結果，這實際上是不充分的。需求調查是用來克服用戶訪談的片面性的。因此我們必須在分析調查結果時找到差異性，分析造成這些差異的具體原因。
3. 參考文檔
參考文檔的方式優點是能詳細、直觀的對數據流細節進行了解和分析。缺點則是文檔數量比較大，有效信息提取不容易且容易被誤導；文檔是有滯后性的，所以信息很可能是過時的。
研究、分析、細化數據需求細節的時候。數據需求通常比較瑣碎、趨于細節信息，因此不要期望用戶能夠將其記在腦子里，這些信息往往寄生于各種類型的文檔中。
4. 用戶界面原型
使用界面原型的優點在于直觀生動，用戶界面提供了早期評審，易于用戶理解。缺點同樣很明顯，就是耗時。在業務很復雜或很重要的需求部分時（不建議全程使用，除非有專門的UE），與客戶就需求甚至方案產生盲區，不易達成共識時。
使用該方式需注意，以業務場景展現頁面交互，在講解原型時，按照客戶工作的業務活動說明某個業務場景下客戶應該怎么做，把相關的頁面交互串聯起來，讓用戶帶著業務線索來審視系統的操作過程，看看是否合理、是否滿足需求。串聯體現了原型的動態性、交互性，用戶不僅僅關心用戶界面的樣子，更關心用戶界面的流轉過程、交互過程。
5. 現場學習
現場學習最大的優點在于百聞不如一見，能夠對需求與業務流程建立直觀的認識。但缺點則是耗時長，不宜安排，且由于“觀摩”心理干擾，可能會失真。當客戶無法詳細解釋他們在做什么或遇到問題說不清楚原因時。“人正在做一件事時，最能解釋他在做什么、為什么要這么做”。
使用該方法需要注意，第一避免失真：現場觀摩或學習時，不要“大張旗鼓”的進行，導致操作者受到“辦公室文化”影響而呈現出理想化的狀態（會遮蓋問題）。第二切勿走馬觀花：現場觀摩時要努力總結整個任務的步驟、找到主要的業務活動（脈絡），切不可嘻嘻哈哈看完了事；第三盡量錄像：在條件允許的情況下可以錄像反復觀看，降低對客戶的影響且可以給其他人員在需要時觀看。
6. 聯合開發（駐場）
這種方式優點是客戶、產品經理、開發齊聚一堂一起探討，更容易完成用戶需求到解決方案的轉換過程。缺點則是成本高，且控制不當就會變成扯皮大會。
項目啟動初期：剛開始對項目的目標與范圍都很模糊，需要一起討論使得目標更明確，范圍更清晰，為需求、開發指明方向，。同時對于關鍵業務域、功能塊：系統中核心的關鍵部分，保證需求的準確性。
五、需求分析分為三個階段
一階段主要針對中層管理，用于梳理清楚需求脈絡，為需求捕獲二階段業務活動的捕獲與分析做鋪墊，我們將該階段比作“畫骨”。
二階段主要針對操作層（基層），用于梳理清楚業務活動的業務步驟（細節），為之后的用例建模與數據建模做鋪墊，我們將該階段比作“填肉”。
三階段針對質量要求與約束進行補充，我們將該比作“化妝”。
一、一階段（畫骨）
1）流程相關知識
什么業務流程？即由多人協作，并且需要一些有效的規則來控制，才能達到預期效果的過程。
業務流程的六大特性：
- 目標性：流程是針對目標進行設計的，是一個整體，或許從局部來說是低效的，但目標是整個流程的高效。
- 內在性：流程本身是一個高內聚的整體，是一個很好分離業務耦合點的線索。
- 整體性：通常流程是由多個業務活動組成的，分析的要點在于確定業務活動之間的關系。
- 動態性：流程是行為流，不是一個靜態的快照，而是一個順序的行為流。
- 層次性：組成流程的活動本身也可以是流程，這也經常困擾流程分析的BA人員。要點在于理清流程的層次，通過逐層嵌套的形式理清脈絡。
- 結構性：流程之間的關系主要包括串聯、并聯和反饋三種。
業務流程的分類：
如果拿軟件開發過程來說的話，需求分析、軟件設計、軟件編碼、軟件測試都是生產性流程；
項目管理、質量保證就屬于管理性流程了；支持性流程包括配置、文檔控制等。。
- 生產性流程：流程中最重要的部分，是企業/組織價值的核心體現，通常是最容易識別的一部分；
- 管理性流程：是對生產性流程的管控，通常是由管理層發現的，對一些質量、效率進行監督的控制性流程，是容易忽略的部分。
- 支持性流程：是對生產性流程的補充，通常是協作部門、本部門員工執行的工作，是最容易丟失的部分。
業務流程的設計原則：
- 以產出為中心：流程以產出為中心，而非任務為中心。流程是否合理，是否高效，關鍵是從整體上進行評價，僅對一個業務活動進行分析是片面的。不要聽從操作層的一面之詞，要更多從整體來看待合理性。
- 自食其力：讓那些需要得到流程產出的人自己執行流程。
- 權力下放：就是管理層級的扁平化，將決策權下放到更低的管理職位上，這樣就會得到更高的效率（在需求分析過程中，如果發現現有的流程將決策點放在較高的管理崗位上時，就應該注意它經常會帶來流程執行上的瓶頸，也就會影響信息系統的運作）。
二、執行步驟
1）業務流程識別（確定子系統范圍），
同時堅持先內后外，先業務后管理的原則。業務流程屬于脈絡信息，掌握在中層管理者手中，因此該部分需求獲取與確認應該找中層管理層，一般是部門負責人（關鍵干系人）；梳理服務請求時，將諸如修改密碼、數據備份之類的技術活動先放在一邊，我們梳理的是業務事件，而不是系統事件。
2）任務執行指引
1、識別外部引發的主、變、支流程
- 識別外部客戶：本業務子系統有哪些外部客戶；
- 識別外部員工：哪些其他部門員工會提出服務請求；
- 識別主業務流程：外部客戶/外部員工的服務請求是什么？端到端流程是什么（主業務流程）；
- 識別變體業務流：主服務請求，存在的無法整合到主業務流程的獨立變體；
- 識別支撐業務流：為了更好服務外部客戶/外部員工，需要哪些輔助業務流程支持；
2、識別內部引發的主、變、支流程
- 識別內部員工/時間/狀態：特別注意哪些特定時間、狀態引發的流程
- 識別主業務流程
- 識別變體業務流
- 識別支撐業務流
3、識別管理流程
- 業務上線類的審批控制；
- 人財物資源的管控
- 進度與異常的控制
- 判斷業務流程優先級
業務流程是信息系統交付的最小單元，只有實現了一個完整的業務流程支持，才能對用戶產生增量價值，所以建議以業務流程來制定迭代計劃。
- 是否為主營業務：主營、非主營
- 發生的頻率高低：高、低
3）輸入產物—《業務流程列表》
- 類型：說明是主業務、變體業務、支撐業務流程，管理流程
- 流程名稱：不要將服務請求名稱寫入，轉化為合適的流程名稱（只通過服務請求尋找流程）
- 簡要說明：說明流程的起點終點及流程目標概述
- 優先級：關鍵、重要、有用、一般
4）業務流程分析與優化
任務指引：
- 選擇流程圖描述方式：根據讀者、流程類型選擇合適的流程圖來描述流程分析的結果。其中包括：
- 跨職能流程圖/活動圖：強調每個角色執行的活動；
- 順序圖（序列圖）：強調各角色之間的協作、交互（經常用于表達系統間的業務流程，強調數據交換過程）；
- 數據流圖：強調數據流通、加工和處理過程；
- 勾勒流程主體：厘清業務流程中的五大基本要素，搭出流程主體框架。五大基本要素是指：
- 分工：從提出服務請求到服務請求被滿足的端到端過程，涉及哪些角色；
- 活動：每個角色將負責完成哪些獨立的業務活動；
- 協作：這些業務活動如何協作的，是串行或并行或異步；
- 分支：針對不同情況如何處理；
- 產物：協作過程中會傳遞哪些文檔。
補充事中管控點：厘清業務流程最終的三大管理要素：
- 審批：在流程中應加入那些審核項，以便控制風險。在分析流程時，應該識別出審批內容、審批意圖才是真正的分析到位（禁止使用“崗位+審批”的格式命名審批，例：總經理審批，但這并不能表明審批內容、審批意圖，之后如果換個人干這事，流程實際上并沒有發生本質變化）；
- 規則：在流程各活動有什么規則；
- 異常：完全無法按照流程執行時，如何應對（流程執行中總會出現一些意外、異常，實現需要制定一些備案，以備應急之需。若處理應急過程比較復雜，可以另外繪制一張異常處理流程圖）
分析流程執行過程的監管需求：從管理者的角度對流程進度、異常等進行管控識別、補充輔助相關需求。
- 管理者如何監控流程執行的進度、效率；
- 管理者關心哪些異常？如何監控；
- 管理者對監控還有哪些要求；
流程圖繪制：
繪制要點：
- 分工平級：保證在同一水平線，要么全崗位，要么全部門，不要混用。且如果全部門，盡量保證部門都是平級部門；
- 活動命名采取動賓結構：活動是一個工作任務，因此不能夠使用名詞或名詞短語，例：申請體檢（正確命名）；
- 不考慮系統邊界：畫流程圖時先不考慮系統邊界，不是只畫與系統相關的部分，以免在分析、設計階段斷章取義；
- 從服務請求者開始：流程起點從服務請求發起者開始，保證流程的完整；
- 主從活動只留一個：流程中很多時間存在主動活動，比如消費者繳費→收費人員收費，按照流程圖讀者角度保留一個即可；
方法/步驟：
- 一聽：請業務專家或客戶代表講述過程，在紙上或其他形式快速畫出流程脈絡，這時只需要明確分工、活動及基本的協作關系。過程中做到“不打斷、不陷入細節”。
- 二問：沿著流程發問
看看是否存在分支的情況，邊問邊修正；
問問各協作之間的產物關系，將其補充出來和業務專家、客戶代表就“異常”進行交流，思考“是否存在完全不能當前描述業務流程執行的情況？如果發生了，應該怎么處理？”
沿著流程思考是否需要設置一些規則，比如協作間規則：用于控制流程協作，例：滿足什么條件，流程如何流轉。活動執行規則：執行每個步驟時需遵循的規則，例：當前活動只能干什么，不能干什么；數據規則：針對產物格式、內容進行限制，例：金額需要精確到小數點后兩位。針對業務流程的“執行進度、效率、異常執行、風險”等管控需求進行詢問排查
三讀：產品經理講一遍流程，確保與客戶代表/業務專家達成一致
流程優化：
思路：
要想“解決問題，首先要發現問題”，要優化流程同理。那如何發現流程中值的優化的地方？
建議以“同理心”轉換到客戶角度，通過“穿越流程”的方法識別問題。通俗的講，就是將自己想象為當前“執行人”執行流程時，讓你自己去做一件事時，思考流程中有哪些繁瑣、可以簡化或優化的地方，識別出來。
策略：
- E（清除無效）：找到流程中不產生效能的、浪費的、低效的環節，想辦法清除
- S（簡化高頻）：對流程中頻率最高的環節進行優化，提升流程效率
- I（整合依賴）：將相互依賴的環節整合在一起，提升效率，例：開單和收費就可以在“同一窗口”處理
- A（自動化繁瑣）：將人做起來麻煩的事情讓電腦干，提升效率比，例：復雜的計算只需要人提供輸入，由計算機按照預設規則運算，輸出結果
本文由 @渣渣 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自?Unsplash，基于 CC0 協議
- 目前還沒評論，等你發揮！
