前不久發生的一段小插曲，讓我很有感觸，事情是這樣的。

Linkedin給我發來邀請，參與關于“被研發問到不懂的問題該怎么辦”的討論，結合工作經驗我給予了我的建議。Linkedin上一個做工業人工智能的兄弟回復：

“這些理論看似頭頭是道，其實都是唬人的，一個高水平的需求分析、系統工程師、構架師，是不會出現這種問題的。當然我說的高水平，至少是這三個角色都是牛人的級別。05年在和rational（當時剛剛被IBM收購）聊RUP的時候，就討論過類似的問題，最后的解決方案是：一個superman。所謂的知識管理、配置管理、流程管理都只是工具，指望它們能夠解決人的問題，只能是南轅北轍。”

不談這位仁兄的言論的正確與否，但他談到的一個現象的確存在，那就是我們在研發管理中想要、甚至是迫切需要的合格的系統工程師、架構師非常難以得到。這位兄弟的觀點我理解是：找到這樣的人才，是不可能的，并開玩笑地提出解決方案，找到superman！

隨著社會分工越來越精細，在某個領域的專才比較容易找到（領域的深度），但是跨多個領域的全才就不容易發現（領域的廣度）。在工作中，我們時常會焦慮：我不是全才，不是所有領域都懂，面對各樣的挑戰，感覺知識積累不足，無法跟上公司快速發展的步伐。這種現象，我想每個人身上都發生過。同樣的事情也在企業中發生：這個崗位需要的人力素質模型太高，很難找到合適的人。

遇到這樣的情況，怎么辦？難道要祈禱老天降下Superman？！

等、靠、要的思想不會存在學習型企業中。遇到問題，我們來解決，沒有合適的人才，該崗位不能空著，也不能“矮子里拔大個”，這都不是優秀企業的做法。

結合我的工作實踐，我推薦“知識管理”中的“同行協助”這個工具，可以有效地解決這類問題。這和IPD核心思想之一“跨部門合作”異曲同工。從管理角度看，思想是相通的，只是實施的手段不同而已。

下文以筆者在H公司開展同行協助為例，介紹如何開展“同行協助會”，結合英國石油開展“同行協助會”的經驗，知識互補，梳理“同行協助會”的步驟。

H公司C地區部下A代表處簽下一個訂單，由A國電信部牽頭，H公司A代表處負責實施，在2年內為A國電信部培養2000名電信人才。如何開發培訓教材、選擇什么樣的培訓方式，符合當地人的習慣？這都是問題。而且在啟動會時，A國的總統要到現場并參觀A代表處，如何接待總統？這些問題A代表處都沒有任何經驗，于是求助到地區部，地區部也沒有相關經驗，求助到機關KMCoE（Knowledge Management Center of Excellence）。當我們接到一線求助，通過圈子發了求助帖子，同時通過PMO在全球尋找具備相關經驗的項目。很快PMO有反饋，機關的國際關系部小M處理過類似項目。于是我聯系小M，講述了A代表處的難題和挑戰，小M的確有類似項目經驗，對當地的習慣也非常了解，于是答應參加我們的同行協助會，于是由KMCoE組織C地區部、A代表處、機關國際關系部小M，機關PMO五方共同開展了同行協助會，我作為聯絡人及主持人召集本次同行協助會，大致的過程如下：

1.會前由A代表處提供項目背景信息，項目問題；

2.聯絡人與與會的各方確定會議主題及會議時間（預定電話會議）；

3.會議召開，由主持人介紹與會成員，明確會議主題，會議注意事項；

4.由求助方（A代表處）介紹項目背景，遇到的問題；

5.機關小M介紹她參與過的項目過程，濃縮關鍵點；

6.A代表處對于不清楚的地方再次詢問，小M提供解答。C地區部、PMO也分享各自觀點。對于引申的其他問題，開展討論；

7.當討論問題過于發散，由主持人及時將會議討論導引回會議主題；

