你如何向销售人员解释编程确实很困难并且需要时间
我经常与销售和营销人员一起工作，他们不知道如何使用 Excel，更不用说从技术角度理解他们的请求范围了。 当然，期望他们这样做是不公平的，但这仍然给我留下了一个问题。
向营销和销售类型展示他们所要求的需要大量复杂编程和一些耐心的东西的最佳方式是什么？
您能分享一下问题和解决方案的例子吗？
您能推荐一下这方面的书籍吗？
谢谢！
I often work with sales and marketing types that cannot figure out how to use Excel, let alone understand the scope of their requests from a technical perspective. Of course, it would not be fair to expect them to, but that still leaves me with a problem.
What is the best way to show marketing and sales types that they have asked for something that requires a lot of complex programming and some patience?
Could you please share examples of problems and solutions?
Could you please recommend books on this subject?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
将问题分解为尽可能多的细分任务。 在每一项旁边提供每项的估计时间（以小时为单位）。
当他们将项目视为一个整体时，它似乎很简单。 然而，当他们看到必须完成的每件事情以及每件事情需要的小时数时，他们就会将其转化为业务人员可以理解的术语。 突然间，他们想要的软件解决方案对他们来说不再是“黑匣子”，他们现在对这个过程有了一些了解。
如果您正在寻找书籍，我建议您软件估算 - 揭秘黑魔法。
Break the problem up into as many sub-divided tasks as possible. Provide a per-item estimate in hours beside each one.
When they think of a project as a whole, it seems simple. However, when they see each individual thing that must be done and the number of hours each item will require, it is putting it into terms business people can understand. Suddenly the software solution they want isn't a "black box" to them anymore and they now have some insight into the process.
If you are looking for books I would suggest Software Estimation - Demystifying the Black Art.
计算机会按照你的指令去做，而不是你想让它做的事情。
任何形式的抽象都需要转化为精确的细节。
来源 http://c2.com/cgi/wiki?TeachMeToSmoke
...等等。 你可以玩很长时间的游戏。 即使您了解领域，也很难给出明确的指示。 编程将持续很长一段时间。 ——罗恩·杰弗里斯
The computer will do what you told it to do, not what you want it to do.
Any form of abstractions needed be translated to exact details.
source http://c2.com/cgi/wiki?TeachMeToSmoke
... and so on. You can play the game for a long time. It's hard to give clear instructions, even when you know the domain. Programming will endure for a long long time. -- RonJeffries
我有一个朋友可以在几秒钟内完成魔方。
这让我想到了向我的经理解释为什么我们最新的项目失败了！
Olivier 在观察大约 5 秒后，平均需要 10 秒才能将 3x3 魔方的所有颜色完全分类。
如果你让他估计一下排序需要多长时间，你给他立方体，启动时钟，5秒后他会说：
“好吧，一旦我开始，我将在10秒内完成”
你微笑着说：“开始吧！
3秒后你让他停下来..给他另一个魔方并说..对这个进行排序...
在他开始第二个魔方后4秒，你认为他需要多长时间才能再次对第一个魔方进行排序？
如果您回答的时间约为 7 秒，那么恭喜您：您是高层管理人才！
（奥利维尔有权强迫你吃方块）
I had a friend who could do the Rubik's Cube in seconds.
That made me think of this way of explaining to my manager why did our latest project FAIL!
Olivier takes an average of 10 seconds to completely sort all colors of a 3x3 Rubik's Cube after looking at it for approximately 5 seconds.
If you ask him to make an estimate of how long it will take to sort it, you give him the cube, start the clock and after 5 seconds he will say:
"OK, as soon as I start I will be done in 10 seconds"
you smile and say: "Start!"
After 3 seconds you ask him to stop.. give him another Rubik's cube and say.. sort this one instead...
4 seconds after he starts the second Rubik's cube, how long do you think he will take to sort the first one again?
If you answered 7 seconds approximately, congratulations: You're upper management material!
(and Olivier would be rightly entitled to force you to eat the cubes)
我同意 Simucal 的观点，即当你将问题分解为几个小时而不是分解为编程任务时，管理者往往会做得更好。 例如，对你的老板说：“这大约需要两个小时才能完成，但我还有一些其他事情需要先完成，所以我应该在明天之前把它交给你。” 比说“好吧，首先我必须设计一个接口来在对象之间进行通信，然后创建类来实现该接口，等等”有用得多。 管理者了解他们所看到的内容，因此只要您能够根据最终用户的影响来解释您的任务，您就可能会取得更大的成功。
话虽如此，不要让你的经理恐吓你做出你无法兑现的承诺。 你可能知道他们想听到的只是“我会在今天结束之前得到它。”，但如果你知道它无法完成，请不要说它可以，希望如果你拥有它在接下来的几天里的某个时候，他们会说这将“足够接近”。 如果您开始及时考虑设计和测试的时间因素并给予他们适当的估计，最终他们将开始了解完成某些类型的任务需要多长时间，并且不再期望在昨天之前完成所有事情。
我还注意到，一路走来的切实成果往往会让他们的神经放松（至少暂时如此）。 当我的老板开始担心任务能否按时完成时，他开始要求完成结果。 然而，当他能够“看到”一步一步的进展时，他就更有可能理解我们实际上正在取得进展，即使它还没有出现在成品中。
另外，当你开始这个过程时，尝试从他们的角度看问题，并理解，直到你可以花费你认为必要的时间，你可能必须找到一个折衷的办法。 根据我的经验，我需要开发一个 Cache 对象，虽然我希望花几周的时间来设计和实现一个可以广泛分布在多个应用程序中的可配置和可扩展的 Cache，但我不得不限制自己手头的任务。 只要确保如果您决定缩减规模或继续实施短视的设计，请确保它有详细的文档记录，以便您可以在有时间时返回并修复它（或者其他开发人员可以接手该设计）你无法完成的思路）。 另外，不要牺牲良好的编码标准和风格，因为这也将使您的代码在将来更容易维护和正确更新。
祝你好运！
I agree with Simucal in the sense that managers tend to do better when you break a problem into hours, rather than into programming tasks. For example, saying to your boss, "That should take about two hours to complete, but I have a few other things that I have to complete first, so I should have it to you by tomorrow." is a lot more useful than saying, "Well, first I have to design an interface to communicate between objects, and then create the classes to implement the interface, and so on." Managers understand what they can see, so anytime you can explain your task in terms of end-user effects, you will likely have more success.
With that said, don't let your manager intimidate you into making promises that you can't keep. You may know that all they want to hear is "I'll have it by the end of the day.", but if you know it can't be done, don't say that it can, hoping that if you have it to them sometime in the next couple days, that it will be "close enough". If you start factoring in time for designing and testing and give them appropriate estimates, eventually they will start to understand how long it takes to accomplish certain types of tasks, and stop expecting everything to be done by yesterday.
I've also noticed that tangible results along the way tend to put their nerves at rest (temporarily, at least). My boss starts demanding finished results when he starts to panic as to whether or not a task will be completed on time. However, when he is able to "see" the step-by-step progression, then he is more likely to understand that we are, in fact, making progress, even though it isn't in the finished product yet.
Also, as you start this process, try to look at things from their point of view, and understand that until you get to a point where you can spend the amount of time you think is necessary, you may have to find a happy medium. There came a point in my experience where I needed to develop a Cache object, and while I would have loved to take several weeks to design and implement a configurable and extensible Cache that could be widely distributed across multiple applications, I had to limit myself to the task at hand. Just make sure that if you decide to scale back or follow through with a short-sighted design, be sure that it is well-documented so you can go back and fix it when you have time (or so another developer can pick up on the train of thought that you were unable to finish). Also, don't sacrifice good coding standards and style, as this will also make your code easier to maintain and update properly in the future.
Good luck!
对于非程序员来说，这可能是一本好书，可以帮助他们了解失控需求的一些问题和陷阱：
代码梦想：两打程序员，三年，4,732 个错误，一次对卓越软件的追求
This one may be a good book for non-programmers to understand some of these issues and pitfalls of runaway requirements:
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
严肃地说，我认为最好的做法是实际告诉他们，有些事情很复杂，确实需要复杂的问题解决、分析和设计。 他们所做的事情和程序员所做的事情之间存在差距，不幸的是他们永远无法理解完整的含义。 有时你只需要坚定地解释这可能需要很多时间。
也许将任务分解为子任务并给出估计可能会有所帮助。
In all seriousness, I think the best thing it to actually tell them that some things are complex and do require complex problem solving, analysis and design. There is a gap between what they do, and what the programmer does and its unfortunate that they will never understand the full implications. You sometimes just have to be firm and explain that it can take alot of time.
Perhaps a breakdown of the task into subtasks and giving them estimates may help.
确保您也了解他们的问题。 人们通常会提出解决方案（“我们需要这个功能”），而不是从根本业务需求开始。 您对问题了解得越多，您就越有可能提出折衷方案。
有时我被告知某个大型功能是绝对必要的，但我已经能够部署更简单的解决方案来基本上解决问题。 有时，这些临时解决方案已经发展成为重要的功能，就像我经常在两个版本后删除它们而没有人注意到一样。
Make sure you understand their issues too. People will often bring solutions to the table ("we need this feature") rather than start with root business needs. The more you understand the problem the more likely you are to be able to suggest a compromise.
On occassion I've been told a certain large feature is absolutely essential, but I've been able to deploy much simpler solutions that substantially addresses the problem. Sometimes these interim solutions have grown into vital features, just as often I've been able to remove them two releases later without anybody noticing.
根据我的经验，每当我过去开始向销售人员解释为什么一项任务需要一定的时间时，他们很快就会承认他们并不是真的想了解技术细节，我对此很满意。 我通常也不希望他们向我解释为什么他们在 n 天后仍然没有敲定那笔大买卖。 为了有效地开展工作，每个人都有自己的责任范围。
只需确保您与提供估算的销售人员关系良好，并且他们相信您有能力进行正确合理的估算并完成工作。 恕我直言，不需要对每个细节进行解释和推理，但如果有的话，我会说真正的问题在于其他地方。
我完全同意上面的“视情况而定”。
In my experience, whenever I started to explain to sales people in the past why a task takes a certain amount of time, they quickly admit that they do not really want to know the technical details, and I am fine with that. I usually do not want them to explain to me why they still have not nailed down that big sale after n days either. To do work effectively, everybody has his own area of responsibility.
Just make sure that your relationship with the sales people that you provide estimates for is good and they trust in your ability to do proper and reasonable estimations and get the work done. IMHO there should be no need to explain and reason an estimation in every detail, but if there is, I would say the real problem lies elsewhere.
And I wholeheartedly agree with "It depends" above.