为了账号安全,请及时绑定邮箱和手机立即绑定

产品需求回顾

标签:
职场生活

晚上再回到公司,想看看接下来准备要做的项目,这两天产品需求讲了8个多小时,之前没有经历过这样的会议,突然有点震惊,表现的也不好。

然后再想想,发觉产品经理提到的需求她们提到的东西,我都记得不多了,虽然自己有看了一部分,但是主要属于自己理解,然后问一下组员学到的。想到这两次会议,自己的状态很不好。

对于我自己:

  • 初来咋到,代码内部逻辑读的不多,业务熟悉程度不够,直接去讲对业务关联比较多的东西。如果我听懂了,对我帮助很大,但我没有认真听,或者听一会就累了。

  • 不要寄希望于别人为你改变什么。入乡随俗,学会适应

我个人觉得这两次会议有不好的地方:

  • 时间太长了,对于我不好的地方是消化不了

  • 中间夹杂很多讨论,议论, 在说产品需求文档的时候,我觉得一气呵成的去讲产品的内容,哪怕讲错了,先不要停下来。 而如果错了一点点,就停下来产品经理之间的讨论,开发没有参与产品需求的撰写过程,不会知道产品经理在哪里讨论什么东西,如果产品经理相互讨论,最好私下讨论,如果大部分人都不知道产品经理在讨论的点是什么,那么占用的是大家的时间。

  • 有谁试过连续上4个小时的数学课?或者中间休息20分钟,上4个小时的数学课吗?

互相换位思考,职责分明,产品经理上面文档又问题,私下讨论,不要在说需求的时候讨论,我没办法参与产品人之间的讨论过程,只能等待消磨注意力。

个人觉得有效率的会议应该是:

  • 产品讲需求,开发认真听。

  • 文档有问题,讲完讨论好之后再反馈过来。

  • 开发有疑问,再去私下讨论或去找产品。

大段的世间用来开会,就和代码集成到一个大的单体架构一样,启动慢,效率低。采用分而治之的思想…大段会议,分成几次阶段性高效的会议.

以上仅仅是个人愚见。

参考三星高效会议:

凡是会议,必有主题;
凡是主题,必有议程;
凡是议程,必有决议;
凡是决议,必有跟踪;
凡是追踪,必有结果;
凡是结果,必有责任;
凡是责任,必有奖罚;
凡是奖罚,必须透明。

最后

毕竟到公司也没有多久,不要太嚣张了,低调,好好做事,不管开什么会,认真听... 硬着头皮也要听。有方法的听,记录着听。

点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消