8.A代表處得到問題的解決方案，對本次同行協助參與各方表示感謝；

9.會后，KMCoE感謝小M的參與，給予紀念品表示感謝；

此次同行協助使得A代表處獲取了經驗，結合自身實際，圓滿的完成接待工作，并順利的完成了教材的編撰，成功的實施了第一次培訓，得到當地政府高度贊揚。本次同行協助會在當年獲得最佳同行協助獎，小M作為協助方，也獲得了榮譽。

事后回顧本次同行協助，還是有不足，有些地方還有改進的空間，比方說，會前可以私下聯系，但邀請小M，則應該通過BU的領導聯系小M的部門領導，這樣正式的邀請會使得小M支持本次同行協助更正規，會后，應該由BU的領導發郵件給小M領導表示感謝，這樣使得小M更有榮譽感。這里分享IBM的做法，IBM為了營造知識共享的氛圍，這個郵件是由一級部門領導直接郵件給對方一級部門領導，抄送協助者及其直屬領導，對該部門的支持表示感謝，并對員工的支持點評，給予肯定。領導通過郵件來往，就表達出公司對知識共享的肯定態度，同時也使得協助者更加有榮譽感，更愿意提供經驗共享。在公司營造良好的知識共享氛圍。

回歸主題，在H公司開展知識共享的經歷，再融合英國石油公司的同行協助的經驗，將組織一次成功的同行協助會分如下步驟：

1. 明確目的；

A、列出你希望得到幫助的問題；

B、考慮一下，同行協助是否有最合適的幫助途徑；

C、聯絡人注意：搞清楚同行協助的目的，確認主持會議的人，是否真的想要學點東西。理想情況，同行協助目標是解決企業/項目的一個主要風險。

2. 查找是否有人已經解決了這個問題；

A、查公司的知識庫，找到其他人是否解決了這個問題；

B、告訴其他人，你要做的同行協助，他們可能有同樣需要；

3. 任命一個聯系人；

A、接受一線求助后，了解求助內容；

B、協助一線尋找資源，并協調資源提供幫助；

C、安排會議；

D、主持會議；（PS：會議記錄由一線自己整理，然后制定一線的行動計劃）

4. 考慮時間期限，安排日程進度；

A、會議時間越早越好，不要在即將行動/決策前再開會；

B、會議的安排要避免假日，出席人的時間安排不要沖突等；

C、會議的時長，取決于討論問題的復雜程度和小組成員對背景條件的熟悉程度。

5. 挑選不同人員參加會議；

”等級制度會阻礙思想自由交流，人們對自己的同行會更開放些，他們之間會更愿意分享和傾聽“? ?—— 約翰·布朗尼 （BP執行總裁）

A、一旦目標明確，列出需邀請的與會人員名單。

B、要擁有這個同行協助會議需要的各種技能、能力和經驗的人；

C、6-8人參加最理想；

D、聯絡人注意：會前與一線及邀請的客人充分溝通，避免匆忙邀請不熟悉求助內容的人；同時，時間安排合理，讓所有人自由暢談，不能壓制新思路；

E、拒絕質疑者。這種人習慣傳播負能量，如前文提到Linkedin上的仁兄，未有實踐，或者實踐方法不正確，沒有起到效果，然后就否定一切，這不是學習型組織期望看到的現象。

6. 清楚定義你希望達到的目的，以及你計劃怎樣達到；

A、盡量早為與會人員提供必須的資料摘要，使他們在會前過目；

B、清楚表達會議目的和面臨的問題，或你希望大家能夠給予幫助的那些問題；

C、將這些觀點和思路再整合到迎接挑戰的過程中去；（注意，求助者找出的問題可能只是一些“征兆”而不是根本病因。）

7. 會前如果能讓大家彼此熟識，開會的效果會更好；

8. 確定會議目的，制定基本規則；

