记录学习过程中的点点滴滴
Yvonne
该用户没有分享资料
Yvonne
信息分析工具之—$APPEALES【转】
二 23rd
$APPEALS 是一种市场需求和收集的方法,一般是使用在市场规划和产品规划的细分市场中,因为可以从多个维度,不同的权重来分析需求,所有$APPEALS一定会联系到细分市场,联系到竞争对手,涉及到差异化分析和蓝海的价值创新(减少,增加,剔除,创新)。差异化可以说是理解市场和分析市场中的一个重要内容,只有清楚了差异化才能够树立自己产品的核心竞争力。
- $-产品价格(Price);
- A-可获得性(Availability);
- P-包装(Packaging);
- P-性能(Performance);
- E-易用性(Easy to use);
- A-保证程度(Assurances);
- L-生命周期成本(Life cycle of cost);
- S-社会接受程度(Social acceptance)。
使用客户$APPEALS框架来确定客户的欲望与需要,建立针对每一个细分市场的产品包对应图。客户$APPEALS框架的目的主要包括以下方面的内容:
- 处理目标细分市场的全部客户欲望与需要
- 建立客户驱动的需求集,作为投资的重点
- 确定要想在所选细分市场获得成功必须达到的主要分界标准
- 确定促使客户选择公司产品的主要差异
$价格
这个要素反映了客户为一个满意的产品/交付希望支付的价格。用这个标准来要求供应商时,要从实际和感觉这两方面来考虑客户能接受的购买价格。将包括以下的数据评估:技术、低成本制造、物料、人力成本、制造费用、经验、自动化程度、简易性、可生产性等。
A保证
这个要素通常反映了在可靠性、安全和质量方面的保证。用这个标准来要求供应商时,要考虑客户在可预测的环境下关于减少他/她关注确定的性能方面如何评价整个产品?这可以包括保证、鉴定、冗余度和强度。
P性能
这个要素描述了对这个交付期望的功能和特性。用这个标准来要求供应商时,要从实际和感觉这两方面来考虑有关功能和特性的产品性能。产品工作得怎样?产品是否具备所有的必须的和理想的特性?它是否提供更高的性能?从客户角度来衡量,如速度、功率、容量等。
P包装
这 个要素描述了期望的设计质量、特性和外观等视觉特征。就软件而言它描述了交付或提供的功能包。用这个标准来要求供应商时,要考虑客户对外形、设计等意见, 还有这些属性对交付的期望的贡献程度。关于包装的考虑应该包括样式、模块性、集成性、结构、颜色、图形、工艺设计等方面。
E易用
这个要素描述了交付的易用属性。用这个标准来要求供应商时,要考虑客户对产品的舒适、学习、文档、支持、人性化显示、感觉的输入/输出、接口、直观性等方面的考虑意见。
A可获得性
这个要素描述了客户在容易和有效两方面的购买过程(例如:让客户有他自己的方式)。用这个标准来要求供应商时,要考虑在整个购买过程的优秀程度,包括预售的技术支持和示范、购买渠道/供应商选择、交付时间、客户定制能力等。
L生命周期成本
这个要素描述了所有者在使用的整个生命周期的成本,用这个要素来要求供应商时,要考虑安装成本、培训、服务、供应、能源效率、价值折旧、处理成本等。
S社会接受程度
这个要素描述了影响购买决定的其他影响。用这个要素来要求供应商时,要考虑口头言论,第三方评价、顾问的报告、形象、政府或行业的标准、法规、社会认可、法律关系、产品义务等对购买决定起了怎样的促进作用。
对 于$APPEALS方法里面涉及到很多内容,首先是要通过用户调查收集具体的用户最关心哪个维度的问题,根据这些调查数据来确定每个维度的权重;其次是要 分析自己公司和竞争对手公司的产品在先阶段各个维度的评分,然后是画出相应的雷达图进行差异化分析。根据公司的战略目标和市场策略,应该重点关注哪些核心 功能和核心需求,如何减少自己的弱势并提升自我优势以体现差异化,如何进行价值创新等。
第一次拜访客户
十二 6th
今天下午第一次拜访客户收集需求,我的感受主要有三点:
首先,直观的了解客户需要一个什么样的功能:以前听别人转述可以知道我们要实现怎样的功能,
但通常都包含了转述人对需求加工的成分,如果描述不完整还容易造成理解的偏差;今天直接听到了客户对需求的描述,我要注意自己转述的时候别扭曲了用户的原意。
其次,知道客户提出某个需求做什么用、将如何使用:客户描述了实际使用中遇到的问题,所以希望这个功能怎样怎样实现以解决这个问题。
这样便于我们理解客户提出的需求,并且站在客户的角度思考功能的实现方式。可以在一定程度上避免做出来的产品是客户不需要的,或者不符合客户的使用习惯。
最后,客户能帮助我们排除他们不会使用的场景:前期我们项目组内讨论需求时大家都尽量覆
盖猜想到的使用场景和实现方式,与客户沟通的时候他们直接回答“我们不会这么用”。
另外客户和咨询师也会顺便给出一些对产品的反馈。并且是单纯的学习产品功能不考虑用户实际使用场景时不会考虑到的。
总之收益匪浅,以后能力提高了还要主动提供解决方案供参考,以后的事儿明天再说,今天回家了先~~
需求分析小试牛刀【1】
十二 5th
上周开始可以开始参与需求工作了,暂时参与需求跟踪和需求分析两个方面,先谈谈对需求分析的认识(太教科书的东西自己已经看了很多,不再这儿赘述):
- 最初的想法:需求来源于客户,所以我们尽量采集客户的需求,然后整合规划后按照客户的希望实现即可。
- 实际情况:假设客户可以正确的表达自己的want和need,但究竟想要个怎样的产品来满足自己的want和need客户通常没想好,或者压根儿不愿意想。这个设计、实现产品的工作就需要我们来做。我们要制造需求,并培养需求。
对新需求的需求分析是从想法到产品的分析,重点在思考如何实现;
新需求实现后如果需要整合到整个产品中,就要重点分析对原有功能的影响:
- 并入需求和整个产品的风格是否一致?
- 新需求属于整个产品框架的哪部分?
- 业务流程是否有矛盾?
- 功能是否有冗余?
- 加入新功能后是否可提升产品的整体功能和竞争力?
- 新需求的数据来源于哪里?处理后流向何处?
暂时想到这些,多问些问题还是有好处的,提问有助于促进思考。
关于增量模型和迭代模型的区别
十一 7th
迭代模型和增量模型都属于并行开发的软件生命周期模型,但是这两个模型大家往往容易混淆或者不好理解。下面对两个模型的区别和相同之处做一下介绍。
迭代是不能并行的,迭代的并行是指迭代任务,比如从3.1-3.31号是一个迭代计划,该迭代计划需求人员可以分析功能点5-功能点10,设计人员可以做功 能点3-功能点7的设计,开发人员可以做功能点2-功能点4的开发,测试人员可以做上个迭代周期发布的代码。 迭代的并行是指工作流的并行。
大家看到迭代计划是比较复杂的,因此对项目经理的经验要求很高。
增量模型一般是指具有底层框架和平台的项目,在该稳定的框架和平台上,来开发和增加具体的业务功能。每个增量之间相对独立,各个增量可以并行开发, 比如:3.1-31号实现增量1(包含5的功能点),3.20-4.15开发增量2(包含另外的4个功能点)。增量内部是瀑布模型。
两种类型的区别在于迭代是基于IBM的RUP的以架构为核心,用例为驱动,角色职责划分不同,在同一时刻项目内部需求、设计、编码、测试的活动都在发生。迭代适合需求不明确、架构风险大的项目,增量适合需求比较明确,架构比较稳定,而且增量功能的实现基本不影响架构。
还有一个不同就是迭代计划是基于角色的,增量计划是基于任务的。
两种类型的相同之处,每个迭代和增量结束后都有产品发布。
转自 http://blog.csdn.net/li_hualing/archive/2007/03/07/1522988.aspx
组织过程资产
十一 2nd
什么是组织过程资产
组织过程资产指一个学习型组织在项目操作过程中所积累的无形资产。组织过程资产的累积程度是衡量一个项目组织管理体系成熟度的重要指标,项目组织在实践中形成自己独特的过程资产,构成组织的核心竞争力。
组织过程资产的内容
组织过程资产主要包括但不限于以下内容:
- 项目组织在项目管理过程中指定的各种规章制度、指导方针、规范标准、操作程序、工作流程、行为准则和工具方法等。
- 项目组织在项目操作过程中所获得的经验和教训,其中既包括已经形成文字的档案,也包括留在团队成员脑子中没有形成文字的思想。
- 项目组织在项目管理过程中形成的所有文档,包括知识资料库、文档模板、标准化的表格、风险清单等。
- 项目组织在以往的项目操作过程中留下的历史信息。
组织过程资产的构成
组织过程资产由两类构成:
一、组织指导工作的过程和程序:
- 组织的标准过程,例如标准,政策(如安全和健康政策),标准产品和项目生命周期,质量方针和程序(如过程审核,目标改进,检查清单,以及应用于组织中的标准化过程定义)
- 标准化的指导方针,工作结构,提案评价标准,以及工作状况测量标准
- 模板(如风险模板,工作分解结构模板,项目进度网络图模板)
- 为了满足项目的特殊要求,组织标准过程中采用的指导方针和标准要作适当的修剪
- 组织通讯需求(如明确可用的通信技术,被许可的传播媒体,录音记录和安全需要)
- 项目收尾的指导方针或需求(如最终的项目审计,项目评价,产品确认和认可标准)
- 财政控制程序(如时间报告,必要的花费和支出复核,会计法规,标准合同规定)
- 问题和缺陷管理过程定义了问题和缺陷控制、鉴别、处理决定和活动条目跟踪
- 变更控制过程,包括了修改正式的公司标准,政策,计划,过程(或任何项目文档)。以及批准和生效任何改动时遵循的步骤
- 风险控制过程,包括风险种类,确定概率及其后果,以及概率和后果的矩阵。
- 批准和发布工作授权的程序
二、存储和检索信息的组织公用知识库:
- 过程测量数据库是用来收集和提供测量过程和产品的数据
- 项目文件(如范围,成本,质量基线,执行情况测量基线,项目日历,项目进度网络图,风险登记,计划应对活动,以及定义风险影响)
- 历史信息和来自知识库的教训(如项目报告和文档,项目收尾信息和文件,跟以前所有项目选择和执行情况有关的信息,以及风险管理努力的信息)
- 问题和缺陷管理数据库,包含了问题和缺陷的状态,控制信息,问题和缺陷解决方案和行动结果
- 结构管理知识数据,包含了对所有正式的公司标准、政策、程序和任何项目文档的释义和基线
- 财政数据库,包含诸如劳动时间、花费成本、预算和任何项目费用超支的信息
转自 http://wiki.mbalib.com/
对需求管理和范围管理的理解
十 27th
1. 什么是需求管理
需求是指项目接受并生产出的产品和产品构建。需求管理是为确保各方对需求理解一致而进行的管理和控制活动。
2. 需求管理包含哪些方面
1) 制定计划:准备所需的软硬件资源、跟踪矩阵、变更申请等,便于管理需求并保持需求管理工作一致。
2) 各方对需求达成共识:各方干系人对确立的需求进行确认,建立一致。
3) 控制需求变更:项目进行期间当发生需求变更将对整个项目产生影响,如果需要变更,要先提出申请说明变更需求的来源,相关人员综合各方面因素审核是否实施变更。
3. 什么是范围管理
项目范围管理界定了为成功完成项目所需要的一系列过程,确保项目包含且仅包含必须完成的工作。即定义和控制项目内包含什么,不包含什么。
4. 范围管理包含哪些方面
在软件开发项目管理中,范围通常包括产品范围和项目范围。
产品范围:表示产品或服务的特性和功能。如需求、目标、工作产品、交付成果;
项目范围:指为了完成产品范围内规定的特征和功能,所必须完成的工作,如确定干系人、WBS、资源安排、时间分配等;
产品范围是否完成以产品需求作为衡量标准;项目范围的完成以项目管理计划作为衡量标准。二者相结合确保项目在规定的时间内、使用特定的资源、按照约定的质量交付约定好的成果。
5. 范围管理与需求管理的关系
1) 范围管理包括需求管理:范围管理需要清楚的定义项目的具体工作范围和工作内容。
2) 需求管理为范围管理提供依据:在需求开发确定的项目需求基础上确定项目的范围,制定工作内容、项目预算、估算时间和资源;根据需求的级别安排资源投入工作;当需求有变更时会引起项目范围和时间的变更,对需求变更的管理可以减小项目管理的风险。
近期评论