对软件时间估计的分歧
如果客户对软件产品的时间预估与您的不同，您将如何应对？
我将描述一个不是我的场景，但它捕获了大致相同的问题。我是一家拥有编程部门的大公司的分包商。我们正在开发的软件项目属于该部门认为他们掌握的领域，但由于他们的专业知识和我的非常不同，我们往往会得到不同的结果。
示例：在项目开始时，我建议了一种开发方式，他们认为这种方式非常困难，并建议将不同的框架（他们熟悉的框架）与我们正在使用的编程语言（Python ）以获得或多或少相同的结果。
- 他们对这次整合的估计：不到一周（他们之前没有做过整合）。
- 我对整合的估计：两周以上。
- 使用我建议的方法获得所需的结果（包括使用 matplotlib 以及项目内其他地方使用的其他库）：45 分钟。这不是估计，实际上这个部分在 45 分钟内就完成了。
示例：为了将软件与他们的内部系统集成，他们需要提供一个网络服务供我使用。他们提供了一个损坏的工具，尽管它确实可以与他们的内部工具一起使用（不能与 .Net 或 Java 主流包以及其他选项一起使用）。他们坚持认为整合时间比预计的时间长是我的错。
问题不是他们不知道，问题是他们对编程有足够的了解，这很危险（在我看来）。是否有一些指导方针可以指导如何处理此类情况？期望管理的一种方法？或者也许我不应该从一开始就参与此类项目，在这种情况下，有哪些明显的迹象？
How do you deal with a client who has different time estimates for the software product than yours?
I am going to describe a scenario that is not mine, but that captures broadly the same problem. I am working as a subcontractor to a large company that has a programming department. The software project we are working on is in an area that the department believe they have a handle on, but because their expertise and mine are very different we tend to get different results.
Example: At the start of the project I suggested one way of development which they rubbished as being unrealistically difficult and suggested integrating a different framework (one they are familiar with) with the programming language we are using (Python) to get more or less the same result.
- Their estimate for this integration: less than a week (they haven't done the integration before).
- My estimate for the integration: above two weeks.
- Using my suggested way to get the result needed (including using matplotlib among other libraries used elsewhere within the project): 45 minutes. This is not an estimate, the bit was actually finished in 45 minutes.
Example: for the software to be integrated with their internal system, they needed to provide a web service for me to use. They provided a broken one, though it does work with their internal tool (doesn't work with .Net or Java mainstream packages among other options). They maintain that it is my fault that the integration has taken longer than the time estimated.
The problem is not that they don't know, the problem is that they have enough knowledge about programming to be dangerous (in my opinion). Is there some guidelines for how to deal with this type of situation? A way for expectation management? Or may be I shouldn't get involved in such projects from the start and in this case what are the telltale signs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果客户对时间估算不满意，就不要做这项工作。如果他们认为自己可以做得更好或更快，请告诉他们继续。
我从来不允许的一件事就是我的估计被修改。这是我职业生涯早期遇到的问题，但我们吸取了教训。
如果客户如此擅长这项工作，他们就不会雇用我。我只是想指出，他们雇用我是因为我的专业知识，所以为什么他们忽视我的专业知识。当然，如果他们允许项目范围发生变化（即减少工作量），那将是另一回事，需要讨论。
如果您没有准确锁定他们在交易中应提供的内容，那么就会出现“他说，她说”的情况，不幸的是，客户控制着钱包。然而，通常，你能拥有的最大力量就是走开的能力。
没有人说你必须做这项工作。
当然，上面的所有建议都是值得的:-)
我不知道你的具体情况。
If a client isn't happy with a time estimate, don't do the work. If they think they can do it better or faster, tell them to go ahead.
The one thing I never allow is for my estimates to be modified. That's something that caught me out early on in my career but we learn our lessons.
If clients were so good at doing the work, they wouldn't be hiring me. I'd simply point out that they hired me for my expertise so why are they disregarding that expertise. Of course, if they were to allow the scope of the project to change (i.e., less work), that would be another matter, and one up for discussion.
If you didn't lock in exactly what they were meant to provide as part of the deal, then it's a "he says, she says" situation and, unfortunately, the customer controls the purse strings. However, often, the greatest power you can have is the ability to just walk away.
No-one says you have to do the job.
Of course, all that advice above is worth every cent you paid for it :-)
I don't know your specific circumstances.
我的回答是肯定的。如果你可以避免这些项目，那就去做吧。
一些迹象：人们认为他们知道如何做事情，而你可以猜到他们不会。 “哦，不，我们不要使用这个完全合适的工具，因为我不知道”是一个主要指标，表明此人在技术上受到挑战。
My answer for sure. If you can avoid those projects, do it.
Some signs : people thinking they know how to do things when you can guess they can't. The "oh no let's not use this perfectly suitable tool because I don't know it" is a major indicator that the person is technically challenged.
首先，处于这样的环境中一点乐趣都没有。
所以，如果你喜欢从工作中获得乐趣，并且你不需要因为经济原因而接受这份工作，那么就不要接受这份没有乐趣的工作。
由于在许多情况下这几乎不现实，因此您最终会得到这份工作，并且需要尽最大努力处理这种情况。一种方法是确保有书面记录记录您对该计划的反对和担忧。尽量不要表现得过于消极，而要尽量表现出建设性并提出有效的替代方案。在这里，你需要摸清政治格局，确定“老板”会欣赏你的评论还是受到威胁，并采取相应的行动。
很多时候，管理层正在处理一些您不知道的其他问题。对这一事实保持谨慎，也许可以询问管理团队是否属于这种情况，同样不要居高临下或消极。
最后，如果您有比讨论它们所需的时间更少的替代方案，只需在沙箱中尝试并展示它即可。这对于“证明”你的观点大有帮助。这里要注意的是，您可能会被指责不具有团队合作精神，或者浪费资源，或者不遵循指示。确保通过在自己的时间做这些类型的事情来缓解这种情况，或者在仔细考虑你在这些事情上花费了多长时间以及你的老板对替代方案的既得利益后。
哈
first of all, it is no fun to be in such an environment.
So, if you like to have fun at your job, and you do not need to take this job for extenuating financial reasons, then simply do not take the job that is not fun.
Since that is hardly realistic in many cases, you will end up with the job and need to manage the situation as best you can. One way is to make sure there is a paper trail documenting your objections and concerns with the plan. Try not to be overtly negative, but try to be constructive and present valid alternatives. Here you will need to feel out the political landscape, determine if the 'boss' will be appreciative or threatened by your commentary, and act accordingly.
Many times there are other issues that management is dealing with that you are not aware of. Be cautious of this fact, and maybe ask the management team if this is the case, again without being condescending or negative.
Finally, if you have alternatives that take less time than the meetings it would take to discuss them, just try it in a sandbox, and show it off. This would go a long way to 'proving' your points. Caution here is that you could be accused of not being a team player, or of wasting resources, or not following direction. Make sure this is mitigated by doing these types of things on your own time, or after careful consideration of how long you are spending on these things as well as how vested your boss seems to be on the alternatives.
hth
哇，与我与客户的经历非常相似。我能建议的最好的事情就是保留良好的文档。最终这拯救了我。当谈到指责时，我已经整理好了所有电子邮件和事实，并准备好为自己辩护。
我建议的一件事是将目标和估计分开。我不会改变我的估计，除非它涉及实际删除功能或揭示一些可以使它更容易的东西。告诉他们您将尽一切努力实现目标，并且您关心业务目标。但是，您的估计不会改变。如果它没有任何进展，而且它们只是密集，那么微笑并点头并接受它，如果它是唯一的演出。
我刚刚在我的博客中写到了这个
如何估算错误的方式
Wow very similar to what I was experiencing with a client. The best thing I can suggest is to keep good documentation. In the end that is what saved me. When it came to finger pointing I had all of the emails and facts in order and was prepared to defend my self.
One thing I would suggest is to separate out a target/goal and an estimation. I would not change my estimate unless it involved actually removing features or something is revealed that would make it easier. Tell them you will try to hit the target in anyway you can and you care about the business goal. However, your estimate will not change. If its getting no where and they are just dense then smile and nod and take it if its the only gig around.
Was just writing about this in my blog
How to estimate the WRONG way