如何设计优秀的伙伴关系合约?-InfoQ



 写点什么

咨询知识工作者入门

你是一个咨询师么？可能是的，即使你从来没有这么想过。就算所从事的工作完全是在雇主的公司之内，你也有可能是一名咨询师。如果真是一名咨询师的话，那你可能要考虑与客户签订咨询合约，即使合约之中不包含任何涉及金钱交易的条款，不进行正式的签署活动，也不包含任何附加法律条款。

奇怪吗？那好，让我们先看看在彼此熟知的系统开发场景中，典型 IT 知识工作者的角色，然后再观察当工作开始后，都发生了哪些活动。在这其中，我们会核查与（内部或外部的）客户制定合同时要考虑的要素，以及建立一种设计好的关系的重要性。我们的目的是要为客户创建卓越的绩效，同时要以一种符合我们的价值观与喜好的方式工作——举例说：希望能够平衡工作与生活，同时具备高度协作的工作环境，或者要得到技术的卓越性以及收益。

故事

我们的知识工作者 Hans 在一个软件开发团队中工作。该团队要为 Applied Genetics 的 Research 业务部门构建一套计算机系统。不管 Hans 是不是 Applied Genetics 的雇员（并非我们的关注点，所以不予澄清），他不在 Research 业务部门中工作。从这个业务部门中某些人的观点来看，Hans 会带入“外部”的专业知识，而且这些知识不在 Research 的日常规定范围之内，也不属 Research 的工作范畴，不受制于 Research 的管理范畴，因此对他们来说，Hans 是一个“咨询师”。

当团队开始为 Research 工作后，Hans 希望创立一个清晰的协议——一种“设计好的关系”——明确表明各参与方对该工作的期待产出，每个团体的付出（他们共享的责任），彼此之间如何互动，以及共享的工作文化如何运作。Hans 将与团队成员和客户一起建立“设计好的伙伴关系合约（Designed Partnership Contract）”。

什么是“设计好的伙伴关系合约”？

要理解这个新的词汇，不妨把它打散了来看。首先，我们看看“设计好的伙伴联盟（Designed Partnership Alliance，简称 DPA）”的概念。DPA 来自关系系统辅导（relationship systems coaching）（注1）这个新领域。具备一个“设计好的伙伴联盟”，是在两个或更多伙伴之间、或是团队之间创建真正良好关系的第一步。所谓真正良好的关系，正确关系中心（Center for Right Relationship）（注2）是这样解释的：“自觉的、有意识的关系”。开始时，伙伴或团队之间讨论他们想要什么样的关系——关系的“气候”状况。比如，一个团队希望彼此之间可以坦诚沟通，提供真诚并且是建设性的反馈，并且要有智力上的挑战性。另一个团队可能希望非常努力地工作，但也要有娱乐的时间，并且在成功后要有庆祝活动。当发生了不可避免的冲突之后，团队希望彼此能将对方作为值得尊敬的人放在首位。这样可以帮助他们迅速找到冲突的解决方案，而不会互相责备或是导致对个人的攻击和批评。DPA 会记载团队成员对于彼此关系的价值观和喜好，无论是团队之间的或是个人的。有些软件开发团队在开始一个项目时，会以团队规范列表的形式完成该工作。

第二个概念——“咨询合约”——来自Peter Block 的书籍《完美的咨询》（Flawless Consulting）（注3）。咨询合约首先而且也应该是一种社会化的契约，提供“咨询师与客户对彼此的期望值，以及如何共同工作的清晰协议”。

Block 将签订合约视为一次咨询活动的重要阶段之一，此时咨询师们有最大的影响力（如果试图在实际工作开始之后再就这些因素进行谈判，经常很艰难而且起不到什么效果）。在所有团体之间达成清晰共识，就有可能构建一种最成功的工作关系。在与组织内部一起工作时，签订的这种类型的合约很少可以完成；而与组织外部人员一起工作时，这种合约经常不能完成——或者说不能完成的不彻底。在后者的情况中，合约一般就是一个法律文档，关注的就是金钱和交付的东西，并且由合约专家来处理，而不是在咨询师和客户之间面对面讨论决定。

