向非程序员介绍软件项目

Dal*_*ale 31 language-agnostic

很快,我将需要为我的大学的工程学院和一大批工程技术专业的学生介绍我的荣誉项目.虽然所有参加会议的人都具有技术头脑,但并非所有人都是程序员,而且大多数人都来自其他工程学科.

我之前做过演讲,我有信心和一群人说话,但我现在意识到我之前给过的所有演讲都是CS/SE的专业和教学人员.我想知道我的演讲风格是否假设我正在向其他软件爱好者展示,所以他们会知道我在说什么,我可以进行一个涉及观众的更具互动性的演示.

我的荣誉项目并不是非常复杂或理论上的,我有一个原型C#Winforms应用程序,但它的设计是可扩展的,并且将来可以使用不同的数据源(ODBC或WS)进行操作,还有一些关于它如何扩展的研究规则引擎和DSL,并变成了一个可销售的产品.正在测试我的原型的组织通过自动化关键业务功能每年节省数万美元.

我曾计划通过一些实时编码和UML风格的图表来展示它的可扩展性.我非常喜欢做演示和现场编码,但我不知道非程序员是否可以访问这种演示文稿,我担心如果我太过于讨厌和技术性,我可能会疏远观众和评委.

您发现以非程序员感兴趣的方式呈现软件项目的有效技术是什么?

Bob*_*phy 27

当我在攻读博士学位时,教师为研讨会提供了这个规则 - 事实证明它非常有用:

  1. 告诉他们你要告诉他们的是什么.(例如,简要的介绍性问题描述和结果摘要)
  2. 告诉他们.(例如,大部分时间都包含技术细节)
  3. 告诉他们你告诉他们的是什么.(例如摘要和结论)
  4. 打开场地提问.

在你的位置上,我会花大约10-20%的时间以很大程度上非技术性的方式做#1.因此,您可能会描述代码自动化的业务功能,为什么这很重要,应用解决方案之前和之后的情况,以及如何节省资金,这类事情.

然后我开始进行针对CS/SE人群的高度技术性讨论.即使其他人不理解并且他们的眼睛茫然,你的介绍至少会让他们了解它的全部意义,他们可能会在这里或那里认识到一点.

对于第三部分,我简要回顾一下这个问题并描述你是如何用非技术语言解决它的,然后进行实时编码扩展性的真实演示.即使非CS/SE人员不理解这个演示,他们也会看到眼睛盯着糖果,你的专业同事和教师都点头微笑,所以他们会认为这很酷.

我曾经参加过一个人,他因将混沌理论应用于化学系统而获得诺贝尔奖.他采用了这种方法,所以即使像我的有机化学家和我一样的所有非理论家都完全超出了我们的深度,理论家们都兴奋的事实让我们觉得这是一次很棒的研讨会,即使我们没有对他说的话有一定的线索.

  • 这家伙得到了它:"去那里/完成了".但是我需要补充的是,当你第一次出现在一个超过50 - 100或更大的大群体面前时,会有一个精神锁定来自你突然注意到的所有注意力.两个工具可以克服这个问题:1 - 对你所谈论的内容感兴趣+继续关注你必须说的话.2 - 去Tostmasters做一些公开演讲,这正是他们的目的. (4认同)

Rob*_*vey 11

为了吸引观众,我有时会提供技术解释,然后用我的"英文,请"解释.CSI和其他有科学的戏剧一直这样做,效果很好.

换句话说,[在这里插入简单的英文解释].


Kev*_*bet 9

你已经在努力了解你的观众,我认为这很棒,你只需要更进一步,并问自己,如果我是观众中的x人,我会从这个演示文稿中得到什么.

如果你要介绍的小组永远不可能使用你的具体实现,我会质疑技术/编码演示的有效性和努力程度.描绘你如何处理可扩展性可能更为重要,这样你就可以在同行中获得关于未来如何处理它的想法,以及在整个过程中获得的点对所有观众成员都很重要,也许快速演示一点,只是表明,是的,确实它确实有效.

我不了解你,但我个人总是从这些类型的演讲中获得更多的价值,这些演讲基于项目对每个人的吸引力,你如何为这家公司每年节省数万美元,理论上为什么其他公司也可能想要使用它,市场和其他因素是什么,你必须克服的巨大技术冲击是什么,即使这是一个简单的项目,你必须提前考虑的事情要避免并防止你被困在角落里.

我想如果你是一位非常优秀的主持人,并且演讲的目的是广泛而且吸引整个团队,而不是关于混沌理论和化学系统应用的讨论,这有着明确的目的,你应该吸引观众的最低共同点,整个观众可以受到娱乐,欣赏你在整个过程中的每一步所取得的成就,并且要做到这一点,他们不一定要了解所采取的每一步.


elv*_*o79 9

让我们将此作为重构问题进行攻击.

,有没有一种方法可以把你的东西拿出来?

例如,我不认为展示您的演示应用程序可以使用多个数据源是必不可少的,更不用说在演示期间您可以直接编程.我知道在你的应用程序设计中要小心达到这一点,但仍然大多数人对OUTPUTS而不是应用程序的INPUTS更感兴趣.在应用程序的好处中更是如此.

