如何处理非面向过程的组织？

Question

从3个月以来，我一直在一个机构工作，担任自动化工程师。有时候我对我的工作很满意，这里我的职责是分析端到端的产品特性，自动化它们，帮助同事解决问题。一切都很好，他们无疑对我的表现很满意。

但是这里的手工测试过程并不好。这是一个启动组织，我们也在使用JIRA跟踪敏捷(在某些地方缺少完整的流程)。负责所有项目相关事项并与公司所有者协调的人员并非来自技术背景。他的想法就像我们可以像机器一样工作，他不想让所有的团队都使用JIRA (按他自己的说法)，并且希望以临时的方式工作，一切都很匆忙。

因此，有时，我也需要看一些手动测试(7-8小时在一周内)。这个过程和气氛有时会让我很恼火，甚至大多数同事都是在同一问题上。

那么，有人能建议，在这种情况下，一个人是如何处理的呢？显然，只有我不能建立或改变这个过程。但能接近一些高级技术人员吗？还是我专注于我的工作，提供他们对我的期望，而不涉及高层管理的事情？

Answer 1

根据我的经验，这种紧张关系在我工作的每一个组织中都是相当典型的。我的建议是：

• 批评往往不受欢迎，所以我更多地关注改进建议。
• 考虑与有关的人1:1，以便更详细地讨论你的问题。
• 使用类似石油变化，投资，植物，花园的类比，指的是时间和资源的投资以保持质量。
• 在你的组织中找出正确的平衡，这样你既能完成工作，又能为变革提供建议。
• 在敏捷领域阅读很多领导力风格的书籍，这样你就可以提出更好的论据，并参考其他人见过的更真实的例子。
• 通过让自动化成为频繁的话题来展示你对自动化的热情.而不让人讨厌。这很难。

主要考虑的是“如何才能更好地倡导更高的质量、更好的流程和更多的自动化”，而不是“我如何处理这个人的问题”。

Answer 2

有一个叫做技术债务的概念。这意味着，如果你现在“节省”精力，你就得在以后支付利息。

技术债务并不全是坏账。尤其是对于一家初创公司。如果你现在需要时间去市场，或者如果有一个大型的交易会，或者你只是被资本化了半年，那么花上几个星期甚至几个月的时间来构建一个完美的软件项目来获得真正的效率是不值得的。

应该由管理层来打那个电话。但是技术人员必须向他们解释发生了什么。

“我有这个测试用例。手动运行需要一个小时。自动化需要两个工作日。这意味着，从现在起，自动化将为自己支付十几个版本的费用。所以告诉我，我们现在是要自动化它，还是以后再自动化，还是永远不会？”

Answer 3

Go Agile.Take小步.

我建议，在这个时候，完全专注于手工测试和“测试过程”。

采取小步骤，小流程改进，将其有形的利益出售给利益相关者。

与其简单地说“过程是好的”，不如证明它。