通过集成“设计好的伙伴联盟”（注 4），可以通过签订合约的过程创建一种协作的、高度积极的工作“气氛”。这样签订完成的“设计好的伙伴关系合约”可提供很多好处：它为工作关系巩固了一个高度积极、正向的环境，预想到了（甚至可以避免）在与别人一起工作时可能产生的典型问题，明确定义了订立合约牵涉的人、目的、时间、地点以及原因。接下来不妨看一下 Hans 的团队如何与客户订立“设计好的伙伴关系合约”。

设计合约

Research 的副总裁 Maryellen 与 Hans 的老板达成协议，后续工作应从 Research Tracking System（RTS）起步并尽快开始。之前 Hans 被告知要给 Maryellen 打电话并召开一个会议。于是他让两个团队成员——一名开发人员和一名测试人员——与他一起参与会议。

会议一开始，Maryellen 就强调 RTS 对 Applied Genetics 市场竞争地位的重要性，由于执行层不知道目前有哪些产品在研发之中，使得 Applied Genetics 在市场上受到了一些挫折。Hans 因为能够有机会帮助 Research 集团，向 Maryellen 表示了诚挚的谢意，这也设定了一种正确的基调。

“在深入讨论之前，我们希望花几分钟来更好的了解你们，并讨论一些我们一起工作应遵守的协议。你看这样可以吗？”在开始后续工作之前，Hans 就开始设计伙伴联盟关系了，这也开始构筑团队钟爱的、基于协作的工作模型。

二十分钟之后，参与会议的人们已经就共享彼此关心的问题、共同维护协作的精神以及保证维持工作与生活的平衡这几点，达成了一致意见。团队成员们知道，这些“好话”在项目真正开始之前，这种相对轻松无甚压力的情况下，是很容易形成共同意见的。于是他们打算用某些难于应对的例子来检验下这些共识。他们问道：如果项目延期，并且 Maryellen 面临业务上的压力时，会发生哪些状况？那时的工作与生活之间的平衡还能保证吗？这引起了一些关于相对优先级和“怎么做才是对一个家庭真正有长远好处？”的激烈争论（“度假”与“成熟的股票期权”的对决！）。另外一个例子，当发布日期临近之时，代码质量和上市时间二者的冲突会如何处理？如果 Research 业务部门需要跟 Applied Genetics 的架构标准有冲突，又当如何处理？

这些讨论让参加讨论的人们新增一条附加协议：出现冲突时，他们仍会彼此尊重，并以职业人士互相对待。该原则是在讨论中实际涌现出来的。（Hans 可以在一开始就提出这个建议，不过他从过去的经验中认识到：直接提出一个现成的建议列表，通常无法让团队意识到这些建议的重要性，而且也无法让客户发现对他们真正重要的东西是什么。）当讨论开始演变成争论时，急躁焦虑的情绪会在会议的参与者中产生；而此时来自开发人员积极正向的言词，会唤起与会者事先培养起来的理解与尊敬之情，从而让气氛缓和下来。此时 Hans 感觉良好，他相信团队与客户正在打造一种真正的伙伴关系。现在可以进入到制定“合约”的工作中了。

合约元素

与法律合约类似，咨询合约也有两个主要的条目：共有协议（mutual consent）与约因（consideration）。协议意味着参与双方（基于情况不同，可能是三方或四方）必须是自由加入该协定。作为知识工作者——咨询师，也许会遇到感觉被组织的期望所强迫的状况（如果是外部咨询的话，可能被经济状况所压迫），强迫接受项目的某些条件，以及遵循某些客户提出的具体条款。正像 Block 讽刺的那样，以“折腰”的姿态来协商合约，客户在此阶段也会知道咨询师确实是处在一个“弯腰”的位置上，从而对咨询师“要挟”。以此姿态进行“谈判”，便让合约和咨询活动从一开始就被“污染”了！

在另一种极端情况下，我们都曾经见识过人们用充满敌意的态度来保卫他们开发软件的方式——甚至不愿意接受客户提出的可以理解的、并且是相当理智的需求——并基于一种准宗教式的态度来捍卫他们所采取的方法论。有技巧地表达不同意见而不体现出不友好的态度，对咨询师这样的知识工作者来说，是一种非常值得学习的技能。通常在大多数情况下，这样可以通过安静但是明确的方式表达对同事或客户的反对意见，而且不影响他们与咨询师之间的互相尊敬。我们可以在下面看到是如何做到的。

