在每个演示之后，经理都会不断更改需求规范。

我的工作环境背景

我的经理对计算机或软件没有任何背景或了解。他很可能一生中都没有看过任何形式的代码（甚至从10英尺或更短的物理距离来看）。

有没有人谁懂什么，我要求执行的复杂性。到这一点，如果我半硬编码，没人会知道。

在Joel的测试中，我们得到了令人难以置信的0分。

问题所在

• 经理和其他“高级”经理有时会不断更改需求规范。如果进行了良好的工程设计而不是修补性的“修复”，则需要进行基础设计的更改。
• 有绝对没有人谁看代码（也许是因为没有人知道如何，或者即使它应该做的），这意味着没有人会能够：
  • 欣赏问题的复杂性或解决方案的精妙之处。
  • 建议改进方法。
  • 赞赏代码的质量。
  • 指出可以改进代码的地方。
• 使用了很多行话，这在语法上是有意义的，但是在任何其他方式上都没有任何意义。
• 不像软件公司那样感觉，表现或工作。

问题

应该做什么？特别是关于没有人指出我的代码有所改进。

更新资料

要回答HLGEM（以及可能的其他问题）有关我为修复该问题所做的工作。我提议成立Redmine并向所有人介绍源代码控制。我说过我会推荐分布式（git或mercurial），但也会讨论集中式的，让团队决定。回应是事情正在做，将在几周内完成。还没有看到，我也不知道公司的其他部门是否在使用它。

简短版本：

跑。

更长的版本：

如果经理不知道如何运行项目，并且如果高层不满意，那么您几乎没有机会解决问题。

为了管理软件项目，经理确实需要了解有关软件的某些知识。如果管理者没有，他们需要首先学习。您有什么机会说服您的管理层和上司他们弄错了一切？您有什么机会教他们一些东西？

我曾经有过类似的情况（只有没有前辈）。经历了可怕的一年，我辞职了，再也没有回头（除非厌恶）。

...继续更改需求规格。如果进行了良好的工程设计而不是修补性的“修复”，则需要进行基础设计的更改。

听起来像现实世界。这无时无刻不在发生。是的，它很烂，但是以某种敏捷的态度是可以忍受的。此外，软件良好性的一种度量是其可延展性。将其视为挑战。

使用了很多行话，这在语法上是有意义的，但是在任何其他方式上都没有任何意义。

再次，听起来并不陌生;-)

没有人能理解我被要求实施的复杂性。

甚至没有你 如果您确实了解这一点，那么镜子里只有一个人知道。因此，您对公司福祉的责任可能比正式头衔要重。如果您确实了解问题，而经理却不了解，那么您有责任向管理层说明问题，以便他们可以正确地指导公司。可以合理地假设离您最近的经理在技​​术上应该胜任（不一定与您一样胜任-当他们是经理时，您是专家-但至少一点点才干），但如果他们显然不行，您可以帮助他们，为什么不呢？

一个简单的逃避现实的解决方案是切换公司。但是，作为另一种选择，请考虑实施Joel测试的项目。尽管从5开始的项目需要与管理层进行更多合作，但从1-4开始的项目使您无需问任何人就可以进行设置。

也就是说，SE的任何人都无法知道您的确切情况。您可能在一家无能为力的混蛋中拥挤的公司，而从这样的混乱中做出好的事情对任何人来说都是太多了。您必须自己评估情况。

您在其中一个评论中说这是您的第一份工作。根据我的经验，除了专门的软件商店外，经理通常都不是技术专家。这是生活的一部分，请习惯一下。

您哭泣和抱怨，因为没有人欣赏您的解决方案的优雅。真正的问题不是没有人欣赏您的解决方案的精美性，而是没有人教您解决方案不如您想像的那么好。几乎所有新程序员都高估了他们的实际技能。没有导师，没有人可以帮助您更好地实践。如果没有人可以指导您，请加入本地用户组，​​积极参与，并在那里找人指导您。更好的是，这将最终帮助您找到更好的工作。

