一、前言
今天不讲技术，分享一些日常工作中的感悟与体会。在学校的时候曾经想象过自己的程序员生活，耳机一带，两耳不闻窗外事，一心只写圣贤代码，就像是接任务完成任务一样，所有的需求都是通过线上提工单的方式发放给你，然后你去接收、实现、提测、改bug、提测，完成任务。不知道大厂是不是已经规范化到这种程度，反正我没有去过大厂（狗头）。
但是实际到工作中后，会发现并不是这种情况，反而是传说中另一种工作状态：
上午开会确定新需求；下午改原来的bug；晚上加班写新功能。
所以，到了工作中，真正让你能带上耳机安安心心开发一整天的情况，反而成为了一种奢望，甚至一种享受。而更多的是什么呢？开会、确认、沟通。所以，如何高效的沟通，给别人讲清楚你要表达的意思，就成了一个大学问。
二、如何有效的沟通
不如我们先去问问豆包：在日常工作中，如何高效的沟通、组会、表达（顺便说一嘴，现在连和AI都要注意提问的方式方法，可想而知高效表达真的是一门艺术）
以下是在日常工作中实现高效沟通、组会和表达的方法：
- 在沟通之前，要清楚自己想要达到什么结果。例如，是为了传递信息、获取反馈、解决问题还是协调工作？明确的目的可以让沟通更有针对性。比如，你要和同事沟通一个项目进度的问题，你的目的可能是让对方了解目前的延迟情况，并一起商量解决方案。
- 不同的沟通场景适合不同的渠道。对于简单的信息传递，如通知会议时间，使用即时通讯工具（如企业微信、钉钉）发送消息就很高效；如果是复杂的问题讨论，面对面交流或者视频会议会更好。例如，涉及到产品设计细节的沟通，通过面对面的交流可以更直观地展示草图和想法。
- 沟通内容要有条理。可以采用 “总 - 分 - 总” 的结构，先说明主题和重点，再展开细节，最后总结和确认。例如，“我们今天主要讨论新产品的市场推广策略。首先，我想谈谈目前市场的情况；其次，我们的目标客户群体…… 最后，总结一下我们要重点关注的推广渠道是线上社交媒体和线下体验店。”
- 给予对方充分的表达机会，不要打断。并且通过点头、眼神交流等方式表示你在认真倾听。在听完后，重复对方的关键观点进行确认，如 “你刚才说的是希望增加这个功能模块，对吗？” 这有助于确保理解的准确性。
- 保持礼貌、尊重和专业的态度。避免使用带有傲慢的语气。即使在意见不合时，也可以用 “我理解你的观点，不过我有另一种想法……” 这样的表达方式。
- 在会议前，确定会议要解决的问题或者达成的目标，并制定详细的议程。将议程提前发送给参会人员，让他们有时间准备。例如，销售会议的议程可以包括上个月销售业绩回顾、本月销售目标分解、重点客户跟进情况等内容。
- 为每个议程事项预估时间，并严格遵守。可以使用定时器来提醒自己和参会人员。对于讨论容易跑题的情况，主持人要及时引导回到主题。比如，在技术研讨会上，如果大家开始讨论无关的市场趋势，主持人可以说 “我们先聚焦在技术方案的可行性上，市场部分我们可以之后再讨论。”
- 营造开放的会议氛围，鼓励参会人员积极发言。可以通过提问、小组讨论等方式调动大家的积极性。例如，在头脑风暴会议中，主持人可以说 “大家可以畅所欲言，现在请每个人提出至少一个新的创意。”
- 安排专人负责会议记录，或者使用录音设备辅助记录。会议结束后，及时整理出会议纪要，包括讨论的要点、达成的共识和下一步行动等内容，并发送给参会人员。这有助于大家明确责任和跟进事项。
- 无论是演讲还是汇报，都要提前收集和整理资料。了解你的听众，他们的背景、兴趣和需求，根据这些来调整你的表达内容。例如，给管理层汇报工作时，要重点突出项目的成果、收益和风险等内容；而给技术团队分享，可能更侧重于技术细节和解决方案。
- 表达内容可以采用 “开场白 - 主体内容 - 结束语” 的结构。开场白要引起听众的兴趣，比如通过讲一个小故事或者提出一个引人深思的问题。主体内容要有逻辑，分点阐述观点。结束语要总结重点，并给听众留下深刻的印象，如呼吁行动或者再次强调重要观点。
- 根据需要使用幻灯片、图表、实物模型等辅助工具来增强表达效果。但是要注意不要让辅助工具喧宾夺主。幻灯片的内容要简洁明了，图表要清晰准确。例如，在介绍市场份额变化时，用一个直观的柱状图会比纯文字描述更有说服力。
- 语言要简洁、易懂，避免使用过于复杂的词汇和长句子。同时，要注意肢体语言，保持良好的姿势，与听众有眼神交流，适当使用手势来强调重点。比如，在强调一个重要的数据时，可以伸出手指指向幻灯片上的数字。
三、亲身感受
在最近的一段时间，我的工作内容是需求调研、功能设计，不可避免的要与公司各个小组的人员进行沟通，因此，接下来我分享我组织的三次会议的经历，讲解都是同一个东西，来切身说明一些事情。
场景一：第一次做组内方案讲解
做好方案之后，我们组织了组内成员的讨论，组内成员，大家都很熟悉，理论上来说是最容易的一次，但是事实却给我当头一棒。当时我在想，大家都是一个小组的，平时对各自做的东西也都有一些了解，因此并没有什么特别的准备，只是拿着我写好的概要设计文档，以及一些小demo，就组会讲了，因为讲的东西是一个比较复杂的大系统，也没有一个特别明确的流程线索，因此在讲的时候，东扯一点、西扯一点，讲到一点就深入进去，慢慢的感觉自己就讲乱了，然后就开始着急，然后越讲越快，后面感觉自己都讲不下去了，匆匆结束。
这种描述方式，让组内成员在有一定的基础的前提下，还是被讲的一脸懵，也讨论不出个所以然来。总体来说，这次讲解说明是失败的。
场景二：第二次线上会议
给组内成员讨论完，下一步就是给其他相关组的人收集需求，收集需求这个事情，说着简单实际做着很难，因为很多时候我们并不在一个频道上，你讲你的，他可能关注的点完全不在这里，就导致你讲你的，他讲他的，你没有得到你想听的，他也没有得到他想要的。
所以不如换种方式，我先讲我的，我先把我的方案给大家心里埋个种子，然后再角色互换，让其他小伙伴去讲他手里的东西，这样他在讲的时候，就会不自觉的带入他内心被我埋下的种子，一定程度按我的思路去分析自己的东西。
在第一次会议讨论之后，我仔细反思了好几天我到底是为什么讲乱了，在一次和组内大哥的讨论中，我恍然大悟，大哥跟我讲，你要列几个框框大致讲一下你有些什么。
是啊，我们讲解者不会乱，是因为我们内心知道我们有什么东西，我们要做的是利用心里这点东西去达成目的；而倾听者并不知道你有哪些东西，他是一张白纸，认知不同，自然无法互相理解。
那不如把认知拉齐，我重新整理了我的概要设计，把他按模块直接分成三块，画了一个脑图，三个模块下分三个使用场景，截了三个图。我先给他把我有什么讲明白了，然后我再讲我通过这些可以达到什么效果，齐活。
我拿着我的脑图、设计文档和demo，去参加了第二次会议，是线上会议，总体还是我来讲，这一次有了脑图加持，整个人有了一定的思路，然后在脑子里告诉自己，一定要压下来自己的速度，慢下来，语速慢下来，心慢下来
这一点我真的觉得很重要，很多时候我们演讲、讲话甚至唱歌，都会越来越快，这不是一个好事，越快代表越急，别人听不明白，自己还着急，只会讲的更乱，所以一定要沉住气，一句一句压的说，有节奏的说，反而会越来越舒服
果然这一次，相较于第一次会议，有了很大进步，成功的把我的思路讲了出来，也把会议进行下去了；但是还是存在一点小瑕疵：
- 在针对对面需求做细化讲解的时候，还是太过深入了，导致有一个部分讲的很乱，没有逻辑性；
- 然后几个议题不够连贯。
场景三：第三次线上会议
今天下午的会议，我又找回了我自信的感觉，首先是基于上两次教训，我直接列了一个会议流程，连同我之前的脑图，分析在开会之前先发给参会人员查看；其次我直接放弃所有设计讲解的内容，只针对“有什么”和“怎么做”去阐述，带的demo也都是按照操作顺序去排列，依次展示，让与会人员感觉这个东西已经存在了；最后在开会一开始，就首先把会议要讨论的三个内容，先声明了一下，让每个人都知道要做什么。
这种流程下来，整个感觉十分良好，我甚至不需要去控制自己的节奏，只是完整的讲解我内容，在我讲解完之后的提问环节，自然会有问题过来：
- 这块是怎么设计的啊？
- 这里有没有这个功能啊？
- 我们有一个这个东西可不可以实现
看到了么，有些东西不用你讲的那么细，自然会让你讲到。这样提问的方式，也成功带动了大家的积极性，对我讲的东西，也有了一定的认知；到了角色互换时，他们也自然而然的给我分析上了现有的和我设计上的异同，改进点等。
最后，在轻松愉快的氛围中，结束了最后的一次会议，我也得到了我想要的。
四、总结
通过这次组会经历，我体会到了几点：
- 一定要确定好自己的讲述框架，给他列出来，因为我们的思维是发散，在脑海中很容易带偏，如果没有系统性的讲解，别人很难理解你想说什么
- 组会的目的是为了获取到有用知识，因此，要让会议的每个人知道我们的会议是干什么的，这就是会议前的章程的重要性
- 会议纪要很重要，这一点前文没有提，但是这是我们会议的痕迹，更是会议的目的，像我们这种拉通性的会议，可以不要很正规，但是讨论的问题，确定的解决方法，一定要体现出来，一般可以采用问答式。
最后
如果你只是想写点代码，然后35岁另谋生路，那这些都无所谓
如果你有更远大的理想、当架构师、当项目负责人、当组长、当老板，那这些职场软技能，就是职场必备技能了
分享一个最近看到的弹幕
原来的我不屑一顾，现在的我逐帧学习
