2018年有写过一篇文章提到IT部门的业务和开发之争：Who am I？，居于当时的情况我想了一些解决方案，一年过去了，今天补上后续事件的发展。
上文说到，我们公司有一个让项目中的各个角色“搞不清自己是谁”的关键问题，其实追根溯源会发现在招聘的根源上这个问题必然会产生。公司喜欢招BAT、华为、SAP、IBM等大厂出来的解决方案架构师和开发工程师，但招进来后往往又没有对应的岗位，于是很多招进来的人不得不学习其他类似甚至不相关的业务或开发方向。如我，是以Android移动端开发工程师的定位招进公司的，但进公司到现在过了2年半的时间，我可以“自豪”的说“我从来没有为公司提交过一句Android代码”。
其实就算招进来的人有对口的岗位，但如果整个业务流程或开发流程没有成套的岗位，那么零散的几个“有模有样”的岗位，并不一样能发挥应用的作用，最容易的结局往往就是东施效颦、画虎不成反类犬。
也许成长型的公司必须经历这样的阵痛。
敏捷其实还不够
针对成长型的公司，面对快速变化的需求，大家最容易想到的解决方案往往就是抛弃传统的瀑布式开发，转而拥抱敏捷。我在很多公司（包括大厂）实施过敏捷，敏捷从来都不是随随便便就能成功。
用敏捷来解决公司里IT项目开发，并不能解决问题。我们的问题不是需求变化快，而是缺上很多重要环节，搞不清自己是什么需求是什么。很多公司搞敏捷开发都是从开发和测试团队搞起的，这注定了搞出来的是先天发育不良的敏捷，大概率结局是除了有几个“站会”、“回顾”等会议形式外一切照旧。
如果我们从开发的角色不能搞定各方“利益人”参与进来，敏捷无从谈起。我曾经让业务在软件开发开始阶段就参与使用每日迭代发布的产品，却遭到对方的质疑：“你没有经过测试验证过没有达到交付要求的产品为什么让我用？”
也许，我实施敏捷的能力和手段太差，但现实中没有足够的利益代表方支持，敏捷很难名副其实。开发这类角色在敏捷过程中真的没有你想象的那么重要。
我实践的两个解决方案
但总要做一些自己能做且能发挥一定影响的事情来让项目的开发过程和结果变的更好。我努力的方向是让沟通更有效！既然大家之间有明显的裂痕（gap），而又无法推动对方去修补好，那就用技术解决些裂痕。而争吵是我首要解决的问题。
我其实很不喜欢争吵，因为我了解语言的特性，大家有各自的过滤器，你听到的不一定是你理解对方要表达的意思，同理对方也很难从话语（哪怕是文字）上听懂你要表达的意思。很多争吵完全都不能算是真正的争吵，说大家在“各抒己见”、“鸡同鸭讲”更加合适。
我的解决方式就是让争吵的东西所见即所得!
第一：项目管理实现业务需求和代码“同步”
既然公司没有专业的业务和需求分析，写出来的需求文档也不规范，那就让他们连需求文档都不用写（其实是剥夺了他们的某项权利，但一定要说成：帮助你生成需求文档）。
我们Team自己做了一个项目管理的平台，和业务谈需求的时候直接按DDD（领域驱动开发）的方式将他们的需求分解成对应的问题和规则描述。然后用Python编写的脚手架工具将这些问题、业务事件等生成模版代码，而且是可直接部署上线的工程项目代码。以此弥补业务和开发人员之间的裂痕。
而且，当对方需求或问题发生变化时，我们在这个系统上做修改就好，然后开发的模版代码会发生改变，业务也可以直接获得这个工具实时生成的需求文档（doc格式）。最终，通过这个项目管理工具实现了需求和代码的同步。
做到这一步有一个重要的前提：你的项目实现了自动化部署和测试驱动开发。
为此，我花了很多时间改进公司的项目部署流水线，并通过引进DDD模式让业务代码和平台特性（数据库、网络等）分离，实现管理平台根据业务需求规则自动生成单元测试代码，由测试驱动开发。不要试图让没有做好代码高内聚低耦合的项目开发人员去写好单元测试代码，那样的单元测试基本上只有满足代码测试覆盖率的功能。
也不要试图让一般的开发工程师理解代码分离，直接用模版代码“强制”隔离，否则累积到后面的意大利面式的代码能直接让你崩溃。
第二：开发和业务的共同语言：图
代码的维护是一件很让人头疼的事情，而“成长型”的公司肯定喜欢频繁修改上线后的应用，而且“理所当然”的认为修改、添加个小功能比原来的开发不要太容易！但看别人的代码进行项目维护或二次开发往往比让自己重写一遍还要痛苦万分。项目是否能成功，除了按时交付外，是否能有效控制维护成本、能灵活升级也很重要。
从业务和开发理解的角度，降低项目的业务理解认知负荷都很有必要。如果能有效的降低业务和对应的业务代码的认知负荷，那么代码的维护和改动也将变得更容易和更可控。
我做的第二件事情，就是解决认知负荷的问题。
我的目标是让新的人员接触这个项目时，不管是新的业务或是新的开发、测试人员都能很快就了解这个业务的流程和规则。我不想让他们去读一遍需求文档，不想让他们必须通过需求文档的文字了解业务规则。
回到我前面说的“让争吵的东西所见即所得”，我的第二个技术弥补裂痕的方式就是让业务规则实时化、图形化！
只让人看到最终的结果，只按某个最终的结果来讨论和理解业务都是很片面的。很难对业务有全局的理解，最容易的就是维护时顾此失彼，改一个BUG产生一两个新的的BUG，BUG永远生生不息。所以，我们的理解的过程应该是可以交互的，不同的输入应该要向我们展示不同的业务流程分支，并要把边界异常标明清楚。
如下图，一个实际中生成项目预测的业务流程，界面除了展示最终的结果数据，还根据不同的项目编号向用户展示不同的数据获取和解析流程。
结局
其实，还在进行中。
