13 | 白天开会，加班写代码的节奏怎么破？

精选留言(16)

• 

  kirogiyi

  会而不备、会而不议、议而不决、决而不行、行而无果本身就失去了开会的意义。
  
  我认为会前准备是相当重要的，组织会议或者抛出问题的人，应该对整个会议的内容有深刻而清醒的认识，并且将思路整理成文（Word、PPT等），给参与会议的人一个明确的引导，让会议一开始就能很快进入状态，不需要过多的预热。
  
  开会期间如果不讨论会议主题，只是聊一些边角料，去讲人生经历、讲感悟什么的，讲的人快活了，听的人郁闷了，但为了以示尊重，大伙儿还得专心致志听着，职场上也有不得已的地方。这里就会用到宝玉老师说的，会议组织者的场面掌控能力，什么时间、多长时间讨论某一问题，并控制参与者自由发言的节奏，及时拉回会议主题，保证会议的时效性。
  
  如果因会议主题的讨论而衍生出的很多有用的信息，觉得这盘西瓜不错，那盘哈密瓜也不错，芝麻丢掉也可惜了，领导没决策，下属没主见（有主见也是从自己工作便利性上考虑），最终在会议结束的时候，留下了更多的问题，核心主题却没结果。个人觉得，每次会议的参与者都要达成共识，组织者是谁，决策者是谁，甚至有时候组织者要暗示决策者该表态了。
  
  会议只是产生良好结果的前奏，相当于理论验证结果有了，剩下的就是去实际操作了。一旦决策者表态了，有了决定了，就该指定相应的负责人，定期汇报进度、展示阶段性的成果。最近就遇到旁边的一个部门，加班加点的修改方案，到客户那里去出差三天，回来了，本以为会有点动静，接下来一周都没啥动静，和大家聊天才知道，没指定谁来总览这件事，一直挂在相应副总经理名下，副总经理好像忘了似的，要么就是结果已经堪忧了。
  
  行而无果，实际上是最让人绝望的，花了大量的人力物力，最后发现一切都是徒劳的，会前准备、会中讨论和决策、会后执行，好像每个环节都出了问题，没人有致命的错误，反正就是事儿没干成。
  
  写这些，实际上是希望得到宝玉老师的指点，从专业的角度指点下我思维的误区，谢谢您。

  作者回复: 总结的非常好的👍
  从课程的理论知识，结合了实际工作场景的案例👍
  
  我不觉得思维上有任何问题：）
  
  有一点意见可以参考：如果你需要别人给你意见，本质上跟开会一样，不宜主题太多太分散，不然别人抓不住重点。
  
  下次你可以在总结完了后，针对一两个具体问题问，这样被提问的人更容易抓住重点，供参考。

  2019-03-26

  

   9
• 

  alva_xu

  老师今天的话题确实是我们大家在做项目中特别头疼要处理的问题。开会吧，怕耽误别人时间，不开会吧，怕别人的意见没有收集到，或者拍板了不算。我来谈谈我的学习体会：
  1，会议组织者或者相关人员必须在会前确定好会议目标，并在线下预先和相关人员沟通准备材料，会后尽量要有一个会议纪要，特别是跨部门的会议（对于每日站会等scrum 中规定的常规性会议，已经形成了规范，相对好组织）
  2，对于必须邀请领导（们）参加的会议，是最最考验组织者的。因为领导的发言可能是最不能受控的，这需要会议组织者的会议控制技巧，比如说事先给领导暗示时间，及时把领导发散出去的话题收回来，等等
  3，在需要多人发言，征求多人意见的时候，用先发纸条各自写下自己的想法，然后再发言的形式会提高效率。
  4，如果一些会议本身的话题比较多，可以考虑将议题分散成多个会议，大会拆成小会。
  5，实在没办法必须开大会的时候，我作为组织者，鼓励大家带上笔记本电脑等工作工具，允许大家边工作边开会。这是，作为组织者，必须把握好哪些信息需要哪些人听或者反馈。
  总而言之，会议组织者是最最重要的角色，除了考虑会议要达到的目的之外，还需要考虑节省与会者的时间。否则，参会人员的积极性会大打折扣，以后就没人来开你的会了。

  作者回复: 你这些宝贵经验对大家包括我都很有价值👍
  
  我以前老板就特别能说，完全收不住😂

  2019-03-26

  

   7
