【01】程序员的职场素养，技术类汇报

这里必须要问一个本质的问题，汇报是为了什么？为了升职加薪登上人生巅峰？别人说分享是为了“给予”， 那么汇报更多是为了“共识”。

不同层级的汇报

不同层级的汇报

在现在的软件行业，跟以前英雄主义式开发大不相同，基本都是集团军作战，在BAT这样的大公司，最大型的研发团队差不多2000多个开发，跨部门/BG合作的大型研发项目组，不同的研发中心/部门负责不同的功能模块。这时你会发现上下级的“共识”就会显得非常重要。

不同模块的研发负责人要汇报，与项目的sponsor、虚拟项目的负责人建立愿景、战略、使命的共识；研发中心下面有不同的研发小组，有负责研发基础组件的，有负责做业务需求的，他们都需要汇报给研发中心的负责人建立目标与关键成果的共识。这些研发小组的日常，也会有汇报，例如Scrum里面的站立会议，通过汇报建立任务维度的共识。不同层级的负责人都会有汇报，但是越往上走，汇报的内容会更加聚焦和提炼。当然，你也可以当部门、中心、小组是公司，也可以有自己的愿景、战略，当然就可以有对应的汇报形式，如PDM 会议、战略会议等等。

千万别把“汇报”当成“分享”

汇报各式各样，但有千万要注意千万别把“汇报”当成“分享”。这里讲个故事，最近，我们中心在推行工作Review，可以看作定期的汇报。下面是我们工作Review的具体要求

时间：每周三下午4点-6点/周五10点-12点（每周排期上限5个topic）

持续时长： 30分钟/人

参与人： 工作相关干系人与感兴趣的同学或review者推举

内容：　请简要介绍过往1月中在腾讯负责的主要项目及工作成果重点谈一个你认为最成功或最能体现个人专业能力的项目或成果：

为什么要做？ 业务遇到什么痛点，有多痛，有没有数据和截图的佐证

怎样做？过程中的挑战和难度在哪里，你如何克服的，过程中你做过哪些重要的决策或抉择

阶段性成果是什么？对部门/公司有什么价值，如：业务突破、技术进步、管理提升等

阶段性成果是什么？有哪些方法论/工具的应用或突破

评分规则：客户导向、技术突破、优秀工程实践、方法论建设、技术影响力、人才培养，6个维度， 挑选其中涉及的一到两个维度，给予“优”，“良”，“中”，“差”的评价与评语。后续作为影响半年考核的指标

邀请：可以邀请相关的工作伙伴参加，邀请到中心内的成员强制参加

执行下来发现一个问题，居然有小伙伴弄不清楚“分享”与“汇报”的区别，上来就开始谈“故事”，如果这里可以发表情的话，“捂脸笑”是最适合。我基本每年都会有些分享的机会，讲故事在分享里面是很重要的技能，但是在汇报就显得非常不合时宜，原因有两，一，汇报的对象通常是上级，而上级都“很忙”，没时间和耐性听故事；二，对于听汇报的人来说，几场汇报下来需要接收巨量的信息，并没有空间去存储“故事”这个形态。所以一切的汇报有个基本准则，下一堂我们会听到的“结论先行”。