沟通的壁垒
早上和售后的同事出差去地铁，跟对接我们SNMP的烽火同事一起，讨论集中告警系统和我们系统的对接问题。由于刚开始讨论需求的一波人，做需求的是另一拨人，出事了又去解决问题的又是一波人，所以一个并不复杂的问题，来回沟通近一个月的时间却是无果。顺带跟售后同事聊了一下，发现有一个很有趣的现象:
- 售后同事们，都认为，研发人员是老大，他们提的要求，研发这也不愿意做，那也不愿意做。
- 一线的研发人员认为，自己是最底层最可怜的人，售后的同事说是什么就是什么，他们才是老大。
不禁反思了一下这个问题到底出在哪里？一线的人员离客户太远，客户的声音无法准确及时的传达到一线人员的手里，一线人员的一些好的建议和想法也传递不到客户耳朵里。中间环节太多、部门之间的壁垒太严重。导致有一种两头黑，两头不讨喜，大家都过得很痛苦，做事不给力，不得劲的感觉。在今天双方交战的过程中，我感受到大家各种情绪的能量在房间里流动，出现了，又消失了，而我始终能保持一种第三者的立场去觉察他们，感受他们，感恩教头今天在微信里的分享。如果人和人之间的沟通能如流水般顺畅，该是一件多么幸福的事情。
分享和连接
早上坐班车，遇见每天接孙子的大爷，他跟我分享了秀丽东方免费注册会员，可以一年免门票的消息。遂把这个消息分享给了多个小伙伴儿，小伙伴又很快把消息继续传播开来。感恩大爷的分享，八十多岁的大爷依然会用微信，保持着与时俱进的心态，乐呵呵的笑容，忍不住想要给他大大的点赞。
不同的视角
今天扮演了一把QA的角色，在不是很了解具体代码逻辑的情况下，纯粹从QA的边界和异常场景的角度和高老师结对审查代码，还发现了一些逻辑问题。不明白具体实现逻辑，反而测试场景梳理的思路不会被实现逻辑所干扰，思路更清晰，这和曾经遇到过的一个案例很相似。
当遇到复杂的逻辑时，先写测试代码，把测试场景梳理清楚，再去写实现代码，这样写实现代码的时候，目标就很明确，只要梳理出来的场景用例都实现了就可以了。这样和先落入具体实现细节，却因为过于复杂，而陷入一种场景的盲区状态完全不一样。
因此，面对一些复杂的场景，如果能结对，有第三者的视角，则更能发现一些问题。如果没有第三者的视角，最好能先从QA视角入手，再去陷入实现代码的细节更为妥当。
