开早会的意义是什么 如何让大家都能积极发言 能分享一下你们是怎么开早会的吗

[beeyoung]

咱们程序员的性格很多都是闷骚的

心里有话 却不愿意表达

开早会的渐渐成了流水账

大家能分享一下你们是怎么开早会的吗

[JaguarJack]

周例会。组长分配任务。组员一般都是说说项目遇到的问题，顺带说下进度。

[zhoudaiyu]

什么都不说，这是坠好的

[xsen]

早会要说的其实就是，昨天做了什么、遇到什么问题（资源协调或配合）及今天安排

对于我来说（团队或项目负责人）的好处是，
1. 团队内不同同事之间的交流明显会多起来（氛围）
这里说的不是早会，是推行早会之后日常工作中同事之间的交流沟通

2. 团队成员有问题或及时跟我沟通
3. 我可以了解潜在风险，进而调整计划、协议资源或人员
4. 可以对架构、进度与设计进行监控

[leafShimple]

记流水账,搞清工作进度

[richzhu]

早会是万恶之源

[cassyfar]

@GeruzoniAnsasu

你提的这些问题为什么要等到每天早上，不应该一有疑问就聊天或邮件询问对方吗？

另外我发现组里都在做不同项目，大项目很多又是牵扯到几个组的，这种同步，早会是做不了的。

[bingoshe]

显得 leader 有在干活

[g0thic]

如果每天开早会 那还不如写日报。如果每周开会 还不如写周报。讲的一下子还会忘了 写的还有个记录

[Rache1]

呆过的公司都不怎么开会，曾经在一个初创公司呆过一段时间，项目搞得火急火燎的 “敏捷开发”，每天搞个站会，周三还有个会。

个人对这种环境没啥好感。

[mikuazusa]

同步信息，早会最佳实践是时间必须严格控制，不要讲废话，只讲需要同步的内容，越短越高效，控制在 10 分钟内。

[hansnow]


[1002xin]

学的国外呗，Facebook ，Standup Meeting ，人家那个是六个人一组，十分钟，主要是报问题，与要完成的事情，我们的早会基本流于形式

[aino]

问个问题。你们早会的组织人，会不会叙说他昨天做了什么，今天要做什么，我们的不会，所以我觉得恶心

[codeEleven]

在项目中，信息同步很重要。知道每个人在干什么，也能更好的安排自己的工作。走出时不时摸鱼的舒适区，提高工作效率，是节约自己的时间，等同于为自己延长寿命。

[InDom]

有事早奏，无事退朝。

[GeruzoniAnsasu]

@cassyfar 「一有疑问」？

没有形式来保证，谁知道其他人什么时候「有疑问」？早会的目的就是每天都让所有人都清楚了解有没有问题。

> 组里都在做不同项目，大项目很多又是牵扯到几个组的，这种同步，早会是做不了的

这也叫「从早会反映出的完全失败的项目管理」。



敏捷团队必须以目标为单位来组织，而不是什么技术栈或管理部门。这个团队应该是能随时（指在 milestone 之间）重组、扩容、调配的，包含完成一个 milestone 所需所有「基本常驻人力单位」的组织。并且敏捷模式就是与小团队和快迭代才契合的模式，其它场景根本就不适合 agile/scrum 。换言之，「一个组」应该代表「做同一件事的一群人」，如果「组里在做不同项目」，说明管理失格。


如果项目很大需要很多团队配合



这个项目需要不断迭代吗

> 是 >> 那么能把项目拆成多个小团队各自进行敏捷开发和迭代吗
>> 能 >>> 各个小团队各自日会，各组长与项目总管理时不时沟通同步情况。这种情况一般是有很多个组件相互存在松散依赖，各组件会不断 build 新的稳定版本供其他组件引用，组件的版本迭代就可以继续采用敏捷模型。
>> 不能 >>> 说明项目的架构就很有问题，只会越迭代越痛苦，趁早副本一个团队重新做 2.0 才是正确的事。

> 不是 >> 那么这种项目的生命周期根本就不采用迭代模型，瀑布模型前面的需求分析写完了吗？设计文档和 PRD 完整了吗？没有的话根本都不到开发干活的时候，到开发干活的时候风险点和技术调研照理都已经全完成了，当然就不需要天天应急似的对进度

