IT部门的业务和开发之争：Who am I？
最近半年参与了公司一个HRIS系统的流程开发，中间经历坎坷，公司先后选了两个系统来做BPM（Business Process Management）。先是Salesforce公司的Lightning Platform，然后中途换上专业做流程的Pega。这篇文章并不是要说这两者的好坏，因为即使换上了业界先进（或者号称行业老大）的Pega，也并没有让这个项目按时成功上线。
最后，国庆节大家加了6天班做最后的殊死一搏，还是只能接受项目延期或者重新再来的命运。记得国庆中有一天，大佬发火要看需求文档，竟然没有人能拿得出来！
这并不算严重的，严重的问题是竟然项目经理不认为自己是项目经理，需求分析不知道自己要分析哪块需求。最后，供应商的开发不知道怎么开发，只能别人说一点开发一点，或者按自己理解的先做。
我以为这种乱糟糟的事情就这样结束了，没想到我接手的另一个项目仍然是这样的问题。有了前车之鉴后，大佬们规定需要每个项目有正式的文档，这其实又引发了另一场“战争”。
为什么大家都找不着北？
我们属于公司的IT部门，IT部门有业务交付团队和开发团队，具体的命名方式不便透露。公司还是一个PMO（Project Management Office）的来管理项目和项目经理，大佬要求的需求文档和其他的文档有这个部门来制定。
然后他们屁颠屁颠的制定了一套文档和流程，落地时业务分析和开发无法达成一致，并引发了更多的争吵和混乱。因为存在于部门和公司的根本问题并没有解决：大家不知道自己是谁！业务分析和业务方的代表也搞不清楚自己的责任范围，开发拿到的需求文档根本就没多大用处，要做什么还得重新再找业务分析讨论，完全的一个倒逼机制，开发做到某个的功能了就倒逼业务去理清这个功能的业务规则和具体的问题。
你要问我，项目经理呢？产品经理呢？
我会告诉你：“没有！”
PMO会告诉你：“A就是产品经理！”
A会告诉你：“我怎么会是产品经理？！”
开发会说：“需求文档业务需求描叙不清楚，没有具体的业务规则。”
B会说：“要你们开发来干什么的？”
业务方代表（需求提出方）：“我只能管我这块的需求，级别比我高的人的需求你们要去跟进。”
目前来说，除了使用某种编程语言码代码的那个人角色和责任很清楚之外，其他人包括我在内很多时候都搞不清自己是谁。没有明确这些角色、权力和责任之前，PMO就已经制定了需要签署需求文档再开发的规矩，需求文档不清晰，开发不能干活！哪天清晰，哪天重新评估重新开发。
于是IT内部的开发和业务分析只能爆发“战争”。
冲突的根源在哪里？
业务交付团队希望能尽快的交付产品给用户，毕竟他们直接面临一线业务的压力，时间对他们来说很关键；开发团队希望保证质量和控制开发的风险，其实并没有本质上的冲突。
我一直认为搞不清自己是谁是最本质的问题。如果一个参与项目的角色明确知道自己是项目经理，那么他会知道自己要管理项目的进度和对各种资源进行协调，产品经理会知道对需求负责并明确哪些需求是必须要做的，需求分析才能明确具体的业务规则。但往往一些小的项目，很难有齐全的人员和组织配置，可能会存在一人分式多角，甚至很多项目只有需求提出人和一两个码代码的程序员。
搞不清楚自己是谁，可能需要大家慢慢磨合和明确下来，这个顽症并非一朝一夕可以医好的。我从技术的角度，在思考另一个问题：能用技术解决开发和交付的冲突吗？
开发和交付团队的冲突有两个方面我想是可以尝试技术突破的：
- 需求提交、分析、开发，到交付用户使用的周期过长，即使签署了相应的文档，也无法保障开发出来的产品是业务需要的；
- 业务、分析和开发讨论的有效性不高：多方的角度和认知不一样，大家往往不在一个频道上。
可能你会想到敏捷开发！没错，这也是一个可以尝试的方案，不过我在尝试另一个方案。
欲知后事如何，且听下回分解（抱歉，我的尝试还没有成功，之后有效果了会总结奉上）。