管理沟通案例分析
——以罗克韦尔自动化大连研发中心为例
12行政2班 12110242 芮新云
一、案例背景资料
（一）案例来源
《RA公司跨文化管理沟通案例研究》 作者：姚雪勤
（二）案例正文
美国罗克韦尔自动化（RA）主要从事于提供工业自动化与信息解决方案，致力于帮助客户提高生力，降低运营成本，以更快的速度将产品和服务推向市场，并最大限度地降低能耗、提高工厂正常运行时间、满足安全需求和监管规范。
FTV是RA公司大连研发中心负责开发的主要产品线之一，该产品线的联合发布系列包括可视化解决方案、数据服务器通信、集成管理以及系统诊断等多个家族产品。FTV下属产品A的新一代发布将会跟随整个FTV产品线的联合发布周期(15个月)，由中美的跨国团队协作完成。
John是FTV下属产品A的研发主管，他将在2013年带领研发团队的5名队员负责该产品新一代升级的开发和维护。2013年第一个季度是产品的需求收集和资源评估阶段。美方产品经理Steve为大连的研发团队划定了该产品此次发布需要涵盖的客户需求，其中包含5个主要的新功能研发以及4个既有功能的维护。Steve根据市场调查分析的结果，将9个功能按照优先级进行排列，新功能开发的优先级整体高于旧功能的维护。
John和他的研发团队在充分理解客户需求以及新功能设计方案的前提下，根据既有的人力资源配备估计完成所有工作量所需要的时间。其结果是基于现有团队的人力条件，需要9个月的时间完成所有功能的研发维护；之后预留3个月与大连测试团队合作进行单产品测试、再调试以及验证；最后3个月要交付产品A参与整个FTV产品线的集成测试。此外，还困扰着John的一个问题是每年都会有客户反馈的紧急问题，客户
应急响应的优先级高于新功能开发，总结历史数据并结合往年经验，此类事件通常要用3个月的工作时间。也就是说，基于现有资源的估计(18个月)已经超过了 15个月的发布日期要求。
John先向自己的直属领导(部门经理)反馈了工作量的评估结果，部门经理跟他交流了自己的意见。部门经理强烈建议他保留3个月时间来保证客户应急响应，并提醒他在本次产品的发布周期内一定要提高产品质量，潜在的产品问题应当从产品设计和开发阶段早发现早解决。由于FTV的此次联合发布涉及到多个产品的新功能研发，每个下属产品均从整个大连研发团队的人力资源库中配备资源，部门经理希望John的团队能够抽调1-2位队员去其他产品组，对客户优先级更髙的其他产品进行支援。部门经理建议John与Steve协商，考虑将产品A优先级最末位的3个功能项从此次联合发布的工作范围中去除。
John次日将评估结果完整上报Steve，并参照部门经理意见，建议Steve考虑去除3个优先级较低的功能开发，报告要点总结如下：结合FTV产品线的联合发布时间，产品A工作量溢出。现有研发团队共计6人，完成现有5个新功能开发以及4个既有功能维护，预计18个月完成所有工作量，超出发布预期3个月。
潜在的客户应急响应时间预计需要3个月，因其优先级最高，将影响功能开发进度，交付日期延长的风险进一步加大。
FTV产品线内存在优先级更高的产品，产品A团队中的1-2位队员需要转去其他产品支援。
产品经理Steve听罢John的报告之后，做出如下反馈：
认可John的团队对于产品功能的评估时间，并同意将原有的9个功能的研发计划按照优先级调整为6个。其他3项功能虽然可以不承诺参与此次联合发布，但他强烈主张保留它们作为备选，团队可以在人力条件充足的时间段内选择性地完成。虽然这对于研发团队来说是很大的挑战，但是这3项功能的存在将帮助产品团队和营销团队向客户推广产品A 时，增加更具吸引力的卖点。
Steve对于“3个月”的客户应急响应时间提出异议。理由是客户应急案例十分随机并且不可预测，并不能排除本年此类案例稀发的可能性，他认为伴随产品性能的稳定，此类紧急案例将逐年减少，因此他个人认为这并不会对交付日期产生很大的影响，建议将“3个月”时间预留给3个备选的功能开发。而且他明确表明，自己能够接受此风险带来的影响，并建议团队可以等到该风险出现时重新讨论工作任务的优先级并调整工作范围。
当得知本产品的团队中有1-2个人要转移到其他产品时，Steve表现得十分吃惊，并表达自己的抵触情绪。他坦言没有放弃3个备选功能的实现，希望John的团队将全部精力用于自己的产品。同时，对于中方团队擅自内部决定的做法，Steve表达了自己的不满，对于项目人员的安排“没有任何人以任何方式提前征得他的意见”，他觉得自己在团队中的存在没有得到尊重。
另外，因为地域和时差的限制，跨国团队合作交流几乎都是通过远程电话会议和电子邮件完成的。如何协调跨国团队并确保其信息交流的通畅成为项目管理团队十分头痛的问题，在协调上也常常遭遇困难。不同地区或不同部门的团队共同参与一个历史问题的讨论，一封电子邮件在几个月里常常会在十几位项目相关人之间发送和转发，项目信息往往在不同渠道间传送时发生遗漏或者反馈不及时的情况。
项目经理CK每天的日程几乎都被电话会议占满了，哪怕是晚上十点甚至是半夜，因为时差的限制，一方的白天工作时间必须对应另一方的晚上时间，召开多方团队会议之前尤其需要确认时间是否安排得合理。
当晚CK，十点钟准时拨通远程电话，当日的会议主题是讨论本地化版本软件产品术语修改引产品发布-延误问题。在三个月前，项目经理通过寻求欧洲产品团队的帮助，对软件产品CCW本地化版本界面进行术语翻译的检查。因为整个过程要经过数层人际网的推动，当时的进展很不顺利，CK在邮件催促几轮之后，只得到寥寥数封信的回复。考虑到三个月后的产品发布安排，CK用信件告知所有项目关系人，为了不影响项
目进度，在未完成所有界面术语翻译检查的情况下，产品将按照原定日期进行发布。在邮件发出之后，没有人提出反对意见。在临近项目发布前两周，欧洲产品团队的反馈姗姗来迟，产品经理看罢检查报告致信CK，他坚决反对产品在存在如此多翻译问题的前提下进行产品发布，因而产品发布决定延期。
由于转勤、离职等原因造成的跨国团队成员替换，信息交接不完善等情况也时有发生，项目经理Jenny在与美国同事Jim的一次项目讨论中进行了以下对话。
Jim：Notice that your team already had a naming convention. Thafs what's so surprising to us that your team is asking these questions when you already had a convention.(我发现你们已经有命名规则了，所以你问这些重复问题时我很吃惊。) Jenny：CF is transferred to Dalian after vl 1. So it's a little bit hard for members to track the information for v8. (CF产品是在版本11之后交接到大连来的，所以小组成员要找到版本8的信息有些困难。)
Jim： Your team has had too much turnover. Too many new PM's and Project leads has made things very inefficient. You make a good point. Going from Patni to Dalian was big in terms of turnover too. We keep revisiting things over and over. Sorry to vent， but this is a very touchy subject for me.(你们的团队人员流动太频繁了，太多项目经理和团队主管的轮换让项目变得很没有效率。你说的对，项目从Patni交接到大连也是很大的人员流动。这让我们不断重复地讨论同样的问题，抱歉在这里抱怨，但是这的确让我很为难。)
二、案例分析问题
[问题1]John对部门经理以及产品经理Steve的工作上报属于什么沟通？产品经理Steve对john的报告做出的反馈又属于什么沟通？