A、主持人表明會議希望的行為；

B、用矩陣圖解釋知識共享過程；

C、先簡要介紹求助者的問題；

D、要保障有充裕的思考和反饋的機會——可以問一些簡單的問題；

E、參與者的責任是提供迎接挑戰所需要的幫助、知識和經驗，而不是增加工作負荷。

F、主持人注意：確保討論時，對事不對人的原則！

G、被邀請的會議成員應該建議求助者不要做什么，可以再做些什么。他們的首要任務和重點是努力使求助者面臨的挑戰做的不同。

9. 將可用的時間劃分4個部分，從分享信息和背景條件開始；

第一個1/4時間，請求助方講述問題的背景、歷史和將來的計劃。

A、要防止講述時帶有過多的傾向性，不能讓他們說得太多，只要說到正好為協助會提供正確的前進方向即可；

B、若想進一步了解某些事情，可以向求助方提問；

C、確保協助方有足夠的時間參與，仔細傾聽協助方說什么；

D、聯絡人注意：問題背景介紹要簡明扼要，會議所講述任何一點信息都有可能成為討論的焦點。避免這種情況的方法——了解協助方想知道的內容。

10. 鼓勵客人詢問他們想知道的問題；

第二個1/4時間，協助方思考他們聽到的并開展討論；

A、討論“那些使他們驚奇的部分”&“他們想知道還沒有聽到介紹的部分”；

B、同行協助會成員確定他們的行動計劃。

C、聯絡人注意：協助會不是要協助方解決問題，而是根據他們自身經驗，提供一些選擇和觀點。

11. 分析你聽到的；

第三個1/4時間，分析并總結你所學到的東西。

討論過后，總結討論的內容，并向與會人員講解——你學到什么，你看過的方案，什么東西其他地方還能用

12. 將反饋公布于眾，看看每個人都學到了什么，并對行動達成一致，及時報告進度。

最后1/4時間，綜合所有反饋，在行動方案達成共識。

A、協助方需要向小組講述他們對事物的反饋，回答求助方的問題。

注意：

1、避免在這個階段出現爭執；

2、所有的反饋，從做得出色的地方開始，然后是各種不同的做法；

3、將注意力集中在行動上，不是具體個人。

B、協助會的組織人要感謝協助方的幫助。告訴大家什么時候他會用什么行動方案作為回復。并可能再次邀請這次協助會的成員提供幫助。

C、協助方也可以說說他們準備帶走和使用的體會。

D、最后進行事后回顧，協助會是不是按原計劃進行？和原來有無區別，為什么有區別？從中學到了什么？

E、以積極綜合聲明作為會議的結束語。

13. 營造知識共享氛圍，主管間郵件表示感謝，對協助人員肯定。宣傳本次同行協助會；

以上是知識共享中“做前學”管制“同行協助”的介紹，這里融合H公司、英國石油公司、IBM公司關于知識共享的理念及方法。結合我們產品研發管理（本文中A代表處培訓交付采用的是IPD-S開發，即在服務領域遵循IPD原則進行產品開發），特別是在制定Charter時，這個項目我們做不做？在制定總體技術方案時，我們之前有沒有類似的經驗可借鑒？在產品開發過程中，某領域的難點我們是否有過解決方案？這些場景，我們都可以參考“同行協助”的方法，去尋求幫助，去找靈感。

借用在IPD咨詢時客戶的一段話：“我們在做產品開發時，有時間去救火，卻沒時間將事情一次做對”。好好反思，我們匆忙地去開發，前期沒有認真分析、沒有認真學習，真的是“事倍功半”，開發效率下降，質量不高，浪費嚴重，真的是得不償失的行為。

今天分享的只是過往實踐的總結，它在應用中的確發揮了作用，效果明顯。對于學習型的企業，同行協助未嘗不是一個好的嘗試。知識管理，在企業中任何時間開始都不晚，那么，請就從現在開始吧！