当同事们忽略这个过程时该如何站起来？

14

我面临的问题：

我的团队成员在没有准备好功能/技术文档的情况下就开始进行项目工作-即使我们公司的流程要求这些内容在开始之前也应存在。
我的团队成员接受便宜的，非结构化的解决方案，并且会在软件中实施真正的恶意入侵，而在项目管理人员指出他们“时间有限”时不会三思而后行。
我的团队成员开始进行与另一个团队的未完成项目一起工作的项目，该项目尚未经过测试和未完成。（造成大量额外工作）。
软件的改进和整个阶段没有得到适当的计划，当后端开发人员必须开始工作时，通常会导致前端/设计没有完成。

自从我在这里开始工作以来，这些问题已被无休止地讨论了多次。每个人都同意，最重要的是我们必须执行该流程，这意味着后端开发人员只有在处理完所有事情后才能开始。

这些问题一直在发生-直到我对工作本身和我的一些同事感到非常恼火，我才真正变得消极。

我的团队成员抱怨很多-但只能互相抱怨。They keep on going - whatever the situation is。结果？

我变得不安全，也许是我吗？
这就是应该发生的事情吗？

我的问题？How can I say no against work ignoring the process if everyone else seems to mindlessly accept?。

这看起来并不像一些烦人的开发人员那样，他们一直都在寻找东西。

project-management teamwork

— 韦斯利·范·奥普多普（Wesley van Opdorp）
source

质量保证工作是确保遵循该过程的工作。

— mouviciel

我们拥有管理，销售，项目管理和开发团队。缺少质量检查-不幸的是。

— 韦斯利·范·奥普多普

一个过程的作用对于每个人都不是很清楚，因此它没有得到应有的应用。这就是存在质量检查的原因：强制执行流程。在没有负责人强制执行的情况下定义流程就像在没有警察和法官的情况下定义法律。

— mouviciel

当您与他讨论时，您的老板怎么说？

8

大家真的同意吗？

我曾经遇到过一种情况，我们想改进流程。我们提出了一个不同流程的提案，每个人似乎都同意。

但是随后，每次我要遵循此过程时，由于“更重要的事情”而被称为例外，乍一看似乎总是合理的。因此，实际上，这个过程实际上并没有遵循，但是每个人都认为“原则上，我们正在遵循该过程”。

问题是：如果您提出改进建议，那么没有人会不同意（谁不喜欢改进？）。但是，如果您提出费用，通常会有很多分歧。对于大多数人来说，松脱做事的便捷方式是一笔巨大的费用。

为了证明这一点，我用不同的措辞来表述“问题”：“请优先考虑我应该做的所有事情（实现功能，消除错误，遵循改进的流程，清洁办公桌，准时到达）”。

该过程结束于清理桌子，并且迟到5分钟没有蜂鸣。因此，基本上，他们同意与我提议的完全不同的东西。

问题可能是，他们不想为质量付出代价。这可能导致他们理顺你critizism的唠唠叨叨，但以我的经验，它不是。技术债务可能不那么明显，很容易将其归因于环境，但最终会发生现实。

希望在此之前，他们意识到了这一点，或者您选择了乔布斯。

— 开普
source

2

“遵循改进的流程”是唯一不面向目标的选择，因此结果不会出乎意料。在这种情况下，听起来更像是“出于流程考虑而遵循流程”，而不是面向目标的活动（更高的质量，生产率等）。

— MaR 2011年

对于诸如“至少在部署之前进行表面测试”之类的事物而言，“改进的过程”是短期的，这是面向目标的：目标是减少事后清理工作的必要工作，这是不可避免的事情。不是我凭空提出了一个过程并使它成为教条。它来自影响生产率的反复出现的问题。我在这篇文章中所称的“过程”或多或少地遵循了乔尔的2项或3项测试。

— keppla

1

我想指出的是，您如何销售“过程”很重要。我想说的是，“至少在部署之前进行表面测试”比“清洁工作台”要好得多。

— 2011年

@MaR：我同意，我在帖子中忽略了这一方面。在工作中，我并不是说“请遵循流程”，而是说“我们同意，我们必须先进行测试”，以避免再次因服务中断而惹恼客户。我们为什么现在忽略这一点？

— keppla 2011年

3

也许是你

您似乎喜欢一种非常结构化和组织化的编码方式，而您的队友则似乎拥有一种更加“完成任务”的方式。现在，您提到这会导致大量的“浪费时间”，因此也许有些结构井然有序，没有任何草率工作的借口。但是，软件项目往往是不稳定的，强制执行过多的结构也将导致大量组织开销。

也许你们都应该在中间碰面，并尝试一种更加敏捷和互动但结构化的方法。

— 洪德
source

1

