时间: 2021-07-30 09:38:57 人气: 7 评论: 0
本文介绍了4类重要的**议类型、阐述了开**的作用以及在小产如何开**的方法。
工作中，估计没有人喜欢开**，但是无人能从中幸免。
我也很不喜欢开**。开**是非常消耗精力的，全程都要集中精神。就算不是主持**议，只是普通地参与**议，我都觉得非常累人。
每次开完**，回到自己的工位上，总感觉身体被掏空，脑子已经转不动了，好一阵子什么活都干不了。
但是，我并不排斥开**。
在项目推进过程中，有各种**议需要产品经理参与。有些还需要产品经理来组织、主持。那些必须要参与、必须要开的**议，没什么好说的。一些可开可不可的**议，我一般是倾向于，如果条件允许，还是得尽量组织各方过来开一开。
有时候因为各种原因，该开的**不开了，我反而**有一丝不安。
这是因为，“开**”虽然烦人，但是真的有用。
“**议”有很多种类型。这里我们只关注与“需求”、“项目”相关的**议。
普通小厂，一般不像大厂那么规范。每个项目，推进流程可能**很不一样，并没有一套被严格执行的规范。
哪些**要开，哪些不用，**议要怎么开，都是具体情况具体安排，比较灵活，或者也可以说，比较混乱。
概况来说：项目推进过程中，大概有以下4类**议，比较常见，也比较重要。
顾名思义，就是评估需求是否有价值，确定是否立项执行。需求的发起人向各干系人阐述自己的想法，然后让大家评估其价值，商定执行方案。
与**人员根据自身立场，以及自己掌握的其他信息，提出意见建议，补充完善需求内容。这里面，一般没有我们初级产品经理什么事。我们参加**议，往往只是因为我们需要了解这个项目的各种信息，以便后续设计推进。
我们只是“听众”而已。
因此，有时候初级产品经理也可以不参加。等大佬们商定之后，由经办人把**议结果告知我们就可以了。
立项之后，这个项目还是一个粗糙的想法。这时候，产品经理需要制作PRD初稿，将这个粗糙的想法，变成一个范围明确、效果可预期、内容可执行的方案。
一般来说，这个PRD，10%是立项**议讨论确定的，20%是产品经理私下找干系人咨询讨论确定的，还有70%是产品经理自己脑补的。因为大佬们是不管实现细节的。
因此，当产品经理完成PRD初稿后，需要重新召开**议。这一般需要产品经理来组织、主持。**议的主要内容是介绍PRD内容，并讨论其中有争议的部分。
因为开始涉及到执行细节，所以这类**议耗时往往**比较长。一两个小时以上，都是很常见的。
根据项目情况的不同，这样的**议可能需要召开好几轮。讨论、修改PRD、重新讨论、再修改PRD……
经过多轮**议，最终确定需求范围以及各内容细节，确定PRD终稿。
虽然在前面的**议中，技术团队有时候也**参与。但那时主要是负责把控项目的技术可行性。
当需求完成策划设计，进入开发阶段时，有时候产品经理需要组织相关技术同事一起开个**，介绍需求的整体情况。
这时候的重点就不再是讨论需求内容，而是明确传达产品经理的项目要求，并讨论各处的技术实现方案。有时候还需要在**议上完成任务分配，确定开发计划。
开发过程中，出现问题，一般我们**在各种工作群中协商讨论。如果问题比较复杂，无法在工作群中说明白，这个时候就需要让各方碰头开个小**。这类**议，是临时性的、突发的。
如果是比较复杂的项目，这类小**议**比较频繁。与**的一般是产品经理和相关的技术同事，有时候也需要业务部门参与。
我们不喜欢开**，一个很重要的原因就是，认为开**没有用。开**要占用我们的工作时间，影响我们的工作进度。但是同时，却好像没起到什么作用，完全是形式主义，为了开**而开**。
比如上面说的，面向技术团队的需求说明**议。
有时候，产品经理讲了一两个小时，讲得口干舌燥，结果下面的技术同事很多都没有在听。很多**上强调的细节，之后还是照样**出错。
那这样的**议，又有什么意义呢？
其实，我们认为开**“没用”，是因为我们对**议“作用”的预期不对。
还是上面这个例子。其实，阅读和思考，始终都是一个人的事情。产品经理在**上最多也只能说个大概。技术团队最多也只能听个大概。**后，还是需要自己一个人，去一字一句阅读PRD，去思考每个细节的具体实现方案。
那么，开**到底有什么作用呢？
我认为，开**有2个重要的作用：
“多方同时在线”，相对应的，就是“单独私下”的讨论。
A向B提出要求。B把要求告知C。C向B询问某些细节。B发觉自己也不清楚，因为A没说到这个。所以B又重新去问A。A回复后，B将A的回复告知C。C说B理解错了，不是这个意思。于是B再重新去问A……
这种可怕的“传声游戏”，想必大家在工作中都碰到过。
相对于这种“单独私下”的讨论，将相关的各方拉在一起讨论，效率的提高是巨大的。而且，多方一起碰头讨论，还能极大地避免错误。
我曾经碰到过这样的情况：
A误以为当前系统没有某个功能，所以在和B的讨论中，确定了无需使用该功能的次优方案。
作为执行方的C，他接到B传达的需求后，就感到疑惑。因为当前系统已经有该功能了，完全可以采取最优方案。
然后C向B询问。
B明确说了，A在最优方案和次优方案中，选择了次优方案（虽然不知道理由），这是已经决定好了的事情。
C想，那可能是有其他的限制吧，没办法，那就按次优方案来搞吧。
像这样的误解，越到后面就越说不清。而如果，一开始大家一起碰头开**，那么错误从一开始就能避免。
比如上面说的，面向技术团队的需求说明**议。其核心作用，某种意义上讲，其实在于：确保有效地通知到技术部门各团队的各成员：“我们现在要做这个项目了。”
你可能**疑惑，我们发个工作邮件不就可以了吗？
其实不然。
我举个工作以外的例子。
大学时，体育课要上什么，是自己选的。同一个行政班的同学，可能有的人上篮球课，有的人上足球课。我当时上的是排球课，是这个课的体委。这个课有不同专业不同行政班的同学一起在上。每个行政班内有他们自己的体委，管理他们自己班的同学。
有一次，我需要通知大家，下一节课要在室内上**课。
所以，我通知了各专业各行政班的体委，让他们自行通知自己班里的同学。作为一个理科生，我看不出这个“信息传递”模型有什么问题。但是，最终来上课的人，不到3成。
理由有很多。有的是忘了通知，有的是通知漏了，有的是以为非强制参加……
信息如何准确及时传达，其实是一件比预想中要复杂得多、困难得多的事情。我们“浪费”几个小时，把相关人员都聚集起来，告知他们接下来我们要做的工作。大家来了，意味着“知晓”了；然后走了，意味着“同意”了。
后续我们推进项目时，让相关业务部门配合，让技术部门各团队配合，阻力就**比较小。
我之所以说，有时候该开的**不开了，我反而**不安。这是因为，在普通小厂，团队组织往往是比较混乱的。
如果没有“确实”地完成告知工作，那么项目推进过程中，很可能**突然发现，部分团队因为各种你想不到的原因，居然不知道这个事情，工作现在还完全没有开展。
这就非常可怕了。
普通小厂的**议，一般比较随意。
一些关于开**的方法建议，在这里很难发挥作用。
**前分发的资料文件，一般不**有人看。
**议流程基本不存在，有时候开**就像是在开下午茶**。
**议记录这种东西，基本也是没有的。
但这些都没关系。我们不需要开一个“规范”的**议，只要能达到目的就可以了。
产品经理需要经常参与各种**议，有时候还需要负责组织、主持。除了一些常见的注意事项外，这里我根据我的经验，分享2个比较重要的点。
如上面说的，有时候，**议内容本身不重要，“参与**议”这个行为本身才是开**的目的。所以，当我们在组织**议时，需要尽可能让所有干系人都参与。
如果项目涉及多部门，就必须让所有涉及部门都派人参加。哪怕不参与，也得确保该部门负责人知道这个项目。不然，后续各部门间的配合就**出问题。
如果项目比较复杂，或者技术上有难度，就必须在早期的**议上就让技术部门参与。让技术负责人提供可行性建议。
如果有些部门平时不太配合，就需要尽早让其参与到**议中，让这个项目变成“我们”的项目。
如果这个项目领导很在意，就需要在组织**议的时候，询问领导是否参加。我们需要尽量让领导来参加。不然，有可能我们讨论了半天，结果偏离了领导的预期。然后领导一句话，所有工作就都白费了。
普通小厂的**议，没有严格的“**议流程”。
有时候，上一句还在讨论这个问题，下一句突然就开始说那个问题了；有时候，对于一个问题，有人说了这个方案，有人说了那个方案，然后大家没有进行表态，就开始下一个话题了。
我们初级产品经理，是负责具体执行的人。所以，我们需要对“结论”非常敏感。
具体要怎么执行，如果没有说清楚，一定要打断大家，提出疑问，让与**人员给一个明确的结论。
“所以，具体我们是要……，对吧？”
“现在我们说了3种情况，第1种情况是要……，第2种情况是要……，那第3种要怎么处理，现在还没确定吧？”
具体怎么执行，结论我们一定要确认清楚。
开**，本质上是一种信息传递的手段。
在组织比较混乱的普通小厂，我认为，很多时候，开**是一种不可替代的沟通手段。
看似低效，其实有大作用。
虽然开**烦人，但是该开的，还是得开好。
作者：简明产品论，微信公众号：简明产品论（ID：JianMingPM）
本文由 @简明产品论 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
