2015年的某一天，产品面临着上线，大部分的上线压力都在界面设计上面，我跟ui同学都很头大，沟通期间设计各种不满意，自然也会影响情绪，迫于发布时间，也只能作罢。我自然是不甘心的，所以一直在想办法伺机找个机会能改点什么，跟开发、设计人员产生了不少摩擦，一开始我感觉大家在偷懒，然后被倒推回来，又一次上升到工作流程层面，大家把球踢到流程上面。
后来，我错了，大家不是不愿意改，是因为各自站的角度不同，你动动嘴而已，我却要动一下午,而且，因为我的改动，这里那里全部都要改，造成整个发布的delay.在团队协作中，dead line 是一个不可逾越的门槛，delay事件在在外面团队是绝对不被允许的，因为大家都是工作流中的一环，一环为一环负责，一环delay下游的全部delay导致整个发布delay.所以，在这个过程中，团队协作中矛盾最为频发和尖锐的矛盾点，这个矛盾点的根源的在于改，切后果很严重，不信你看：
可我一直在坚信，只要能赶上发布上线之，一切都可以改的，及时不改，全队也应该有拥抱改变的意识。跪求不被打。
改变，大的层面说，需求改变是在不确定世界里寻找的一种相对确定。世界是动态的充满不确定性和随机，产品是一个探索的工具，我们是在不断的尝试试图在相对短的时间里无限的接近事情的真相，争取正确的道路上，我们必须认清和面对这样一个残酷的现实，唯结果导向---无论我们产品做的多么完美，没有用户的认可价值撬动市场的能力，一切都是零。就像是钓鱼，无论我们做了一个多么完美的萝卜诱饵，钓不到鱼，无卵用。而在这个过程中，无门只是一点点、慢慢的无限的接近这个结果。
需求变化是软件开发的属性之一，如同钓鱼岛自古以来就是中国的固有领土一样。这也是敏捷产品的价值观之一。在现阶段下找到正确的方向从不是一件容易的事情，反复、甚至倒退都是有可能的，尽可能行在相对短的时间内做到最好，需要灵活的细胞，即使是每周两次的发布频率，也应该把事情做到极致。
小的层面说，产品是团队的脸面。we r 伐木累，无论我们的家多乱，我们总要洗刷干净，以最好的面目示人。借用一句话：体面着装不是炫耀的工具，是你约束自己的工具，有值得炫耀的东西，不是很酷的事情吗？
情怀一点说，再借一句话说，改变不是产品经理刷存在感的工具，是你约束自己的工具。你有多大的耐心把自己的设计推倒重来？一次，两次三次？我知道说这句话容易被打，所以我才不会说要代码写成艺术范之类...找死的话。
我逼逼叨这么多，就是想改个需求少汪汪几句。而对我来说，让产品行驶在正确的航道上，才是保护自己和团队的终极出路，如何行驶在正确的航道上呢？that is a question.