产品经理日记-悠哉产品经理的一天坐着公司的班车，在八点二十分钟到达公司楼下，公司是八点半上班，中午休息两个小时从十二点到两点，下午六点钟下班
。有的公司是九点上班，中午休息一个半小时，下午六点下班。到了公司，上个厕所，整理一下桌面，去装点茶水，晃晃悠悠的也就差不多九点钟了
，这个时候开始进入工作。因为今天下午有个需求评审会需要召开，所以早上要做一些准备工作。开会的通知邮件昨天已经发出，通知的人员有，需
求的提出方业务部门的一位同事，还有负责研发的后台JAVA工程师2名，前端工程师2名，测试工程师1名，因为这个是个小型的需求，所以应
该讲一到两个小时应该就可以结束了。当然，在昨天的邮件里，我也抄送了这封需求评审会议的邮件给到技术总监以及各个相关领导，知会他们有这
个事情在开展了。需求评审会也不是自己弄好了就召开，我已经提前和技术那边的老大技术总监讲过这个东西，技术总监也点头同意这个可以做，做
起来不麻烦，于是我就把需求文档给整理出来，召开各需求评审会，准备把这个功能给做出来。看了来看下午要讲的原型之后，就到早上九点半了，
我打开钉钉，点开了为这个需求而组建的钉钉群，@所有人要记得今天下午两点钟前来召开需求评审会，看着各位同事都回复收到之后，我放下心来
，下午的评审会召开应该没什么问题了。我再单独通知了我们的业务部门的同事，也告诉他今天下午前往某会议室召开需求评审会，因为他不属于技
术部门的，所以不会在那个钉钉群里，顶顶群里都是产品、研发和测试人员，为了方便后期开发的时候好沟通才组成的，而业务部门，是需求的提出
方，只要需求传达给了产品经理，那么产品经理就负责和研发对接进行实现就好。之所以邀约业务部门的人参加需求评审会，目的是让业务部门再看
看，我给技术讲解的过程，和业务部门传达给我的需求，是不是一样的，确保信息的传达是准确无误的。业务部门的同事知道了下午的开会时间和地
点，也回复我说没有问题，下午准时参会。各方面情况都协调到位了之后，我就要做自己的准备了。其实关于这个需求，我也不需要准备什么，我大
致把我的需求文档和原型图过一遍，想想开发可能会问到的问题，并在脑子里预演一下如何回答，然后再看看自己画的一些流程图，确认都没问题之
后，就可以了。在我思考中的时候，钉钉的闪烁打断了我的思路，点开一看，是产品总监在跟我说这边领导有个紧急的需求，要我和某个业务的同事
对接一下，把这个需求给梳理出来，这两天召开评审会，具体的细节让我咨询某个业务部门。我回复说收到，马上根据这个人的名字，通过钉钉搜索
出这个人来，并跟他说了刚刚产品总监有交代我一个紧急需求说需要和你对接一下，他回答说是的后问我什么时候有空，最好当面沟通，这个钉钉里
说不明白。我说下午四点钟吧，因为我下午2点到4点这段时间要开个需求评审会。对方回答说没有问题，这件事情就过了。我的思绪再继续思考下
午的需求评审会中，此时的钉钉又闪烁起来，又有人在群里@我了，我又打开钉钉群，原来是之前跟进的一个开发的群里在问我问题，这个需求已经
进入测试阶段了，下周就要上线并交付使用了，大概情况就是测试觉得有个功能研发没有做好，有个小功能操作起来不顺畅且有点反人类设计，研发
说这个细节在需求文档没说明清楚，所以就做成这样了，最后研发和测试都来找我让我决定这个到底该怎么做，改还是不改？我看了看他们的在群里
说的情况，我思考了一番之后，回复说这个东西还是要改动，按照刚刚测试的说法改会更人性化一些。开发在群里回复说好的那就改，然后我再叮嘱
测试说改好之后再重点测测这个功能。回复完了群之后，又有一个钉钉群在@我问题，我又做出了回答，没办法，毕竟需求文档不可能面面俱到，有
些东西只能在开发的过程中才能暴露出问题，但这也没什么，只要回复好就行。我把刚刚我决定的东西再次记录到我的相应需求的文档中，作为记录
，不然下次都不记得当初做了什么改动，记得东西多了就会忘记了。把刚刚在钉钉群里讨论的改动小问题记录在需求文档之后，我再把这些文档上传
到公司的SVN上（SVN可以理解为共享空间，就是我修改后在这个上面更新，其他人只要登录上去就能看到我最新更新的文档，不用自己重新下
载替换等，是一种云文档管理方式）这样一来一回，很快就到中午十一点半了，因为午餐可以提前十五到二十分钟去吃，所以在这个时候，我休息了
一下，玩了下手机，到了11点45分，我就和同事一起去吃饭了，也有一些同事是自己带饭的，公司有微波炉可以热饭吃。午间的休息都是伴随着
玩手机和趴在工位上睡觉度过，有的同事会买折叠床，但我嫌麻烦就从来没买过，一晃就到了两点的下午上班时间，会议举行的时间是两点半，太早
两点也不好，刚睡醒同事们都还没准备好呢，太晚了，怕是被拖去忙别的事情又拖拖拉拉的来开会，所以我觉得两点半是刚刚好的时间，刚好给了研
发和业务同事们准备的时间。我一般会提前10分钟先到会议室准备，带着自己的手提电脑，到了会议室，把投影仪打开调节好，就再坐着等待其他
人员登场了。顺便一提的是，会议室一般都是提前预定的，一般会在公司的oa系统预订，小型一些的公司因为人少可能就不需要。前端两名和后台
两名以及测试1名同事已经在2点中到达会议室并落座，业务人员1名来晚了几分钟，我们也已经习惯了。在互联网中，我觉得挺有意思的一点就是
，各职能并不是权力越大工资越高，得看职能的难易程度。其实在整个团队中，最能决定事情的是产品，而产品很多时候又要咨询业务部门的意见，
也就是最终的拍板人还是业务部门的人，最没有话语权或者说决定权的是研发，研发只需要按照产品和业务定的规则去实现即可，这就好像是建筑行
业，工人是研发，项目经理是产品，业务部门的人就是老板，然而工资等级一般确实倒过来，也就是业务部门一般薪资低于产品，产品低于研发。在
召开需求评审会的时候，ui设计师一般是不需要参与的，因为ui设计师，只需要负责画图就行，不必参与需求的讨论，测试是必须要参加的，而
且测试在召开评审会的时候一般都是不说话的，他的角色就像是刻录机，把会上的所有信息都装到脑子里，然后在研发开发完成后，测试就要根据那
天开的需求评审会的情况，结合需求文档和原型图测试一遍，哪些产品在会上说了要重点测试，哪些可以随意，一些没办法写在文档上的，通过口头
说的，测试人员就得记住，这就是为什么测试人员需要参加各种需求评审会，而且一般他们都不说话，就默默的听。好了，需求评审会马上开始。首
先我投影的是什么东西呢？我投影出来的东西是原型图，也就是我用axure画的低保证界面，这些图旁边都会附带一些文字说明。我说：那么接
下来我们就召开需求评审会，我先交代一下需求背景，即为什么要实现这个需求，以及实现了的意义和好处。因为年底将至，我们想在我们的app
上搞营销活动，这样能活跃新年的氛围，也对我们app和微信的用户活跃度有所帮助，所以我们决定本期做一个功能叫拼团群开红包，类似于拼多
多的功能，通过微信分享，凑齐人就可以开红包，奖品是我们的优惠券，优惠券金额不等。实现的地方是在我们的微信小程序上。好的，讲完了需求
背景，那我们就开始讲详细的需求。首先请大家看投影出来的流程图，这个流程是这样的，由一个人（比如a）通过点击小程序页面的某个按钮发起
拼团，这个人就成为了该团的团长，然后他通过微信分享给其他人，其他人加入他的团，直到他凑够人数，则成功开团，获得优惠券奖励。以上是正
常流程，接下来讲解非正常流程，第一个是，到了这个点，我们有一个判断，判断这个人凑团是否过了时间，一个人要在规定时间内凑齐人，而如果
过了规定时间，则要弹窗提示，这是第一点，第二点是如果用户拼团成功，但优惠券库存用完了，没法派发了怎么办？这个时候后台如何保障充足的
库存？第三点第四点第五点......此处省略了很多问题，一般在讨论流程的时候，研发会不停地提出问题，这些问题一般是为了让研发他们更
好的了解这个流程，然后也会提出自己的一些不明白的地方，直到你把这个流程给研发讲明白讲透彻，当然我也不是神仙，研发问的有些问题我也回
答不上来，当我没办法决定的时候，业务部门的人就会发话，他说的就是决定，当然我们也可以对他提出决定的合理性提出自己的观点来质疑，不过
在模凌两可的情况下，还是听业务部门的即可。研发有时候也会内部互相讨论，讨论这个该怎么实现，四个研发，两个前端两个后台，会在会上讨论
这个需求他们该怎么配合能达到，他们互相讨论的东西，我和业务一般是听不太懂的，就等他们讨论，讨论完了，他们说ok,我就接着讲下一个逻
辑，直到所有逻辑他们都点头说ok为止。好了，讲完了流程图，其实这个需求已经讲完了80%了，因为页面呈现的东西，其实工作量在前端工
程师，而页面这个就好比人的一张脸，你想让他长得美长得丑鼻子高还是眼睛大这都是产品经理决定就行，但鼻子和眼睛必须要齐全，也就是说，页
面的按钮要齐全，至于按钮你想怎么摆放，产品说的算就行。比较复杂的其实是后端工程师（一般是java工程师）的工作量比较大，他的工作是
写逻辑，相当于人脸背后的思维，比如一个人在接触到外部反应后的面部表情，喜怒哀乐，就是需要通过脑子思考并呈现在脸上，而后端工程师就是
写这些逻辑问题。而逻辑问题，就是我画的流程图，我的流程图走顺了走通了，后端工程师也就可以根据我的逻辑去做去开发了，前端工程师，其实
更接近ui设计师，只是前端工程师是把ui设计师画的图转换为代码呈现到终端如电脑或手机上，然后通过一个叫“接口“的东西，来接收后台的
信号，比如有人打你一巴掌，你觉得疼，这个流程是有人打你一巴掌，是外界发生的事情，人接收到了这个被打的信号，脸部（前端）通过神经（接
口）传递给脑子（后台），后台接收到了信号后，进过逻辑处理后，发出疼痛想哭的指令，再次通过神经（接口）返回给脸和身体的其他各个部位（
前端），表现出来了我很疼想哭。就是这么一个情况。所以召开需求评审会，讲逻辑我得花去百分之八十的时间，期间研发不断问我这个流程的问题
，哪些特殊情况该怎么办？我就一一回答，回答不了我就找业务部门确认，最终完全定下来。最后我再过一下前端的页面，让大家可以更加直观的看
见原来最终做出来的呈现在我们眼前的就是这个效果，最后会议结束。所以召开两个小时其实是很短的，讨论东西会觉得时间过的很快，一眨眼就两
个小时了，有时候还觉得时间不够。会议结束后，大家都散会了，我回到自己的位置上，我要做两件事情。第一件事情是把刚刚开会讨论的一些我没
有想到但又在会议上决定的东西，体现在我的原型图中。第二件事是在做完第一件事情之后，我要发送会议纪要，包括这次会议上临时决定的一些比
较重要的内容以及附上我的原型图发给在会上的所有人，以及抄送给各部门的大佬让他们知悉情况。做完这些已经快要下班了，有时候这些做不完我还要留到第二天去做。然后我还要在一个叫teambition的任务管理系统中，把这个需求的进度从“未评审”改为“已评审”，这个任务管理系统整个团队都能登录在电脑中看到，就知道这个需求的进展了，然后涉及到这个需求，也就是今天开会的研发和测试就会在线上领取这个需求，每天在上面标注自己的完成进度，比如今天百分之十，明天百分之二十，遇到了什么情况等，我们就可以实时去观察进展了。对了，早上说的一个紧急需求需要对接，我一忙起来又忘了，只能等明天了。 |
|
