一个程序编制中类似于表格格式设计的小小路线分歧，经过慢慢地发酵演译，居然发展到使得整个程序的编程工作的停止，并且使得原本关系不错的双方最后都感到挺不愉快，这种连环多输结局的蝴蝶效应，我在开始是完全想不到的。回想起当时那个小小风波，我的记忆中看不到电脑，看不到技术，甚至看不到工作内容，看到的只是满满的人性。
结果发展到那样，是我所不愿意的，但是按当年的我对于人情世故的理解层次，发展到这样的结局虽然无奈却是必然的。这些年，有时我会试想一下，如果时光能倒流，我带着我现在的人生经验回去那个节点，我应该怎么破解这个难题呢。
我给自己的回答就是，如果遇到那种情况，先不要急着处理，我们需要及时判断这种分歧是哪一种类型，第一种，单纯技术性的分岐，第二种，已经转化为其它非技术层面上的分歧。
先看第一种类型。
第一种类型的麻烦，虽然其实也比较棘手，但是如果实际工作真得非常需要，还是有解决的可能性。当事人需要以高度的工作责任心，用曲线救国的方式，比较技巧性地解决。首先要做的就是换位思考，充分考虑实际情况是什么，工作需要什么，自己需要什么，还有就是从领导或管理方的利益角度出发看他们需要什么，找出有没有能让三种需要可以共容的空间，哪怕是仅仅一个小小的角落。
我想强调一下，从别人的角度出发思考，去设想别人究竟需要什么，这种方式不仅需要对工作的各个方面，牵涉到工作的各个人都具有相当准确的了解，更需要的是一种“冷酷的诚实精神”。
什么是“冷酷的诚实精神”，那就是：对现实诚实，对自己冷酷。
我们要真正地从别人的利益角度出发，而不是我们认为他们需要什么，或者我们希望他们最好能怎么样，哪怕思考出的结果对我们自己再不利，也不能回避。我其实见过太多反方向的例子，一些人先找一个对自己最有利的结果，然后再去找他人应该能接受的理由，最后在碰到钉子后，再四处抱怨社会不公。
在分析出各方面情况后，在考虑好尽可能全面的细节后，接着要主动设计一个解决方案，这种方案是可以满足工作需要的，也是能应付相关人员提出的哪怕是很奇怪的要求。这个设计过程中，对设计方有一个基本要求，那就是“沉默”，不可以向外人商量，更不能找领导指示，因为本身就是走曲线救国路线，把底牌透露出去后，就改变了原先的各方面细节，那只能推倒重来了。
在做好计划后，就可以去施行，最重要的内容，也是最麻烦的事情就是得到领导的同意，对于这些必须得到需要领导同意的，要想好对方会关注什么会问什么，尽是想全面一些，这样在汇报时碰到领导提疑问或建议时，能够及时解释清楚，并先指引到一个有利于最后解决问题的方向，这时速度要快，争取当场能拍板定方案，不要给他们在关键的技术点上太多随意发挥的机会，因为没有经过深度思考的建议是价值不高的，但是从领导嘴里说出来不执行就会转成面子问题，异常麻烦。所以需要做的就是始终主导方向。
方案制订后，在基本原则方面是不能让步的，当然啦，在一些无关全局的地方可以手松一些，对一些非关键点的指示，可以作一些让步，哪怕过程会比较麻烦，但是为了全局要求，该低头时也得低头。
关于第一种分歧，有一个比较典型的例子就是“样品编号的定义”。
我们做过实验的人都会接触到检测样品，用编号去登记管理样品是一个最基本的实验室文书工作，无论是手工帐本登记还是电脑软件登记，总是一个样品对应一个编号，或者也可以说一个编号对应一个样品，这是我们现在习以为常的常识。但是当年为了这个常识居然也需要走曲线救国的道路。
本部门在有实验室软件前，登记样品当然也是手工帐本，在编程序时，需要确定样品编号，这时A领导提了个要求，每年的样品编号都是从1 号开始一下，也就是说，1,2，3。。。而且每年都一样。当时就有点傻了，每年的编号都重复，就象一个学校的新生，每年都编成完全一样的学号，点名时叫任何一个号码，都有四个人站出来，那最后谁知道谁是谁啊。
觉得这应该是件很明确的事情，也跟A领导这样表述了一下，没想到他的脑袋摇的和拨浪鼓一样，坚决不同意每年的号码不一致，说虽然号码重复的，但是样品是不一样的，写在本子上也是不一样的，一定要从1 号开始，哪怕重复。如果做不到只有一种可能，“电脑没有用!”。
定下样品编号是实验室程序的张一步，这个定不下来，就啥也做不了。纠结了好几天，居然让我想出一个解决方式。A领导不是强调每年的样品登记要重复号码么，那就在电脑上登记从1 开始的编号，但是在数据为内部结构加一个“年份”的字段，这样程序在运行时，起作用的是“样品编号”加“年份”两个相加的字段，而在登记样品信息，以及最后打印出样品登记本时，“年份”这个字段是不显示的，和它不存在一样。这样对于领导来说，他的要求做到了，也就满意了，而对于我来说，虽然多了不少麻烦，但起码不用去挑战最基本的数据要一一对应的逻辑了。曲线救国的道路虽然不好找也不好走，但起码还是有救成的可能性的，想做点事情从来都不容易。
关于第二种类型的分歧，其实从严格的意义来说，这一种分歧与技术完全无关，仅仅是由人性所致，由第一种分歧得一到及时解决而恶性转化所致。
曲线救国也许能解决一些问题，但是却不能解决所有的问题。多年后回过头来看，我这种编程的行为在第一天开始就存在了一个潜在的隐患，那就是我作为程序编制者的身份，与同时又是实验室的基层实验员之间是存在一定矛盾的。这种隐患在平时我没有意识到，但是意识到时已经来不及了。
我们分析一个案例，在某一个部门向某一个软件公司采购程序的过程中，这个行为中有两个主体，也就是作为“需求方”的某部门，和作为“供应方”的某软件公司，这二者虽然是各有所求，但是在商业地位是平等的，没有一个绝对的强势方，在出现不同意见的时候，需要比方协商达成共识，就算没有共识，也需要有一方能接受结果。在这个模式下，就算走到一个很极端的情况，如双方无法完成合作，变时也能选择和平或不和平的分手。这就是一般商业行为中的常规模式。
再看我的情况，我作为当时部门唯一的软件供应方，却同时又是需求方(本部门)的基层员工。编程序的工作没有任何报酬，所有的个人收入是要以自己作为一个基层实验员而得到的，这一点就决定了我在需求方面前的话语权极低，部门领导愿意接受我的方案时双方相安无事，而如果以任何理由不愿意时，我则完全没有平等对话的可能。从另一个角度来看，领导如果对编程工作中的任何不满，都可以顺手转移到实验工作上的我这一身份上来。
很多事情的走向，在它的一开始就已经决定了。由于这种需求方和供应方的特殊关系，使得需求方，也就是本部门的领导具有了相对更强大的支配权，虽然不能说，想怎么就怎么样，但是却可以想不怎么样，就不怎么样了。不是所有问题都是可以通过曲线救国解决的，这些分歧处理不好就可能恶化，转成面子之争或意气之争，这时就是再多的代码也无能为力的了。
我现在能意识到，这种非技术范畴层面上的分歧，其实是无解的，特别在建立在供需双方地位完全不平等的情况下，在我这样一个层面，更是不可能完成的任务。
“不是所有难题都能解决的”，这个道理无法从书本上得知，只能通过在现实中经过几次撞墙后，才黯然领悟。可惜的是，以前不懂，但是当自己明白的时候，已经撞得一头包了。
当年碰到这种情况，真是彻底发了蒙，完全不知道怎么办。在多年后再回头再看，虽然还是不能解决这类问题，但是起码知道如何应对，将其尽量无害化。
当遇到问题时，可以看能不能解决，其次还可以看能不能应对。应对的方法也就只有一个字，“避”。
“避”，即回避，分主动回避与消极回避两种。
主动回避，就是在预计到有可能发生不可协调协调的分歧时，避免这种分歧发生或发展的可能。以我自己遭遇的事情主例吧，想一下我其实有很多机会回避的，如果当时能预见A领导和B领导会意见不同且难以调和，就不应该分别找两个人去要指示，我可以先想一个大致可行的方案，再估计会更对哪个领导的品味，然后找他认可一下，同时还要注意不要碰到另一个就可以了。在这个过程中，自己具有一定的主观能动性，或者说还是有选择怎么做的权利的。在最差的环境下，我估计这个功能会引起我我这个层次上不可协调的争执，那不如一开始就不要上这个功能。这个小功能费掉了，程序的其它作用还在，总比由它引起程序的整体瘫痪要强得多，还搞得大家都不愉快。