一些指导点:

  • 制作关于它们的演示文稿.如果观众感受到您的节目所解决的痛苦,请提醒他们这种痛苦.如果他们是像你这样的其他研究,那么请他们把自己放在你帮助的组织的鞋子里.

  • 比较旧的方式与新的做事方式.为什么新方法更有效率?它会导致更多的销售吗?它会减少库存吗?还是存钱?有人会失去他/她的工作,因为你的解决方案使他的任务无关紧要.注意:在进行技术演示时,我观察到对于解决以前执行任务的人员所发生的事情非常重要.幸运的是,大多数时候人们不会失去工作,在大多数情况下,由于技术,同样的人可以管理更多的工作.

  • 显示结果.您的演示公司观察到的真实结果是什么?

  • 使用有意义的视觉效果.如果你能制作一些动画来更好地解释你的算法.

  • 开始和结束时说出你的观点.大多数人会忘记中间发生的事情,所以一定要在开头和谈话时告诉最重要的事情.

  • 实践,实践.是的,这听起来很荒谬,但是在镜子或录像前至少录制两次你的整个演示.越多越好.没有排练,不要给出你生命中最重要的一个演示.

呼吸和积极你会做得很好:-D

PS:我的建议来自这个网页.它引导了我好几次: 6个刺激到达旧脑


dev*_*xer 6

首先,我建议您与您的教师顾问讨论他们对您的演讲的期望.如果您有任何关于如何平衡只有CS人员可理解的技术细节与更广泛的观众可以理解的一般概念的问题,我认为从那些评估您的人那里获取意见真的很有帮助.

我真的希望从演示文稿中看到一件事是"带回家的消息".你想让那些观众中的每个人在他们离开房间后很久都要记住这一点是什么?一开始就告诉他们带回家的信息.告诉他们你将花费其余的演示文稿解释他们应该关心的原因以及他们为什么要相信你.即使人们在某些技术问题上迷失方向,如果你至少把这一条信息带回家,那么你已经向很多人提供了一件事.

另一个建议:不要忘记格式.演示幻灯片应该可以在礼堂/演讲厅的任何地方阅读.不要在一张幻灯片上压过太多文字的人.保持子弹短,易于扫描.你想让人们花时间阅读你的幻灯片,还是希望他们听你说的话?不要使用首字母缩略词,但如果必须,请解释它们的含义 - 并将定义放在幻灯片上 - 除非您确定它们是常识.如果有人坐在那里想知道这首字母缩略词的含义是什么,他们就不会听.

至于你是否应该显示实际代码或进行实时编码,我的直觉是你不应该除非它对你所做的那一点绝对至关重要.如果你的项目实际上是关于某些编码结构(例如,如果你发明了"扩展方法"的概念),那么,进入一些实际代码是有意义的.但听起来你所做的事情的重要性肯定是从那个水平上来的.您可能想要显示连接不同数据源所需的代码很少,但我实际上并没有深入研究代码本身,除非您觉得自己无法表达自己的观点.如果我在观众中,我可能希望看到的一件事是演示您的代码.告诉我这是做什么,并告诉我为什么这很酷.

我希望这会顺利!


hef*_*rav 5

这是我的建议:

  1. 要清楚你的观众是谁以及你的信息是什么 - 你是否想要给那些标记你的项目的六位教师留下深刻印象,或者证明你可以招待整个观众.
  2. 早期有一个目录页面 - 这样观众就会知道会发生什么.
  3. 将极客的东西放在主要演示文稿的附录中.这样你就可以深入了解问题,但是你不会忽略你的话题.
  4. 确保您的演示文稿流动并讲述一个故事 - 限制幻灯片编号并且不要混淆它们,例如项目目标,可能的用途,设计挑战,软件选择,您做了什么(限制技术),结果(演示),结果和限制,下一步步骤,问题.
  5. 最后有一个结论页面 - 确保您回圈并交叉参考原始内容页面.
  6. 留下15-20%的时间来提问.这将揭示观众感兴趣的内容,并允许您展示对该主题的更深入理解,即只有在他们要求时才进行实时编码.
  7. 即使你觉得这样做很愚蠢也要大声排练.

祝好运.


Dan*_*rod 5

我一直处于同样的境地
(在EE教师竞赛中展示软件工程/图像处理/识别项目).

  • 从问题开始(问题)

  • 然后是背景(技术背景的BIT)

  • 解决方案:

    • 从块图开始(所有工程师都阅读这些图表)

    • 然后解释技术以及简要说明 - 实施的复杂程度
      (不要低估复杂的部分 - 否则你可能会让你的工作看起来对其他领域的工程师来说很简单 - 他们不会理解你的努力)

  • 结果:

    • 显示简短的可视化示例(尝试使它们有趣)
      (短代码示例可以在这里)

    • 简短的用户界面演示

    • 显示令人印象深刻

  • 参考书目,谢谢,可能的未来改进/研究

  • 问题(如果论坛很大,请事先告诉他们问题的结束时间)

  • 一般建议:

    • 练习演示(一遍又一遍)

    • 每张幻灯片留45-60秒

    • 每张幻灯片不超过5分

    • 每点1行

    • 添加笑话

    • 除了更快地演示复杂问题外,没有动画

    • 使用清晰的字体(Ariel或Calibri用于常规文本,1种不同的字体用于标题)

    • 使用高对比度颜色(如果必须,亮黑色或深白色 - 黑暗或明亮或明亮时不暗)