点击蓝色“常柱”关注，一起成长
这是公众号2020年的第 040 篇原创内容
在技术团队工作过程中，经常会反复出现一些的经典的问题，这些问题会严重影响团队的工作效率，同时也会给团队的士气带来重大的影响。接下来，我们来讨论一下这些问题发生的具体场景，造成的问题原因，以及如何预防和解决这些问题方法技巧。
今天来讨论第 4 个常见问题：在软件开发过程中，一个问题的影响范围被过于夸大，给团队造成不利影响，这个时候你该怎么办呢？
问题被过度夸大
这与其他几点有一定的关系，“万事都着急”和责怪某个人。当有人开始放大一个错误或问题造成的影响时，可能会点名羞辱到团队中的人。当他们正试图尽快的解决当前的问题，当被别人放大和指责时，他们一定会感觉到不安全。小题大做，可能适得其反。
我经历过产品经理和项目经理在团队会议上挑出某个开发人员来讨论一些不太严重的问题，这些问题被描绘成完全阻碍进展的重大失败。
团队成员看到了这一切后，他们会感觉到不被尊重和不安全，因为事实不是这样，这些纯粹是夸大其词。这样就会造成团队内部的对立状态发生。
这也可能是由系统演示过程中遇到的 bug 引起的。如果演示偏离了主题而偏离了所演示的特性，这种情况尤其可能。对于不熟悉开发的人来说，常常会挂在其他小细节上，而这些细节反过来又会给负责人增加压力引爆情绪。
背后的原因
为什么这个过度夸大问题会是影响团队效能和士气的一个重要原因呢，主要是有以下几点：首先，在演示和反馈要保持在关键主题上。如果演示没有回到主题上，它将大大降低反馈会议的有效性，保持焦点是至关重要的。
不让演示反馈集中注意力会减少对实际感兴趣的领域的反馈和响应，反而会收集一些可能已经知道的不相关的反馈(比如指出当我按下按钮时 B 部分没有出现等)。
第二，在开发期间，在主要功能被实现之后，对琐碎的调整的夸大会让开发人员完全失去积极性。它忽略了成就的重要性，并把它变成了消极的。
第三，这些类型的过度反应鼓励绕过适当的问题分类和反馈。提出这个问题的人试图引起的反应是，这是紧急的，最重要的是，在正常的工作流之外。这就反馈到了 "一切都很紧急 "中的许多相同点，包括难以跟踪成本和问题。
第四，在开发过程中，把细节问题过度夸大是无意义的。如果产品距离发布还有几个月的时间，就没有什么事情是这么紧急的。例外的情况是当一个演示正在准备中，在这种情况下，应该安排一些时间来进行特别的打磨工作。
第五，这类夸大对问题的关注，会让团队变成 "我们与他们 "的防卫态度。他们会开始以一种减少这种情况发生的机会的方式来操作。他们可能会减少沟通，降低对提出这些问题的人的关注度，或者停止做任何高于和超出分配的工作，这样他们就不得不减少处理这种情况。这些都不是理想的结果。
解决之法
对于问题的反馈和影响范围的评估，我们需要有一个合理体系做管控。一边要避免将团队的精力浪费在非核心问题上，也同时要避免夸大的问题给团队造成不安全感的产生，影响了团队的效能和士气。你可采取以下一些策略：
第一，在项目演示/反馈会议期间明确你或你的团队中的某个人是会议的主角。这样明确职责，快速确认要演示的的功能范围，并围绕确定的范围领域进行有效的对话。
第二，在项目演示期间，要和需求方声明当前为 demo 版本，一定会存在一些问题。用合理方式明确强调系统仍在开发中，并优雅地将会议再次引导到正确的主题上，避免被小问题误导。当然，小问题也及时记录在案，以便后续的跟进和解决。
第三，在正常的开发过程中，当问题被过分夸大的时候，一定要识别出来，并引起注意。从长远来看，这是无益的，也是有害的。每个人都需要保持对项目和问题的看法。
第四，不去猜测提出这样问题的人的动机。我们姑且认为他们是由于外界的压力，或者是对开发流程不熟悉。
总之，不管是哪种情况，都要认识到，把琐碎的事情当做紧急的事情提出来，尤其是用不尊重的方式提出来，是不可接受的。在团队内要呼吁减少这种行为，或者以其他方式遏制这种行为的发生。
最后的话
无论什么情况，在工作中提交和反馈问题一定要实事求是，不要过分的夸大问题，更不要用不尊重人的方式去反馈问题。
因为，过分的夸大问题的影响和严重性，只会造成团队之间的不安全和不信任，增加团队成员之间的对立性。
小题大做，往往适得其反，因为高效的团队需要安全的环境和彼此的尊重与信任。