产品需求

对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” (Leffingwell 1997) 。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟 ( 期望差异 ) —开发者开发的与用户所想得到的软件存在着巨大期望差异。 在软件工程中，所有的风险承担者 (stakeholder)( 这个词很有意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众的，也有的翻译成参与者的，但是我想他的主要意思就是和这个项目有密切相关利益的人 ) 都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员 ( 负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人 ) 、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用有效的需求分析过程。软件需求的定义 IEEE 软件工程标准词汇表 (1997 年 )

组织过程资产库下面有组织级标准过程库， 这个库里一共有19各PA（就是标准过程啦） PA的英文是Process Area CM（配置管理过程，英文是Configuration Management） 项目研发和管理过程中会产生很多工作成果，例如文档、程序和数据等，它们都应当被管理起来，以便查阅和修改。鉴于用户的需求会发生变更，导致项目的相关产品也会随之变更，为了使项目的所有过程和产品保持一致性，并且便于跟踪控制，我们需要建立一套严格的配置管理流程 制定配置管理计划 配置库管理 版本控制 变更控制 配置审计 DAR（决策分析过程，英文是Decision Analysis And Resolution） 当项目出现重大问题的时候，为了降低问题所带来的风险，需要一套系统的方法来帮助项目选择一个解决方案 识别需要决策分析（DAR）的问题 组件决策委员会 建立评价准则和评分方法 提供候选方案 评价候选方案 选择最优解方案 跟踪解决方案 IPM（集成项目管理过程，英文是Intergrated Project Management） 集成项目管理的活动贯穿在项目定义、项目计划、项目开发和项目结束这四个项目阶段过程中 建立已定义过程 使用组织过程资源策划活动 建立工作环境 集成计划 使用集成计划进行管理 贡献组织过程资产 MA（度量和分析过程，英文是Measurement and Analysis

先说项目开发过程中团队人员的分工协作。 　　 一、人员安排 　　毕业至今的大部分项目都是独立完成，虽然也有和其他同事协作的时候，但自认为对团队协作的了解和认知都还有所欠缺。很清楚团队协作的重要性，但尚未有很好的机会在相对成熟的团队中锻炼实践。 　　先抛开 软件开发 团队中人员的具体安排不讲，单纯的看软件开发工作的分工。在上面设想的开发架构中，宏观上可将一个项目划分为前端、程序、 数据库 三个模块。由此可推导出团队中需要的成员：美工、程序员和项目经理。 　　认为理想的软件开发团队由四个专业技能过硬的成员组成：一个美工，熟悉UI的设计并具备将效果图转换成前端页面的能力，也就是得同时精通PhotoShop、HTML、CSS、jQuery等前端知识；一个程序员，熟练掌握代码的编写重构；一个项目经理，具备 需求分析 的能力、数据库设计维护的能力、架构设计的能力、程序编写的能力、前端样式脚本编写的能力，最重要的是对业务流程有精准的把握；一个部门经理，和前三位不一样，部门经理只具备领导能力即可，他是兼职，不需要把全部时间投入到团队中。 　　大部分中小型项目可以由这样的四人团队完成，可如果项目较大，已经大大超出了四个人可完成的工作量，可以再加一个前端开发人员。也就是说两个前端开发者，一个负责UI设计，做出完整的效果图，这个人的设计功底应该比较强；一个负责将效果图转换成页面，并完成样式、脚本等的编写

这几天一直在处理各方面收集到的需求，目前整理的进度应该在80%左右，通过整理和分析得到如下一些数据： 需求数目：353 预估的开发量：2536人天 也就是说，如果我一个人来实现这些需求，一年做250天的话，需要做10.14年，如果365天斗来做的话，需要6.95年，目前预估的开发量还没完成，因此需要的时间只会更多。 有了这些真实的数字，很多想法就理性多了，要仔细甄别需求，确定每个需求的商业价值和估算开发量，计算每个需求的性价比。 舍弃低价的需求，选择高性价比的需求，进行详细分析和整合，逐步将这些用户需求转化为真实的产品需求，并根据人员和时间情况，最终确定下阶段要做什么？ 做产品最难的不是怎么做？而是选择做什么？而选择的核心就是需求的价值，如何衡量需求的价值？ 1、实现需求能给用户带来什么价值？ 2、实现需求能给产品带来什么价值？ 3、技术上能否实现？ 4、时间上有什么要求？ 整理需求的过程就是一个思考的过程，在纷杂的用户需求中明确产品需求就是一个扬弃的过程。 形成这个需求列表后，剩下的就需要团队的智慧了，需要大家来讨论了，希望的曙光就在前方。 来源： https://www.cnblogs.com/Duiker/archive/2009/08/11/1543722.html

