如何将需求环节零碎的日常整理到井井有条?

栏目: 编程工具 · 发布时间: 7年前

内容简介:需求管理/方案设计与需求评审,如何将零散的工作整理整理得井井有条?这篇文章给了我们作者的思考,希望对你有所帮助。高效完成工作,准点回家,能有更多的时间陪伴家人及自我提升,是我向来非常希望实现的工作状态。

需求管理/方案设计与需求评审,如何将零散的工作整理整理得井井有条?这篇文章给了我们作者的思考,希望对你有所帮助。

如何将需求环节零碎的日常整理到井井有条?

高效完成工作,准点回家,能有更多的时间陪伴家人及自我提升,是我向来非常希望实现的工作状态。

无奈长期以来自己的各种无意识的习惯一直起主导作用,自己被推着走,始终没下狠心做出改变。

近来随着工作的越发繁忙,工作、身体、生活趋于恶性循环,对于工作效率提升的紧迫感越发强烈。

这篇文章期望通过梳理回顾自己的产品日常工作,整理出工作流程及重点,找到并优化那些可能有坑的地方,达到高效工作的目的。

产品经理最为日常的工作,可以分为:需求管理、方案设计及原型产出、需求评审、研发及测试跟进。

一、需求管理

1.内容管理

在内容层面,需求管理可以指需求的来源管理,覆盖的范围包括:

  • 产品主动进行的用户调研及需求采集
  • 产品主动根据线上产品表现(数据分析、用户行为等)提出的优化或新功能
  • 产品被动接受的外部需求

2.优先级和重要性管理

之所以要管理需求的优先级和重要性,最直接的原因是:研发资源是有限的,而需求是无限的。除此之外,无序地堆砌需求,毫无目的和定位,只会导致产品最终臃肿不堪。

基于以上的基本情况,我想到的可以优化的点包括:

1.专门的用户调研及需求采集是比较费时间的。在版本定期紧凑迭代的情况下,产品很可能没有整块、足够的时间用于用户调研,而通过临时拍脑袋、臆想用户可能的场景来设计产品,最终的方案很大可能不能有效解决用户的痛点。

我想到的方案是,用户调研的时间分散到平时,而不是等到需要出需求的时候。比如:

  • 跟进线上问题的时候,除了了解用户出现问题的场景,也可以借机了解用户使用相关功能的场景、心得、评价、痛点.。
  • 线上问题要及时地记录,并定期整理分析,可以集中发现问题及待优化点。
  • 提前一个版本发放下一个版本所需的用户调研问卷,提前收集用户意见。能这样做的前提是产品对下一版本的规划已经有了初步思考。

2.数据分析和用户行为分析,工作也要花在平时。比如每周定时监控和分析线上数据情况。针对发现的问题,可以抽至少一位用户聊一聊,或者观察他对某些功能的实际操作场景,也可以借此验证行为数据是否正确。

3.对于外部对接的需求,比较耗费时间的是需求内容的反复沟通和确认、需求变更的风险把控、技术方案的沟通、双方研发资源及配合时间的协调等等。对接得不好,不单只浪费产品的时间,也浪费研发的时间,甚至影响整个团队的产出。

个人感觉,外部对接需求,更多地要运用到项目管理的智慧。项目管理的核心是把控风险,协调资源,按时按质交付。在外部对接需求上,风险体现在需求内容的变更、研发资源的变更、配合时间的变更。

产品在这几个关键节点上尤其要注意把控:

  • 前期一定要明确支持的需求范围,所有内容在需求范围内讨论。
  • 对方产出明确的原型和需求文档后,才开始分配时间和资源对接,不接受“一句话需求”。
  • 需求内容和细节都对接清楚后,双方通过邮件明确双方配合的时间、对接人、版本等。
  • 人算不如天算,对接得再清楚也有可能有变数,比如上线时间调整、研发资源调整等。

如果是外部的需求方调整,我方的应对策略可以有:

A.注意几个关键时间节点的确认。我方需求评审前、我方技术方案评审前、我方研发开始前,注意跟对方确认可能的变数,减少我方的被动情况。

B.在一开始需求对接时,即跟对方明确,如果对方需求变更,我方的惩戒措施。

如后续的需求优先级自动降级、版本延后处理等,通过明确犯错成本让对方重视对接。

C.万一遇到开发开始后的需求变更:

a.如果只是开发前期,迅速补充其他备用需求,协调研发和测试重新评审和排期。减少研发资源的无端浪费。

