项目无国界--在多元文化项目中收集需求
项目无国界
--------在多元文化项目中收集需求
项目无国界：在多元文化项目中收集需求 Elizabeth Larson ，PMP 和 Richard Larson, ………………著
获得客户需求是项目管理和业务分析所面临的一个最困难的任务。即使业务分析员和他们的客户同处一室工作，误解仍然还是会产生。不管参与方的背景如何，问正确的问题，让合适的人参与，归档明确的需求都是一个挑战。而如果项目包括多元文化参与者，尤其是包含一个边远地区看不到的团队就更难了。
项目管理和业务分析所面临的挑战不仅仅在多元文化项目中。而个人日程安排，优先级和角色的冲突，以及有效性都会使情况糟糕。此外，近期一些研究表明，几乎一半的典型项目的预算会因为需求缺陷而重新修订。虽然有许多潜在因素导致预算修订，但和多元文化业务客户或项目成员打交道是会产生严重障碍的。
挑战从不同文化背景的商业客户那里收集需求
与客户客观上的距离
虽然即使团队和客户共处一室办公也仍然存在许多挑战,客观上的距离则更会使困难增加。时区问题导致会议计划很难安排.负责这种全球项目的业务分析员体会到8小时工作制不存在了。因为如果我们为客户考虑或为建立良好的客户关系以获得需求，我们安排会议的时间是方便客户，而不是我们。
全球性的项目中很少会议是面对面举行的,这种非口头交流做出评估机会不可能。但事实上为了获取需求非口头的交流并没有减少，因为大多数的业务分析员竭力将它作为获取需求的过程中一部分.虽然最终有视频会议和网络会议可以替代面对面会议,但都不是很理想.视频会议通常缺少鼓动性、声音延迟导致与会人员精神涣散。因为视频会议上多方会谈，个人或群组主导，以及其他一些引出困难的因素大量存在，使用视频会议来推对一个大的团队交流是非常有挑战性的。借助视频会议和网络会议还经常出现设备问题而影响需求的获得。
职责和角色
任何时候职责不清晰和角色不明确都是项目管理和业务分析的毒药。一旦责任和角色不明确，任务总是失败并出现互相推诿指责。更不幸的是，一旦参与人员变化，就需要花更多的时间发现遗漏，更难纠正错误。一旦业务分析员要客户定义需求问题就出现了，客户认为他们已经提出方案了，剩下的事情是业务分析员的。如果站在不同的文化角度对待冲突，意识到这是不同的观念都需要很长时间，更不用说解决这些问题了。
语言
不同文化间的语言障碍是很多的。因不同语言甚至参与者不同的发音带来的困难都是众所周知的。此外，大多数人对于非本土语言的口头以及书写的理解表达能力水平不一。比如有的人能听但不能写。有的人听比说好、写比读好。为了获得需求，项目经理和业务分析员最好和那些在读和说比较好的客户一起工作。
最后，我们需要考虑缩写（取首字母的写法）、幽默、晚言（化妆室、去世、缩小），运动相关的（越位、左进、远射），这些容易引起迷惑和误解。
文化背景的不理解
另一个障碍是假定团队所有成员持同样的文化观点处理项目，不管他们是否一致。比如，我管理一个项目团队里有位男成员对被一位女士直接领导感到很不安。我对会议截止日期、沟通状态，团队协作的重要性谈得越多他越不合作沉默寡言。最后我发现真正的问题是我没有和他建立信任和良好的关系。他工作的文化伦理影响了关系的重要性。因此，他不因为任务属于工作架构中而因为这个关系才完成了任务。
工作的诀窍和技巧
作为从事很多全球项目或包含多方客户项目的公司，他们需要在承诺、包含物、垮国界认知上达成一致意见。此外，项目团队需要明白为了使项目成功完成，它们之间是互相依赖的。客户和项目经理或业务分析员之间需要协作以保证最终产品的成功。因此，相关的每一分子，项目经理、业务分析员、投资者、以及所有的客户都有责任承担文化多样性风险。没有项目经理，公司将花更多的时间和金钱在失败的项目上。没有业务分析员最终产品将不可用。没有强大的支助者和积极的配合的客户，就没法发现真正的需求，最终产品也就不会有了。
参与项目的每一分子都有责任使项目和最终产品成功，而项目经理和业务分析员可以为跨越文化鸿沟作些贡献。
建立信任和关系
建立信任和友谊在所有项目中都是重要的。当客户害怕最终结果危害和极大的改变他们的工作，或者当本地需求没有考虑时，他们有很多方式可以破坏一个项目。随着良好的关系的建立，问题更易于发现、更快能解决
不同方式的需求获取对团队促进团队建设产生或多或少不同的作用：
1．例如：使用调查方式对促进彼此了解作用甚微。
2．便利会议（在全球项目里面可能不得不是网络会议）能帮助建立团队，但可能要花几个星期甚至几个月才能使这个虚拟团队稳定。
3．一对一服务能建立关系和不同政治文化的了解。项目经理或业务分析员可以通过个别会议评估项目进展，讨论个别问题，从那些不喜欢在会议上发言的成员那里收集需求，从全球业务中的专家那里了解本地需求。语言毕竟是小问题，一对一也更容易促进不同文化背景的团队成员相互理解，个人经验和经历更容易被分享。
利用矩阵定义职责和角色
利用矩阵表格文档化能够帮助避免因角色和职责不清晰引起的缺陷，如任务分配矩阵（Responsibility Assignment Matrix）、RACI 图。这些工具使用很少的文本，因而比那些普通的文本描述更容易理解。此外，我们需要进行必要的讨论以完成这些图表。项目经理通过推动这种必要的讨论来协助，确保各种工作角色和职责的细微差别能在早期消除而不是推迟到项目后期。
RACI图表示例：
任务/状态
R
A
C
I
项目计划
Martha
Mary
PMO
团队
需求列表
Martha
客户
需求顾问
团队客户成员
建模（流程、用例、数据）
Ying,Susan,David
Mary
数据库管理员（DBA）
团队
用户界面需求/原型
Martha,David
Mary
可用性测试员
团队
编程
Sunil,Shashi
Mary
All BAs
团队
用户初验测试
Martha
客户
Sunil,Shashi
。。。
。。。
需求建模
得出需求一个最好的方法是建立不同的模型呈现需求。例如流程模型、用例模型、原型，这些模型能提供一个框架构件，这个构件激发提问以发现潜在需求和更快归档一系列完整的需求。总之，模型又很多好处，尤其是在有文化差异的项目中。
1． 模型有一个优点是需要很少的文字，这样，语言问题就很容易解决了。同时还有一个优点，它能促进双向需求转化，大量构件少量文字的模型，从客户需求提取到模型再返回给客户。为了便于清晰和最大程度被理解，以及供客户使用，应该创建模型。
2． 模型是避免不同成员对需求不同的主观描绘最有效的方法。它最大程度的不受文化约束。模型在很多需求获取方式中都可以创建使用，包括：便利会议、一对一以及调查法。
3． 模型因其减少模糊需求能帮助我们跨越文化背景。也就是说，我们很少会曲解他们。使用了图片而不是文本，跟文化有关系的需求最大程度减少了，不管客户、业务分析员、团队是哪国人。
4． 最后，不管你是本地客户还是外地客户，模型都能用。技术使模型能很容易通过个人、电子邮件、视频、网罗会议被分享。因为任何人都能看到模型，需求也就很少有机会被误解。
总结
因为有一个大的以美国为主的联合制药客户，我们体验了获取不同文化需求的挑战。这里借此文用该例子的经历来总结一些要点。
1．一个有一个东京客户参加的流程演示会议比全部国内客户参加举行的时间多了两倍。分析员一直再问：“还有什么问题吗？”因为不想遗漏什么重点。（结论：一旦和文化不同客户工作，计划增加时间）
2．有相似的日本客户在项目开始时就坚持熟悉它的IT合作者。他们经常不断的要求对方去日本访问他们。组员们都亲自会面，每次见面后都庆祝。（结论：在某些地方建立关系比什么都重要，即使延误工作。项目也就延迟直到关系建立，信任也就更难建立。
3．美国、法国、英国客户花2个小时讨论一个工业条款，三组得出三个不同的意思。结果后来他们发现这个条款其实是一样的，接着不得不同意采用某一个。（结论：语言不同也是一种挑战，所以在项目中花点时间定义关键术语记录成术语表）
5． 在一个项目中项目经理去访问一个拉丁美洲客户。项目经理发电子邮件给客户说他找到了一个饭店，但是要去BYOB。客户很困惑的问他什么时候他们一起来：“谁是‘bee-yob’？”（结论：小心使用缩写）
总之，在含不同文化的项目中收集需求有着巨大挑战。为避免和减轻缺陷带来的影响，项目经理和业务分析员应该花时间建立关系，理清角色和职责，进行需求建模帮助获得需求。最终目标是以对客户来说最简单的方式发现需求，不管他是用什么语言，什么文化背景。
Elizabeth Larson,PMP……….
--------在多元文化项目中收集需求
项目无国界：在多元文化项目中收集需求 Elizabeth Larson ，PMP 和 Richard Larson, ………………著
获得客户需求是项目管理和业务分析所面临的一个最困难的任务。即使业务分析员和他们的客户同处一室工作，误解仍然还是会产生。不管参与方的背景如何，问正确的问题，让合适的人参与，归档明确的需求都是一个挑战。而如果项目包括多元文化参与者，尤其是包含一个边远地区看不到的团队就更难了。
项目管理和业务分析所面临的挑战不仅仅在多元文化项目中。而个人日程安排，优先级和角色的冲突，以及有效性都会使情况糟糕。此外，近期一些研究表明，几乎一半的典型项目的预算会因为需求缺陷而重新修订。虽然有许多潜在因素导致预算修订，但和多元文化业务客户或项目成员打交道是会产生严重障碍的。
挑战从不同文化背景的商业客户那里收集需求
与客户客观上的距离
虽然即使团队和客户共处一室办公也仍然存在许多挑战,客观上的距离则更会使困难增加。时区问题导致会议计划很难安排.负责这种全球项目的业务分析员体会到8小时工作制不存在了。因为如果我们为客户考虑或为建立良好的客户关系以获得需求，我们安排会议的时间是方便客户，而不是我们。
全球性的项目中很少会议是面对面举行的,这种非口头交流做出评估机会不可能。但事实上为了获取需求非口头的交流并没有减少，因为大多数的业务分析员竭力将它作为获取需求的过程中一部分.虽然最终有视频会议和网络会议可以替代面对面会议,但都不是很理想.视频会议通常缺少鼓动性、声音延迟导致与会人员精神涣散。因为视频会议上多方会谈，个人或群组主导，以及其他一些引出困难的因素大量存在，使用视频会议来推对一个大的团队交流是非常有挑战性的。借助视频会议和网络会议还经常出现设备问题而影响需求的获得。
职责和角色
任何时候职责不清晰和角色不明确都是项目管理和业务分析的毒药。一旦责任和角色不明确，任务总是失败并出现互相推诿指责。更不幸的是，一旦参与人员变化，就需要花更多的时间发现遗漏，更难纠正错误。一旦业务分析员要客户定义需求问题就出现了，客户认为他们已经提出方案了，剩下的事情是业务分析员的。如果站在不同的文化角度对待冲突，意识到这是不同的观念都需要很长时间，更不用说解决这些问题了。
语言
不同文化间的语言障碍是很多的。因不同语言甚至参与者不同的发音带来的困难都是众所周知的。此外，大多数人对于非本土语言的口头以及书写的理解表达能力水平不一。比如有的人能听但不能写。有的人听比说好、写比读好。为了获得需求，项目经理和业务分析员最好和那些在读和说比较好的客户一起工作。
最后，我们需要考虑缩写（取首字母的写法）、幽默、晚言（化妆室、去世、缩小），运动相关的（越位、左进、远射），这些容易引起迷惑和误解。
文化背景的不理解
另一个障碍是假定团队所有成员持同样的文化观点处理项目，不管他们是否一致。比如，我管理一个项目团队里有位男成员对被一位女士直接领导感到很不安。我对会议截止日期、沟通状态，团队协作的重要性谈得越多他越不合作沉默寡言。最后我发现真正的问题是我没有和他建立信任和良好的关系。他工作的文化伦理影响了关系的重要性。因此，他不因为任务属于工作架构中而因为这个关系才完成了任务。
工作的诀窍和技巧
作为从事很多全球项目或包含多方客户项目的公司，他们需要在承诺、包含物、垮国界认知上达成一致意见。此外，项目团队需要明白为了使项目成功完成，它们之间是互相依赖的。客户和项目经理或业务分析员之间需要协作以保证最终产品的成功。因此，相关的每一分子，项目经理、业务分析员、投资者、以及所有的客户都有责任承担文化多样性风险。没有项目经理，公司将花更多的时间和金钱在失败的项目上。没有业务分析员最终产品将不可用。没有强大的支助者和积极的配合的客户，就没法发现真正的需求，最终产品也就不会有了。
参与项目的每一分子都有责任使项目和最终产品成功，而项目经理和业务分析员可以为跨越文化鸿沟作些贡献。
建立信任和关系
建立信任和友谊在所有项目中都是重要的。当客户害怕最终结果危害和极大的改变他们的工作，或者当本地需求没有考虑时，他们有很多方式可以破坏一个项目。随着良好的关系的建立，问题更易于发现、更快能解决
不同方式的需求获取对团队促进团队建设产生或多或少不同的作用：
1．例如：使用调查方式对促进彼此了解作用甚微。
2．便利会议（在全球项目里面可能不得不是网络会议）能帮助建立团队，但可能要花几个星期甚至几个月才能使这个虚拟团队稳定。
3．一对一服务能建立关系和不同政治文化的了解。项目经理或业务分析员可以通过个别会议评估项目进展，讨论个别问题，从那些不喜欢在会议上发言的成员那里收集需求，从全球业务中的专家那里了解本地需求。语言毕竟是小问题，一对一也更容易促进不同文化背景的团队成员相互理解，个人经验和经历更容易被分享。
利用矩阵定义职责和角色
利用矩阵表格文档化能够帮助避免因角色和职责不清晰引起的缺陷，如任务分配矩阵（Responsibility Assignment Matrix）、RACI 图。这些工具使用很少的文本，因而比那些普通的文本描述更容易理解。此外，我们需要进行必要的讨论以完成这些图表。项目经理通过推动这种必要的讨论来协助，确保各种工作角色和职责的细微差别能在早期消除而不是推迟到项目后期。
RACI图表示例：
任务/状态
R
A
C
I
项目计划
Martha
Mary
PMO
团队
需求列表
Martha
客户
需求顾问
团队客户成员
建模（流程、用例、数据）
Ying,Susan,David
Mary
数据库管理员（DBA）
团队
用户界面需求/原型
Martha,David
Mary
可用性测试员
团队
编程
Sunil,Shashi
Mary
All BAs
团队
用户初验测试
Martha
客户
Sunil,Shashi
。。。
。。。
需求建模
得出需求一个最好的方法是建立不同的模型呈现需求。例如流程模型、用例模型、原型，这些模型能提供一个框架构件，这个构件激发提问以发现潜在需求和更快归档一系列完整的需求。总之，模型又很多好处，尤其是在有文化差异的项目中。
1． 模型有一个优点是需要很少的文字，这样，语言问题就很容易解决了。同时还有一个优点，它能促进双向需求转化，大量构件少量文字的模型，从客户需求提取到模型再返回给客户。为了便于清晰和最大程度被理解，以及供客户使用，应该创建模型。
2． 模型是避免不同成员对需求不同的主观描绘最有效的方法。它最大程度的不受文化约束。模型在很多需求获取方式中都可以创建使用，包括：便利会议、一对一以及调查法。
3． 模型因其减少模糊需求能帮助我们跨越文化背景。也就是说，我们很少会曲解他们。使用了图片而不是文本，跟文化有关系的需求最大程度减少了，不管客户、业务分析员、团队是哪国人。
4． 最后，不管你是本地客户还是外地客户，模型都能用。技术使模型能很容易通过个人、电子邮件、视频、网罗会议被分享。因为任何人都能看到模型，需求也就很少有机会被误解。
总结
因为有一个大的以美国为主的联合制药客户，我们体验了获取不同文化需求的挑战。这里借此文用该例子的经历来总结一些要点。
1．一个有一个东京客户参加的流程演示会议比全部国内客户参加举行的时间多了两倍。分析员一直再问：“还有什么问题吗？”因为不想遗漏什么重点。（结论：一旦和文化不同客户工作，计划增加时间）
2．有相似的日本客户在项目开始时就坚持熟悉它的IT合作者。他们经常不断的要求对方去日本访问他们。组员们都亲自会面，每次见面后都庆祝。（结论：在某些地方建立关系比什么都重要，即使延误工作。项目也就延迟直到关系建立，信任也就更难建立。
3．美国、法国、英国客户花2个小时讨论一个工业条款，三组得出三个不同的意思。结果后来他们发现这个条款其实是一样的，接着不得不同意采用某一个。（结论：语言不同也是一种挑战，所以在项目中花点时间定义关键术语记录成术语表）
5． 在一个项目中项目经理去访问一个拉丁美洲客户。项目经理发电子邮件给客户说他找到了一个饭店，但是要去BYOB。客户很困惑的问他什么时候他们一起来：“谁是‘bee-yob’？”（结论：小心使用缩写）
总之，在含不同文化的项目中收集需求有着巨大挑战。为避免和减轻缺陷带来的影响，项目经理和业务分析员应该花时间建立关系，理清角色和职责，进行需求建模帮助获得需求。最终目标是以对客户来说最简单的方式发现需求，不管他是用什么语言，什么文化背景。
Elizabeth Larson,PMP……….