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

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

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

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

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

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

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

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

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

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

一、需求管理

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 协议


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

查看所有标签

猜你喜欢:

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

数据驱动设计

数据驱动设计

[美]罗谢尔·肯(RochelleKing)、[美]伊丽莎白F.邱吉尔(Elizabeth F Churchill)、Caitlin Tan / 傅婕 / 机械工业出版社 / 2018-8 / 69.00元

本书旨在帮你了解数据引导设计的基本原则,了解数据与设计流程整合的价值,避免常见的陷阱与误区。本书重点关注定量实验与A/B测试,因为我们发现,数据分析与设计实践在此鲜有交集,但相对的潜在价值与机会缺大。本书提供了一些关于在组织中开展数据实践的观点。通过阅读这本书,你将转变你的团队的工作方式,从数据中获得大收益。后希望你可以在衡量指标的选择、佳展示方式与展示时机、测试以及设计意图增强方面,自信地表达自......一起来看看 《数据驱动设计》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

随机密码生成器
随机密码生成器

多种字符组合密码

正则表达式在线测试
正则表达式在线测试

正则表达式在线测试