所谓共识

首先一个小问题，不约而同算不算达成共识呢？若把共识定义为各方不但意见一致，而且还都知道其他人和自己意见一致，不约而同是不能算达成共识的。
共识体现了沟通的价值，促成共识是一项非常重要的基本能力，比特币/区块链正是在去中心化的场景中解决了信任和共识问题(没有信任则无法达成共识)，才产生价值，获得关注。联系生活和工作中正在发生的事，我意识到为达成共识需要自己更多的思考和努力。

家事

上个月儿子调皮，把花盆里的土拨出来，弄得身上桌子上都是，禁止了好几次，言语态度越来越严厉，总算制止了。小家伙说，'不要玩土，玩土爸爸要生气'。当时感觉松了口气，但现在想来这真是个达成共识失败的例子，小家伙认为不能玩土的原因是爸爸要生气，这以后肯定是有隐患的，下次一定要争取让他明白。
还有另一件事，周一我和老婆需要把小家伙送去外婆家，起得很早，我特别怕挤5号铁，路上来回时间太长，肚子不舒服也很麻烦。我告诉老婆希望早点出门，但是每次都拖到很晚，表示不满结果老婆也很不高兴。想了想其实是两个人对太晚理解不一样，老婆过去一直挤5号铁，根本不怕，而且公司在徐汇区，肯德基再吃个早饭8点不到就到单位了，我觉得晚了的时候她倒是觉得还不急。唉~达成共识还挺不容易，从一开始说明具体时间点就不会有后来的不便和不愉快了。

工作

恐怕在工作中达成共识是最重要和需要严肃对待的事情了，说说几件最近发生的事。

前一阵子ART刚被应用到生产环境，基于性能日志我报了几个I29的story。有天Anne问我，分配给他的story是什么意思，能不能讲解一下，我当时很忙，听了有点紧张，要是每个人都要我讲解那得花点时间，而且调优就是依据日志，没什么好解释的呀。问题总要解决的，进一步沟通后发现原来是Anne自己查了ART数据后发现和我给出的不一样，不一样的原因是我只标出了ART数据时间范围的周数，即2016年52周，而Anne用了另外一个时间段。
原来问题还在我这里，如果我用具体日期表示，就不会有这样的误解了。从这件事我获得两个教训，一是提交story应该给出明确完整的信息，并且用直接和不会产生歧义的语句。如果我一开始用日期表示时间范围，Anne就不会浪费时间用错误的时间段查数据了，而后来的额外沟通也可以免除。这些都是不必要的效率折损和浪费，如果是需要和很多人达成共识，这个问题就要被放大很多倍产生混乱了，而我也会疲于奔命。二是Anne给我的反馈是很及时非常有价值的，让我可以发现自己的不足，是个难得的提高自己的机会，让我下次更有信心把工作做到位，我也应该怀着感恩的心更有耐心地进行沟通。
在此特别向BA的卓越工作致敬，原来他们是如此的不容易！

第二个是关于设置最晚发货日期的story，我是owner，有好几个dev参与开发。brief时我不在场，而且被告知我的task很简单，我也就没重视这件事。结果后来晚了2天才给QA，我自己测，有问题通知相应的人，改好我再测，就像每个齿轮都要手工转动的机器一样，一个每个task都相当简单的story，被做的效率非常低下。这是我的责任，作为owner，我应该弄清整个用户故事以及每个人要做什么，如何衔接好，并且就此计划和所有开发人员达成共识，并且负责确保最终和QA环节也衔接好。
所以考虑到QA环节的衔接，刚才ART story的故事还没有完，因为并没有告诉QA该怎么测试，其实是并没有DOD(definition of done)。没有一个可以衡量的确切性能指标，也没有code review，全靠dev自己一个人保证。

思考和反馈

为何达成共识以后执行效果也不佳呢，先排除‘领导要我做’这种动力不够的情况，比如每日更新story/bug/timesheet/看板，effort并不大，但执行效果不佳。思考题留给各位了，动脑防衰老。
其实身边实在不乏对达成共识的观察和思考的机会，尤其是在工作中。
就我自己而言，以后不但要从自身的经历中反省，更要向那些擅长沟通，有影响力的同事学习，没有对比，就没有进步。从慢行到散步，从散步到慢跑，总有一天会风驰电掣。