软件开发过程中我经常会遇到这样的问题“软件某个功能实现上，业务人员说一套，软件人员说一套”。
这里就透漏出业务和软件这个既矛盾又依赖的一对小冤家。
业务人员与软件人员的所说的想法，貌似矛盾，实则一致：
业务代替不了软件，软件也代替不了业务。业务人员代替不了软件人员，软件人员也代替不了业务人员。
业务软件中的业务和软件的关系，我觉的可以这样形容：业务就是软件的灵魂，软件就业务的肉体，是相互依存一个统一体。
业务（行业）软件需要业务人员和软件人员密切配合才有可能实现，这个过程里业务人员负责将软件要实现的功能要逐一细化，并分类汇总；
软件的人员则是再次拆解这些业务需求（所以软件开发人员也要对业务应该有较彻底的理解），从软件实现角度来把业务分类汇总。
软件的界面则可以由业务人员和软件人员共同讨论来确定。
在软件开发初期，需求评审阶段。应该有软件的人和业务的人员共同参加。
与会人员中业务人员要有一定软件开发知识，软件开发人员则一定要有必要的业务知识。
需要注意的时需求评审过程中，业务人员一定要给软件开发人员讲清业务的来龙去脉，否则软件开发人员做出来的软件很可能就不是业务人员所想要的东西。
其实软件产品的需求评审过程一个相互学习的过程，
软件的人学到了一些必要的业务知识；业务的也学到了必要的软件开发知识。
只有这样才有可能把业务软件做到业务功能齐全，软件性能优越。
业务（行业）软件项目中不应存在业务人员越俎代庖，直接给软件人员规定怎么实现，这么做应该坚决杜绝。业务人员考虑问题，出发点毕竟是业务需求，而不会在意软件的设计原则更不可能彻底理解软件的整个软件设计思路（复用、已扩展）。如果听业务人员这里加一个字段哪里加一字段，很快软件代码就会陷入混乱。
代码混乱的后果就是项目越做代码越乱，维护成本越高。项目做的最后要不夭折，要不入不敷出。当然公司针对这个情况也有解决方法就是“让软件开发人员免费加班”，这样做的确可以一时奏效。但试想如果你是一个程序员，又碰上这种事情，你会整天加班加点改别人留下的一对乱码而没有任何想法吗？
参加需求评审、概要及详细软件设计评审的人员应该是：业务人员、高级软件开发人员和架构师以及其他项目干系人。
其他开发人员后续可由高级开发人员和业务人员来讲解 业务需求，这样业务人员又可以进一步了解到软件需求是否正确理解了业务）
所以业务软件开发过程中要看清业务和软件以及业务人员和软件开发人员的关系。
只有弄清这些关系，业务软件的开发项目才有可能步入正轨。
未完待续