前段时间公司在推行需求的DOD制度，要求业务同事和我们讨论需求方案的时候要输出对应需求DOD，作为后续需求实现的依据。结果这件事在推行过程中遇到了很大的反弹，多方不满意。
用户觉得是在给用户增加工作量，我都把我的业务逻辑都提清楚了，为什么还要出一个DOD，是在和我划定合同界面么？之前推行的敏捷理念，要和业务协作大于合同条款的说法哪里去了？
规划经理觉得业务根本就提不出来DOD，只会把需求要点重新写一遍，甚至就不写，最终还是规划经理写了交差了事；对后续的需求开发一点帮助都没有，后面该扯皮照样扯皮。
而且大家在为需求问题阶段的DOD应该是什么定义，如何输出，什么格式吵个不停；始终推行不下去。
舍本求末
我访谈了一下几个关键用户，看了一下这个问题的来龙去脉。
访谈领导反馈收到多次投诉，DT开发交付的内容和实际业务差异太大，验收和上线后有许多扯皮现象，在实现过程中需求会不断蔓延。反推溯源，DT反馈按业务要求开发，是业务需求没提清楚，一句话需求。于是领导为了卡死源头，要求杜绝一句话需求，利用DOD规定双方界面，业务提需求必须提DOD，倒逼业务多想一下，不能前面说的是a，后面说的是A。
访谈用户反馈在前期方案阶段，需求DOD业务是没办法提供的，业务只能描述他们的问题，怎么解决应该是DT的专业，业务给的DOD，最终会限制DT的实现，如果最终的结果不好，引发双发更大的冲突对抗。
我的理解，这件事本质就是：你看到的问题是别人处理他的问题的解决方案。
我们所看到DOD，是领导解决用户投诉问题的解决方案，但是业务为什么会投诉？因为我们给方案的时候是按业务要求输出的方案，这个方案是业务处理他问题的解决方案，和实际真实业务问题是否一定要用这个解决方案处理，是否有更好更简单的问题处理方案？这是我们发挥我们专业性价值的地方。我们的BA、规划同事确实需要提升自己的专业水准，在业务专业性上高于业务才有可能引领业务。所以，我认为在需求方案层面，我们至少要明白三个道理：
1、你看到的问题是别人处理问题的解决方案，这是一个基本认识。
2、同理心，把你的脚放到他的鞋子里。感同身受，站在他的位置上你才可能理解他的问题。
3、认知高于业务，发挥你的IT专业性。业务只能从业务的维度理解问题，你能通过IT抽象的维度去理解问题。问题本身的维度是解决不了问题的，高维打低维才更容易解决问题。
业务的需求问题分成价值需求，和详细需求，这两块需求的内容都是业务和IT一起共同输出的东西，甚至整个需求到实现的过程都是业务及IT一起努力实现双方共同愿景的过程，如果想从一开始就想着把要实现的内容确定下来，交付就想着按蓝图实现，最后不扯皮是不可能的，正是因为双方有了中间的合同界面，反而更容易出现后面的扯皮事件。因为从需求到实现是一个负反馈的过程，一个控制偏差的过程。我们也要认识到这个过程是渐进明细的，灵活操作的，不应该认为一开始的蓝图是对，后面实现要完全和蓝图一样，为避免偏差去用DOD说话。
SO，我觉得整个的解决方案方向应该去分析我们IT的整体价值流，如何让业务更好的参与进来，更好的去促进双方的和协作，同时提高IT人员的专业能力，来解决需求到实现过程中的问题。
以上。
网友评论