起源
昨天团队发生的一件交互让开发调整细节的小事，让我看到了一些问题。
首先，种种原因，这个项目是由一个资深的开发来写的。和这个资深的开发相配的，也是一个多年的设计。
交互不停的让开发调整细节，差不多就是那种字体颜色啊，边距啊，有时还会牵涉到一些无关痛痒的交互行为。
我竟然有点为这个开发感到伤感，原因是这样工作太耗费精力，并且不会有任何能力的提升，觉得对不住。但由此也在思考什么样是一个好的团队。
现代软件开发的结
现代软件开发，关键点是软件越来越复杂，人也会越来越多，所有的流程，方法，都是围绕着这个话题进行的。
组件是一个很大的成果，将复杂的东西包括其中，对外提供简单可用的接口，从而将开始周期大幅度缩小，并大大降低复杂度。
现实中大多数时间也都是组件的拼装，不会从零开始造轮子。
在这家公司里，这多年的耕耘，在技术的标准之下，这些组件已经很完备了。但问题是，围绕在这些技术人员的标准周边，并没有形成产品、设计对这些标准的认知。
技术团队中的产品、交互和设计
一个技术公司的产品、设计和交互如果不能编码这个是没问题的，但如果都长年不对技术的一些知识有了解，这个就可悲了。
如果他们知道开发的一些模式，一些知识。就可以在设计时，去和技术一起，想办法在产品、设计时，也遵循一些技术的模式。
比如这个场景中，设计师在设计时，考虑到已有的组件，尽量的去复用。可不是每一次的随意一笔，这一笔自己设计只要一小时，而带给开发的可能需要不只一天，但设计师没有这个成本的概念。
技术认知造成的成本的不对等性
刚提到了一点，就是因为不了解技术，就造成认知的困难，这其中就是时间和成本。
产品可能一分钟就能想到一个方案，设计要花一天来补全这其中的细节，但对于开发来说，可能就是几个人的一周。
抛开业务的模式不说，从技术上，如果有
这其中一个重大的原因就是成本的不对等，
从这个问题，又联想到另一件事，就是团体与进步的关系。
团体与进步
逻辑思维中有好多节是关于教育，阶层等进步相关的，最后的方法都是加入一个好的团体。
而本案就是一个很好的说明。如果在一个好的团体里，这些琐碎的小事，大家会同步进步，用一些合理的方法论来简化掉了。这样对于个人，则可以更多的发挥自己的能力，让自己在更高的点上，得以提升。
总结
这个解来自管理层，而中国式管理的人都不看技术，这和硅谷的公司很不一样。所以，也就是无解。只能靠团队中的这个成员自身的提升意愿。
但恰恰还是有很多人愿意去做技术型产品、设计和交互。
找到一个这样的组织，对个人的幸福度和能力的提高都很有必要。
