产品经理的工作方法与反思-1

产品经理日常工作方法与反思：本文分享三点 需求调研应该怎么做？如何做？有哪些步骤与方法？如何避坑？ 需求评审应该怎么做？怎样的评审才是有效的？评审后怎么推进工作？ 项目延期了该怎么处理？怎么处理才是有效的？

• 产品经理的工作方法与反思-1
• 项目延期怎么办？
  • 查明原因
    • 导致项目延期的原因：离不开需求变更、原型+规则考虑不周全、技术bug、项目工期评估有误、突然更换项目组成员等等。
    • 是其中哪个原因，还是哪几个原因，找出来，然后对症下药，争取下个版本或者其他项目，不要再犯。
  • 定解决方案
    • 出现问题不可怕，可怕的是连产品经理都手足无措，没有解决方案。
  • 上报风险
    • 项目都报风险，导致延期了，如果该知道的人还不知道相关原因的话，那就说不过去了。而且，必须给出大家合理解释。
• 如何需求评审？
  • 产品出原型+规则：
    • 评审之前，必须自己独立想清楚此次需求所有涉及到的规则。
    • 虽然，可能未必有些情况自己考虑完全周全，但必须自己用心深度思考一番。
  • 产品初步与需求方原型评审（可多次）：
    • 自己初步画的原型和规则，得先跟需求方单独过一下，确认是否达到初步预期。
    • 如果没有的话，那就要及时调整出新的原型+规则，循环往复，直到需求方满意为止。
  • 产品初步技术原型评审（可多次）：
    • 需求方搞定，那么就要单独搞定项目组中的技术成员（前端、后台、测试、UI等），技术与需求方关注的是不同的视角。
    • 技术，会问为什么有这样的页面和规则，能否解释清楚明了。
    • 技术提出的问题，你解释不清楚，那就要修改原型+规则，直到任何一个技术都没有问题为止，此轮评审才算结束。
  • 产品组织项目组所有成员正式评审：
    • 需求方与技术都搞定了，那么召集项目组所有成员，组织大会议室，进行系统当前版本的正式评审，就水到渠成了。
    • 最后调整完毕的原型+规则，必须同步给项目组所有成员，如果此次正式评审仍有疑问，那么又要重新调整原型+规则；
    • 如果没有疑问，那么项目评审成功，顺利推进到开发阶段。
  • 项目排期
    • 产品与技术讨论项目排期，并将最终确认的上线时间，汇报给需求方。
    • 如果有延期风险，必须事前告知需求方并给出合理理由。
  • 上线验收
    • 测试验收需求后，进入产品+需求方验收阶段，此时一般在灰度环境，不会影响正常线上数据。
    • 双方同意上线后，测试走上线流程，项目当前版本上线成功
• 如何需求调研？
  • 问题现状：
    • 首先，问清楚需求方遇到什么问题，
    • 其次，了解清楚要解决什么问题，不爽在哪里，痛在哪里，不解决会怎样?
    • 最后，将需求加以记录，并与需求方确认。
  • 当前流程：
    • 问题是出现了，那么当下你们是用什么方式规避这个问题的呢？
    • 现在你们的业务流程是怎样的呢?希望在流程上做哪些优化呢？
  • 用户期望：
    • 你想要的结果是怎样的？
    • 怎样的结果才是令你满意的？
  • 需求价值：
    • 这个问题解决后，对你有什么好处，产生什么价值？
  • 可行性分析：
    • 辨别真伪需求后，排好优先级，及时反馈结果。
    • 做还是不做，都要给合理解释；
    • 并不是需求方说的全部就是需求，要自我加以过滤；
    • 他说的痛，是不是以偏概全，要追踪问题的本质，他到底是要解决什么问题？