随着2016年的结束，眨眼间，一年时间又过去了，在这一年里，移动互联网行业得到了高速的发展，由于市场营销和分析的进步，APP世界以一种高度个性化的方式面向用户，并将他们链接到多个平台上以创建无缝和全面的体验，其结果就是，2015,年，APP颠覆过去，继往开来，2016，充满欣喜，时下，APP创业急剧增加，今天我在这里分享一下，关于APP用户需求的一些问题，以下为演讲全文：　　只有当自己知道需要什么的时候，才有可能会获得它，这也是探索需求的必要性。　　我们常常谈需求，但是需求真的是我们想象的那样吗？下面我就给大家梳理一下，关于需求你可能误解了的11个真相。　　1. 写需求其实并非是在谈需求。　　需求活动主要不是编写需求文档，相反，它专注于理解业务问题，并为之提供解决方案。　　怎么样才算理解了业务问题呢？　　即你做的是哪个行业的产品，就对这个行业的商业模式、产业链、竞争状态等要有所了解。而只有深入了解了业务本身，才有助于发现使用场景，并为之提供解决方案，让用户用得爽。　　2. 如果我们必须构建产品，那么它必须为拥有它的人提供最理想的价值。　　除非产品提供了利益，否则拥有产品者不会付钱　　作为产品开发者或设计者，要深谙一点：即我们关注最终结果的拥有者，只是间接地关注用户。但是在免费时代，很多公司并不靠产品本身盈利，所以不能孤立地看这个上图中的曲线，应当将整个产品生态搭建起来，看看哪个环节是赢利点。　　很多大公司，平台级的产品均是不盈利的，通过专心打磨产品获取千万级的用户，然后通过其他方式进行盈利，例如在线广告、增值服务或电商。　　3. 你必须知道要求是什么，才能构建正确的产品。　　要理解产品打算为用户完成什么，以怎样的方式完成，就必须理解拥有者的业务工作。产品经理得到需求，描述产品的功能(做什么)以及产品的属性(做到什么程度)。　　不幸地是，交流的无奈导致需求并非总是被恰如其分地理解了。　　4. 构建一个产品和解决一个业务问题之间，存在巨大的差别。前者不一定实现后者。　　这一点是对第一点的补充。做一个产品就是为了解决一个业务问题，因此开发工作必须从问题开始，而不是从解决方案开始。　　5. 需求不一定要写下来，但是构建者必须知道它们。　　需求文档是为了更好的沟通想法，一份高效准确的需求文档能够让开发人员和设计人员非常明确需求是什么，从而实现它。但很多时候，口头沟通更方便、直接，特别是一些细节的确认，往往需要口头表达。　　但值得注意的是，口头沟通需求效率虽然高，但是不是所有需求都能用这种方式来沟通。编写需求是为了让利益相关者和产品经理彻底地理解需求，也有利于追踪文档。　　6. 客户不一定能给你正确答案，有时候他也不知道要什么。　　利益相关者在描述一个需求时是由困难的，交流的无奈是存在的。所以产品经理应该把握业务的复杂性和规模。　　有时候，产品经理应该如实记录下客户的要求；有时候，应该从解决方案中导出需求，有时候必须提出创新，得到更好的解决方案。　　7. 需求不是偶然得到的，要通过某种有序的过程得到。　　做产品就像拍电影，要先有一个剧本，确保剧情有序地发生。　　任务的次序、重点和应用程度需要采用该过程的人或团队来决定，参与这个过程的人必须能看到为什么不同的任务是重要的、哪些任务对项目最重要。但优先级是可以调整的，过程中要灵活变通。　　8. 怎么迭代都行，只要理解了业务的需求。　　敏捷迭代越来越成为新宠，取代着原始的瀑布流开发方法。但是冷静的头脑在开发之前已经将需求过程吸收到开发的生命周期中了。　　聪明的办法不是废除需求，而是从一个不同的方向接近需求。真正值得关注的是，既要发现需求，又不必编写无用的、不成熟的文档。　　9. 所有的方法和工具都无法弥补糟糕的想法和糟糕的手艺。　　这一点是对第7点和第8点的补充。　　有序的过程并不能替代思考。需求收集、验证、编写文档的过程并不是一种流程，而是由提交的产物驱动的。　　要记住，自动化的工具只是辅助手段，产品经理最重要的工具就是：脑袋、眼睛和耳朵。　　10. 要想成功地实现需求，需求就必须可度量、可测试。　　需求可以主要分为以下三类：　　功能需求：产品支持其拥有者的业务时必须做的事情。　　非功能需求：产品要再拥有者的环境中取得成功，必须将功能完成得多好的量化描述。　　限制条件：全局性的需求。　　例如，产品有一个需求是“应该对新用户有吸引力”：　　建立可测量的指标即：注册时间少于2分钟、数据项(例如姓名、邮件地址等)犹豫时间不超过5秒。　　可以很肯定地说，如果你不能为需求找到测量指标，那么它就不是需求，只是一种无根据的想法。　　11. 作为产品经理，你终将改变用户思考这个问题的方式。　　产品经理的部分工作就是帮助人们尽早理解和质疑他们的需求，这样他们就可以帮助你发现它们真正的需求。　　当产品经理开始理解需求时，尤其是在需求来自于不同利益相关者时，就开始建立起一套抽象概念，通过展示业务过程的模型渐渐参透工作的本质，得到清晰、可测量的需求，并把这些反馈给利益相关者。　　在做这些事情的时候，产品经理就在渐渐改进(改变)他们对业务的看法。　　简言之，需求就是产品支持其拥有者的业务所必须完成的事。而产品经理的工作就是理解需求，理解到应该做什么、做到什么程度，并建立起一套解决问题的方案，反馈给产生需求的人。　　六牛科技.cn/s/blog_14c9dc3e00102w36x.html致力于卓越有效的企业转型互联网咨询和和转型技术支持、运营支持，服务项目涵盖：六牛四网合一商城系统、六牛科技o2o系统、APP定制开发、互联网+房地产解决方案、汽车行业解决方案、智慧城市解决方案、在线教育解决方案、服装行业解决方案、金融行业解决方案等各领域互联网+解决方案，服务行业涵盖了IT、家电、房地产。金融、汽车、服装、快消品、母婴等众多行业。
楼主发言：1次 发图：0张 | 更多
请遵守言论规则，不得违反国家法律法规回复(Ctrl+Enter)APP开发过程中如何控制客户频繁改需求
（归属地：
在APP开发过程中我们遇到较难解决的问题就是客户频??繁的该需求，对于频繁该需求的顾客我们找到根本原因：1、签合同马虎，没有明白顾客真正需求；2、没有深入了解客户需求以及需求的流程理；3、没让客户知道变更的代价；4、没发挥合同的作用。知道这些原因就好找到解决方案了，我们要在各个环节把控好，比如UI设计、原型图都需客户签字确认；前端需要与客户沟通；建立变更审批流程；确认变更需求的影响，技术能不能实现变更需求的展现等，都是要考虑的问题，也是我们在签订合同前需要考虑到的问题。同是为了避免这些问题的出现，要找家技术精湛，团队各成员完善，同是也要有产品总监帮您规划，我知道的一家叫专注科技--浙江APP开发领导品牌。
联系我时，请说是在58同城看到的，谢谢！
热门推荐：
2005-版权所有| 京公网备案信息| |乙测资字| |违法信息举报：&&如何分析APP功能需求、结构？
这篇文章有点偏向于APP系统架构方面的设计，很赞。by
&linco_zhang
&APP分析过程在项目管理体系PMBOK中归属于项目范围定义（Define
Scope）过程。从PMBOK的角度来看，在完成需求收集（Collect
Requirements）后，需要对项目和产品的详细范围进行描述，清晰完整的项目/产品范围说明书有利于制定出具有良好执行性的WBS（Work
Breakdown Structure），但其更为重要的意义在于科学的构建了用户所需要的系统功能架构。
从业务演变到系统的角度来看，APP是业务在系统的具体呈现，APP的分析过程是将业务语言翻译为机器语言的表现。只不过这不是普通的翻译，是包含了智力和经验的过程。所以，对于计算机信息领域的技术专家来说，更需要去学习和掌握跨领域的业务语言，并在不同领域的交界处形成明确的定义，实现不同语言间的准确对应。
&举个例子，假设在电子商务领域里有一个业务，我们称之为A：用户通过网站填写了一份购买汽车坐垫的订单，付款成功后可以通过连接电脑的打印机自动打印一份A4幅面标准格式的确认单。那么在信息系统的世界里，A被翻译为：1、用户通过web表单填写完订单内容后；2、在线支付。2.1、如果支付不成功，系统提示用户哪里出现错误，并引导用户修正错误。2.2、如果支付成功，系统提示用户：订单已经生效，系统即将打印确认单。3、系统传递打印控制信息，打印机负责打印出指定格式的文件。4、系统提示交易完成。
上面的例子说明了不同的领域有不同的表达标准，想要在不同领域都能准确表达同一个意思，将是非常困难的事情。
在计算机领域，信息系统的APP的设计过程非常的复杂，不只是纯粹的描述计算机处理流程那么简单，还包括了抽象过程（建模过程），设计过程（包括系统流程设计、功能设计、权限设计、用户体验设计、异常处理设计等等），测试过程（建立demo，必要的验证）。而在这些过程中，建模环节是最为重要，也是最为复杂的一个步骤。
举个例子来说明为什么说业务建模过程最为关键、也最为复杂：
假设家里有很多的杂物被堆放在不同的角落里，有衣服，裤子，鞋子，碗，清洁剂，锤子，可折叠的小凳子等等，家里每个人都会用到其中的某些物品。久而久之，大家都觉得这些东西胡乱放置，既不利于保管、用时也不方便找到。于是，大家推举你来解决这个问题，并给你提出了很多好的建议。例如，把这些东西整理到一个角落放置，给每个物品一个固定的位置，可以请木工打个大木箱子来放置，也可以去家具商店买个好点的柜子来放置，又或者买几个大的袋子分类来装。最后，一家之长告诫你：在投资允许的情况下，尽可能的选择最好的一种方案来满足家里所有人的需求。
那么这个时候，你应该怎么去做呢？让我来试着描绘一种可能成功的做法。
&O&&首先，对每个人的需求进行登记。即收集需求的过程（Collect
Requirements）
详细的与每个干系人（Stakeholder）进行沟通，识别出每个人的一些行为特性，例如：
你一般什么时候会去哪儿找哪些物品做哪些事情，什么时候又还原回去？（流程）
这些物品有些什么保管的要求？（功能需求）
你希望去哪里去取最方便？（非功能需求）
有别人和你一起用这些物品吗？（权限要求）
5、 大致预算在什么范围，等等（限制条件）
&O&&对需求展开分析，进入设计和构造阶段。即需求的定义过程（Define
对收集的信息展开分析。保留有用的，去除相同的和无意义的需求。（需求过滤）
对物品进行逐一的分析，整理归类。确定物品分作哪些类别，例如，衣服类，鞋类，餐具类，清洁剂类，工具类，小家具类等。（分类&抽象）
确定每个类别的行为特性，尺寸大小，放置要求等。例如，衣服类物品要求存放于封闭、干燥的环境，拿取方便、好查找，部分衣服要求挂放，需要足够的空间；鞋类要求每双鞋都单独放置，存放时能具备一定的空气流动性，要方便查找和拿取；餐具类，要求单独存放，最好放在与水池较近的地方，要求能封闭放置，能在需要的时候进行通风干燥处理，储物构造的材料要求防水；清洁剂类，没有特别要求，只需要和衣服类，餐具类分开存放即可；工具类，……（抽象&分析）
形成初步的设计方案。设计思路为，配置两个不同的储物柜解决储物的问题。一、在靠近厨房的角落设计一个三栏式的壁挂组合储物柜，采用防火，防腐蚀的UV板材。设计为挂式的原因是，节省房屋的空间，利于时常打开柜门通风；大人拿取方便，也防止小孩子随意拿取玩耍而摔破；三栏结构可以分开放置餐具类、清洁剂类物品和工具类物品，空间设计更为合理。二、在靠近卧室的角落放置一个落地的多功能储物柜。储物柜设计为三层的实木结构，下层主要放置鞋类，其后面板和内隔档板采用镂空设计，内置4个隔层，总体高度约占柜体的1/4。镂空和隔层设计主要起到通风干燥和分类放置便于取放的作用；中间层为抽屉式设计，主要放置可以摺叠放置的衣物；而一些需要挂置的衣服则挂放在上层。在储物柜的顶上还可以放置一些小家具，例如摺叠的凳子，卷席等。另外，采用全实木材料还以防止甲醛等有害物质的侵害。（建模过程）
&O&&验证设计的成果是否满足干系人需要。即范围确认过程（Verify
形成结论后，召集相关干系人商议、评估方案。一般依据业务程度，可以采用简单的评审（团队内部小范围的评审）或复杂（有客户、用户或者专家参与）的评审方式。
一旦方案得到大家的认可，则可以进入实施过程了，这时可以再推举一个人作为实施的负责协调人，由他来控制预算，制定行动计划，确定需求的优先级别，落实方案的执行。
从上面的例子可以看到，设计和构造阶段中建模（Build
Model）是整个APP设计过程中最具有技术含量的一个环节，不仅需要依靠知识和经验，还需要较强的逻辑能力，构思和策划能力。
其实，这么多年来我们在做需求分析和建模时，也是有一定的规律可遵循的，我用一句话来概括就是：从业务对象入手，识别业务对象的行为，抽象APP，从而构造系统模型。
下面用网上订票的例子来详细说明我们的做法：
假设，我们已经知道了用户的业务流程。
第一步：用户通过浏览器登录web网站，浏览和查询需要的信息。
第二步：选择票，填写订单信息，确认个人的信息，以方便取票时核对。
第三步：通过网站提供的支付方式，在线完成支付。
第四步：系统生成电子票号，并短信通知订票人，告知用户出票相关的信息和兑票方法。
具体参见下图：
前面我们说到：业务的核心是数据。所以，理清业务的基础是分析清楚业务下流动的数据都有哪些，这些数据分别代表了什么意义，对应了哪些业务对象。
所以，第一步我们分析业务中包含了哪些业务对象。
&O&&业务对象分析（确定BO）
在线订票业务中，有登录、填写订单、支付和出票四个环节。仔细分析，我们发现，这四个环节分别包括了四个相对独立的业务对象：用户、订单、账单和票。（这里没有把手机短信也列为一个业务对象）
订票过程的所有活动都是围绕这四个对象来开展的，少了任何一个对象，这个流程都是不完整的。
那么在识别BO的时候，我总结了几个简单的标准：
该业务对象是否有一定的明确业务含义，如果少了这个BO业务流程将不完整。
业务流程中一定有一个或多个环节是有这个BO参与的。
大多数BO往往是可以映射到现实生活中的某一类物体的。例如，人，账单，公司，电话，系统，卡，存折，车辆，身份证等等。
另外，我们在判断是否所有的业务对象都被识别时，也有一个很简单的判断标准：业务流程中可能涉及的数据内容都与已经识别的业务对象能紧密关联上。
在确定BO后，需要分析和识别所有与业务对象相关的行为。
&O&&识别与BO相关的行为（BO属性和行为分析）
BO本身是有意义的，这些意义可以被细化为一些属性。我理解，属性就是说明和识别BO某一方面的一些具体标识或参数。
识别业务对象属性时，最重要是能分清楚哪些属性是与目前工作范围相关的。例如，用户有很多属性，但高矮胖瘦这些与我们正在分析的电子商务系统毫无关系，所以，找到BO属性并准确过滤才是这个过程的关键行为。
（在正式的团队协作过程中，必须要对每个BO，BO的属性和BO的行为进行统一编号标识。）
我们在识别BO的行为时，可以分为三个层次：
1、从业务流程中识别。从流程中只能识别一部分BO的行为，这一部分行为往往被称之为业务行为；也是BO最容易确定的一类行为，只要流程定义清楚了，这类行为就已经被确定了。例如，在上面的例子中，用户在流程中有登录和注册行为；针对订单对象，有填写订单，提交订单行为；账单对象有支付行为等。
2、从分析BO的完整性来识别。例如，用户有登录，就一定有注销行为；订单能新增，一定可以修改和查询；账单能支付，也可以退款。
3、从外部的需要来识别。例如，电子票本身是没有核对识别需要的，但考虑到安全性，一些运营商还是考虑了将电子票号进行了加密处理，票号本身含有身份识别信息。一旦电子票号遗失，只要有身份证信息，则电子票仍能使用。
通过三个层次的分析，一般能识别出绝大部分的BO行为，当然，还需要对这些识别的行为进行统一的描述。描述的内容包括行为名称，行为说明，涉及的BO属性和变化。例如，
在识别BO行为的过程中，我们往往会遇到一些模棱两可的境地，例如，商品和购物车是两个不同的业务对象，那么将商品添加到购物车的行为，是归属商品的行为，还是购物车的行为呢？
有人说是购物车的行为；有人反问，为何这个行为主要出现在商品的单页上？
我的意见是：当行为涉及到两个对象，一般把其归属到拥有管理职能的对象。购物车管理被放入的商品，管理放入的数量，也可以从购物车中删除。所以，放入购物车的行为主体对象是购物车。识别了BO，BO的属性以及BO的行为后，我们可以开始建立APP了。
&O&&建立APP
建立APP的过程是明确系统范围的过程，同时也是生成系统模型的过程。
建立APP有两种视角：
1、一种是以BO为视角，聚合BO的行为，以管理BO的功能组成一个APP；例如，我们将针对订单的所有行为，组合成为一个APP，称为订单管理。
2、另外一种是以业务为视角，聚合一个流程的所有环节，以实现流程的功能组成一个APP。例如，我们将针对打折票的预定流程中的所有行为环节，组合成为一个APP，称为折扣票预定APP。
具体参见下图：
但不管怎么组织APP的构成，在BO层面看，都是一样的：系统都是由操作BO的一堆行为构成的。
&上面是从业务分析BO，分析BO的属性行为，然后组织APP。
&然而，此刻还不能完成系统模型的构建，因为还需要思考这些已经被识别的APP是否足够支撑一个应用系统？
这里需要引入两个重要设计分析过程：一个是用户体验设计，一个是非功能设计。
用户体验设计（User
Experience）是以用户为中心的设计，是一种经验与创造相结合的设计过程，主要目的是提升用户的操作舒适感，增强在同类产品中的竞争力。在web2.0时代，用户体验设计将不再局限于展现流程和完成数据操作方面，还承载了不同角色之间的信息多元化交互的设计需要，以用户为核心将不再是简单的信息提供（推送）而已。
&那么，在构建系统的APP时，也要充分的考虑UE设计的需要，加入一些用于提升用户体验的APP，例如，Dashboard。
&非功能设计来源于用户的非功能需求，例如，系统的可管理要求，灵活扩展要求，性能要求，安全要求等。这些设计除了在系统的架构设计时需要充分的考虑和满足，在功能APP设计时也需要做相应的响应。例如，最常见的一个APP-系统管理，通常包含数据管理，日志管理，参数管理，模型管理，模版管理，接口管理，APP管理等等。这些来源于UE设计和非功能设计的APP与最早被识别的业务APP共同构成了系统，行成了系统模型。
&&系统模型构建完成，进入设计APP的阶段。在设计APP时，我们发现大型项目中的单个APP往往都很巨大，内部包含了很多行为和内容，如果不进行拆分细化，则很难展开有效的设计。
已经被我们熟知的拆分方法有很多，可没有一个标准去衡量一定要拆分为多少层级才合适，这往往需要视系统的复杂程度和设计需要而定。
&我建议把较大的APP拆分为三个层次，即：APP层，Module层和Function层，这样拆分的原因是为了与系统层面的功能模块-页面-和页面里的操作（或者一个单独处理单元）逐一对应。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。