说服公司将新技术和工艺添加到其标准体系中?

发布于 2024-07-09 21:47:50 字数 172 浏览 5 评论 0原文

我在一个严重依赖技术标准的组织中工作。 在过去,这非常棒,有助于为开发人员提供指导,并帮助他们真正轻松地跨团队移动。

然而,在过去的一年中,我发现了使用新技术做事的更有效方法,并且我正在努力将这些策略添加到技术路线图中。

有人有过这样的经历吗?如果有的话,他们做了什么来给组织带来变革?

I work in an organization that relies heavily on technology standards. For the most past this is great and helps provide direction to developers and helps them move across teams really easily.

However in the past year I have discovered more effective ways of doing things using new technologies and I am struggling to get these strategies added to the technology road map.

Has anyone had this experience and if so what have they done to bring about change in the organization?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

锦爱 2024-07-16 21:47:50

获得许可后,提出使用新技术开展一个小型项目。 展示它的价值和它的作用。

With permission, offer to do a small project using the new technologies. Demonstrate its value and that it works.

妥活 2024-07-16 21:47:50

我认为我所在的商店相当落后和陈旧。 我们仍在使用 CVS(!),Perl 本周才从 5.6 升级到 5.8,今年我们才从 4 升级到 PHP 5。 如果你取得了任何成功,请告诉我:)但是根据经验,我可以告诉你,有时阻碍新技术采用的一个重要因素并不是不知道或不承认该技术的好处和优越性,而是相反,管理层想要处理更紧迫的优先事项。

如果团队、部门或公司正在使用当前使用的技术,甚至做得相对较好,那么改变甚至测试新的技术可能还没有足够的理由。

您可能会考虑我正在做的事情是记录您认为较差的技术所遇到的实际的、有形的问题。 例如,就我而言,我会记录 CVS 给团队任何成员带来问题或挫败感的次数,特别是当我的首选解决方案 (git) 可以节省团队时间,或者使 CVS 提供快速解决方案成为可能时不允许。 在某些时候,收集到的证据可能足以支持转向新技术的决定。

I'm in what I think is quite a backward and archaic shop. We're still using CVS (!), Perl was only upgraded from 5.6 to 5.8 this week, and we came on board PHP 5 from 4 only this year. If you get any success, let me know :) but based on experience, I can tell you that sometimes a big factor that impedes adoption of new technologies is not so much that the benefits and superiority of the technology is not known or acknowledged, but rather that there are more pressing priorities that management wants to get to.

If the team, department or company is getting by with currently used technologies, or even doing relatively well with them, then changing to or even test driving new stuff may not have sufficient justification yet.

Something I'm doing which you might consider is keeping a log of actual, tangible problems encountered with the technologies you consider inferior. For example, in my case, I am keeping a log of the times when CVS gives any member of the team problems or frustration, especially when my preferred solution (git) would have saved the team time, or made possible a quick solution that CVS doesn't allow. At some point, the amassed evidence might weigh heavily enough to support a decision to change to the new technology.

街角卖回忆 2024-07-16 21:47:50

我在一家小机构工作,很幸运能够直接接触到我的老板。 当我找到更好的方法来完成我的工作时,我只是确保让他知道在工作周期的早期有选择。 随着时间的推移,我们已经建立了一定程度的信任,每次我提出新方法时,阻力都会越来越少。

我还确保准确记录使用新技术节省了多少时间/金钱。 这无疑是发展公司流程的最引人注目的方式。 精算师喜欢指标!

I work in a small agency and I'm lucky enough to have direct access to my boss. When I find better ways to do my job I just make sure to let him know that there are options early in the job cycle. Over time we've built a level of trust and every time I suggest a new approach there is less and less resistance.

I also make sure to document exactly how much time/money was saved using the new technology. This is easily the most compelling way to evolve your company's process. Bean counters love metrics!

捶死心动 2024-07-16 21:47:50

如果你所做的事情最终得到了除了你自己之外的一群人的支持,你就需要遵守标准。 您能想象在没有标准的情况下开发开源软件吗?

If what you make ends up being supported by a group of people other than yourself you need to live with Standards. Can you imagine open source being developed without standards?

夏の忆 2024-07-16 21:47:50

如果您向适当的决策者清楚、合理地阐述您的观点,您的提案很有可能被接受。

一些提示:

  • 阐明标准变更的价值。 确保您以商业价值来表达这一点,而不仅仅是您自己的个人偏好或便利。
  • 确保您能够证明变革的成本和风险与收益相比很小。 如果你能量化这些,它会有很大帮助。

示例:

  • 对最新版本的 Java 进行标准化意味着我们不必继续以每年 £YYm 的成本维护 XX 旧代码分支。
  • 采用云基础设施技术 YY 将把配置新服务器的时间从 7 天减少到 1 天,这将使我们能够向客户收取六天的额外收入。 风险很低,因为我们已经在 A 组成功试用了这项技术。

If you make your case clearly and rationally to the appropriate decision maker(s), you stand a good chance of your proposal being accepted.

Some tips:

  • Articulate the value of the change in standards. Make sure you express this in terms of business value, not just your own personal preference or convenience.
  • Make sure you can demonstrate that the costs and risks of the change are small in comparison to the benefits. It helps massively if you can quantify these.

Examples:

  • Standardising on the latest version of Java will mean we do not have to continue to maintain XX old code branches at the cost of £YYm per year.
  • Adopting cloud infrastructure technology YY will reduce the time to provision new servers from 7 days to 1 day, which will enable us to bill customers for six days extra revenue. The risk is low because we have already trialled this technology successfully in Team A.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文