您在Joel测验中得到零分吗？如果您是唯一的编码器（听起来像是您写的那样），那么他们为什么不使用源代码控制？是什么在阻止你？如果您不是唯一的编码员，为什么没有人可以进行代码审查？我们所有的开发人员都进行代码审查，这不是管理功能，尤其是当管理人员是非技术人员时。

需求几乎在所有地方都在变化。业务需求不断变化，非程序员通常无法视觉化程序将要做什么，直到他们吃了东西。然后他们意识到这不是他们所需要的。这就是为什么敏捷之所以真正应运而生的原因，因为较旧的方法无法很好地应对这种变化。

即使管理层不想自己输入数据，也要设置错误跟踪。当有人向您提及新的错误/功能时，负责输入这些错误/功能。告诉经理您想要更改时，您还被分配了27项其他东西，这是非常有帮助的，这是列表，您希望我将优先级列表向下移动以适应此新更改。这将在审核时有所帮助，因为您将能够算出所实现的错误修复和功能的数量。如果每个人都没有使用它，那么至少您可以进行自己的工作。如果他们不允许您安装任何软件，请使用Excel电子表格。采取主动。一旦您可以显示结果，其他人就会更感兴趣。如果您认为一个人的工作量过多，则错误跟踪器将帮助您证明这一点。

不要提供精美的演示！演示应该看起来像是在纸上用钢笔写字。界面看起来越光滑，非技术人员认为它完成的越多。

即使没有人知道您是否不遵循最佳实践和例如Semi_hard代码，您也将知道并且会养成马虎的坏习惯。那将不会为您的下一份工作提供良好的服务。因此，请在这种情况下尽可能以正确的方式进行操作。确保编写测试（只是将其视为开发时间的一部分，并把时间花在您提供的管理估算中，即使您没有明确地说这是估算的一部分），并使用这些测试来确保以后的更改不会破坏其他功能。

您需要将其视为发展和改进的无价机会。您在实际编码中的自由度超过了职业生涯中许多人所拥有的自由度。因此，应将这视为创建成功实施的项目组合的机会。当您确实寻找下一项工作时，能够指出诸如已完成的源代码控制，建立的错误跟踪，创建的X个成功项目实现数量等成就，将使您脱颖而出。

您在这里也有很好的机会来学习如何向上管理期望。这是一种技能，将在您的整个职业生涯中派上用场。您在这里尝试这样做不会有任何损失，事情已经不好了。但是，您可以学习一些政治技巧，这些技巧将在以后帮助您改善生活。学习进行成本效益分析。学会不了解业务领域，以便与他们交谈时可以说服自己。学会谈论对公司的利益和利润。对分配给您的每个任务进行估算，即使它们与管理人员给您的任务不匹配，也要记录您的估算值以及实际用于提高自己的估算能力的估算。一旦您可以证明您的估算在历史上比管理的更为准确，当您告诉他们估计值太低时，他们将更有可能听。但是，您必须首先建立更准确的估计，而且最重要的是交付项目并使它们工作的能力。同样，这是您职业发展中的一项很好的技能。

最重要的是，不要被动，要期待进步。

如果我是你，我会尝试寻找另一份工作。为什么？我想您知道，不幸的是，您的经理是“不好”。但是，您应该尝试与经理一起解决一些问题。

如果您不想离开，和/或不想与任何人交谈，那么您将不得不自己找点东西。如果公司中没有人知道您的代码，那么您的经理应该如何知道您符合要求？只是说。

与您的经理和上级交谈。说明您的问题并提出解决方案。稍微准备一下谈话，以便您知道要传达的一般信息。

谈话后，花点时间。看看情况是否改变。如果他们不这样做，请尝试自己进行更改，并向经理和上司展示更改的积极结果。

如果谈话无济于事，而您的更改被驳回，则您必须自己评估自己喜欢在那个地方工作的程度。是的，工作可能很糟糕，但是也许薪水不错，而且您只有5分钟的通勤时间？您的工作的积极方面胜过消极方面吗？如果他们没有，我会开始寻找新工作。