• 

  aya

  老师【你是砍柴的，他是放羊的，你和他聊了一天，他的羊吃饱了，你的柴呢？】说的醍醐灌顶呀，人家还会说你的柴和我有什么关系...

  作者回复: 同一个会议，对不同的人价值是不一样的，别让自己当砍柴的陪放养的聊天：）

  2019-03-26

  

   6
• 

  Felix

  我说一下我对开会的看法：
  1. 要有主持人，之前遇到过没有主持人，就像没头苍蝇一样，特别容易脱离主题，尬聊，主持人控场，能够保持会议围绕议题进行
  2. 要有书记员，当然书记员不是记流水账的，从同事那里学来，开会最重要一句话是"结论是什么"，讨论半天没有结论，这会还不如不开，所以书记员重点记结论，会后将结论，即会议纪以邮件形式群发参会人以及抄送领导知晓
  3. 如发现会议与自己无关了，要勇敢地离会，如需求评审，产品经常会邀请多方开发，如果已经确认剩下的议题与自己无关了，跟主持人确认后就可以离会，有同事跟我说他们会不好意思，我觉得大家都是做事的，应该能够互相理解，雷厉风行，不用不好意思😄

  作者回复: 对，我支持你的观点：有时候要勇敢离场，只要解释一下相信都能理解，毕竟会议之外创造的价值更大。

  2019-03-26

  

   4
• 

  纯洁的憎恶

  提高会议效率，从成本收益入手。会议有成本，开会需谨慎，时长与人数和会议成本紧密相关。
  
  主动做减法，减少会议数量，缩短会议时间，削减参会人数，降低会议成本。
  
  努力做加法，明确会议目标，得出会议结论，落实后续责任，复用“听会”时间，提高会议价值。

  作者回复: 你这个简洁👍
  本质上就是做加法和减法

  2019-03-26

  

   3
• 

  hua168

  老师能说下，整个项目开始前到项目完全结束，一般都要开那些会议呀？目的是什么？

  作者回复: 我确实整理了一些，后来因为篇幅原因删减了，我和编辑商量一下，在下一次整理留言的时候放出来，作为这条回复。

  2019-03-26

  

   3
• 

  williamcai

  看个人吧，作为程序员，我一般喜欢参加技术评审会，方案设计会，和代码评审，和我的职责息息相关

  作者回复: 是的，很多会议是有价值的👍

  2019-03-26

  

   3
• 

  bearlu

  老师，能不能说说开会要留意些什么内容，我是个新手，每次开完会议，到开发的时候又找产品确认具体功能。

  作者回复: 我想你说的应该是需求评审会议或者需求讲解会议，对于这类会议，建议你会议前读一下文档，这样心中有数，同时对于文档中觉得不清楚或者有疑惑的地方记录下来，在会议中提出。
  
  不同的会议重点不一样，开会之前你都可以实现了解下这次会议的主要目的是什么，然后事先准备一下，这样开会就会更有效率一些。
  
  如果你是有具体某个类型的会议，也可以新开留言。

  2019-03-26

  

   3
• 

  果然如此

  正好有一个昨天开的产品会的案例，产品经理刚讲了不到一半，另一个技术人员就提了很多问题，有的是需求问题、有的是技术问题、还有的是这个产品的历史数据更新的问题，对于以上问题，由于产品只讲了一小部分，我觉得在这个时候提问题有点激进并且有的问题偏离了主题，所以在适当的时机，我及时打断谈话，并向产品经理询问是否全讲完了，答案当然是否定的，并请其继续讲完，在讲的过程我记录了一些问题，然后讲完之后，大家继续讨论和需求有关的话题。

  作者回复: 👍赞，这样的打断很有必要，不然很容易就偏离主题了！

  2019-03-27

  

   2
• 

  青石

  组织会议，一定要有会议时间、地点、人员、主题，会前要有准备、会中讨论要有结果（指定干系人）、会后要跟踪。
  
  没有主题、没有讨论结果、没有跟踪的会议，都属于无效会议。

  作者回复: 👍有价值的补充

  2019-03-26

  

   2