[zhouyou457]

个人觉得如果团队是多地远程协调的话早会非常必要.

以我们组来说，一共 6 个人，一个项目经理一个主管，两个前端两个后端（ UI 和测试都是公共资源。。）
由于项目经理在北京，另一个后端在重庆，而剩下我们几个都在成都，所以每天早上的早会基本上就是同步两边的进度，也不是说必须得说话，基本上就是有什么具体的问题就直接沟通交流了。

如果是发消息的话时常会出现有人看到消息然后“忘了”，搞的大家会很不愉快，因为一个人而导致整个项目组都背锅。

[uleh]

早会的意义是同步信息和确认，确保每个人都明白自己在干什么，要干什么

所有的管理实践活动一定都是结合现场情况来做的。
一个成熟的小型团队可能早会很简短甚至不需要；
一个即将交付的团队就需要每个人在早会上明确问题甚至进行小规模的讨论；
一个新人为主的团队，就需要 Leader 在早会上明确的跟踪每个人的进度并且布置任务

[locoz]

其实就是 leader 管理能力不行或者管控欲过强，所以才喜欢搞这种晨会、日报之类极度流程化的东西。如果真的要高效管理和同步项目进度的话，合理的做法应当是通过工具来做，每个人自己把任务细分清楚、做好时间预估再按重要程度排个序，看板、图表、自动生成的进度报告之类的一目了然，根本不需要这么反复汇报。

别说啥“用工具会不自觉”之类的，在合理使用工具的前提下使用良好的工具来管理进度时，执行人员面对的核心部分应当始终是一个简单的 todo list ，根本不需要花费过多的时间成本或心智成本做多余的事情，为什么会不自觉？顺手就操作完了。

如果连个 todo list 都懒得写、懒得点的话，那说明是招的人本来就有问题...leader 自己应当反思一下为什么会招进来这种人。毕竟做这事比写日报或者进度报告之类的简单多了，每天每个任务上就花个几秒的时间而已。

---

有些只会看些管理学书籍然后生搬硬套别人方法论的 leader 可能根本没想过：

晨会之类短周期的会议之所以不好，就是因为对于执行人员来说，有很多信息在大多数时候都是无意义的，日积月累下来这么浪费的时间就非常多。不管是按项目组来开会，还是按职责关联程度来一部分一部分地开会，都总会存在这种情况。

而使用日报或进度报告之类的方式之所以也不好，是因为对于执行人员来说，要么是需要把一个具体的任务进度通过文字这种相对抽象的方式表达出来，需要耗费心智成本；要么是多余的操作过多，比如有些奇葩报告需要估算进度百分比，且是通过 word 之类非专业工具进行操作，每次都需要花费额外的时间来处理，而不能是做事的时候顺手就处理，心智成本和时间成本都需要耗费。

相比之下，一个在项目初期开立项会之类会议时就能大体定下的 todo list ，在大多数时间里都只需要顺手点几下就能完成项目管理的需要，不管是心智成本还是时间成本都耗费极低，效率不高、满意度不高才怪了。

[locoz]

@shot #22
"团队荣誉感 /自治性不足，主观上不愿意作为团队的一部分去共同实现一个有意义的目标"
绝大多数人打工只是为了赚钱，只有级别较高的人才会是因为前景或者意义之类的原因进入公司、参与项目，跟只想赚钱的人谈荣誉、谈理想之类的没有任何实际意义...换个难听点的说法就是“画饼”。

“团队成员职业能力有短板，客观上无法理解团队目标，达成团队协作，阐述团队及个人的工作内容和价值”
无法理解团队目标，达成团队协作是能力问题，但有没有这种会议其实都会很容易暴露出来，甚至正常来说面试的时候就应该暴露出来了，即使没立即暴露出来也会在做事的时候自然暴露，跟有没有开会没啥关系...而“阐述团队及个人的工作内容和价值”，这是表达能力的问题，如果不是以说为主的职业，表达能力相对较差是很正常的，这并不代表职业能力不行。