一起学习，共同精进
前段时间基于系统工程“迭代、递归”的核心理念，做好了一项工作的协调，今天分享给你！同时也是为了小小的反驳一下那些总想需求一次到位的人！
作为系统工程师，经常需要与负责产品实现的工程师打交道，其中打交道时间最长的可能就是软件工程师了，因为现在"软件定义一切"嘛，毕竟产品的硬件更改是长周期事件，软件更改是短周期事件。
我的工作也大体如此，确实是和软件工程师打交道时间更多。而且工作中经常被软件工程师质疑：
为什么你的需求总是逐渐增加，不能一次到位？
不知道朋友你是否也会遇到同样的问题？
想当年，初出茅庐的我，被老软件工程师谆谆教导：设计要考虑充分、要一次到位，不然软件更改太费时费力。
为了形成融洽的协作关系，为了体现自己的能力，我真的充分考虑、认真设计、力求完美，全力付出了。但付出的努力越多，感觉被现实暴击的越狠。
为什么会这样呢？
现在回忆起来，我可以自恋的说不是我能力不行，实在是我真的奔着一次到位这个目标去的。
我的设计结果敢说比很多老设计师考虑的更周全，对每个很小的设计我都能说出不得不这样的理由，每次交付成果的时候，大家其实都评价很好，几乎很少提出改进意见。
可即使这样，还是会有更改，要么是外部输入变了；要么就是实现过程中发现有些地方难以做到或者需要再细化；再有就是设计中考虑不充分的问题，虽然这种情况是少数。
除了外部输入变了这种情况外，其他情况带来更改时，我通常都会有点沮丧，因为全情付出了、当时认为完美的作品现在有了瑕疵，应该换了谁都不会开心吧。
我不开心的时候，有人比我更不开心！
这样的事多来几次，上面类似的质疑就产生了。每到这种时候，确实是自己的问题我都不逃避，积极承认失误，主动沟通；其它的情况只能摆事实讲道理，争取支持。
但我一直也在思考，怎么能够真的做到"一次到位"呢？和我遇到同样问题的同事一样也在思考。大家共同的答案就是输出需求前应该充分验证，解决办法就是自己做仿真验证。
早期我们做过分布式仿真，但仿而不真，不能真正解决问题。现在分析主要是因为周期、时间、人力、环境和要求的标准不一样，仿真是追求是否逻辑上基本正确，实时性、稳定性等要求的就宽松，但这方面恰恰是真实产品要必须保证的。而且通常都不是产品实现的人来做仿真，最终的成果也无法用于产品实现，导致这个过程费时费力，最终没有走通这条路。
后来接触到了基于模型的设计——MBD，这个经历我在《系统工程：不是一个点，而是一张网》中介绍过。MBD这个方法至少在理论上完美的解决了仿真成果和产品实现的衔接问题，而且还有模型在环、软件在环、硬件在环等测试步骤做辅助，通过工具确保高效设计、验证与实现。
现实中推行起来很困难，实现MBD需要改变习惯、改变工具链、改变工作流程、改变组织结构和分工，大企业船大难掉头，还需要大量资金投入，进展很缓慢。
虽然我在工作中没有真正的应用MBD，还停留在最传统的方法中，但多年的工作下来，我慢慢认识到：
一次到位只是诗和远方，不是眼前的苟且！
我相信就算用了MBD，一样是如此。不然它为什么还有那么多的在环呢？
之后深入的的学习了系统工程方法后，知道了它的核心理念是迭代、递归，我更加确认了自己的想法。
真正的设计工作，从来都是由粗到细、逐步迭代和递归完成的，无论你有怎么样的基础和工具，至少目前看只能加快和减少迭代和递归，不能消除它们。
我举个朋友你大概率经历过的事情来举例说明。
作为系统工程师，都应该自己编过程序吧？不知道你编程的过程是什么样子的。只要是稍微复杂点的程序，我即使前期做了设计，但真到开始编程总会遇到接口不匹配的情况，或者数学公式不全面的情况，当总算把这些解决掉的时候，程序运行起来依然会出现出各种语法错误，所以都要反复的运行调试，最终才可能通过。
今年在项目中系统工程师和软件工程师换了一部分新人，他们之间没有原来的同事合作顺畅了，软件工程师经常要求输入要一次到位，我参加了几次沟通也没有特别好的效果。
然后我就想到了自己编程的情况，想到了系统工程方法的核心理念，虽然我不是专业做软件的，但我不信专业的就会一次成功实现，这有点违背客观规律。
我去和新的软件工程师请教，他是不是一次就能成功实现，他自己也说，即使是简单的程序也不能确保一次成功，像我们的复杂系统软件那就更不行了，肯定需要反复调试。
听完我在心里就笑了，我跟他介绍了我编程时的情况和系统工程的核心理念，然后也请他从实际出发相互理解一下：
既然你的程序也需要反复调试才能通过，那怎么可以要求需求一次到位呢？
大家都要互相理解，瞄准一个目标，共同提升才是。
他听了之后也认可了这一说法，之后配合上融洽了不少。
—END—
业余时间写文不易，有收获的朋友敬请：
转发、分享、在看三连，帮助推广
关注、星标公众号“SE与MBSE漫谈”
扫描下图二维码加我微信，加入“SE&MBSE共进群”，与同道共同交流
公众号加“星标”，及时接收文章！
