让您的编程/开发团队加快步伐
我最近离开了一家大型大学医院，去了一家小得多的医院，因为工资上涨，而且这对我的职业生涯有促进作用。当然，这两件事通常是令人兴奋的事情和伟大的成就（特别是对于我这个年纪的人来说），但我发现自己每天早上开车上班时都会在心里撅着嘴，这就是原因。我加入的新 t=eam 在编码实践、最新技术（是的，他们仍然使用经典的 .ASP）和软件方面严重落后于时代 - 让我陷入了使用 VS2008、.NET 3.5 和 SQL Server 的倒退时间扭曲中/BIDS 2008 使用古老的 SQL 2000/ VS 6.0 遗迹。
起初，还不错，我认为并非所有公司都立即处于最前沿，只是在等待正确的火花将他们引向变革和改进的方向 - 不 - 我开始建议（以专业和非专业的方式）居高临下的方式）一些新工具以及它们对我们公司和客户端都有什么好处，但他们（就像我所在的团队一样）看着我，就像我是一个外星人一样，并给了我简单的，即使我已经提出了自己的观点，为什么我们还需要那些东西呢？
这让我相信我可能没有以正确的方式处理这个问题，并希望一些更高级的开发人员/工程师能够分享他们年轻时和刚刚起步时的经验。我知道时代已经改变，但我觉得它仍然有用，任何建议将不胜感激！
谢谢大家！
I recently left a large university hospital for a much smaller one because of the pay increase and because it was a career booster. Of course these two things would generally be something to be excited about and a great accomplishment (esp.for someone my age) but I have found myself pouting on the inside as I drive to work every morning, and here is why. The new t=eam I joined is dreadfully behind in the times with coding practices, latest technology (yes they still use classic .ASP), and software - leaving me in a backwards time warp from using VS2008, .NET 3.5, and SQL Server/BIDS 2008 to using ancient SQL 2000/ VS 6.0 relics.
At first, not so bad, I figured not all companies are on the cutting edge right away and are just waiting for that right spark to send them in the direction of change and improvement - nope - I started suggesting (in a professional and non-condescending manner) some new tools and what benefits they'd have for our company on both our side and client side but they (as in the team I am a part of) looked at me like I was an alien and gave me the simple, why would we need that stuff, even after I had made my case.
This has led me to believe that I may not be going about this in the right manner and was hoping some more senior developers/engineers would share their experiences when they were younger and just starting out. I know times have changed but I feel it'd be useful nonetheless and any advice would be much appreciated!
Thanks everyone!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
除非新技术比以前的技术更容易、更有效地解决实际问题，否则采用新技术是没有意义的。 （包括学习曲线。）。
您的大学可能有大量遗留代码，这些代码依赖于那些旧技术。转向后来的可能是一个极其昂贵且令人厌烦的过程，而且很难证明其合理性。
引入新技术的方式要么是架构上的一步改变，就像整个大学决定迁移到SharePoint或其他什么，要么是在一个新项目中，你可以在其中展示新技术的优势，并让现有的开发人员有时间对它们进行一些了解。
所有这一切需要记住的是，大多数人不喜欢改变，而通过改变现有技术，你将会踩到人们的脚趾。
例如，特定系统或技术的专家。
It's pointless adopting new technologies unless they resolve actual problems in a easier and more efficient manner then previous technologies. (Including the learning curve.).
It may be that your university has a huge amount of legacy code, which relies on those old technologies. Moving to later ones can be an extremelly costly and tiresome process which is quite hard to justify.
The way to introduce new technologies would be either at a step change in architecture, like the university as a whole decides to move to SharePoint or whatever, or in a new project, where you can demonstrate the advantages of the new technologies, and let the existing developers have time to get some understanding of them.
Something to bear in mind with all of this, is that most people do not like change, and by changing the existing technology you are going to step on people's toes.
For example, the experts in particular systems or technologies.
首先，要明白，当你是新人时提出重大改变几乎总是一个坏主意。首先，你要通过表现让他们尊重你，然后你提出改变的建议。然后您可能还会了解进行这些更改给企业带来的成本，这就是他们没有进行这些更改的原因。
如果他们告诉您在您去那里之前他们正在使用这些工具，那么您应该接受这是您选择在那里生活和工作一段时间的环境，然后再再次提起该主题。如果他们告诉你，他们想要你是因为你具备他们所缺乏的前进技能，那么你需要交谈的人就是招聘经理，而不是团队。请注意，这不会为您在团队中创建朋友。
我对你的主要建议是你开始阅读一些有关办公室政治的书。在再次尝试之前先建立一些联盟。可能还有其他人也想使用更新的东西。也许 dba 也不喜欢被十年前的技能所束缚。
至于从 SQL Server 2000 到 2008 的更改，您可以指出，2000 将不再受支持，并且当 SQL Server 2010 推出时，不再有直接升级路径。这就是我们最终开始升级到 2008 的原因。最好在此之前进行转换。研究 Microsoft 网站，了解何时发生的具体细节。
First, understand that suggesting major changes when you are new is almost always a bad idea. First you get them to respect you through performance, then you suggest changes. Then you may also understand the cost to the business of making those changes which is why they haven't made them.
IF they told you they were using these tools before you went there, you should accept that this the environment you choose to live in and work there for awhile beofre bringing the subject up again. If they told you that they wanted you because you have the skills they lack to move forward, then the person you need to talk to is the hiring manager not the team. Note that this will not create friends for you on the team.
My main suggestion to you is that you start to do some reading on office politics. Build some alliances before you try this again. Possibly there are other people who also want to work with newer stuff. Maybe the dba doesn't like being stuck with ten-year-old skills either.
As far as changing from SQL Server 2000 to 2008, you can point out that 2000 is no longer going to be supported and that when SQL Server 2010 comes out there is no longer a direct upgrade path. This is what finally got us to start upgrading to 2008. Better to convert before that happens. Research the Microsoft web site for the exact details of what happens when.
坦白说，你运气不好。如果他们认为没有任何学习的必要，他们就永远不会自己去做。你将不得不努力让办公室强制使用新的东西，并且可能找到一种方法来支付他们的一些培训费用。或者说服他们的老板解雇他们。
在许多非技术环境中，人们会墨守成规，继续使用相同的工具，即使这些工具已经过时了。看过一百遍了
You're out of luck, frankly. If they don't see any need to learn, they're never going to do it on their own. You're going to have to work to get the newer stuff mandated in the office, and probably find a way to pay for some training for 'em. Or convince their bosses to fire them.
In a lot of non-tech environments, people settle into their rut, and continue using the same tools, even as they go out of date. Seen it a hundred times.
这里有很多未知的变量，太多了，很难给出建议。我想知道：
如果你负责这个团队，那么就由你来制定议程，让每个人都对新方向感到兴奋，并且可能解雇某人，以向其他人表明你是认真的（最好是抱怨声最大或最响亮的人）拖沓的脚步最为明显）。
如果你只是一个代码猴子，或者如果高层管理人员对现在的工作方式感到满意，那么就开始发送你的简历，因为你无法改变任何事情。下次你接受一份工作时，询问他们所使用的技术的细节。
There are a lot of unknown variables here, so many that it's kind of hard to give advice. I'd like to know:
If you're in charge of this team, then it's up to you to set the agenda, get everyone excited over the new direction, and, possibly, fire someone to show the others you mean business (preferably the one who groans the loudest or drags his feet most obviously).
If you're just a code monkey, or if upper management is just fine with the way things are working now, then start sending your resume out, because you're not in a position to change anything. And next time you take a job, ask for specifics about what technologies they're using.
这种情况经常发生。
在同意加入他们之前，您应该询问他们使用什么工具以及它们如何工作。
我还会指出诸如“如果我发现你编造出来只是为了让我注册，我就不会呆太久。”。
This happens all the time.
You should have asked what tools they use and how they work before agreeing to join them.
I would also point out something like "If I discover you made it up only to get me to sign up, I will not be staying long.".
你会发现人们强烈抵制改变，你应该知道人们为什么拒绝改变并试图改变它。
首先，一般人都是风险规避者（除了一些“早期采用者”例外）。也就是说，人们回避风险，任何改变都是风险。
其次，在你的情况下，人们往往害怕变化会将他们置于何处。这样看：你团队中的开发人员会想“如果我们改用xxx技术，这会对我的职业生涯产生什么影响？这会对我升职甚至被解雇的机会产生什么影响？他们不知道新技术，他们不想过时或失去专家地位或以“旧方式”的任何东西
最后，所有新事物都很难学习和理解，特别是当你已经在旧事物上工作了很长时间时。这需要时间，会让你觉得自己在最老的团队中是个白痴（我的意思是指年纪较大的人），这也会增加你对已经了解技术的年轻人被取代的恐惧
。打算克服解决所有问题所需的阻力。
首先，事情必须循序渐进，一次一个产品，不要试图改变整个公司的整个流程。相反，建议进行一个较小的项目并应用新技术，现在是一个机会和一次测试。如果它没有用，那么我们就不会再使用它，但我们只是尝试一下，那么风险就会很小。
然后安抚民众。确保每个人都感到感激，并且您或公司更信任在该领域的多年经验，而不是对所使用的任何特定技术。倾听人们的声音，尊重他们的意见，让他们觉得你关心他们的想法。当然这不应该是一种行为，你应该真的有这样的感觉。伟大的团队相互信任。
另一方面，应对变化。里程碑需要更广泛，你必须考虑到变化。你必须让团队觉得你明白改变是困难的，而且这是一个漫长的过程。如果新事物比旧事物花费更多时间，那么没有人会受到评判，失败是可以预料的，没有人会因此被解雇。
最后，如果你想要改变，你必须让人们放心，让他们明白改变只是一个测试，如果它有效，那么对每个人都很好，如果没有，那就没关系。当然，公司也需要了解这一点。对于管理者来说，这意味着向他们提供清晰的风险与收益报告，陈述真相并告诉他们为什么必须进行变革。
在与管理层交谈时，请记住，竞争始终存在。你必须不断发展，或者更准确地说，你必须不断发展。即使产品在功能上是相同的，而且看起来很可悲，但从营销的角度来看，说你使用最新的 xxx 技术和最新的 yyy 开发技术是一个很好的钩子。客户并不愚蠢，但他们也不懂计算机，因此他们很容易被模糊的词语所打动，因此竞争可以窃取他们，而无需真正拥有更好的产品，而只是“更新”的产品。
还有一件事：也许您会发现告诉他们“谁动了我的奶酪？”很有用。历史”，围绕变化以及市场如何围绕变化演变。
变化是每个人生活中的一件基本事情，无论是个人生活还是职业生活，都应该始终予以考虑。每当有人说“现在改变风险太大”或“我们无力承担改变”时，你必须认真思考……这幅图景是从长远来看还是我们谈论的只是短期情景？因为如果是后者，那么我们知道就很好，但从长远来看就完蛋了……就像总是向每个人提供贷款来买房子，因为房子总是会增值……或者是吗？ ..
You're gonna find people resist to change strongly and you should know the reasons why people use to reject change in order to try to change it.
Firstly people in general is risk avoider (with some "early adopter" exceptions). That is, people avoid risk and any change is a risk.
Secondly, in your situation, people tend to be afraid of WHERE the change will put them. Look at it like this: a developer on your team will be thinking "if we change to xxx technology, how will that affect my career? How will it affect my chances to get a promotion or even get fired? They don't know the new technology, they don't want to get outdated or lose their position as experts or whatever in the "old ways".
Finally everything new is hard to learn and understand, specially when you've been working in the old thing for a long time. It takes time and makes you feel as if you were an idiot. In oldest teams (and I mean literally in terms of people being older) it also increases the fear for being replaced for someone younger who already know the technology.
If you intend to overcome the resistance you'll need to address all the things.
Firstly the thing will have to be gradual. One step at a time, one product at a time. Don't try to change the full process for the entire company. Instead propose taking a lesser project and apply the new tech to it. Present is as an opportunity and a test. If it isn't useful then we won't use it anymore, but let's just try, then the risk will be minimal.
Then reassure the people. Make sure everyone feels appreciate and that you or the company trust more on the long years of experience in the field that on any given technology used. Listen to the people, respect their opinions and make them feel you care what they think. Of course this shouldn't be an act, you should really feel that way. Great teams trust each other.
On the other hand, handle the change. Milestones need to be wider, you have to account for the change. You have to make the team feel you understand change is difficult and that is a long time process. That no one will be judged if the new thing takes more time than the older one and that failures are to be expected and no one will be fired because of it.
In the end, if you want change you have to reassure people and make them understand the change is just a test, if it works then great for everyone, if it doesn't then it OK. Of course the company needs to understand this as well. For managers this means presenting them with a clear risk vs benefit report, stating truth and telling them WHY the change must be done.
When speaking to management remember also to remember them that competition is always out there. You have to evolve or more correctly be always evolving. Even if the product is the same in terms of functionality and saddest as it may seem, from a marketing point of view, saying you use the latest xxx technology with the lates yyy development technique is a great hook. Clients are not stupid but they aren't computer literates either so they are easily impress with fuzz words so competition can steal them without really having a better product, just a "newer" one.
Just one more thing: Maybe you'll find useful to tell them about the "Who moved my cheese? history" which revolves about the change and how the market evolves around change.
Change is a fundamental thing in everyone life, both personal and professional and should be always took into account. Whenever someone says "change now is too risky" or "we can't afford change" you have to really think it trough... is the picture being seen in the long term or all we talking about a short term scenario? Because if it is the latter, then we'll be fine for know but screwed in the long term ... something like always giving a loan to everyone to buy a house because houses ALWAYS increase their value... or do they?...
仅仅是工具已经过时了吗？或者他们生成的代码是否低于标准？如果是代码，最好的选择是进行小组代码审查。如果只是工具，只需制作文章和/或文档，列出它们缺少的功能以及这些功能如何使团队受益。
Is it just the tools that are out dated? Or is the code they are producing subpar? If it is the code your best bet is group code reviews. If it's just tools, simply produce articles and/or documents that list features they are missing and how those could benefit the group.
如果团队陷入过去，你可能无能为力。一些开发人员要么没有看到更新的技术/方法的好处（在某些情况下他们可能是对的），要么害怕改变。我想说的是，你可以从他们身上学到很多东西——你可以学到很多人际交往、项目管理、政治和其他技能。花一些自己的时间跟上当前的技术，并保持警惕，寻找转向其他事物的机会。现在，学习什么可以。许多开发人员专注于技术，而错过了他们在职业生涯后期真正需要的重要技能。
If the team is stuck in the past there might not be much you can do about it. Some developers either don't see the benefits of newer technology/methods (and in some cases they might be right) or are scared of change. I'd say learn what you can from them - there are lots of interpersonal, project management, political and other skills you can learn. Spend some of your own time keeping up with the current technology and keep your eyes open for a chance to move on to something else. For now, learn what can. Lots of developers focus on the technology and miss out on the important skills that they will really need later on in their careers.
我们所有人都有自己的平台和技术偏见，当一个新人加入团队并想要改变一切以他们的做事方式时，这是破坏性的，团队经常会尝试拒绝这种改变，即使动机是好的。
不幸的是，“您正在使用 Java？糟糕！我们需要立即将所有这些移植到 C#！”类型让人们理所当然地对新人提出的许多新事物表示怀疑。
在提出新流程或技术时，我可能会提出的一个建议是根据他们遇到的或与之相关的实际问题来构建它。技术不是解决方案，而是答案。找到问题，然后也许可以向一个棕色袋子教授该技术，强调能够根据团队的痛点引起共鸣的方面。展示价值并让他们自己解决问题，而不是采用推销方法。
All of us have our platform and technology biases and when a new person joins a team and wants to change everything to their way of doing things it is disruptive and the team will often try to reject the change, even if the motivations are good.
Unfortunately the "You are using Java?? Ick! We need to port all this to C# immediately!" types have made people rightfully skeptical of the new guy suggesting a lot of new things.
One suggestion I might offer when suggesting a new process or technology is to frame it in terms of an actual problem they are having and can relate to. The technology is not the solution it is the answer. Find the problem and then perhaps offer to teach a brown-bag on the technology emphasizing the aspects that will resonate with the team in light of their pain-points. Demonstrate the value and let them come around on their own rather than taking the sales-pitch approach.
你是如何提出你的案子的？专业且不居高临下固然很好，但这只是开始。
当你试图说服某人改变时，强调这对他们有什么好处。弄清楚他们想要什么，并向他们展示新技术如何提供帮助。
管理层希望完成更多工作并节省资金。经理们不会关心想要更新更好的东西。尝试寻找案例和研究来证明购买最新产品可以节省 X% 的金钱和工作。找到或创建对其所需成本的良好估计（不仅在工具方面，而且在培训、双重开发轨道等方面）。请记住，旧的东西会保留下来，你必须有一个计划来解决这个问题。
您的同事需要被告知这对他们有什么好处，并且他们不会因此而受苦。他们在这方面投入了很多。他们知道自己在做什么，也知道代码库。转移到一个新的系统，他们将不知道自己在做什么，不知道代码库，一开始会无能，并且可能担心自己会变得无用。对于普通人来说，这是一个很高的要求，对于某些人（例如距离退休三年的人）来说可能要求过高。
找出他们不喜欢当前系统的地方，并向他们展示新软件如何提供帮助。讨论培训并至少坦率地说明转换的容易程度。如果您可以向他们展示如何在新系统中执行他们通常执行的操作，而不必担心如何利用新功能，那将会有很大帮助。强调他们的知识不仅涉及代码库，还涉及业务及其需求。
并且不要指望丢弃遗留的东西。您只能在启动项目时引入新工具，如果它与遗留系统不兼容，它就无法工作。
当然，这很困难，您最好呆上几年并搬到更现代化的商店。
How did you make your case? Professional and non-condescending is good, but it's just the start.
When you're trying to persuade somebody to change, emphasize what's in it for them. Figure out what they want and show them how the new tech can help.
Management wants more work done and dollars saved. Managers won't care about wanting newer and better stuff. Try to find cases and studies showing that going to the latest stuff saved X% in money and work. Find or create good estimates of what it's going to cost (not only in tools, but in training, dual development tracks, and the like). Remember that the old stuff will stay around, and you have to have a plan to account for that.
Your co-workers need to be told how this is good for them, and that they won't suffer for it. They've got a lot invested in this. They know what they're doing, and they know the code base. Move to a newer system, and they won't know what they're doing, won't know the code base, will be incompetent at first, and may be afraid that they'll become expendable. This is a lot to ask of the average person, and may be too much to ask of some people (like the guy who's three years from retirement).
Find out what they don't like about the current system, and show them how the new software can help. Discuss training and be at least upfront about how easy it will be to convert. If you can show them how to do what they usually do in the new system, without worrying about taking advantage of new features, that will help a lot. Emphasize that their knowledge is not just of the code base, but of the business and its requirements.
And don't expect to dump the legacy stuff. You'll only be able to introduce new tools when starting a project, and if it's incompatible with the legacy systems it simply won't work.
This is difficult, of course, and you might be better off staying a few years and moving to a more modern shop.
正如之前提到的，忘记遗留项目，如果它们运行良好，您将无法说服任何人重写它们。更好的方法可能是等到新项目出现，然后建议使用新工具。争论这些新工具将如何提高效率或其他什么，但不要争论你应该只使用它们，因为它们是新的。对于管理层认为不那么重要的小项目来说，这样做可能更容易。
一旦你启动并运行了一个项目，你就已经成功了一半，并且可以将其作为新技术给管理层带来的优势的一个例子。
无论如何，祝你好运。
As was mentioned before forget the legacy projects if they are running OK you aren't going to be able to persuade anyone to rewrite them. A better way might be to wait until a new project comes in and at that point suggest using new tools. Argue how these newer tools will improve efficiency or whatever but don't argue you should only use them because they are new. It might be easier to do this with a small project that management will see as less important.
Once you have one project up and running you have won half of the battle and can use it as an example of the advantages of new technology to the management.
Good luck anyway.
当新人进来并开始宣讲新工具时——即使是以一种完全合法、积极和有益的方式——通常会营造出一种“你与他们对抗”的氛围。
事情不应该是这样的，但是承认这些令人惊叹的新工具将为他们节省大量工作，就等于隐含地承认他们一直在浪费大量时间。即使他们在个人层面上对此表示同意（除了外部限制，大多数人只是想做好工作！），如果“新人”知道的东西比他们知道的多得多，他们也会对上司的看法保持警惕。他们。
想法：让他们和你一起去参加一些当地的开发者活动。然后，这更像是你们一起发现令人兴奋的新东西，而不是“我的工具比你的更好”的事情。
最重要的是，你需要付出一些努力并完成一些项目，以便在新的工作场所建立信誉。
另外，我一直认为 SQL Server 2000 非常棒。 SQL 2K5 和 2K8 是不错的升级，但 2000 确实是可靠的东西；它们不像在 Access 上运行。
When the new guy comes in and starts preaching -- even in a totally legitimate, positive, and helpful manner -- about new tools, it can often set up a "you versus them" atmosphere.
It shouldn't be that way, but by admitting that these amazing new tools will save them lots of work, it's kind of an implicit admission that they've been wasting lots of time. Even if they're okay with that on a personal level (external constraints aside, most people just want to do good work!) they'll be wary about how it might look to their superiors if "the new guy" knows much more than them.
Idea: get them to go to some local developers events with you. Then it's more like you're discovering exciting new stuff together and less like a "my tools are better than yours" thing.
Above all else, you need to put in some elbow grease and nail some projects so that you build up cred at your new workplace.
Also, I've always thought that SQL Server 2000 is fantastic. SQL 2K5 and 2K8 are nice upgrades, but 2000 is really solid stuff; it's not like they're running on Access.