不确定这片文章的作者是不是认真发问但之后我想写一些跟工程有关的blog，
先献丑一下
职涯当过support engineer, AE, 整合工程师, pre sales, 技术行销，这些类型的工作
沟通跟技术能力重要性至少7：3，因此跟大家分享一些经验。
首先，沟通最重要的前提，是知道你的对象以及他的想法/目的，否则你就只做到“表达
”，而非“沟通”。
以几种类型对象为例
1. 同公司的执行单位（QA, TE, 生管, 行政）
这种你只要表达跟他有关的action item以及表达你会对决定负责，其他你的思路、做过
的实验、有什么结果对他们都不太重要。
举例：跟TE说某项测试项目range要调整成XXX，不用解释你分析什么资料、做过什么验证
，TE 只要了解这是RD的决定他们去执行，有事找RD
2. 两层以上主管或管理层
“先讲结论”：这个案子会准时/delay 多久，如果有什么资源/缺乏什么资源，会有什么
变化。不用解释你做了什么、跟谁沟通了什么、你发了mail，中层以上主管他们需要的是
调配资源和做决定&善后（如果你要的资源没办法取得，例如缺料，要协调其他部门补救
或是跟客户乔）
举例：这个案子因为XX供应商技术文件经催促后没有提供，因此预计会delay一周，如果
周五之前能够提供预计只会delay三天
3. 客户
“保护自己” & “只给出肯定的答案”
不管你是AE, RD, FAE... 跟客户沟通时候一定要给出有把握的答案（至少85%把握），不
要说“应该可以”、“可能ok”，不确定的部分宁愿当作action item回去评估，否则客
户对公司的信心会大受影响
举例：这个功能我们有相关经验，三个月能够完成/这个功能我需要和团队负责的人确认
，之后再回复给您
但给出的commitment 一定给自己留余地，你认为两周可以做完，也先回复最多需要一个
月，所有的事情都会有突发状况，保护自己&公司。若客户不满意业务自己会再回来找你&
你老板，到时候再假装帮他赶工提前交件都比较好
4. 业务 & PM
类似对管理层的做法，但尝试让业务做点事
可以提出一些业务&PM端对你工作有帮助的要求，这可以增加“合作”的感觉，也能够让
他们更了解状况。而不是只能整天等你进度报告。
他们应该要是你的同伴，只是他们KPI是完成时间or业绩
举例：
你可以帮我和客户确认他这个小修改能不能priority 放低一点吗？/ 如果按照这样作dem
o时间会花比较长，我们按照这样来做你觉得可以吗？或是要和客户讨论/ 这个案子如果
改推另外一个产品，客户和我们的工都会比较简单，要不要试试看？
5. 主管
如果你是资深的：
尝试在报告时候讲清楚你的思考逻辑和考虑的点，除了展示你的经验也能帮助团队菜鸟思
考，主管了解你的思路之后也会对你独立运作更放心。
在不影响工作的情况，适时对主管提出一些要求，例如你想要当mentor, 你想要花一点时
间研究不同的芯片, 你想要主持什么跨部门专案，你想要出差...等等，累积自己的履历
也能让主管更了解你在意/不喜欢的点。
如果你是菜鸟：
千万不能害怕讲出错误，越早讲越有机会补救。在资深同事/主管询问时，勇敢说出为什
么自己做了这个决定（或是为什么认为不用再确认），有时候可以发现制度上的问题。
在和资深同事时候，用“因为OOO和YYY原因，我觉得应该这样子layout，XX哥你觉得ok吗
？另外这边我比较不确定会不会出问题，再麻烦你帮我review一下”取代“XX哥你可以看
看我的电路吗？”相信我效果一定会更好
初步想到这里，希望有帮助到大家，如果觉得还ok 也请跟我说你们的建议或是之后我的b
log可以有的主题，感谢~
※ 引述《marsonele (胖子的脂肪该被抽税吗)》之铭言：
: 有些人讲话就是很琐碎 流水帐的报告
: 说话没重点 听得有点累有点不耐烦
: 会看技术文件没有用
: 要能跟人家讨论 有自己的观点才能够往上爬
: 不然人家问你想法如何 都说不知道没想法要怎么往下讨论
: 我有跟他说起码自己要有立场有自己的想法
: 但他说 自己没实际做过只看paper 而且才看一两篇 无法给评论（知之为知之 不知为
不
: 知 是知也？）
: 这种技能上班之后都怎么学
: 有社会人士上的课程吗？