产品经理之客户确定需求

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

产品经理之客户确定需求

客户仅仅懂得业务,不懂得怎么来实现。

而作为程序猿的我们,仅仅懂得用代码来实现功能,不一定了解客户真正想要的是什么。事实上,客户也不知道自己想要什么,所以在和客户沟通过主要业务以后,仅仅需画

原型并确定需求文档,找客户确定就能够了。尽管。说起来非常easy,可是真正实现的时候并没有想象中那么简单。

9月11日,带着自己设计的原型和需求文档,随同经理来和客户确定需求。在沟通的过程中,越来越发现自己太想当然了。

仅仅顾得依照自己的思维方式去想问题,并没有站在客户的角度来理解业务。

反而是客户在诉说业务的过程中,帮我梳理了需求。

这也充分说明:一纸文档害死人呀!仅仅有静态的文档和原型。easy让人产生歧义。当然不如当面和客户交流,更能直观清晰的明白需求。

可是。由于各种原因导致交流不便。

由于文档,也成了客户和我们之间交流的一种方式。这也更加说明写文档的重要性!

文档一定要丰富。用户须要什么功能?先后运行顺序?每一步有什么限制?一定要屡清晰

思路。

经理这时也意识到,先前仅仅顾得忙工作,没有把和客户之间的交流跟我们交代下去。

本来以为非常easy的业务,结果被我们理解的有偏差。

导致此行无果。最不愿让经理看到的是:我本着学习的心态来做项目。把功能扩展了。而对于经理而言,价钱已经谈好了。功能上仅仅要简单实现就能够了。立场不同,所以……

还真是惊喜不断呀!

本来应该是由PM确定需求后,我们仅仅负责开发的。

结果,PM却说这个项目由我和客户直接沟通。沟通后的结果须要整理成需求文档反

馈给PM。恰好锻炼一下和客户的沟通能力,这倒是挺好的。

接下来的一个星期,就是依照客户的要求进行设计原型界面,同一时候依照PM给定的模板编写需求说明书。然后反馈给PM,PM修订文档后,通过文字+电话+视频指导的方式,和我进行交流。并指出一些须要和客户确定的问题交给我来做。再加上经理的初步

验收和指导,这三人和我的耦合度实在是太紧密了,终于导致了需求文档和原型界面修订

了十五多个版本号。这叫一个纠结了。

怪不得设计模式总是说:解耦合、解耦合。这样的高耦合性,恐怕仅仅有身在当中的

人才深有体会吧!

以下和大家分享一下,我在确定需求的过程中的几点建议:

大体的流程是这种:

1.先和客户沟通想要实现什么功能?

2.整理一份粗粒度的需求文档,并设计原型。

3.找客户确认原型,并在需求文档上签字画押。

4.循环上述步骤

该怎样和客户进行交流?

1.用户须要什么功能?用户提供了哪些数据?这些数据是否可以实现用户所须要的功能?

2.注意聆听客户的要求。并用自己的语言反复给客户听。

建议:录音保存后整理。

3.软件的使用频率、使用周期、数据量是多少(比方:每月最多上传多少条记录),

以便于后期优化。

以及谁使用本系统?涉及到权限的管理。

4.专业领域的术语一定要明白。类型、是否唯一。如:"代码证号"=="组织机构代码

证号"

怎样写文档?全部人都能看懂。并正确理解就是好文档。

1.最主要的要求是:文档的格式、字体、分级、缩进、字体大小……。

须要的基本功:批注、修订。

最最重要的是:不要有错别字!

2.用通俗的语言来描写叙述、逻辑要清晰、简明扼要、不要有歧义。尽量用图片/原型+文字描写叙述的形式向客户展现。

3.重要的是:突出重点。如:是否保存历史数据?一定要找客户确认。否则就会遇到

这样的情况:客户要求扩展功能。可是原始数据都不存在了。

1)另。“已上传”未“确认”的文件。“删除”后可又一次上传。经过“确认”的文件,不可删除,请确保操作无误后。进行上传。

2)另:系统中以每月上传的最新文件为准,均不保留历史文件。

4.对照清晰。

描写叙述一种现象有非常多种情况。能够採用提取公共部分,对照差异部分的方式来

比較。

1)每月上传两次四险文件(第一次为欠费文件,第二次为已缴费文件)

2)每月上传两次医保文件(第一次为欠费文件,第二次为仍欠费文件)。

5.举例说明:假设非常难描写叙述业务。不防通过举例的方式来解释清楚。

6.提示信息模板:有必要的话採用。提示信息由客户给定模板,或者由客户手动输入。

如:设置欠费提示信息模板、不欠费提示信息模板。

7.上传文件:假设是上传Excel之类的,上传前要注意版本号兼容问题、有哪些字段、数据的格式有哪些要求。上传错误的分类情况须要一一列举,并和客户确定

8.容错处理。

系统中的全部东西都是能够手动改动的,不要写死了。

9.流程图一定要保持思维逻辑严谨。

先有图,后有说明。

怎样画原型?这里使用的是AxtureRP

1.风格要统一:

假设是子系统(小的模块),一定要仿照基础系统的风格来处理。

本系统内部样式、色调也要统一,这些都是最主要的。

假设是一个独立的系统。还须要了解客户平时经常使用什么办公软件。操作风格、布局之类的。最好要符合用户的使用习惯。

2.页面之间的交互:

不只要显示静态的页面,更要注重界面之间的交互。

使用假数据模拟真实场景。尽管。仅仅是一个原型,可是一定要让客户感觉是在真实操作系统一样。

3.友情提示不可少:

此处能够标注本界面用来干嘛的?怎样操作?有什么须要强调的地方?

工作中的一些经验拿出来,整理了一下。希望可以帮助您高效的工作。做好需求调研是战略上的决策,其重要性就不言而喻。

相关文档
最新文档