搜索 | 会员  
知识管理在IPD研发管理中应用实践
来源: 简书   作者:CIO之家的朋友  日期:2021/7/16  类别:研发管理  主题:项目管理  编辑:不羁与醉
所谓的知识管理、配置管理、流程管理都只是工具,指望它们能够解决人的问题,只能是南辕北辙。”不谈这位仁兄的言论的正确与否,但他谈到的一个现象的确存在,那就是我们在研发管理中想要、甚至

所谓的知识管理、配置管理、流程管理都只是工具,指望它们能够解决人的问题,只能是南辕北辙。”不谈这位仁兄的言论的正确与否,但他谈到的一个现象的确存在,那就是我们在研发管理中想要、甚至是迫切需要的合格的系统工程师、架构师非常难以得到

随着社会分工越来越精细,在某个领域的专才比较容易找到(领域的深度),但是跨多个领域的全才就不容易发现(领域的广度)。在工作中,我们时常会焦虑:我不是全才,不是所有领域都懂,面对各样的挑战,感觉知识积累不足,无法跟上公司快速发展的步伐。这种现象,我想每个人身上都发生过。同样的事情也在企业中发生:这个岗位需要的人力素质模型太高,很难找到合适的人。遇到这样的情况,怎么办?难道要祈祷老天降下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咨询时客户的一段话:“我们在做产品开发时,有时间去救火,却没时间将事情一次做对”。好好反思,我们匆忙地去开发,前期没有认真分析、没有认真学习,真的是“事倍功半”,开发效率下降,质量不高,浪费严重,真的是得不偿失的行为。

今天分享的只是过往实践的总结,它在应用中的确发挥了作用,效果明显。对于学习型的企业,同行协助未尝不是一个好的尝试。知识管理,在企业中任何时间开始都不晚,那么,请就从现在开始吧!



德仔网尊重行业规范,每篇文章都注明有明确的作者和来源;德仔网的原创文章,请转载时务必注明文章作者和来源:德仔网;
头条那些事
大家在关注
我们的推荐
也许感兴趣的
干货
了解一下吧