b.如果到了开发的中后期,除了启动惩罚措施,似乎只能认栽。

如是我方的研发资源和上线时间有调整,则尽可能提前周知对接方,减少对方的资源浪费,让对方及时调整版本和排期。

外部对接一个总的原则是:细节前期明确,风险前期暴露,节约的是双方的资源和时间。

二、方案设计及原型产出

1.准备工作

方案设计的前提是,用户调研已整体完成、数据分析结果有了明确指向、外部需求内容已经确定。

但在设计方案的时候,依然会涉及到一些不确定因素,比如技术实现可能性、技术实现最优方案等。这个时候,一定要明确自己产品设计的初衷,以及要解决的问题,确保自己是了解用户的使用场景的。然后才在完成产品方案初步框架后,找相应的技术负责人咨询确认可能性,避免走弯路。

这里要注意的是: 一定要找对技术全局和细节都足够了解的人,不然一定是更多的弯路。

2.流程梳理

原型产出前,需先进行所有流程细节的梳理,流程的梳理一定是减少返工和遗漏的重要环节。

3.交互参考

对一个功能的实现,可能有很多种交互方案。如何让自己的设计的方案不至于怪异而不符合潮流,可以充分参考市面上已有的交互设计。

如果平时喜欢研究并总结各类产品交互,这个时候就能省下些时间。如果想法不够,找寻对比知名产品的交互方案必不可少。

建议在参考别人前有自己的初步想法,且自己要的效果应该是明确的,不然有可能挑花眼、被带偏,白白浪费时间。

4.模板积累

平时注意积累出自己的一套标准的原型模板,包括框架、图文排布、元素等等,方便快速产出。

三、需求评审

从评审听众的分类看,需求审批的种类包括:业务方评审,产品内部评审、需求终审(含产品、研发、测试、UI、UE)、技术方案评审、测试用例评审。

不同的评审,产品的侧重点不同:

  • 业务方评审,注意确认产品方案符合业务方的需求。
  • 产品内部评审,注意将自己的疑惑点、特殊场景抛出来,征求同伴的意见。
  • 需求终审,确保自己对流程、细节已经完全把握,注意记录争议点,会后重新讨论设计,注意把控评审时间、评审节奏和评审氛围。
  • 技术方案评审,研发是主角,其次是测试,最后才是产品。产品注意确认研发伙伴对需求的理解正确,以及对需求有疑问的地方。
  • 测试用例评审,测试是主角,其次是研发,最后才是产品。产品确认测试用例覆盖了产品所有的需求点,还有极限情况和特殊情况。

一轮又一轮的评审,其实是非常占用时间的。评审开始前,产品最好对可能出现的争议点有预估,方便把控评审节奏和评审时间。

别人主导的评审,如技术方案和测试用例评审,产品如果提前拿到了文档,可以提前审阅,对于有疑议的地方记录下来,在会上重点讨论;这样一来,会议期间也可以处理一些其他琐事,不至于完全被占用。

四、研发及测试跟进

  • 研发阶段,主角是研发,产品主要确认需求不明确或有争议的地方。
  • 测试阶段,主角是测试,产品及时处理指向自己的BUG。在第二轮测试完成后介入验收,尽早发现问题。

研发和测试阶段,产品可以花更多时间在下个版本的产品调研、方案设计。

总的来说,提高产品经理工作效率的方法:

  1. 产品心中一定要有一个明确的工作主流程。
  2. 明确每个阶段(每个版本、项目每个阶段、每月、每周、每天)的工作重点。
  3. 在各个阶段见缝插入琐事处理(如线上问题跟进、需求细节等)和常规工作(数据分析、用户调研等)。
  4. 减少重复沟通、确认环节,准备充分,风险前置。
  5. 注意预估和总结每种工作内容的工作时长,能更好规划自己的工作时间。
  6. 平时注意积累产品文档、产品交互、产品方法。

作者:产品一二一,微信公众号:产品一二一

本文由 @产品一二一 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash ,基于 CC0 协议


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。

Learning PHP, MySQL, and JavaScript

Learning PHP, MySQL, and JavaScript

Robin Nixon / O'Reilly Media / 2009-7-21 / USD 39.99

Learn how to create responsive, data-driven websites with PHP, MySQL, and JavaScript - whether or not you know how to program. This simple, streamlined guide explains how the powerful combination of P......一起来看看 《Learning PHP, MySQL, and JavaScript》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

html转js在线工具
html转js在线工具

html转js在线工具