作者回复: 总结的非常好的👍
从课程的理论知识,结合了实际工作场景的案例👍
我不觉得思维上有任何问题:)
有一点意见可以参考:如果你需要别人给你意见,本质上跟开会一样,不宜主题太多太分散,不然别人抓不住重点。
下次你可以在总结完了后,针对一两个具体问题问,这样被提问的人更容易抓住重点,供参考。
作者回复: 你这些宝贵经验对大家包括我都很有价值👍
我以前老板就特别能说,完全收不住😂
作者回复: 同一个会议,对不同的人价值是不一样的,别让自己当砍柴的陪放养的聊天:)
作者回复: 对,我支持你的观点:有时候要勇敢离场,只要解释一下相信都能理解,毕竟会议之外创造的价值更大。
作者回复: 你这个简洁👍
本质上就是做加法和减法
作者回复: 我确实整理了一些,后来因为篇幅原因删减了,我和编辑商量一下,在下一次整理留言的时候放出来,作为这条回复。
作者回复: 是的,很多会议是有价值的👍
作者回复: 我想你说的应该是需求评审会议或者需求讲解会议,对于这类会议,建议你会议前读一下文档,这样心中有数,同时对于文档中觉得不清楚或者有疑惑的地方记录下来,在会议中提出。
不同的会议重点不一样,开会之前你都可以实现了解下这次会议的主要目的是什么,然后事先准备一下,这样开会就会更有效率一些。
如果你是有具体某个类型的会议,也可以新开留言。
作者回复: 👍赞,这样的打断很有必要,不然很容易就偏离主题了!
作者回复: 👍有价值的补充
作者回复: 1. 帮助老板成长超出了你的职责范畴,让老板听话也超出了软件工程的范畴:)
2. 如果你加上“所有”,那么答案就是否定的,很多务虚的会议可能并不需要有会议总结。但开会之前有明确主题和目标,开会之后有结论、有后续行动和相应责任人、有总结,是很好的会议习惯。
作者回复: 代码评审会我建议你可以改成Code Review。参考《06 | 大厂都在用哪些敏捷方法?(上)》中描述的。
也就是你每一个人写的代码,要合并到主分支之前,需要有人Review,Review的过程自然就需要去了解对方代码的逻辑和规范,也是个很好的相互学习的机会。
但这个必须要有配套的流程规范严格执行,要是流于形式就没有意义了。
需求分析会要拆开效果更好,先开一个大会概要性简单讲清楚整体需求,然后开小会和业务相关的开发人员沟通,这样更高效。
开发设计的评审会议要分多次开,一开始不要太细,先确定大方向,然后逐步细化。不然修改成本高,沟通难度大。
参考《21 | 架构设计:普通程序员也能实现复杂系统?》
还有一个很重要的会议就是迭代/项目回顾总结会议,在迭代或者项目结束后,大家一起讨论总结项目中得失,提出具体的改进意见。
作者回复: 这种确实不合理,如果有新任务插进来,那么就必须要对现有计划进行调整。
建议以后遇到类似临时插入任务的问题,当时就说清楚优先级,以及造成的影响和后果,当时就一起把计划做出调整。
作者回复: 👍很好的经验分享
作者回复: 👍有收获就好
也谢谢补充
作者回复: 👍很好的经验分享