内容简介:需求管理/方案设计与需求评审,如何将零散的工作整理整理得井井有条?这篇文章给了我们作者的思考,希望对你有所帮助。高效完成工作,准点回家,能有更多的时间陪伴家人及自我提升,是我向来非常希望实现的工作状态。
需求管理/方案设计与需求评审,如何将零散的工作整理整理得井井有条?这篇文章给了我们作者的思考,希望对你有所帮助。
高效完成工作,准点回家,能有更多的时间陪伴家人及自我提升,是我向来非常希望实现的工作状态。
无奈长期以来自己的各种无意识的习惯一直起主导作用,自己被推着走,始终没下狠心做出改变。
近来随着工作的越发繁忙,工作、身体、生活趋于恶性循环,对于工作效率提升的紧迫感越发强烈。
这篇文章期望通过梳理回顾自己的产品日常工作,整理出工作流程及重点,找到并优化那些可能有坑的地方,达到高效工作的目的。
产品经理最为日常的工作,可以分为:需求管理、方案设计及原型产出、需求评审、研发及测试跟进。
一、需求管理
1.内容管理
在内容层面,需求管理可以指需求的来源管理,覆盖的范围包括:
- 产品主动进行的用户调研及需求采集
- 产品主动根据线上产品表现(数据分析、用户行为等)提出的优化或新功能
- 产品被动接受的外部需求
2.优先级和重要性管理
之所以要管理需求的优先级和重要性,最直接的原因是:研发资源是有限的,而需求是无限的。除此之外,无序地堆砌需求,毫无目的和定位,只会导致产品最终臃肿不堪。
基于以上的基本情况,我想到的可以优化的点包括:
1.专门的用户调研及需求采集是比较费时间的。在版本定期紧凑迭代的情况下,产品很可能没有整块、足够的时间用于用户调研,而通过临时拍脑袋、臆想用户可能的场景来设计产品,最终的方案很大可能不能有效解决用户的痛点。
我想到的方案是,用户调研的时间分散到平时,而不是等到需要出需求的时候。比如:
- 跟进线上问题的时候,除了了解用户出现问题的场景,也可以借机了解用户使用相关功能的场景、心得、评价、痛点.。
- 线上问题要及时地记录,并定期整理分析,可以集中发现问题及待优化点。
- 提前一个版本发放下一个版本所需的用户调研问卷,提前收集用户意见。能这样做的前提是产品对下一版本的规划已经有了初步思考。
2.数据分析和用户行为分析,工作也要花在平时。比如每周定时监控和分析线上数据情况。针对发现的问题,可以抽至少一位用户聊一聊,或者观察他对某些功能的实际操作场景,也可以借此验证行为数据是否正确。
3.对于外部对接的需求,比较耗费时间的是需求内容的反复沟通和确认、需求变更的风险把控、技术方案的沟通、双方研发资源及配合时间的协调等等。对接得不好,不单只浪费产品的时间,也浪费研发的时间,甚至影响整个团队的产出。
个人感觉,外部对接需求,更多地要运用到项目管理的智慧。项目管理的核心是把控风险,协调资源,按时按质交付。在外部对接需求上,风险体现在需求内容的变更、研发资源的变更、配合时间的变更。
产品在这几个关键节点上尤其要注意把控:
- 前期一定要明确支持的需求范围,所有内容在需求范围内讨论。
- 对方产出明确的原型和需求文档后,才开始分配时间和资源对接,不接受“一句话需求”。
- 需求内容和细节都对接清楚后,双方通过邮件明确双方配合的时间、对接人、版本等。
- 人算不如天算,对接得再清楚也有可能有变数,比如上线时间调整、研发资源调整等。
如果是外部的需求方调整,我方的应对策略可以有:
A.注意几个关键时间节点的确认。我方需求评审前、我方技术方案评审前、我方研发开始前,注意跟对方确认可能的变数,减少我方的被动情况。
B.在一开始需求对接时,即跟对方明确,如果对方需求变更,我方的惩戒措施。
如后续的需求优先级自动降级、版本延后处理等,通过明确犯错成本让对方重视对接。
C.万一遇到开发开始后的需求变更:
a.如果只是开发前期,迅速补充其他备用需求,协调研发和测试重新评审和排期。减少研发资源的无端浪费。
b.如果到了开发的中后期,除了启动惩罚措施,似乎只能认栽。
如是我方的研发资源和上线时间有调整,则尽可能提前周知对接方,减少对方的资源浪费,让对方及时调整版本和排期。
外部对接一个总的原则是:细节前期明确,风险前期暴露,节约的是双方的资源和时间。
二、方案设计及原型产出
1.准备工作
方案设计的前提是,用户调研已整体完成、数据分析结果有了明确指向、外部需求内容已经确定。
但在设计方案的时候,依然会涉及到一些不确定因素,比如技术实现可能性、技术实现最优方案等。这个时候,一定要明确自己产品设计的初衷,以及要解决的问题,确保自己是了解用户的使用场景的。然后才在完成产品方案初步框架后,找相应的技术负责人咨询确认可能性,避免走弯路。
这里要注意的是: 一定要找对技术全局和细节都足够了解的人,不然一定是更多的弯路。
2.流程梳理
原型产出前,需先进行所有流程细节的梳理,流程的梳理一定是减少返工和遗漏的重要环节。
3.交互参考
对一个功能的实现,可能有很多种交互方案。如何让自己的设计的方案不至于怪异而不符合潮流,可以充分参考市面上已有的交互设计。
如果平时喜欢研究并总结各类产品交互,这个时候就能省下些时间。如果想法不够,找寻对比知名产品的交互方案必不可少。
建议在参考别人前有自己的初步想法,且自己要的效果应该是明确的,不然有可能挑花眼、被带偏,白白浪费时间。
4.模板积累
平时注意积累出自己的一套标准的原型模板,包括框架、图文排布、元素等等,方便快速产出。
三、需求评审
从评审听众的分类看,需求审批的种类包括:业务方评审,产品内部评审、需求终审(含产品、研发、测试、UI、UE)、技术方案评审、测试用例评审。
不同的评审,产品的侧重点不同:
- 业务方评审,注意确认产品方案符合业务方的需求。
- 产品内部评审,注意将自己的疑惑点、特殊场景抛出来,征求同伴的意见。
- 需求终审,确保自己对流程、细节已经完全把握,注意记录争议点,会后重新讨论设计,注意把控评审时间、评审节奏和评审氛围。
- 技术方案评审,研发是主角,其次是测试,最后才是产品。产品注意确认研发伙伴对需求的理解正确,以及对需求有疑问的地方。
- 测试用例评审,测试是主角,其次是研发,最后才是产品。产品确认测试用例覆盖了产品所有的需求点,还有极限情况和特殊情况。
一轮又一轮的评审,其实是非常占用时间的。评审开始前,产品最好对可能出现的争议点有预估,方便把控评审节奏和评审时间。
别人主导的评审,如技术方案和测试用例评审,产品如果提前拿到了文档,可以提前审阅,对于有疑议的地方记录下来,在会上重点讨论;这样一来,会议期间也可以处理一些其他琐事,不至于完全被占用。
四、研发及测试跟进
- 研发阶段,主角是研发,产品主要确认需求不明确或有争议的地方。
- 测试阶段,主角是测试,产品及时处理指向自己的BUG。在第二轮测试完成后介入验收,尽早发现问题。
研发和测试阶段,产品可以花更多时间在下个版本的产品调研、方案设计。
总的来说,提高产品经理工作效率的方法:
- 产品心中一定要有一个明确的工作主流程。
- 明确每个阶段(每个版本、项目每个阶段、每月、每周、每天)的工作重点。
- 在各个阶段见缝插入琐事处理(如线上问题跟进、需求细节等)和常规工作(数据分析、用户调研等)。
- 减少重复沟通、确认环节,准备充分,风险前置。
- 注意预估和总结每种工作内容的工作时长,能更好规划自己的工作时间。
- 平时注意积累产品文档、产品交互、产品方法。
作者:产品一二一,微信公众号:产品一二一
本文由 @产品一二一 原创发布于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash ,基于 CC0 协议
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 完整的语音交互,需要经过这五个环节
- 90% 以上的独立开发者,败在了认知环节
- Debian 开发者商榷在会议上不允许进行问答环节的想法
- Debian 开发者商榷在会议上不允许进行问答环节的想法
- 对话搜狗陈伟:机器同传的关键是做好语音识别、机器翻译的中间环节
- 照片整理系列二 —— 照片整理及归档的辛酸历程
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
数据驱动设计
[美]罗谢尔·肯(RochelleKing)、[美]伊丽莎白F.邱吉尔(Elizabeth F Churchill)、Caitlin Tan / 傅婕 / 机械工业出版社 / 2018-8 / 69.00元
本书旨在帮你了解数据引导设计的基本原则,了解数据与设计流程整合的价值,避免常见的陷阱与误区。本书重点关注定量实验与A/B测试,因为我们发现,数据分析与设计实践在此鲜有交集,但相对的潜在价值与机会缺大。本书提供了一些关于在组织中开展数据实践的观点。通过阅读这本书,你将转变你的团队的工作方式,从数据中获得大收益。后希望你可以在衡量指标的选择、佳展示方式与展示时机、测试以及设计意图增强方面,自信地表达自......一起来看看 《数据驱动设计》 这本书的介绍吧!