产品方法论:需求变更

标签: 产品 方法论 需求 | 发表时间:2011-02-09 12:05 | 作者:大徐 盛开
出处:http://ucdchina.com/rss/all

IT行业中失败项目的比例可以说明“项目管理”是很难做好的事情,项目失败的原因千千万,我认为需求管理、需求变更管理是个很重要的因素。恰恰PM的工作缺不了项目管理,更缺不了对于需求的管理,偶然的原因,和团队分享了我对于项目进行中“需求变更”的理解和管理方法。忽然发现之前写过很多产品思考和细节思考的东西,但从没有整理出方法论,后续应该多整理下方法论。

我认为对需求变更这件事是需要无限关心的,它的目的在于两点:
1,管理需求变更的过程,实际上是不断明确项目目标的过程,是自我完善的过程。
2,需求变更对虚拟团队的打击是PM需要避免的,无论是对PM的信任度,还是对于自身的挫折感,都很重要。

我整理的需求变更循环如下:

1,需求质量
需求包含调研过程、沟通过程、文档产出等内容,PM前期需要尽可能的想清楚、表达清楚,包括大局、节奏和细节。需求质量的高低能够对后续的变更起到决定性的作用,杂乱无章、漏洞百出的需求必然会导致无尽的需求变更。但需求质量也并不是绝对的,要看项目,看开放方案,对于敏捷开发来说,质量要求也许70分就够了,快速迭代才是硬道理。对于重大项目,也许要80分才能过各级的评审。但无论如何60分是必须的,需求达到一定质量才能立项进入开发阶段,这也是一般情况下采取的项目评审方式。

2,团队理解一致
PM团队、项目虚拟团队的沟通效果最重要,要明确每个人的理解一致。PM把自己的调研、设想、预期描述清楚是第一步,这也是PM的必须课。但更重要的是要明确每个人的理解是一致的。要知道很多时候不同的人对于同一句话,同一个描述段落,理解很有可能是不一致的,这必然会导致后续的发展不一致。因此团队成员每一个人的理解是一致的这件事很重要,不光是为了给大家洗脑,更重要的是让大家做同一件事。

3,越早发现问题越好
问题发现的越早,产生的破坏力越小,对项目进度的影响也越小。可行的方法有很多,随时关注开发进度、进行每日例行站会都是好方法。PM的责任当然不是启动开发后把所有的事情交由项目经理(或者开发负责人,或者什么人)去管理,正确的方式应该是要不自己就是项目经理,要不自己也参与项目的管理工作,最低自己也得随时关注项目的进度。

4,积极面对
发现问题后不能等待,要么变更要么放弃,必须做出选择。事实上经常会遇到一些情况,让我们很难去积极面对,比如资源紧张,比如时间紧张,比如麻烦太大,比如无法向老板交代,比如无法向同学们解释,比如会让同学们鄙视等等。但不作为永远都是下下策,积极面对是解决问题的唯一出路,也是必须要使用的方式。

5,及时更新文档
文档虽然不是最重要的,但记录变更非常重要。无论是对团队成员来说,还是对自己来说,记录变更内容都是非常重要的。每个人的记忆力都是有限的,每次评审都是没有记录的,每次邮件都是杂乱无章的,每次会议纪要都是不正式的。唯一正式、可靠的就是需求文档,将变更内容及时更新不但是良好的工作习惯,也是对项目团队负责人的表现,任何人这样做都会获得别人的尊重。

6,冻结时间点
需求太多、诱惑太多、我们每个人都是个完美主义者。无论是从用户角度出发,还是从自己的完美癖好出发,还是从领导交差出发,好像都需要把事情做到极致。但极致是需要一步一步来的,为了避免项目延期、成员灰心丧气,我们需要有个冻结需求的时间点。同事为了保护团队和项目进度,要自我严格执行,任何时候都反过来想一想,我自己是不是已经成为了项目失败的原因,想一想我的所作所为是不是已经是问题本身而不是解决问题的方法了。

7,必要的妥协
事无完美,快速迭代得永生。无论是技术代价还是人力代价,都是有阀值的,虽说技术没有实现不了的想法,人力代价往往也不是问题,但时间代价是实实在在的。而且,世界上没有一口吃成胖子的事情,也没有万事如意的情况。妥协是必要的甚至是每天都要面对的,妥协并不是放弃,而需要仔细的思考和规划。也许之前考虑的就不成熟,也许后续可以更好的安排。

8,事后总结,才能进步,避免重蹈覆辙。

源地址:http://daxu.net/archives/1333.html

相关 [产品 方法论 需求] 推荐:

