目录
一、多说“是”,少说“不是”
测试架构师经常会被咨询问道某个项目的可行性,并提供从战略到战术的多个替代方案,附带若干成本选项,促使上午伙伴能够根据特定项目的投资进行判断。
我们试图说出的答案是对,我们能构建这个项目,这些是相关的信息,产生的信息需要包括诸如所考虑的各种替代方案,下古墓风险,基于假设条件以及需要指出的突出问题。
学会说“是”可以采用多种替代形式。通常,它涉及为某人或某个项目找到继续前行的办法。没有必要你自己来承担任务或需求。也许你可以提供一套合理的替代方案,或者引导提出需求的人找到其他人,后者能够解决项目当前面临的问题。
对于需要可行性信息的多数项目而言,最值得期望的方法就是提供一个自助餐式的选项,详细罗列出成本、风险、战略影响以及有效的组合等信息。这种策略让需求者处于决定者的地位,使他可以选取最能产生商业价值的解决方案。
二、特殊场合才说“不”
从测试架构师的前景来看,只有在若干种情况下你可以简单地说“不”。大多数时候,你必须提供能让事情完成的替代方案(涉及费用、风险和每种方法的好处)。最后的决定取决于项目的主人(即掌握购买权的人)。
在其他时候,说“不”是合适的。通常这种拒绝需要有足够合理的深度来支撑,以应付所有必要的质疑。争论的领域很可能与任何项目都存在的关键限制因素有关,如效果、成本、时间和范围。
对于项目的最后期限,当要求违反“物理法则”,即无法执行项目给定最后期限内的所有步骤(例如:硬件的获取和供应、规划、开发、要求的培训、测试、修正错误和部署)时,说“不”是可接受的。但不能因为工作看起来困难、你不大喜欢它或者有其他不能同时进行的优先级(也许当前需求会很快成为最高优先级--值得将此列为一个风险)。中性地陈述各竞争优先级的任务,从而让执行官能根据各自的相对重要性安排它们。
如果你不说“不”,你可能注定是在“死亡行军”-项目已经有了高度可见性,无休止的加班,客户永远不怎么满意。要求有适当的期望值来避免这种结果,特定的环境有时会影响说“是”或“不”的决定。例如,在停业期或外包期间,可能需要更微妙的方法。每个人在此气氛下都很紧张急躁,项目协商变得很具挑战性。
三、倾听建议来改善合作
从软件开发的角度看,批评别人和被批评的情况经常发生。因为有软件评审、设计评审、架构方法评审、单元测试、功能测试、缺陷跟踪,或者只是简单地向别人寻求帮助,与上司一对一地谈话,这个列表不断在进行。在所有情况下,总有机会将别人说的话特定到你身上。
一旦你把谈话话题转移到自己身上,而不是工作成果或某些事件上,你本能的自卫意识就来了。这时,你听进去任何事情的能力就变得有限,“要么拼命,要么逃跑”的本能反应开始占据上风,而你的大脑指挥身体开始变得激动,以准备自我保护。所沟通的用于改善工作成果的有价值信息烟消云散。从商业角度看,将一项工作产品做得尽可能优秀以符合每个人的最大利益,因为我们越能为产品增加价值,公司越有机会从投资中得到回报。
如果你能避免在谈话中个人化,你听取别人说话的能力就大大提升了。要试着找出他说话的真正用意(即便你不同意他说的话)。以适当的方式取得他想传递的本意,复述一遍要点。一般情况下,别人只是想被理解,他并不是在寻求你同意他的观点。当你倾听并能理解对方表达的要点时,你就能和他心灵相通。
四、了解别人和自己的沟通需求
在测试架构师的世界中,你需要例行地与许多人交流。你可能在上一次会议上与有些人谈过话,也可能没有和这些人谈话。挑战就是快速了解人们在说什么,他们怎么说这些话,来“读懂”本次会议。
观察关键的时刻,即做出决定的时刻是一个要点,以此识别人们提出的问题和关心的地方,来加强核心概念,帮助你关注会议的方向以及把会议引向一个成功的结论。为了认识这些关键时刻,我们需要吸收所有信息,包括提供给我们的语言或非语言信息。
观察别人的举止能够告诉我们如何与每个人最好地沟通。由于每个人都不相同并且对沟通也有不同的需求,架构师必须让传递信息的方式适应这些需求,以确保有效沟通。
关键点就是我们要基于每个听众成员的沟通需求来匹配交流风格。有些人的反应是能够看出来的,他们的偏好能够用诸如“我明白你的意思”之类的话辨别。另外有些人需要倾听,并吸纳语言细节,他们的偏好能够用诸如“我在听你说”之类的话辨别。还有一些人在交谈中比较情绪化,他们的偏好能够用诸如“我觉得怎样怎样”之类的话辨别。
五、选择合适的沟通方式
面对面会,对于重要的讨论和决策,组织面对面会议,以便即时解决疑问,减少误解。
电子邮件和即时通讯工具:对于日常沟通和协作,利用电子邮件和即时通讯工具进行方便快捷的交流。
项目管理工具,使用项目管理工具(如Jira、Trello等)来跟踪和管理任务、问题和进度,确保团队成员之间的信息同步。
六、注重沟通效果与效率
清晰明确的语言,在沟通中尽量使用清晰明确的语言,避免产生歧义和误解。对于专业术语,应提供必要的解释和说明。
及时有效的回复,及时回复和处理来自他人的信息和问题,确保沟通的高效性。
建立反馈机制,鼓励团队成员提供对测试工作的反馈和建议,以便及时发现问题并改进。