• 

  小老鼠

  1、老板无法接受项目三角形这么办？老板不听我话如何办？
  2、所有会议有没有必要形成会议总结的必要？

  作者回复: 1. 帮助老板成长超出了你的职责范畴，让老板听话也超出了软件工程的范畴：）
  2. 如果你加上“所有”，那么答案就是否定的，很多务虚的会议可能并不需要有会议总结。但开会之前有明确主题和目标，开会之后有结论、有后续行动和相应责任人、有总结，是很好的会议习惯。

  2019-09-11

  

   1
• 

  Jansen

  我们项目一般会开以下几个会议，老师看看我对它们的理解对不对：
  1.每日站立会议。这个是很有价值的，可以把控项目进度、知道每个人的产出、每个人的计划、有哪些潜在的问题，偶尔还能意外学习到别人的研究成果。
  2.需求分析会。这是产品经理将业务需求转换为开发人员能理解的系统功能的会议，对开发人员价值很大。但是需要产品经理事先自己充分理解需求的背景和细节，不然等到会议上发现需求问题是很影响开发人员对需求的理解的，因此会降低开会的价值，时间拖长了也会增加开会的成本。
  3.开发设计方案评审会。这个是对需求中较难的点进行开发设计方案的确定，大家一起针对方案进行评估，给出自己的建议并最终达成一致，能有效避免个人思维上的盲点，从而造成测试阶段推翻原有方案大规模返工的风险。
  4.代码评审会。每个人对自己的代码逻辑和规范进行讲解，时间冗长，大家很难保持长时间的注意力集中，而且会认为别人的代码与自己没什么责任关系，投入关注度不高。这个很头疼，不知道该怎么解决？
  另外，老师还建议有什么别的类型的高价值会议？

  作者回复: 代码评审会我建议你可以改成Code Review。参考《06 | 大厂都在用哪些敏捷方法？（上）》中描述的。
  
  也就是你每一个人写的代码，要合并到主分支之前，需要有人Review，Review的过程自然就需要去了解对方代码的逻辑和规范，也是个很好的相互学习的机会。
  
  但这个必须要有配套的流程规范严格执行，要是流于形式就没有意义了。
  
  需求分析会要拆开效果更好，先开一个大会概要性简单讲清楚整体需求，然后开小会和业务相关的开发人员沟通，这样更高效。
  
  开发设计的评审会议要分多次开，一开始不要太细，先确定大方向，然后逐步细化。不然修改成本高，沟通难度大。
  参考《21 | 架构设计：普通程序员也能实现复杂系统？》
  
  还有一个很重要的会议就是迭代/项目回顾总结会议，在迭代或者项目结束后，大家一起讨论总结项目中得失，提出具体的改进意见。

  2019-04-17

  

   1
• 

  nicola

  本身项目在计划中进行着，但又有另外的任务插入需要占用很多时间，又要完成紧急任务又不对原来任务进行计划调整（按原计划进行），完完全全把责任推给开发者。

  作者回复: 这种确实不合理，如果有新任务插进来，那么就必须要对现有计划进行调整。
  
  建议以后遇到类似临时插入任务的问题，当时就说清楚优先级，以及造成的影响和后果，当时就一起把计划做出调整。

  2019-04-03

  

   1
• 

  舒偌一

  这个可以和第12节内容应用起来，会议也要有流程和规范。
  个人认为之所以有一些没有价值的会议，是对会议成本不重视，党都对会议有严格要求了。
  没有目标的会议不参加，没有会议资料的不参加，没有决策人参加的会议、不知道为啥邀请自己的最好不参加。
  项目组自己的会议，不在工作计划中，都安排在下班前15分钟。

  作者回复: 👍很好的经验分享

  2019-03-26

  

   1
• 

  一路向北

  把开会当做一个项目来看待，开会前就把开会需要解决的问题，以及开会的流程，开会的人员都确定好，确实很关键。从老师的这次课中学到很关键的一点是，不管是作为组织开会的人，还是需要参与的人，都应该对这次的会议做一定的分析，觉定如何开会，是否应该参会等，而不是盲目的去开会。

  作者回复: 👍有收获就好
  也谢谢补充

  2019-03-27

  

  
• 

  dancer

  提升会议价值的方法主要有缩短时长和控制人数。首先是明确会议的相关议题，这样可以缩小参会人员范围；其次是事先相关人对议题有所准备，发言要简洁有效，避免议题过度发散；最后是会议结束后相关议题要有结论以及落实细节并存档。

  作者回复: 👍很好的经验分享

  2019-03-27

  

  