如何传递变化？

书太多了就不太愿意读；

每天乱七八糟的事情太多，就什么都不想做；

目标定得太高完成不了，就容易自暴自弃；

变化太频繁，人就容易无所适从；

……

最近遇到的两个问题：

1、设计评审的时候，原定的设计突然说不做了，我想领导的考虑可能是不在沉没成本里继续浪费时间，但变化有点突然；

2、一款产品一直在改进中，可能前一个项目、后一个项目其实施的方式不一样，这样会导致技术支持在现场没有参照依据，到现场后就依靠他们自己的发挥了，导致标准不一致。

一

第一个问题，其实我一直鼓励团队拥抱变化，对于开发项目的变动或者说停止，大家的接收程度比较高。对于已经投入1、2个月时间的开发人员来说可能就是浪费了时间成本，当然心里肯定不愉悦，他们本没有做错什么。但从决策层面来说，公司浪费的是机会成本，因为这个导致其他产品延后或者错过了最佳市场机会。

变化绝不是凭空一步到位的，事情总是一步步变成现在这个样子的，怎么把这种变化，能在苗头刚开始时就传递到团队中，而不是推倒重来？

这让我想起了温伯格“垃圾警告”：我们不要给垃圾包上彩纸，不值得做的事情就不值得做好。如果从一开始就没想好设计能达到的目标，下面的人自然就更是做一步看一步了。所以，在前期花更多的时间进行思考和验证是非常关键的。

二

第二个问题也是比较常见的，涉及到改进点，技术支持希望研发能实时地更新文档，我想到两个解决办法：一是有专人负责，只要技术变更，就更新并下发；第二是通过云端协作的方式，直接在上面改，改动点大家也都可以及时看到，直接扁平化，让一线的人也可以做决定，这可能是一个比较好的解决方案，但很多人接受不了这种做法。

方法一需要人，属于懒人思维，没有人所以这个事情可以先不做；方法二有一点变通在里面，可很多传统企业并没有养成这种工作方式。之前我在团队里推行Trello、Worktile，进行了一段时间后发现，如果不进行强制要求，很难形成这种互联网式的协作工作习惯。

这也引申出一个问题：工作标准就是在这样的变化中降低了。开发如此，技术支持也类似，之前已有文档虽然有点问题，但对于指导整体施工还是有用的，很多时候我们习惯因噎废食。

一周工作中的几点记录。