如何应对对定制开发的恐惧
我正在与现任雇主处理一个问题，这使我认真考虑在其他地方寻找工作。 他们的印象是，应该消除 100% 的定制开发，并用 COTS 产品（例如 SharePoint）取代。 虽然我意识到这不是一个现实的期望，但我发现不可能与持有这些观点的管理层人员争论我的观点。 他们的论点通常涉及与 SharePoint 中已存在的功能类似的内容，该功能涵盖功能 X，因此涉及的风险较小，并且不必针对它进行测试。
举个例子，我们遇到的情况是 SharePoint 列表完全无法满足客户的期望和要求。 然而，将这些数据保存在 SQL 数据库中很容易满足要求。 然而，每当我们的开发团队建议超出 SharePoint 的范围时，管理层都会对每一行代码如何增加项目的复杂性并增加风险感到愤怒。 虽然在某些情况下确实如此，但情况并非总是如此。 然而，他们的论点是，由于 SharePoint 提供了一种存储数据的机制，因此我们应该 100% 地使用它。 不管是否满足客户要求。
我已经到了讨厌上班的地步，因为我经常被迫做一些我知道（100％确定）不正确的事情，而这些事情可以通过定制开发来纠正。 然而，在我工作的地方，这似乎是一个不可能的论点。
你们中有人经历过类似的情况吗？ 如果是这样，您采取了哪些措施来应对这些挑战？
I'm dealing with an issue with my current employer that has seriously made me consider seeking employment elsewhere. They are under the impression that 100% of custom development should be eliminated and replaced with COTS products, such as SharePoint. While I realize that this is not a realistic expectation, I've found it impossible to argue my points with the people in management that share these views. Their argument usually involves something along the lines of a feature already existing in SharePoint that covers feature X, therefore there is less risk involved and testing doesn't have to be done against it.
Case in point, we have a situation where a SharePoint list is completely incapable of meeting customer expectations and requirements. Saving this data in a SQL database, however, would easily satisfy the requirements. Any time our development team suggests going outside of the boundaries of SharePoint, however, management goes up in flames about how every line of code adds to the complexity of the project and increases risk. While this is certainly true in some situations, it's not always the case. Their argument, however, is that since SharePoint provides a mechanism for storing data, that we should use it 100% of the time. Regardless of if it meets customer requirements, or not.
I've gotten to the point that I hate coming to work because I'm constantly forced into doing things that I know (with 100% certainty) are not right and that could be made right by doing custom development. It's simply what seems to be an impossible argument where I work, however.
Have any of you experienced a similar situation? If so, what have you done to work through these challenges?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
你记录下你的担忧并让你的上级知道它们，然后你按照他们的要求去做。 如果不起作用，您有提出问题的文档。 但尽量让事情按照他们的方式进行，这样就不会显得你试图破坏他们的计划。 他们承担了更大的风险，因此他们承担了更大的责任。 尽力让事情按照他们的方式进行，不要再担心了。
You document your concerns and let those above you know them, and then you do as they ask. If it doesn't work, you have documentation that you brought the concerns up. But try to make it work their way, so it doesn't look like you're trying to undermine their plans. They're taking the greater risk, and thus they get the greater responsibility. Try your best to make it work their way, and quit worrying about it.
这可能听起来很糟糕，并且可能不是您想要的答案。 我的办公室里有一个鲜为人知的部门，叫做“臭鼬工厂”。 人们自愿（通常在午休或编译时间）决定编写有助于公司的小程序。 有趣的是，结果并不会给公司带来任何“成本”。
对话通常是这样的：
“我们需要购买这个软件” - 老板
“但是，我们已经有这个东西好几个月了。约翰，那天写的” - 程序员
“？” -Boss
很多时候，开发人员认为决策很糟糕，只是创建一个自动发生的并行流程。 然后，当事情出现问题并且客户感到沮丧时，替代解决方案已经就位。
我有一个自动释放机的例子。 开发人员过去常常创建这些自定义报告。 随着我们的客户增加，开发人员的工作量也随之增加。 问题是“为了让客户获得自定义报告，开发人员必须参与其中。” 因此，当公司正在考虑雇用某人全职做报告或寻找让客户做报告的方法时，我编写了一个自动发布机器，用于查找报告更改并将其直接发布给客户。 我还编写了一个实用程序，允许任何人对报告进行更改，这比开发人员更容易使用。 当老板宣布试图寻找解决方案时，我告诉他，解决方案已经就位，甚至他也可以对报告进行更改并发布它们。 现在，每个人都可以更改报告，通常是管理层和客户支持进行这些更改。 有趣的一面是开发人员不再参与其中。
去做就对了。 如果你无论如何都想戒掉，不妨尝试一下。
This may sound bad and may not be the answer you want. There is a little known division in my office called "The Skunk Works." People, on their own accord (usually during lunch breaks or compile time) decide to write little programs that help the company. The fun things about this is the result doesn't "cost" the company anything.
The conversation usually goes like this:
"We need to buy this software" -Boss
"But, we have had that thing for months. John, wrote that back in the day" -Programmer
"?" -Boss
A lot of times the developers see a decision as being bad and just create a parallel process that happens automatically. Then, when the stuff hits the fan and the customers are frustrated, the alternate solution is ALREADY in place.
I have an example of an auto release machine. Developers used to create these custom reports. As our customers increased, the developer's workload increased. The problem was "In order for the customer to get the custom report developer had to be involved." So, while the company was looking into hiring someone to do reports full time or to find ways to have the customers do them, I wrote an auto release machine that looks for report changes and releases them directly to the customer. I also wrote a utility that allows anybody to make changes to the reports that was easier to use than what the developer has. When the Boss made the announcement of trying to find a solution, I told him that it was already in place and that even he could make changes to reports and get them released. Now, everybody can change reports, usually it is management and customer support who make these changes. The fun side is that developers arn't involved anymore.
Just do it. If you're going to quit anyways, might as well try.
管理层中是否有人拥有 SharePoint 股票？ 这个系统是CEO的弟弟开发的吗？
如果他们对改变如此有弹性，你应该在试图与他们争论之前找出真正的原因。 他们可能会声称增加了复杂性、测试难度等，但如果你可以用一个表明他们立场的论点来反驳每一个论点，恕我直言，被误导，而他们仍然不会讨论，那么你可能会争论错误的一点。
如果他们因为非技术原因而被锁定在技术中，例如有人曾经读到 SharePoint 在任何技术情况下都是终极的（当然，除了 SharePoint 之外，不知道这篇文章在谈论什么 = 好）那么你就不应该费心去争论并节省你的精力。 为了找工作。
Does someone in management own stock in SharePoint? Was the system developed by the CEO's younger brother?
If they are that resilient to change, you should find out the real reason before trying to argue with them. They may claim that there is added complexity, difficulty testing, etc, but if you can counter every argument with one that shows their position, with all due respect, to be misinformed, and they still won't discuss, then you may be arguing the wrong point.
If they are locked into the technology because of a non-technical reason, such as someone once read that SharePoint is the ultimate in any technical situation (and, of course, had no clue what the article was talking about other than SharePoint = good) then you shouldn't bother trying to argue and save your energy. For the job hunt.
向他们证明这一点。 当需求要求一个可以通过多列排序处理 100,000 个项目的列表时，编写一个脚本，将 100,000 个测试项目添加到共享点列表中，并让他们尝试，最好是让请求列表的“客户”观看。 :-)
Prove it to them. When the requirements ask for a list that can handle 100,000 items with a multi-column sort - write a script that adds 100,000 test items into a sharepoint list and let them try it, preferrably with the "customer" requesting the list watching. :-)
如果我是你，我肯定会把我的简历公开。 您当前所经历的经历不仅令人沮丧，而且从长远来看，它确实会损害您的职业发展。 考虑一下。 当您在当前职位上与当前雇主一起苦苦挣扎时，其他开发人员正在采用新技术并扩展他们的经验。
开发人员之间存在意识形态差异，以及公司对开发人员角色的看法存在差异。 如果公开讨论和坦诚无济于事，你也不会因为缺乏努力而受到指责。 对公司的忠诚是一件好事，但这种关系需要是双向的。
可悲的是，人们最终可能会意识到他们的假设是错误的 - 但你不能等待那一天的到来。 有时它永远不会到来。 特别是（不要误会我的意思，我喜欢 SharePoint，当它用于其预期用途时），SharePoint 已成为下一个 Access，因为阅读管理杂志的人们看到了足够多的内容，将其称为“弥赛亚。
I would definitely get my resume out and into the open if I were you. Not only is the experience that you are currently having frustrating, it can really hurt your career development over the long haul. Just think about it. While you are languishing with your current employer in your current position, other developers are adopting new technologies and expanding their experience.
There is such a thing as ideological differences between developers and what a company's idea of a role for a developer is. If open discussion and candor get you nowhere, you will not be faulted for a lack of effort. Loyalty to a company is a good thing, but the relationship needs to be a two-way street.
Sadly, the will eventually probably come to realize that they are wrong in their assumptions - but you can not wait for that day to come. Sometimes it never comes. In particular (and don't get me wrong, I love SharePoint when it is used for what it is intended for), SharePoint is become the next Access, in that people who read management magazines see enough of it thrown around to call it the messiah.
我发现仅靠谈话通常无法“赢得”这些辩论。 许多经理通过阅读面向管理的文章来形成对产品或解决方案的看法。 看看能不能找到一些反面的文章。
如果您可以引用 SharePoint 无法完成的事情的示例，并展示如何通过自定义开发经济有效解决这些问题的示例，那么您就已经成功了。
错误在于试图让这成为一场关于技术的对话，而不是关于效率、成本效益和可维护性的对话——这些是会影响非技术经理考虑替代方案的口号和指标。
如果你能针对其中一些问题整理出一个概念验证，那就更好了，养眼的东西确实有助于在技术团队之外进行销售。
最后，祝你好运：）
I find that there is typically no way of 'winning' these debates through talk alone. Many managers form an opinion of a product or solution through reading management oriented articles. See if you can find some counter-articles.
If you can cite examples of things which SharePoint is incapable of doing, and show examples of how you can cost effectively solve these problems through custom development then you are well on your way.
The mistake is to try and make this a conversation about technology, it's not, its about efficiency, cost effectiveness and maintainability - those are the mantras and metrics which will sway non-technical managers into considering alternatives.
If you can put together a proof of concept for some of these issues so much the better, eye candy really helps to sell outside of technical teams.
Finally, good luck :)
我在目前的工作中也在做同样的事情，没有简单的方法来处理这种情况。 我所能做的就是吞下我的论点，因为它们对我毫无帮助，并按照我的管理层的要求行事。 这当然会违背你的基本程序员本性，即使用最佳解决方案来完成手头的任务，并且可能会在此过程中构建一些很酷的东西，但由于他们是老板，这实际上是你唯一的解决方案。 您可以尝试用证据来定位案例，在这些案例中使用定制解决方案更有意义。 但如果你的老板和我的老板一样，那么在尖叫比赛开始之前就不会走得太远。 唯一的其他解决方案是重新整理简历并找到一份新工作。
I am doing the same thing at my current job, there is no easy way to deal with this kind of situation. All I have been able to do is swallow my arguments, cause they have gotten me no where, and do as required by my management. This off course will go against your basic programmer nature of using the best solution for the task at hand, and maybe getting to build something cool in the process, but since they are the boss it is really your only solution. You could try to site cases, with evidence, where it makes more sense to use custom solutions. But if you boss is anything like mine, it won't get very far before the screaming match begins. The only other solution is dusting off that resume and finding a new job.
从第一天起我就面临着同样的挑战。 管理层自然不愿意向解决方案添加自定义代码。 然而，在大多数情况下，可以向客户解释正确的解决方案将包括一些自定义代码。
请记住，如果您认为可以将自定义代码包含在公共代码库中，那么老板可能会批准这个想法。
I have faced the same kind of challenges right from day one. Management have a natural reluctance to add custom code to the solution. However in most cases it has been posible to explain than the right solution for the customer would include some custom code.
Remember, if you argue that you can include the custom code in the common codebase, then the boss might approve the idea.
我真的感受到你的痛苦。
如果是我，我会利用业余时间收集证明我观点的信息，并以易于理解的方式记录下来。
如果他们只理解金钱，谈论金钱，如果他们只理解恐惧（做“这个”因为他们害怕“那个”），利用恐惧，在“他们的”解决方案中找到对他们来说可怕的事情。
记录每一个新的实施、时间、金钱和出现的问题。 并记录您的解决方案。
他们可能没有在他们的解决方案中看到问题，因为他们专注于“你的”解决方案中没有问题。
I really feel your pain.
If it was me I would use my spare time to collect information that proves my point and document it in a easy to understand way.
If they only understand money, talk money, if they only understand fear (doing "this" because they are scared of "that"), use the fear, finding scary thing for them in "their" solution.
Document every new implementation, the time, money and problem that arises. And document what your solution would be instead.
They probably doesn't see the problem in their solution, because they focus on not having problems in "your" solution.
在我工作过的地方，管理层的做法没有建设性，虽然没有你描述的那么糟糕，但已经够糟糕了。
有几个选择。 一是继续以最佳的“物有所值”选项为客户做需要做的事情。 您可能必须将开发人员聚集在一起作为一个团队才能使这种“公民不服从”发挥作用。
真正让事情变得更激烈的一个更强有力的方法是去找客户（如果是外部客户或者你想保住工作就不要这样做）并列出将要发生的事情项目如果X和Y。这几乎是在讲学校外的故事，虽然会很糟糕，但很有趣。
一个稍微好一点的方法是向上寻找一个可以为你带来麻烦的赞助商。 本质上是在你老板的背后。 这可能会起作用，但它会对你与管理层的关系产生可预测的结果。
最后也是最困难的是找出那些认为任何自定义代码都是不好的人，并与他们进行对话，找出他们的信念从何而来，并通过示例反驳这一观点。 强调对话，因为您必须倾听并理解他们的潜在担忧（这与自定义代码本身无关），并且只有在获得该人的信任后才解决它们。
我无法告诉你哪种做事方式最有效，因为这在很大程度上取决于所涉及的个人。 我所知道的是，你无法改变人，根据我的经验，迄今为止解决问题的最佳方法就是离开并与那些不那么……的人一起工作。
I have worked in a place where management were not constructive in their approach, not quite as bad as you describe, but bad enough.
There are a couple of options. One is to go ahead and do what needs to be done for the client with the best "value for money" option you can. You will probably have to get the developers together as a team to make this "civil disobedience" work.
A more forceful approach that will really make the shit hit the fan is to go to the client (don't do this if it is an external client or if you wish to keep your job) and lay out what is going to happen to this project if X and Y. This is pretty much telling tales out of school and is going to be bad, but entertaining.
A slightly better way is to go up the chain and get a sponsor who can make shit happen for you. Essentially go behind your boss(es) back. This may work, but it is going to have predictable results for your relationship with your management.
Last and hardest is to identify the person who holds the view that any custom code is bad and engage them in conversation to find out where they got the belief and counter that with examples. Emphasis on conversation as you will have to listen to and understand their underlying concerns (which won't be about custom code per se) and only address them after you gain that persons trust.
I cannot tell you which way of doing things is going to work best because it depends so much on the individuals involved. All I do know is that you cannot change people and in my experience the best way to solve the problem so far has been to leave and work with people who are not so...
不调用它自定义代码怎么样？ 相反，如果您将其称为“预期的 SharePoint 用户扩展”或其他名称，则可能会减轻围绕特定术语的误解。
此外，正如已经说过的，管理层推动这一议程可能还有其他隐藏的原因。 最好不要太快地再次猜测这些，因为很多都是有效的。
最后，还有很多需要开发的地方。 寻找更好的匹配对象并没有什么坏处。
祝你好运。
how about not calling it custom code. If instead you call it 'anticipated SharePoint user extensions' or something it may soften the misconception surrounding a specific term.
also, as has been said, there may be other hidden from you reasons that management is pushing this agenda. It is probably best to not second guess these too quickly, as many would be valid.
Finally, there are alot of places that need development. it doesnt hurt to look for a better match.
good luck.
如果您不认同公司的愿景，并且无法启发他们，那么现在当然是开始寻找的好时机。
您是否指出过，向客户强制提供一个对他们没有帮助、缺少功能或无法使用的“解决方案”存在风险？
也许会提出计划来解决和减轻他们感知到的风险。
If you don't share the vision of the company and if you can't enlighten them then sure, it is a good time to start looking.
Have you pointed out that there is risk in forcing a "solution" on a client that does not help them or is missing functionality or is unusable?
Perhaps come up with plans to address and mitigate their perceived risks.