分析应该与技术无关吗？[关闭]

昨天我和一位同事吵了一架。他（业务分析员，以前是程序员）认为，他应该了解实现该系统所用的技术，以便可以做出更好的设计决策。我认为（我是一名程序员），不应以任何方式将分析与技术相结合，并且我相信优秀的分析师可以做出出色的设计而不必担心实现细节。

我这样想对吗？有什么理由导致业务分析师需要了解用于实施该系统的技术？

编辑：我认为我说的时候用错了词business analyst。也许我是指架构师或系统分析师。我不习惯这些条款。如果您愿意，我的意思是像架构师或系统分析师。

谢谢大家的出色回答！我还没有很丰富的经验，很高兴您对此感到惊讶。

在某些情况下，对于业务分析师而言，至少应该足够了解该技术，以至于可以向业务用户询问某个特定功能的重要性是有意义的。例如，如果企业习惯于胖客户端应用程序的行为，而新的应用程序将基于Web，则很可能会有很多“需求”对于胖客户端来说是微不足道的，但相对困难基于Web的应用程序。如果业务分析师了解该业务请求对于开发团队来说是微不足道的还是需要20个小时的AJAX开发，

对于任何给定的项目，很可能存在大量的需求，这些需求实际上可以通过进行各种折衷来满足业务需求。业务分析师对他们正在权衡的事情越了解，他们就越有可能提出一系列要求，以使业务收益最大化同时成本最小化。

在解决了这个问题的双方之后，我必须同意分析师的观点。由于缺乏对技术功能的了解，我看到了一些非常差的设计。在某些情况下，这是将营销炒作当作事实的结果。通常，问题在于生成的规范与技术能力不匹配。

分析人员应指定需要做什么，何时以及由谁执行。他们应该知道为什么要这样做。与其他因素相比，发展优先重点应更多地取决于“为什么”。设计和开发团队需要处理方法。为了开发具有成本效益的系统，分析人员需要以不超出可用技术范围的方式指定需要做的事情。

突破界限会以多种方式增加成本，但在某些情况下可能会带来可观的回报。一些成本因素是：

• 可能需要进行实验以制定可行的解决方案；
• 可能需要招募具有专门知识的新员工或顾问；
• 可能需要对新技术进行培训；
• 开发往往会变慢，错误率会更高；和
• 额外的努力可能会延迟具有更直接价值的简单解决方案。

如果已知将使用的技术，则分析人员在创建设计时应将其考虑在内。不同的技术会做不同的事情，而没有考虑到这些差异的设计将会出现问题。

但是，业务分析师不应在乎使用什么技术，他们的工作是收集业务规则并使技术团队可以理解它们。系统分析师/架构师/设计师或他们使用的其他任何名称都应了解所使用的技术以及围绕它们进行设计，因为他们应该是进行实际设计的人员，而不是业务分析师。

我认为，两条思路之间可能存在一个更现实的观点。如果不考虑技术，高层设计可能是最好的，但是必须考虑到已知的现实世界中的约束和要求，这些约束和要求应纳入设计中。这个设计是什么级别的？您有足够的要求吗？环境有多灵活？管理层是否在特定的技术方向上进行了投资？

是否没有可驱动您朝特定方向运行的参数？您是否拥有广泛的资源，能够在任何技术堆栈中实施解决方案？是否存在需要访问其他系统的互操作性问题？

必须先回答这些问题，然后才能明确地说出技术是否应该成为方程式的一部分，或者设计是否应该推动技术的选择。

由于没有任何限制并且是一个非常高级的设计，我可能会同意您的想法，即该设计是真正不可知的。但是，在我20多年的经验中，我很少遇到没有任何限制我选择的限制的情况，而这些限制将我的设计推向特定技术或技术系列。

在理想的用户界面将是用户认为一个想法，和他们想要做的是简单地完成。缺少的一切都会因我们拥有的技术局限性而受挫，因此，广管局当然需要了解他们可以在何种环境下设计系统。

为了解决给定的问题，不同的技术可能具有非常不同的成本和效率结构。这些成本可能包括诸如当地的雇用成本，特定系统的能源和冷却成本，现有代码和现有设备可重复使用性等因素。因此，是的，也许人们可以忽略这些矛盾和特定技术的细节。如果某人正在从事一个项目，而该项目的成本和效率并不比其他考虑因素重要（例如在航空安全，核工厂控制，医疗植入等方面）。但是对于大多数业务情况，管理层可能会关心潜在解决方案的成本结构与系统实施的收益。

业务分析师应该知道什么样的应用，我们正在开发像* Web应用程序/控制台应用程序/移动应用/报表应用等 *让她能更好地想出一套很好的功能，为应用程序或推回用户对第三层嵌套拖放等不可能的期望（例如）。

他/她不需要知道哪种技术，例如Java / C＃/ Python / SQL等。

分析过程本身需要完全与技术无关。在研究客户及其需求时，您需要完全开放的态度。但是，另一方面，经常要求分析师提供建议，并且可能还需要分析师处理系统架构。这是角色的一个完全不同的方面，在这个角色中，对可用技术的更广泛理解至关重要，因为它不仅可以使项目启动，而且可以为客户带来巨大的变化。客户的长期需求以及项目本身的可持续性。

的确，无论使用哪种技术，设计软件的大部分部分基本上是相同的，但总有一些领域会受到技术选择的影响。平台的选择可能会影响语言和API的选择，而专业知识，支持甚至成本的可用性也将影响所做出的选择。因此，从一个角度看，您的部分职位是合理的，因为应该在不受到任何特定技术影响的情况下进行实际分析，但是使用分析来确定设计总是需要更广泛的技术知识，以便分析师可以提出建议这将允许应用旨在满足客户需求的设计。

每种技术都有限制和约束，因此对于分析人员来说，考虑这些限制是有意义的。另一方面，一位非常了解.net但自从90年代末就没有见过Java的分析师很可能会使用.net术语和设计模式来设计.net解决方案-即使Java（或RoR等）也是如此。会更好地解决这个问题。以后在另一种技术中实现这种设计相对困难。

因此，我认为当尚未选择该技术时，分析师应该是个不可知论者，但对于已经做出选择的那些人，经验丰富。