商业智能 ，又称 商务智能 ，英文为 Business Intelligence ，简写为 BI 。 商业智能通常被理解为将企业中现有的数据转化为知识，帮助企业做出明智的业务经营决策的工具 。这里所谈的数据包括来自企业业务系统的订单、库存、交易账目、客户和供应商等来自企业所处行业和竞争对手的数据以及来自企业所处的其他外部环境中的各种数据。而 商业智能能够辅助的业务经营决策，既可以是操作层的，也可以是战术层和战略层的决策 。为了 将数据转化为知识 ，需要利用 数据仓库 、 联机分析处理（ OLAP ）工具 和 数据挖掘 等技术。因此，从技术层面上讲，商业智能不是什么新技术，它 只是数据仓库、 OLAP 和数据挖掘等技术的综合运用 。 商业智能的概念于 1996 年最早由加特纳集团（ Gartner Group ）提出，加特纳集团将商业智能定义为： 商业智能描述了一系列的概念和方法，通过应用基于事实的支持系统来辅助商业决策的制定 。 商业智能技术提供使企业迅速分析数据的技术和方法，包括收集、管理和分析数据，将这些数据转化为有用的信息，然后分发到企业各处 。 可以认为， 商业智能是对商业信息的搜集、管理和分析过程，目的是使企业的各级决策者获得知识或洞察力（ insight ），促使他们做出对企业更有利的决策 。商业智能一般由数据仓库、联机分析处理、数据挖掘、数据备份和恢复等部分组成

一、如何对需求不确定的创新产品进行分析和设计？简要总结一下有哪些方法和策略 在互联网行业，用户至上，以用户为中心进行产品设计的理念深入人心，满足用户需求也是产品工作的第一原则，因此产品的需求分析是一个项目在实现过程中十分重要的一环。而实现需求分析需要我们全面的考虑到包括用户层面的需求、业务人员的需求以及产品运营需求等等。但对于创新产品来说，这些都是无从得知的，并没有可供参考的概念。因此对于创新产品我们可以按如下的方法进行分析与设计： （1）在需求不明确的情况下，需要预测需求并明确方向。任何事物的产生都不会无迹可寻，任何创新产品都或多或少有着前任的影子。首先我们要通过确定产品的设计方向，提出一系列的预案，同时还可以参照同类的产品。 （2）之后可以按照需求调研的正常步骤，利用访谈法或者问卷调查法调查系统需求，结合第一步的结果，写出系统的相关事件.根据事件列表，归纳抽象出系统相关角色，建立角色列表，而后就建立角色用例图，根据角色和用例模型建立类图模型。再根据角色和用例规约建立界面模型，确定系统的部署需求，最后形成完整的需求规格说明书。 （3）由于是创新型的产品，并没有参照物，因此在产品的运营阶段要一直做好收集用户反馈的工作，积极修改并完善系统，因为用户的需求分析有时也是片面的，只有在实际的使用过程中一些问题才会浮出水面。 二、未来的图书是什么样的？ 古人有云，书中自有黄金屋

摘自： https://www.cnblogs.com/yixinjishu/p/12161359.html 敏捷开发流程之Scrum：3个角色、5个会议、12原则 本文主要从Scrum的定义和目的、敏捷宣言、Scrum中的人员角色、Scrum开发流程、敏捷的12原则等几方面帮助大家理解Scrum敏捷开发的全过程。 一、Scrum的定义和目的 Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程，目的是让开发人员像打橄榄球一样迅猛并充满激情，通过团队合作，提高工作效率。通过团队间的有效交互，为企业创造价值。 二、敏捷宣言 其实，在发表《敏捷宣言》之前，很多的敏捷实践都已经存在且使用了，比如：Scrum、XP、KanBan等。之所以发表《敏捷宣言》，是因为这些实践都是在单打独斗地推进敏捷开发，而不是以一个联合体的形式，且没有一个统一的指导方针。所以17位敏捷联合创始人决定发表《敏捷宣言》，共同在全世界推进敏捷开发运动。下面是敏捷宣言的4句话： 三、Scrum中的人员角色 3个角色 Scrum中的人员分为3个角色：产品所有者（Product Owner）, Scrum Master，开发团队(Team)。 产品所有者：定义所有产品功能，决定产品发布的内容以及日期，对产品的投入产出负责，根据市场变化对需要开发的功能排列优先顺序，合理地调整产品功能和迭代顺序