合约的另一个元素是“约因”（译者注：合约是订约方自愿建立的法律关系，是一方以有价值的代价或者承诺以换取对方的承诺或代价，这些合约中的承诺或代价称为约因，缺乏有效的约因，合约便不能成立。）：双方（或所有的三方 / 四方）从对方处都需要获得某种价值。对于客户来说，很明显他们需要获得咨询师提供的服务，但也可能包括其他东西。对于咨询师，肯定要获得金钱，除此之外，还包括 Block 所说的“他人的需求”。举例来说，作为一名咨询师，出于职业道德的考虑，你认为最重要的是要如实通报目前的进度状况，而不能根据组织的期望，或是根据客户主观愿望来夸大成功的机率，也不能为了向高层管理者展示你的工作成果，或是让他们觉得你的工作有价值，而虚报目前的状况。接下来我们来看看如何实践这些原则。

回到现实

让我们回到 Research 的会议室中，大家在讨论项目的整体范围，以及 Maryellen 的团队中有哪些人会参与到项目中。测试员 Joseph 询问谁将作为团队的客户主要联络人。Maryellen 告诉他们 Research 的分析师 Charlie 将会填补这个角色，“但是不要占用他太多时间。目前他参与了一个关键项目，而且项目的截止日期已经定死了。”

讨论因 Maryellen 的话暂停下来，而且空气中充满了紧张的气氛。Hans 知道：在讨论进一步深入之前，该是他动手干预的时候了。“Maryellen，我们已经同意在出现问题时要共同解决，对吗？坦白的讲，我没预料到这么快就会出现问题，不过我还是要针对 Charlie 的参与度提出意见。我刚听到你说 Charlie 目前在参与一个至关重要的项目，而且不能被打扰。这我可以理解，而且我也不想打乱他的优先级。

“同时，我们的团队希望客户主要联络人能够花费至少一半的工作时间在与项目开发相关的工作上，而且团队任何时候有问题，都可以通过虚拟的方式联系到他；否则我们就很难出色完成工作。要是这些联络人每天都可以花费一些时间与团队坐在一起，那就最好不过了。我在想是不是能够有别的什么人符合这个条件，或者 Charlie 的优先级在团队工作开始之前可以做出调整？”

Hans 利用了在设计好的联盟条款中关于坦诚沟通的协议。这些协议刚刚达成，他就马上按照它们行事了，而不是抄“近道”并置问题于不管不顾。在前述过程中，客户提出的建议违背了 Hans 团队的期望，以及他们彼此达成的关于仅与可以全身心投入的客户代表一起工作之共识，这时 Hans 要控制自己的焦虑情绪。他先表示出来已经听到了 Maryellen 的优先级。这样就传递出来一种信息，证明他在认真聆听并且尊重 Maryellen 的意见。Hans 不会传递类似于最后通牒或是暗含杀机的信息（比如不做进一步的澄清工作，就表示“我不知道这样做能不能行得通”）。实际上，他强调了他自己（以及团队）所处的位置，并本着协作的精神寻找可能的不同解决方案。他用一种不招人讨厌的方式表达了不同的意见。

“我的天哪，没想到我们的人将会在这个项目上花费这么多时间，”Maryellen 带有恼怒地叹了口气。Hans 再次控制住了自己条件反射般产生的失落情绪，而是说：“我理解你的担心。我们怎么样可以用对彼此双方都有利的方式来解决这个问题呢？要不你可以再好好想想，然后跟你的人聊一聊。当你找到合适的人之后，我们再和你以及那个人面谈，然后重新达成一致意见。”

一开始，Hans 以很委婉的方式将困难摆在了大家的面前，他既没有屈服，也不是以强硬的方式来推进。接下来他为 Maryellen 提供了一个退路——让她根据自己的期望重新考虑如何应对。最后，他将另一方——客户主要联络人——加入到了合约当中。这是三向咨询合约的开始。Hans 明白 Block 所说的，“无法与不在现场的人签订合约。”这一点在稍大型的组织中很容易被忽视，因为经理们很容易假定他们可以为下级决定工作的具体细节，并对其进行承诺。而现实往往并非如此，这样产生的协议也往往难以收到成效。

