业务分析人员在开发过程中的作用

Question

我是一名业务分析师，目前负责一个内部项目的大部分开发工作。我负责需求、规格和整体测试。我与开发商(在岸和离岸)密切合作。

离岸小组编制了所有的报告。1.0版有9个月的开发周期，我有4到5个月的时间来测试所有的报告。通常有来回的方法来实现正确的实现。

2.0版的开发周期(3个月)要短得多。大约3周前，我收到了这些报告的第一个版本，并注意到其中有很多地方不对劲。许多需求都是错误的，查询的性能在5x -6倍的时间比它应该的时间长得可怕。

在岸牵头开发商已经出局，并没有监督离岸开发团队编写这些报告。

管理层知道性能问题，我还告诉他们我正在设法提高性能；他们没有明确同意发送测试查询，但他们也不关心我这样做的事实。我查看了报表中的SQL，并能够大大提高性能(提高了6倍)，这对于这个版本来说是可以接受的。

我将更新后的查询作为指南发送给离岸团队，并告诉他们应该考虑做X而不是Y来提高性能，并修复一些特定的逻辑问题。

然后，我和我的经理们谈了这件事，因为我开发SQL查询感觉不对，但是考虑到我们的时间紧迫，我没有看到其他的方法。我们很快就解决了这个问题，我对此感到满意。

目前情况:在岸管理人员对离岸团队没有对业绩进行编码感到不太高兴。我知道在整个过程中有一些事情我可以做得更好，而且我根本不认为自己是一个程序员。

我的问题是，如果一个在岸项目资源之外工作的离岸团队不能提供一个可接受的发布版本，那么是否应该在最后期限之前清理他们的工作呢？这会在未来造成什么样的问题呢？

最新消息:到目前为止，管理层对海外团队感到不满，但没有以任何方式“训斥”我，所以我不确定我做错了什么，但我认为，他们主要的挫败感是离岸团队未能想出解决方案，而我是这样做的，尤其是因为过去曾出现过这样的绩效问题。我不是在为我的行为辩护，但我想给出背景，以便画面更清晰一些。我接受了大多数人批评我的行为的答案，我同意，在我这个位置上的人不应该这样做。

Answer 1

不，清理他们的工作是不能接受的。

为什么这样做，有很多原因。

1) v2.0的开发周期为原始周期的1/3，报告验证周期从周期的50%缩短到不到30%。

可以收缩开发周期，但是除非报告的数量大大减少，否则验证窗口应该保持比例。由于报告要复杂得多，因此期望在整个开发周期内对报告进行持续的验证并不是不合理的。

2)把事情掌握在自己手中，你打破了指挥链，没有及时将报告中的重大问题通知管理层。这些性能和需求问题代表了满足计划的风险，这是管理团队有权知道的。虽然你认为你知道该做些什么来解决这件事，但你并不确定，因为这不是你的决定。管理层的作用是权衡一条路与另一条路的利弊，并对后果承担责任。你假设了答案，并假设岸上团队正在做的事情是一个更高的优先级，从而使这个过程短路了。据你所知，可能有人有能力解决这个问题，或者可以找到一个不同的解决方案。

3)你也脱离了你的责任范围。通常，在我的书中，这不是一个问题，因为我赞成每个人都在他们可能的地方做出贡献，并提高他们的技能。然而，你最有可能不是最有技巧的人来解决这个问题。通过在不通知其他人的情况下处理这个问题，你拒绝了更快地解决问题的机会。离岸团队一旦接到通知，就有可能迅速解决这些问题。如果他没有去度假，并且知道你在做什么，岸上的领队会对你说什么？

使这一切复杂化的是岸上队和离岸队之间不可战胜的紧张关系。你无意中直接走进了政治问题的马蜂窝。

正确的做法应该是立即将问题通知管理层，然后提供您熟悉SQL并乐于应对挑战的信息。这为解决这一问题提出了另一个选择，但仍允许管理层选择解决问题的最佳方法。

Answer 2

它总是适合修复什么是坏的，并使工作尽可能接近规范，尽可能接近最后期限。

这也是适当的文件，您必须修复的所有东西，以使其发挥作用。重要的是要知道您的离岸资源是否提供符合您的规范的可接受的代码。如果它们不是，则向它们发送规范之间差异的文档(特别是re: performance)，并证明它们交付的不是规范中的内容。这可以被你的经理用来谈判未来的工作，或者限制你为你得到的东西付出的代价。

Answer 3

当许多人参与一项任务时，必须明确界定角色，并制定相应的措施。如果你得到的代码是坏的，你告诉他们它不符合预期的性能标准集。如果没有设定性能标准，那么你可以指出它可以做得更好，但我认为你不应该自己改变它。就我个人而言，如果不先和我讨论我的代码，我不会接受有人修改我的代码。

当涉及到不同的组织时，不能在没有仔细考虑的情况下跨越界限，因为人们(主要是管理者)不喜欢这样做。毕竟，这就是管理者的目的(或者至少部分原因)。

这并不是说让提升的机会消失，而是让管理层决定如果它还没有确定。

离岸团队在你认为可以接受的事情上做一些奇怪的事情是很常见的，因为这些公司有时采取的合同的性质，以及许多其他的原因。