我经常与无法弄清楚如何使用 Excel 的销售和营销类型一起工作,更不用说从技术角度了解他们的要求范围了。当然,期望他们这样做是不公平的,但这仍然给我留下了一个问题。
向营销和销售类型展示他们要求的需要大量复杂编程和一些耐心的东西的最佳方式是什么?
您能否分享问题和解决方案的示例?
你能推荐一下这方面的书吗?
谢谢!
我经常与无法弄清楚如何使用 Excel 的销售和营销类型一起工作,更不用说从技术角度了解他们的要求范围了。当然,期望他们这样做是不公平的,但这仍然给我留下了一个问题。
向营销和销售类型展示他们要求的需要大量复杂编程和一些耐心的东西的最佳方式是什么?
您能否分享问题和解决方案的示例?
你能推荐一下这方面的书吗?
谢谢!
将问题分解为尽可能多的细分任务。在每项旁边提供以小时为单位的每项估算。
当他们将项目视为一个整体时,似乎很简单。然而,当他们看到必须完成的每件单独的事情以及每件事情需要的小时数时,这就是将其转化为业务人员可以理解的术语。突然间,他们想要的软件解决方案对他们来说不再是一个“黑匣子”,他们现在对这个过程有了一些了解。
如果您正在寻找书籍,我建议您使用Software Estimation - Demystifying the Black Art。
计算机将按照您的要求执行操作,而不是您希望它执行的操作。
任何形式的抽象都需要被翻译成精确的细节。
来源http://c2.com/cgi/wiki?TeachMeToSmoke
Teacher: "It's hard to express ourselves clearly. You're a smoker, right?
Are you pretty good at it? [Student nods.]
Let's pretend I'm a man from Mars and you are going to teach me to smoke.
Do you have a fresh pack? Let's start with that.
[Takes pack.] OK, now tell me what to do."
Student: "Tear open the pack."
T: [Tears pack to shreds. Cigarettes fly everywhere.]
S: "No, no, tear off the top of the pack!"
T: "OK, sorry, do you have another pack? No? OK, let's just start with this cigarette. [Picks one up.]
S: "Put it in your mouth."
T: [Puts whole cigarette in mouth.]
S: "No, no, just put the end in your mouth!"
T: "Sorry." [Tears filter off, puts whole filter in mouth.]
S: "No, no, don't tear the cigarette, just hold it between your lips!"
T: "Oh, sorry, give me another one." [Places new cig sideways between lips.]
... 等等。你可以玩很长时间的游戏。即使您知道域,也很难给出明确的指示。编程将持续很长时间。——罗恩杰弗里斯
我有一个朋友可以在几秒钟内完成魔方。
这让我想到了用这种方式向我的经理解释为什么我们的最新项目失败了!
Olivier 在查看 3x3 魔方大约 5 秒后,平均需要 10 秒才能完全分类所有颜色。
如果你让他估计排序需要多长时间,你给他立方体,启动时钟,5秒后他会说:
“好的,只要我开始,我将在 10 秒内完成”
你笑着说:“开始!” 3 秒后,你让他停下来……再给他一个魔方,然后说……排序这个……
在他开始第二个魔方 4 秒后,你认为他需要多长时间才能再次对第一个魔方进行排序?
如果你答对了大约 7 秒,恭喜你:你是高层管理人员!
(奥利维尔有权强迫你吃方块)
我同意 Simucal 的观点,即当您将问题分解为几个小时而不是编程任务时,经理往往会做得更好。例如,对你的老板说:“这应该需要大约两个小时才能完成,但我还有一些其他事情必须先完成,所以我应该在明天之前把它交给你。” 比说“嗯,首先我必须设计一个接口来在对象之间进行通信,然后创建类来实现接口等等”有用得多。经理们了解他们能看到的东西,所以只要你能根据最终用户的影响来解释你的任务,你就可能会取得更大的成功。
话虽如此,不要让你的经理恐吓你做出你无法兑现的承诺。你可能知道他们想要听到的只是“我会在一天结束时得到它。”但如果你知道它做不到,不要说它可以,希望如果你有它对他们来说,在接下来的几天里,它将“足够接近”。如果您开始考虑设计和测试的时间并给他们适当的估计,最终他们将开始了解完成某些类型的任务需要多长时间,并且不再期望在昨天完成所有事情。
我还注意到,一路走来的切实成果往往会让他们的神经放松(至少暂时)。当我的老板开始对一项任务是否能按时完成感到恐慌时,他就开始要求完成结果。然而,当他能够“看到”一步一步的进展时,他更有可能理解我们实际上正在取得进展,即使它还没有进入成品。
此外,当您开始此过程时,请尝试从他们的角度看待事物,并了解在您可以花费您认为必要的时间之前,您可能必须找到一个快乐的媒介。在我的经验中,我需要开发一个 Cache 对象,虽然我很想花几周的时间来设计和实现一个可以广泛分布在多个应用程序中的可配置和可扩展的 Cache,但我不得不限制自己手头的任务。只要确保如果您决定缩减规模或继续使用短视的设计,请确保它有充分的文档记录,以便您可以在有时间时返回并修复它(或者其他开发人员可以接手你无法完成的思路)。另外,不要牺牲良好的编码标准和风格,
祝你好运!
对于非程序员来说,这本书可能是一本好书,可以了解其中一些问题和失控需求的陷阱:
说真的,我认为最好的办法就是告诉他们有些事情很复杂,而且确实需要复杂的问题解决、分析和设计。他们所做的事情与程序员所做的事情之间存在差距,不幸的是他们永远不会理解全部含义。有时你只需要坚定并解释这可能需要很多时间。
也许将任务分解为子任务并给它们估计可能会有所帮助。
确保您也了解他们的问题。人们通常会提出解决方案(“我们需要这个功能”),而不是从根本的业务需求开始。您对问题了解得越多,就越有可能提出妥协建议。
有时有人告诉我,某个大型功能是绝对必要的,但我已经能够部署更简单的解决方案,从而基本上解决了这个问题。有时这些临时解决方案已经发展成为重要的功能,就像我经常能够在两个版本之后删除它们而没有任何人注意到一样。
以我的经验,过去每当我开始向销售人员解释为什么一项任务需要一定的时间时,他们很快就会承认他们并不真的想知道技术细节,我对此很好。我通常不希望他们向我解释为什么他们在 n 天后仍然没有敲定那笔大买卖。为了有效地工作,每个人都有自己的职责范围。只需确保您与您为其提供估算的销售人员的关系良好,并且他们相信您有能力进行正确和合理的估算并完成工作。恕我直言,没有必要对每个细节进行解释和推理,但如果有的话,我会说真正的问题出在其他地方。
我完全同意上面的“这取决于”。