您的问题是票务系统和版本控制是技术问题，无论非技术经理的输入如何，都应该这样做。从技术上讲，这应该被认为是一种最佳实践，如果他们没有此设置，那么您应该自己动手做到这一点。

您不能期望非技术经理了解缺陷跟踪，源代码控制和持续集成的好处。这就是为什么他们是非技术人员，他们不应该知道或不在乎，他们是领域和业务知识专家。他们唯一应提供的是高层指导和要求。

我也有一个非技术经理，并且能够将Joel Test得分从4提高到8，仅仅是因为我去做了他们，并且没有得到许可。

您的团队需要强大的技术领导者，没有人能站稳脚跟。

请访问http://community.rallydev.com/，他们有一个社区版本，在敏捷项目管理和缺陷跟踪方面做得很好。仅此一项就可以提高您的Joel得分，并且完全不需要花费服务器空间或时间来建立。

如果这是一间小商店，您和其他“高级”基本上是唯一的编码人员，那么实际上可能是您的责任是向经理指示要满足“ Joel Test”的要求。

需求的变化将永远存在，您的工作就是去接受它们，这是敏捷开发的基本原则之一：

即使在开发后期，也欢迎不断变化的需求。敏捷流程利用变更来获得客户的竞争优势。

但是适应不断变化的需求也意味着要遵循其他敏捷原则。在管理级别，这意味着经理必须能够向客户透明地告知所有这些更改都是有成本的：要么必须更改项目的范围以满足截止日期，要么必须更改截止日期（不建议后者）。

如果这是一个项目，而您的经理是提出所有要求的项目，那么您应该表现得像他/她是您的敏捷客户，并向他们解释相同的事情（范围<->截止日期折中）。

但是在小公司的开发人员层面，我要说的是您的责任是确保编码部分符合敏捷建议。

这些是您绝对需要执行的步骤，可能您需要自己执行：

• 您必须具有版本控制系统（需要一天的时间才能为小型团队设置）
• 您必须具有构建脚本以确保您可以经常发布版本（也非常快地进行设置）
• 您必须使用自动化的单元测试（这是一种编码方式，它从根本上决定了您的整个设计，因此可能很难在紧密耦合的项目中间添加它们）
• 您还可以设置一个持续集成系统，以确保自动化的构建和测试以及功能和GUI测试（这很难编写）

请记住，您可以在自己的计算机上本地拥有一个SVN存储库。一个简单的TODO列表可以用作穷人的错误跟踪系统（有点极端，但是嘿）。没有构建脚本没有任何借口。

同样，在对范围/截止期限折衷做出任何声明之前，还需要有人预测某个功能将花费多少时间。这通常是在敏捷世界的“理想日子”中完成的，这意味着您应该尽力预测每个功能的相对工作量，然后使用实际的编码速度来查看预测的效果（并相应地缩放“曲线” ）。

我认为您的团队中缺少责任层次。应该有一个项目经理，系统分析师，业务分析师和开发人员。项目经理角色负责定义和执行客户与项目的沟通策略（以及其他任务）。

管理人员不需要了解代码或复杂性。需要了解，资源，成本和风险。

源代码版本，代码质量，复杂性等由PM负责或由高级开发人员负责。

解决方案是：

1-定义项目团队的结构及其职责

2-如果管理不善导致软件故障，请培训经理-远离技术细节。您可以通过谷歌搜索找到一些示例。

特别是关于没有人指出我的代码有所改进。

您是否可以尝试设置代码审查，以便有人查看代码？是否存在有助于使代码具有某些结构的约定和标准？前提是您当然不是那里唯一的开发人员。

尽管您可能处在一个不太理想的地方，但最终看起来像在工作吗？项目完成了吗，事情正在向前发展？事情做好了吗？ Duct Tape Programmer将是您可能想要阅读的Joel文章。

选项1-告诉他们“随着您对该项目所做的所有更改，当我们部署它时，系统将运行非常缓慢”或“客户将无法解决”。您的经理不关心意大利面条代码，但他们关心客户。根据他们的理解而不是代码编写来向他们提出问题。

选项2-给他们他们想要的东西。当他们抱怨某事时，您说“但这就是您要的”