Maryellen 同意回去跟 Charlie 和其他人讨论一下目前的状况，并将会在接下来的一周同 Hans 再次会面。这时，开发人员 Sara 对项目的范围提出了新的问题，主要是关于是否应该包括用户文档。团队还问到 Research 中是否有人需要接受某些系统或者一些流程工程规则方面的指导（角色方面的问题），以及团队多久可以与作为 RTS 出资人代表的 Maryellen 见一次面，以获得反馈。

“在我们结束之前，我有最后一个要求。假定我们彼此都相信这个项目一定能够取得想象中的成功，你到时会愿意为我们的工作写封推荐信吗？”这是 Hans 作为咨询师的最后一个“请求”。Maryellen 微笑着回答道：“假定我愿意？我肯定会的啦。”

会后，Hans 在一封简明扼要的 Email 中罗列出讨论的议题、达成的协议以及团队对项目范围、可交付物、角色、成功条件的理解。通过减少协议所占的篇幅，Hans 必须保证无论是他自己还是客户，都能对邮件中的协议有非常清晰的理解。在邮件的结尾，他邀请 Maryellen 纠正他或者团队存在的任何误解。本案例中，Hans 不必要求客户对“合约”进行签字，虽然他希望能够得到所发邮件的回复，如果几天内没有收到回复的话，他会再次跟进。通过将协议以书面形式表述，并邀请评论回复，一种强有力的联系就被建立起来了。Hans 成功地与 Maryellen 完成了“合约”阶段，他知道什么时候客户联系人将于何时被正式提名，届时要让此人跟上其他人的步伐和项目的行进速度，而且 Hans 到时候会根据实际情况看是否需要达成任何新的附加协议。

步骤总结

对能被邀请来解决问题明确地表示感谢。
共同设计团队 / 伙伴关系联盟——工作气氛、冲突解决方式等方面。
保证所有的参与方都做出承诺。
澄清客户想要得到什么以及愿意付出什么，有必要的话就进行谈判。
澄清咨询师想要得到什么以及愿意付出什么，有必要的话就进行谈判。
如果陷入胶着状态，就暂时停止，过些时间有了进一步的研究和 / 或新的协议或条款达成后，再重新召集参与人员。
总结达成的协议，并发送给所有的参与方。

结语

无论是在组织内部为雇主工作，或是在外部为客户工作，很多知识工作者都扮演着咨询师的角色。就其而言，与客户达成“设计好的伙伴关系合约”可以形成极佳的关系并得到上好的结果。

下面给出一些关键的建议：

签订合约阶段是用来针对工作应如何开展进行谈判的最佳阶段。
共同设计伙伴关系应如何开展，有利于将良好的关系上升到优秀的层次。
要小心多方参与的合约。不可能与某个不在场的参与方订立任何约定。
作为知识工作者的咨询师，有权利提出要求，正像客户有此权利一样。
要学习如何以尊重其他人的方式来表述不同意见：进退之间，要学会在刀锋上行走的艺术；要像对你自己一样，尊重每个人所处的位置及其合法性（至少对他们来讲）。

注解

“设计好的伙伴联盟”来自于“良好关系构建研究中心（The Center for Right Relationship）”所研究的关系系统指导（relationship systems coaching）新领域。（ http://www.centerfrorightrelationship.com/services-training.html ）
“良好关系构建研究中心（The Center for Right Relationship）”网站： http://www.centerfrorightrelationship.com/services-training.html 。
本文的完成要感谢 Peter Block 的工作及其书籍《 Flawless Consulting: A Guide to Getting Your Expertise Used 》，Pfeiffer 出版社，1999。
“设计好的伙伴联盟”概念来自“良好关系构建研究中心”组织与“关系系统指导”计划，本文将二者的理念合二为一，定义为“设计好的伙伴关系合约”。

关于作者

Michael Spayd 是一名教练和建议提供者，为伙伴关系、团队和组织工作，以帮助他们在一个高度正向/ 高度自我价值实现的环境中取得最大的工作成果。他经常协助大型企业的组织变更过程，帮助领导和变更代理理解变更的过程以及他们在这个过程中的角色。Michael 经过培训，成为一名关系系统教练，而且是Co-Active 公司的个人教练，并且目前是职业认证推进者（Certified Professional Facilitator）和CSM（Certified Scrum Master）。他目前是Collective Edge Consulting, llc（ www.collective-edge.com ）公司的董事长和首席“哲人”，他的 Email： michael@Collective-Edge.com 。