在软件的整个开发过程中,编码是一个重要的环节,
它实际产出了软件所需要的各项功能,
因此,也最容易受到关注。
可是,究竟是什么决定了我们应当这样编码呢?
我认为,这其中还有一个必不可少的协商过程。
为了决定一件事情的做法,
首先我们自己,会对所有可行的办法进行考量,
得到一个符合自身判断的结论来。
这还不行。
除此之外,通常还要跟其他参与者进行协商,
给出一个符合大家看法的最终结论。
所以,是这个最终结论,决定了事情的发展走向,
协商过程对结果很重要。
那么,怎样让协商出来的结果更加可靠呢?
大家达成一致的前提是什么呢?
这还要进行仔细的分析。
持续性
我们知道,方案的目的是解决问题,
但是,我们怎么知道别的方案不能解决问题呢?
实际上这是协商的一个误区。
因为解决问题的过程并不是一蹴而就的,
而是一个难题接着一个难题,
谁也不知道以后会发生什么。
所以说,解决问题是一个过程,而不是一个状态。
一个问题解决后,马上会涌现出另一个新问题。
对未来可能发生的情况进行争论,是不合理的。
有人认为这样做是对的,也有人认为那样做是对的,
结果很可能是,怎么做都是可以的,
区别是,哪种做法可以让人们更有动力持续的解决问题。
伪装
当存有不同见解的时候,人们就容易产生分歧,
虽然看起来,大家都在讨论客观上存在的问题,
其实并非如此。
客观上出现的问题,只是一个借口,
它掩饰了争论者的真实意愿。
这是人性的一个弱点。
父母对孩子说,“我是为了你好”,真是这样吗?
是,也可能不是。
“这样做对项目有利”,真是这样吗?
是,也可能不是。
我们应当对真实意愿和表面上说辞的不同有所警觉。
避害
一群聪明的人聚在一起,也不见得会得出正确的结论来。
毕竟,我们也没办法证明决定的正确性。
因而,共赢比正确更受欢迎。
最终结论常常是利益之间权衡的结果。
所以,在进行协商的过程中,给出证明并不是特别重要,
那只会让我们听到更多反对的声音。
相反的,应该考虑,我们的主张会对别人会产生哪些不良影响。
人们不是反对我们的方案,
而是反对我们损害他们利益的行为。
回到我们自身。
我们提议的实践方案,真的会对项目有利吗?
还是为了避免自己以后会遇到麻烦?
我们觉得这样的设计,实现起来太困难了,
这种说法,真的是为了筛选优秀的设计吗?
还是仅仅自己想省事一些。
没有人想遇到麻烦,也没有人想费事。
这就是能达成共识的主要依据。
结语
各式各样的协商,推进了软件开发过程的进展。
为了能更快达成共识,我们可以分三步走。
第一,值得协商的所有方案,并没有太大差别,
关键是达成共识,以后一起面对新问题。
第二,看清楚哪些说法是真实意愿,哪些是借口,
不要在借口层面与他人争论不休。
第三,应对反驳的最佳方式是,识别他人的诉求,
以消除方案对他人带来的不良影响。
人气顺了,事情才能办成。
我从不推行方案,是你需要它。