假设使一个职业仅仅是一系列资产，例如宣言或人权法案或一套原则？毕竟，医生有希波克拉底誓言。宣誓就职时，政客会同意他们的话（捍卫和坚持……）。律师有……嗯，他们有东西。敏捷软件开发人员拥有 罗恩·杰弗里斯（Ron Jeffries）撰写的程序员权利法案.

因此，我建议我们对目的，目标和原则作一些陈述，以指导和指导我们的职业。 

由于当今宣言似乎很流行，所以让我们从业务分析师宣言开始。这份宣言是劳拉·勃兰登堡（Laura Brandenburg）创作的 

出于混乱，我们创造了秩序。

出于不同意见，我们达成一致。

出于含糊不清，我们创造了清晰度。

但最重要的是，我们为我们服务的组织带来了积极的变化。 [1]

道格·恩格尔巴特（Doug Engelbart）是鼠标的计算机先驱和发明家，在其他创新中，可能会有助于我们达到目的（表述为）：

业务分析师提高了组织处理复杂问题情况，理解能力以适应组织特定需求并得出问题解决方案的能力。

我可能要加上几年前发布的《权利和授权法案》： [2]

作为业务分析师，您有权：

• 问问题
• 首先了解问题和问题领域
• 确保您正在解决正确的问题
• 挑战业务
• 向解决方案团队提出挑战（解释为什么他们选择以某种方式解决问题）
• 提出解决方案
• 定义问题领域
• 解决这个问题

作为业务分析师，您有权：

• 问问题
• 挑战规范，无论是在业务方面还是在开发方面，都是“完成的方式”
• 尝试新的技术，方法和流程来执行您的工作
• 建议组织中执行业务流程的新方法或新方法
• 分析而不是接受
• 提交解决方案之前先获取并了解信息
• 问更多问题
• 为整个组织而不是单个组织实体做好高质量的工作
• 定义并解决业务问题

虽然已有3年的历史了，但它们仍然适用于当今充满挑战的环境，也完全适用于敏捷开发方法。

最后，我们应该遵循一些原则或准则，结合并结合我们所做工作的一些大规模最佳实践。我认为，我们可以集体地将适用的原则汇总在一起。我将谦虚地提出一些可以采用的原则：

原则1 –专注于产品

业务分析师专注于产品而不是项目

了解什么解决方案对企业有价值

当项目经理专注于项目以确保项目在预算范围内按时完成并交付所需的一切时，业务分析师则专注于要交付的内容以确保真正的问题得到解决，并且可以从中受益。项目完成时的组织。 

原则2 –首先定义问题，然后解决

解读戴维·克罗基特：确保您知道真正的业务问题是什么，然后继续进行。

很多时候，业务分析师认为企业提供给他们的陈述实际上是一个问题，而企业却提供了解决方案。该解决方案可能不是最有效的解决方案。实际上，解决方案甚至可能不正确。当企业抱怨即使您实施了他们的解决方案，他们的问题也没有解决，您可能会因失败而受到指责。提前花费额外的时间来确保您正在处理需要解决的实际问题。 

原则3 –用户没有要求

用户没有要求；利益相关者没有需求–他们只有信息。业务分析师寻求该信息并进行分析，以生成包含需求的解决方案文档。

从仅在业务分析师将需求分析为现实时才存在需求的假设开始，这是解决方案开发的良好起点。采取相反的假设-用户确切地知道他们想要什么以及技术可以解决他们的问题-是长时间开会，持续动荡和变化以及一致解决冲突的秘诀。  

原则4 –关注信息而不是个人

启发的问题在于没有找到合适的人说话。无论来源如何，它都能找到正确的信息。 

太多次要业务分析师被告知要从某些个人那里获得要求。这些人可能不可用，或者可能不知道他们应该是所有答案的存储库。有时候，主题专家不是。对于业务分析师来说，最好的方法是确定业务分析师需要哪些信息，以便业务分析师了解问题并可以创建解决方案，然后才确定该信息位于何处。如果无法访问某些个人，则很可能仍可以通过其他来源获取信息。

原则5 –从分析中分离出启发

在获取信息时，请勿进行分析；分析时，请勿创建信息。

当您在收集信息时进行分析时，响应者会将分析解释为对所提供信息或对自身信息的判断。这阻止了信息流。为了保持信息的畅通，将判断和分析放在交换之外。 
类似地，当您分析信息时，并且添加不是通过启发获得的新信息时，您就对该信息进行了假设。您正在削弱分析结论。将不是基于启发或推断结论的任何假定信息变成需要进一步启发的问题。

原则6 –首先改进流程，然后添加技术

在使用计算机和软件解决业务问题之前，请先评估非IT解决方案。关注业务以及如何使用IT来改善和增强业务现状

不断审查和评估组织的流程和运营，以确定可以在何处进行变更以增加组织价值

作为业务分析师，我们的工作是通过解决业务问题为组织增值。苏珊·罗伯逊（Suzanne Robertson）这样说：“业务分析师的职责是确定人们的需求，以便他们可以改进工作方式，并将这些需求传达给可以实施解决方案的人” [3] 换句话说，确定什么可以使业务更好，然后确定技术解决方案（如果有）。

原则7 –不要让文档代替交流与协作

需求描述了已定义，已理解和已批准的业务问题的解决方案

多年来，在软件开发的需求过程中，重点一直放在生产需求文档上。围绕该文档的创建已组织了整个业务分析师团队。它本身就是一个项目。尽管将解决方案的定义视为一个项目可能是一个好主意，但用文档代替可靠的沟通并不是一个好主意。请记住，文档应记录所有事先发生的通信，而不是通信本身。

原则8 –在获得批准之前获得接受

解决方案的可接受性与批准解决方案不同。有不同的动态在起作用。

当有权批准的人员与需要确认解决方案适用于他们的人员在同一会议上时，会发生各种问题。将确认或验证过程与批准过程分开。得到最终将在现实生活中使用该解决方案的人确认的解决方案定义：“是的，这将解决我们的问题！”并被打算实施该解决方案的人们所接受：“是的，我们可以在项目约束内做到这一点！”在将解决方案传递给需要授权资金或资源来实施解决方案的人员之前。

原则9 –确保商业社区已准备好产品/解决方案 

在业务环境中使用解决方案之前，业务问题无法解决。 

您可以获得最佳的解决方案，诺贝尔奖获得者的解决方案，并且永远不会使用它，因为必须使用它的商人出于任何原因都不使用它。也许他们还没有准备好。也许他们真的很喜欢他们的解决方法。也许他们在最近的过去发生了太多变化，以至于无法吸收这一变化。业务分析师需要领导从当前流程到改进的新流程的过渡。业务分析师不仅需要确保为用户准备好了新的流程和/或系统，而且还需要确保用户已经为新流程和/或系统准备好了。 

原则10 –沟通，合作，合作

保持通讯四通八达

依靠反馈

首先，沟通。没有有趣的讨论或挑衅性的对话，切勿浪费一天的时间。把冲突变成合作。将竞争变成协作。通过暴露新信息来消除不确定性和风险。永远不要成为信息的瓶颈。学习。教导。传播并扩展信息。今天比昨天知道更多

因此，有十项原则可以启动我们的专业原则。我相信您可以考虑将更多内容添加到我们的列表中。

不要忘记在下面留下您的评论。

[1] 勃兰登堡，“业务分析师宣言”， 缩小差距，2009年12月17日

[2] 布莱斯，“业务分析师的权利和授权”， 缩小差距，4/29/1020

[3] 铂尔曼&Archer（ed），《业务分析与领导力：影响变化》，Kogan Page，Ltd，伦敦，2013年