前不久发生的一段小插曲，让我很有感触，事情是这样的。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咨询时客户的一段话：“我们在做产品开发时，有时间去救火，却没时间将事情一次做对”。好好反思，我们匆忙地去开发，前期没有认真分析、没有认真学习，真的是“事倍功半”，开发效率下降，质量不高，浪费严重，真的是得不偿失的行为。今天分享的只是过往实践的总结，它在应用中的确发挥了作用，效果明显。对于学习型的企业，同行协助未尝不是一个好的尝试。知识管理，在企业中任何时间开始都不晚，那么，请就从现在开始吧！
本文来自网络，汉捷咨询
网友评论