提到工程，大家初始的印象就是严谨，高质量，返工率底，比如常见的路桥、楼栋、堤坝等，怎么到了软件工程这，初版还没成型，刚开始的设想就被推到重来，变更了好几版，这算什么工程？完全是任意妄为的产物嘛！
题图 from unsplash
几乎每个传统工程都有一套遇到的限制：功率，热量，体积，质量，流量等，而这些限制在软件工程中都不存在。而且软件工程可以做到日迭代，这些其它工程而言基本不可能实现。另外，软件工程是基础部分可以复用，但传统工程中一颗螺丝钉不能同时打在两个铁板上。
软件的出现是为了提高现实生活中业务的效率，是为了解决业务问题而生。如果一项业务非常稳定，抽象而来的软件应该也会比较稳定，变更升级的几率比较小。相反，如果开展的业务起伏不定，与之对应的软件要保持相应的变更才算合理，不然软件长期下去就会变成不能适应业务发展的垃圾。
公司存在的目标是盈利、创造价值，利润产出来源于商业模式盈利模式，软件在其中起到举足轻重的作用，特别是依赖性很强的组织机构，比如那些头部的科技公司。传统模式开发时采用瀑布模式，变化相对还比较小，进入敏捷时代之后，唯一不变的就是变化，拥抱变化成了主流。
对比其他工程，软件为什么变更这么频繁？实体工程的沉没成本看的见，资金、人力、工期等等，轻易返工会造成更大的成本付出。软件呢，更多体现在无形的时间成本、机会成本，而这些可以通过加班加点来挽回，工程师的脑力成本大多半会被忽略。辛苦半天的劳动成果这么被无情的忽略，有抵触情绪再自然不过。产品人员一定要评估，需不需要变更、变更多少，变更后对历史数据、流程产生的影响有多少，变更后能产生多大的效果一定要心中有数，而不仅仅是一个变更需求就草草了事。
上下同欲，目标一致，有稳定的收入组织才能生存、发展，为匹配业务开展而产生的变更不管是产品人员还是技术人员，都应当积极的适应，抱残守缺只会使团队走向灭亡。有种情况除外：产品人员业务理解偏差导致的返工变更，更容易引起技术人员的反弹，如此以往，团队必定遭遇变故。
实际的团队活动中，产品与研发的角色往往不是那么和谐，更多的处于对撞状态，于团队于公司都是一种内耗，不利于整体向上发展。有时候还会引起激烈的冲突，甚至发生人身攻击。这需要团队文化的熏陶，强有力的团队建设能够引领大家积极的应对变化，迅速做出调整，适应市场的挑战。产品与研发好比孪生，相互促进相互扶持才能走的更远。
一成不变的东西生命力是很脆弱的，软件要积极的演化迭代，逆熵做功，才能保持强大的生命力，否则只有停机下线的份。
-End-
