01
—為什麼要挖掘痛點
軟體研發活動，涉及研發流程、規範、團隊協作、專業技能要求等多方面的組成因素，各方面也需要持續改進才能匹配軟體這樣需求變化快和技能變化快這樣的現狀要求。而縱觀各方面持續改進的手段，一般都是在原有基礎上做加法操作，大動骨架的操作比較少，也不好實施。這種改進方式，隨之帶來的，就是流程的臃腫、規範的多而雜散、協作方的增多、專業技能要求增高等問題，這些問題經常也會是調研一線開發人員的意見反饋時，他們提的較為頻繁的問題。如果不去改善這些問題，那麼研發組織的交付能力只會逐漸惡化，最終交付不順暢、無法快速響應客戶訴求而錯失良機。
但所有問題並不都是痛點，痛點是問題背後的本質原因，針對研發組織而言，無法及時交付高質量軟體的本質原因就是研發組織的痛點，所以問題背後的痛點挖掘，是學習型組織必須持續進行的一項改進活動。
當然，痛點挖掘再重要，也得有前序和後序動作相互作用，才能產生價值和收益。一般的動作步驟如下圖描述，先找到痛點挖掘的出發點，再採用合理的方法進行痛點挖掘，再針對性給出改善方案，進而對方案進行效果評估驗證，最後將驗證通過的方案舉措規範化到研發活動或研發流程當中，作為固化的動作來執行，讓痛點挖掘和改善的價值最大化被利用。
—從何處挖掘痛點
痛點的挖掘，從出發**上講，分為主動式和被動式。
主動式主要是研發組織當中的積極者，憑藉著對未來更優工作方式和工作環境的期望，來持續尋求改進。例如，研發流程相對順暢，但交付效率期望再提公升30%，這時就需要主動從交付效率維度深入分析，找到阻礙效率提高的因素，「如何消除阻礙因素的影響」就成為痛點挖掘的切入點。
被動式主要是當前組織已經面臨交付能力問題，前行受阻，需要直面問題做改進，才能讓恢復組織的生產力。例如，交付給系統測試部門的軟體，頻繁被提嚴重故障單，質量表現很差，這時就需要被動的從質量交付出發，分析哪一類故障洩露佔比高、哪一類功能的故障洩露佔比高或哪些人或團隊的故障洩露多，以此作為痛點挖掘的切入點。
對於主動式或被動式的痛點挖掘**，挖掘方法上基本類似。
03
—如何去做痛點挖掘
痛點**於問題，屬於問題的本質性描述。從問題出發挖掘痛點是首要的，挖掘出的是否是痛點需要驗證，痛點挖的是否到位也需要有準則來驗證，一般步驟如下。
3.1 從問題表象切入
**問題並不能和痛點直接等同，因為有些問題可能只描述了乙個不理想狀態的表象。但痛點的挖掘，又是**於問題的表象。**從問題表象做切入，尋找問題背後的本質原因之後才有可能挖掘到痛點。比如所在的研發組織連續幾個迭代都無法按期交付需求，這其實就是個不理想的問題表象，這個問題背後，是因為交付流程某個環節頻頻阻塞造成的，還是因為流程整體的不合理導致？有了這些why，就算是走到了問題本質挖掘的環節。研發活動中的問題表象比較多，比如無法按期交付需求、任務多卻成就感低、工作效率低下、故障洩露多、資源浪費嚴重等。
3.2 通過找問題本質挖掘痛點
繼續剛才的例子，所在的研發組織連續幾個迭代都無法按期交付需求，分析資料後，發現是因為交付流程某個環節頻頻阻塞造成的；再次分析，這個環節的阻塞又是因為有協作方的介入，但協作方又在節奏上和資源投入上不能與協作的期望相匹配而造成的。到這裡，已經走在找問題本質的路上了。挖掘本質的方法總結如下：
（1）放眼全域性，找聚焦點
連續幾個迭代無法按期交付需求的問題要分析，需要將整個交付流程攤開去面對，從整個流程的全域性去分析，會發現阻塞環節是在不同協作團隊的功能整合上，功能整合環節作為分析的聚焦點被關注。
（2）聚焦區域性，分析本質
聚焦到功能整合環節後，做深入分析，發現最本質的原因是某個協作團隊在大多時候都無法按期交付自己的功能，導致整個功能的整合進度受阻。
（3）擴散到關聯因素，做全面分析
如果只關注到某個團隊的參與力度不充分的因素上，那麼可能僅僅只分析到了區域性的原因，需要擴散到關聯因素。關聯因素，包含需求的計畫制定、人力資源的投入、協作方的任務優先順序等，這些也是直接影響能否按期做功能整合的重要因素。
3.3 驗證痛點挖掘到位
挖掘到的是否是痛點？是痛點，但是否挖掘到位？也是執行過程中必須要面對的疑慮。繼續剛才的例子，「連續幾個迭代無法按期交付需求」問題的本質分析為「協作方在節奏上和資源投入上不能與協作的期望相匹配」，這是否就算是找到了問題的本質原因並挖掘到痛點了嗎？
若肯定的回答「是」，那麼「如何提公升協作方的參與力度」就作為痛點，來被討論和制定改善方案。在討論改善方案時，就會有人提出「為何協作方不願意及時配合？」這種發散性疑問，這個疑問足以說明問題的本質原因還是挖的不夠到位，這樣就難以讓討論者的思路直接聚焦到改善方案上，而是仍然在是否是痛點的疑問上徘徊。
若否定的回答「不是」，那麼意味著問題的本質還可以分析的更加深入。再仔細分析，協作方的參與力度不夠，是因為交付的目標在協作方那裡的優先順序並沒有高到值得去投入充分的資源來保證交付不受阻，說簡單點，就是交付方和協作方的目標和計畫上未達成共識，那麼痛點就變成了「如何保證交付方和協作方在目標和計畫上達成共識」，此痛點的描述，很自然地就會讓討論者去直接思考如何針對達成共識做改善，從而，也才有可能討論和制定出貼切的解決方案。
所以，是否是痛點，痛點挖掘是否到位，都應該有個驗收準則才能更客觀的去評估。是否是痛點，總結為一句話：去反向思考挖掘出的痛點是否會造成問題表象的發生。痛點挖掘是否到位，總結為一句話：挖掘出的痛點，能否讓人看到後就能沿著習慣性思維去想改善方案是什麼，而不是還停留在這是否是痛點的疑問思考上，那麼，這時挖掘出的就是較為到位的痛點。
04
—痛點的改善和效果驗證
痛點挖掘有出發點，也有了體系的挖掘方法，只要做到位，對於研發組織的交付能力提公升來講，輸出的痛點結果就是組織的基本改進目標了。有了改進目標，就方便去聚焦想法和資源進行改善方案的輸出，以求達成目標。由於針對不同的具體問題，改善方案可能相差甚遠，需要展開篇幅去專門討論，此次不做簡單討論。但改善方案的效果驗證卻是相當關鍵的動作。
總體來講，可從方案實現視角和使用者視角兩方面來驗證。繼續用本文的例子來說明，「保證被協作方和協作方在目標和計畫上達成共識」的改善方案是從需求規劃優先順序一致、版本節奏匹配、開發計畫和功能整合計畫同步幾個方面合力矯正，那麼，從方案實現視角看，改善效果驗證通過的完成定義，就是方案中設定的優先順序是否一致的指標、版本節奏是否匹配的指標、開發計畫和功能整合計畫是否同步的指標表現符合預期；從使用者視角看，改善效果驗證通過的完成定義，就是研發的交付順暢程度所對應的指標有所增加、交付效率對應的指標有所提公升，研發組織的交付是否進入到乙個順暢且持續產生提效增益的發展狀態。
將驗證通過後的改善方案中的舉措規範化到日常的研發流程或活動中是極其必要的動作，也是讓挖掘出的痛點不再表現出「痛」的最徹底的手段，充分體現痛點挖掘的意義和價值。
微型研發團隊建設
微型團隊存在於大部分企業，但是微型團隊的建設容易成為企業管理的盲點。本文結合筆者多年基層管理經驗，立足基層研發人員，闡述了微型團隊中研發人員日常工作中遇到的各種具體問題，強調了個體在微型團隊發展過程中的重要作用，從管理角度分析了解決這些微型團隊存在的問題的根本之道。不管是大公司的模組小組還是小公司的...
研發團隊高效溝通思考
研發團隊問1 1等於幾的問題，而不會出現思想障礙的溝通氛圍 研發團隊無縫溝通的思考 研發團隊，從技術創新的角度看，是公司的未來，是祖國強大的基石 招聘的，合作的同事 同仁 同學都是精英中的精英 這是不能質疑的 那為什麼還是要提出這個研發氛圍呢 基於以下幾個原因 1.我們是各個領域的專家 2.我們是公...
創業研發團隊招聘漫談
創業團隊如何招聘到合適的程式設計師是每個招聘主管的頭等大事。我所在的團隊只有10來號人，隨著業務發展，目前正在積極擴建，所以前前後後面試了有1年的時間。其中有成功的，也有很失敗的，有幹一年就跑掉的，最短三天就走人，讓人無比鬱悶，如何才能找到滿意的人員，如何能得到價效比高的程式設計師，可能是創業當中的...