如果队友不喜欢他的方法，为什么他们首先同意呢？阅读他的文章，我没有得到任何印象，那仅仅是他的建议。而且，即使没有规范也不能奏效，在我看来，区别不在于缺少规范，而是规范的显式临时特征。

— keppla

首先，不同意某件事与承诺某件事不一样:)也许他的队友没有其他选择。即使该流程是管理层的想法，也可能需要对现实进行一些调整以确保各方的认同。我同意需要制定一些规范，但不幸的是，有时指定某些事物可能与构建它一样困难。敏捷的迭代过程可以使规范随着

— 制定的进行逐步完善

他明确表示，他的团队同意，而不是他们不同意。请不要误会我的意思，不是不反对敏捷流程，但它们也仅是这样：流程至少需要基本的承诺。如果每个人都忽略立案，没有人保留待办事项，那么“规格”只是一种“顺便说一句……”，即使通过敏捷管理者，也仍然会不断失败。而且，根据我的经验，这甚至还没有画出黑色的图画。并非每个公司都是Google。多数人似乎更加密切了迪尔伯特。

— keppla 2011年

2

我同意，他们需要找到每个人都可以接受的流程。Tacid协议一文不值。他们可能需要试验一下，看看有什么对他们有用的，要么就是他的队友根本无能，需要被解雇:)我注意到有关流程的一件事，尽管即使有买进也常常至少需要一个确保过程成为习惯的“过程纳粹”。仅在流程有买入的情况下才有效

— 洪德2011年

...顺便说一句，我不会将google用作流程的良好示例。由于过多的结构开销，它们似乎遭受了严重的工程设计案例。上一次我听说他们正试图恢复他们的创业根源

— 洪德堡2011年

2

谁负责这些人？有人雇用了他们，有人可以解雇他们/追究他们的责任。

没有我的强制，“我的公司要求...”毫无意义。

您不能做出不允许生产过程的时间要求。

似乎缺乏控制和不切实际的期望是质量低劣的原因。

您可以选择：离开，成为首席开发人员，什么都不做，或者开始与感觉自己做事的人一起工作。确保每个人都知道您将遵循正确的程序，直到有人找到更好的方法并进行更改。听起来像“苹果酒之家规则”。

— 杰夫
source

2

听起来您好像不希望您的同事遵循完全不同的过程，而只是希望他们在其中做出不同的决定。当然，有关于应该做什么的规则（准则？），而他们忽略了它们。但是您描述的问题是他们必须做出决定（开始从事项目工作或拒绝规范），然后决定继续前进。如果您不断提醒他们有关规则，该决定将不会改变；他们只是不像您那样在意规则。他们想要感觉有用，并且说不并不会让他们感觉有用。

如果您希望他们的行为发生变化，那么不断提醒他们有关规则可能不是很有效；更有可能导致他们无视您。尝试找到一种方法来更改流程，以使他们在遵循流程的同时感觉更有用。您是否可以实施某种代码审查，检查彼此的代码并相互学习以防止黑客将其用于生产代码？您可以将规范（docs / ext.interfaces / front-end）的处理方式从黑白的完成/未完成决定更改为更合作的过程吗？帮助完成？（而且，您应该接受要求会发生变化）

通常不是您，不是他们，而是过程。如果您（和您的PM）可以找到某种方式来组织事情，而人们并不需要太多地背叛自己的性格，那么该过程将更快地进行。

— 夏普
source

2

这就是我要与团队负责人进行的闭门会议的时间。希望您与潜在客户之间有足够好的工作关系，可以使他们变得非常非正式。

会议的目的是弄清团队为什么以他们的方式做事。如果每个人都聚在一起，点头，微笑并同意新的程序，那么为什么他们仍然没有改变？与简单的无所事事或无能为力相比，它运行得更深入的机会很大。可能有一些工作人员肉眼看不见。

假设您的同事（如果可以）遵循一个可以减少恐慌，减少技术债务并提高产品质量的过程，那么开始会议吧-毕竟，谁不希望这样做？那么什么是看不见的力量？

听起来在设计和UI原型的前期工作之前有很多实现/集成。公司是否缺少可以进行此类前期工作的人员？也许你可以自愿。与利益相关者达成共识是否存在问题？也许您的团队可以找到与他们交流的新方法，或者可以采用新方法来记录假设。

如果您从一对一开始，问您的领导为什么，那么您可以打开一个讨论的门，避免防御并着重于问题和解决方案。

另一个技巧可能是询问您是否可以开创一种新的做事方式。从您的团队领导那里获得支持，可以使问题变得有些棘手，让您采用您所倡导的方法-当您破坏“系统”时，它可能会出现问题，因此您需要管理人员支持。但是，如果您提高工作效率和减轻压力，则可以为改变事情的方式提供很好的理由，并且很可能会赢得拥护者。

— 贝特拉克希米
source