产品方法论:需求变更

- 盛开 - 所有文章 - UCD大社区
IT行业中失败项目的比例可以说明“项目管理”是很难做好的事情,项目失败的原因千千万,我认为需求管理、需求变更管理是个很重要的因素. 恰恰PM的工作缺不了项目管理,更缺不了对于需求的管理,偶然的原因,和团队分享了我对于项目进行中“需求变更”的理解和管理方法. 忽然发现之前写过很多产品思考和细节思考的东西,但从没有整理出方法论,后续应该多整理下方法论.

中台工具产品方法论

- - 戴传庆
做中台工具产品不是一件容易的事情,需要对接上层所有业务方,做的慢业务方不满意,做的快业务方未必会给好的评价. 属于容易背锅,细节极其多,用户反馈建议多,但又难以出成绩和证明自己做的好. 虚构一些场景,大家肯定都遇到过. 老板:XX功能我觉得不错,做了吗. 老板:XX和XX等N个功能都不错,马上排期做下.

需求分析中的产品定位

- Jessica - 所有文章 - UCD大社区
看过《定位》最大的感受就是产品在诞生之前就决定了他是否能存活或成功. 就像走在商场中,面对玲琅满目的产品,你似乎很难找到一两款绝对同质化的大品牌:. 各式的服装,NIKE的衣服是运动的,但也不会和做户外运动的哥伦比亚冲突. 都是做化妆品,Fancl打出“无添加”没有防腐剂也收获了一群喜爱天然的用户…...

跑步者的产品需求

- fyits0 - 《商业价值》杂志
国家标准滞后了,行业标准落伍了,客户需求才是真正的标准. 跑步在欧美等运动发达地区已有几十年的发展历史. 20世纪70年代的时候,大多是那些看上去黑黑瘦瘦,一周训练很久,追求成绩的运动员在跑. 其后随着社会发展,越来越多的普通人开始跑步. 《阿甘正传》热映,跑步公益组织相继诞生,“如果奥普拉可以跑完全程马拉松,你也可以.

产品需求的4层关系

- - 人人都是产品经理
互联网产品需求,其实跟以前我们做开发的软件需求基本是类似的,我也不知道是不是大家从那里搬过来的,暂且不考究这个. 今天说下产品需求的4层关系; 首先先说是哪4层:. 看官别着急,单独拉出来一个系统需求是有原因的,如果你不是三五年内的小白产品应该能看懂. 业务需求(business requirement).

产品需求分析:用户的“奶酪”不要碰

- paaboo - 所有文章 - UCD大社区
花了差不多2周时间去研究了卖猪肉的商贩,当和行业内朋友谈及这个形象的范例时,他们满是奇怪表情,因为一个做互联网产品的人,不好好做的你的产品,去研究卖猪肉商贩干什么. 先别急,我们都知道产品需求分析是一个产品经理必修课,其实就是在项目立项之后需要把抽象的产品概念及用户业务核心需和内部的发散性的功能点集中并提炼出来并形成一个具体可见可演示的成果.

需求是如何变成产品原型的

- Zhang Yi - 互联网的那点事...
在一个互联网公司的工作流程中,产品经理(主要指偏向产品设计的产品人员)和交互设计师是这个流水线上最起点的环节,也是关系最暧昧的两个环节. 说其暧昧,是因为在很多互联网公司里面,这两个环节所做的事情是有重合的,这就意味着,他们或许也是整个流程中合作最紧密的两个环节. 相对比之下,产品经理更关注的是产品的内部逻辑、操作流程、策略等;而交互设计师更关注的是产品的易用性、流畅度和操作感受.

常见的产品需求获取来源

- - 博客 - 伯乐在线
日常需要做新的产品或者新的项目的时候,总是愁苦该去哪里获取到足够多的原始需求,闭门造车显然不是最好的方式,那样会使产品带上浓重的个人主义色彩. 其实一般有新的项目需要上马,至少总会有个愿景,根据这个再去挖掘需求就稍微容易一点,最怕的就是那种没有方向的,一切都是实验性质的,需要做着做着才能找到方向的项目,刚开始的时候会茫无目的.

产品需求背后的用户动机

- - 月光博客
  在以用户为中心进行产品设计时,产品负责人需要透过简单的需求现象,寻找用户针对这种需求的行为动机是什么,只有这样才能真正达到服务用户的目的. 当我们使用 Foursquare、街旁签到时,这一行为有什么目的. 当我们在知乎上回答问题时,我们的动机是什么. 我们为什么会积极支持 Kickstarter 上的项目.