一、为什么讲这个 　　“初生牛犊不怕虎”，没做过电商的我差点让面试官笑到腹肌扭伤。 　　为了避免这种蠢事发生，咱们有必要接着往下看 二、是什么有啥用 　　“电商后台是默默干活的劳模” ，所以 “逛商品”、“买东西”、“付款”这些看的见的操作，都和后台的“劳模”分不开。 　　咱们以下单流程举栗子 　　 三、下一步 　　好了，以为看到就可以出去装 13 了，不行的，小老弟。看完这里，你有概率明白以下内容。 心得体会 1、 首先，对于萌新来讲，知道电商前、后台应该有这么些系统，不至于被 “ wms 、 erp 、 crm... ”这类听不懂的名词忽悠，它们不过是支持“用户买东西”的一堆程序而已。写的简单叫做“功能”，写的复杂叫做“系统”。 2、 其次，对于 B 端电商产品同学来讲，梳理清楚自家产品的框架是优先级较高的事。可以避免“灭霸”型产品小白被“黑恶势力”无情吊打的惨案发生。 3、最后，提需求经常被砍，可以尝试以下方式： 　　因为这个需求从业务流程上，是 xxxx 这么一回事； 　　所以需要实现 xxxxx 这样的一个功能 / 效果； 　　目前有 xxxxxx （ planA ）和 xxxxx （ planB ）两种方案，你可以选择 xxxxxxxx。 来源： https://www.cnblogs.com/sam-zhang/p/12162754.html

前言：文章来自Worktile产品经理的产品需求管理经验分享。 作为B端产品经理，我接触过很多研发及产品团队，每个团队对产品需求的管理方法不尽相同，各有千秋。下面我来分享一下我司的产品团队是如何管理产品需求的，其实也就是一个产品需求在Worktile中的流转过程，希望我们的经验可以对各位有所帮助，也欢迎各路大神交流指点。 下面我通过需求流转的不同阶段来介绍我们如何做需求管理： 需求收集 管理需求的第一步首先是要进行需求的收集。我们的需求来源除了产品经理自己通过市场调研等各种渠道分析出的需求，来自用户的需求、建议、缺陷，都是由销售、客户成功的同事在一个公开的项目 （公共Backlog） 中提交，然后产品经理和设计师会定期对需求池的需求进行评审处理； 以下是在需求收集阶段我们会设置的一些关键属性： 1.需求描述 对于2B的产品需求，信息无非是角色、场景、原因、目的、预期这几点。但由于不同企业的角色、场景等信息复杂多样，所以无法形成统一的标准化数据来源，因此，我们规定以任务标题来描述需求最终的预期，其他必要信息通过任务描述来进一步补充； 2.功能分类 因为Worktile有“项目”、“消息”、“简报”、“网盘”等不同的应用，不同的应用是由不同的产品经理负责的，所以让需求提交人选择【功能模块】的原因是为了方便产品经理根据自己负责的应用筛选需求； 3.需求类型 新功能、交互优化、视觉优化

用户体验已经成为了每个互联网人的口头词，特别是互联网产品经理或产品设计师。 的确，对于任何一个互联网产品而言，体验都是非常重要的。 但是具体的用户体验到底指的是哪些方面，界面，UI，还是交互，其中到底是什么因素决定了一个产品体验的好与坏？而这些因素之间具体是什么的逻辑关系？决定体验好与坏的整体框架是什么？这是我一直想弄明白的事情。 前后读了很多与用户体验相关的书籍，其中美国作家加瑞特的《用户体验的要素》给了我很好的解答。不过真的感觉这本书不应该取这个名字，这点体验的确很不好，没弄明白读者到底想知道什么。 首先整个产品设计分为5个大的方面，由低到高，底层根本原因决定上层形态构成。和网站分层也很形象。 1. 战略层：我们为什么要做这个产品？ 2. 范围层：我们要建设什么样的内容？ 3. 结构层：如何呈现给用户？模式、顺序、优先级？ 4. 框架层：哪些功能在哪些页面上完成？这些功能在页面上如何实现？ 5. 表现层：不仅是美化，而是产品功能是否得到很好的展示？ 1.战略层 （内）我们要从这个产品中得到什么？产品目标是什么？ （外）我们的用户要从这个产品中得到什么？产品需求是什么？ 产品目标？也许大部分的产品都会是以用户为出发点的，都是为了满足用户需求，赢得市场利润。 那么用户需求是什么？这个可能就是用户体验最大的挑战，就是比用户自己更准确地去理解他们的需求。 用户需求核心：可用、易用的产品