产品需求

继《清晰认识何为产品经理》之后，鸟姐带大家讲述下产品经理从0-1的整个过程。 一个产品的出现需要很多步骤，从产品概念、市场分析（竞品分析）、需求分析、产品设计、项目评审（内评/外评）、视觉设计、产品研发/测试/验收、产品上线、项目运营、版本迭代。 一款产品从0-1开始，那0从何而来，也就是产品概念的提出。一般是由企业的领导根据市场的现状挖掘出来的观点，也可以是产品经理通过自身的想法发起，也可以是运营童鞋在日常的运维工作的总结得出。简单的说就是只要你有想法就可以提出。 当你的产品概念提出后，接下来要分析提出的概念是否具有可行性，是否合理。这个时候我们要深入市场去进行分析。那如何进行市场分析呢？市场分析主要分析产品概念的价值，简单点说就是分析该概念以目前的形势来讲可以带来多少金钱利益。该产品概念会不会存在风险以及想要实现这个概念需要的人力/成本/环境等资源。除此之外，我们也要明确客户群体，考虑未来你的产品推向市场后，面向哪些用户。比如：针对学生、老年人、女人、男人等等群体，积极探索市场中的机遇与挑战。这个阶段，产出物包括商业需求文档（BRD）、市场需求文档(MRD)、竞品分析文档。BRD有些企业无需产品经理进行书写，看各个企业的工作安排来定。MRD也是非产品经理强制写，鸟姐遇到过MRD是项目经理写的。竞品分析文档产品经理需要进行书写。但是虽说BRD、MRD不做强制要求

前言 本篇文章将对敏捷软件开发的方法论及其应用做基本介绍，将描述团队是如何通过协作来完成共同目标的。本篇文章不仅仅适合软件开发人员阅读，同时也适合于团队负责人、项目经理、产品经理、开发经理、测试人员、QA经理、QA工程师、技术文档专员、用户体验设计师等任何涉及软件交付的人员。文章重点介绍技术团队是如何通力协作来计划、构建和交付软件的。但文中没有具体代码的编写，也没有对特定技术的介绍，并且也不会介绍任何微软技术。希望这篇文章可以帮助你改善专业性和团队的效率。 背景 Winston Royce 瀑布模型 引自 1970 年的 IEEE 论文 "Managing the Development of Large Software Systems" 该论文中阐述了，在计算机程序设计开发过程中，无论软件的规模和复杂度如何，都会经过两个必不可少的阶段：软件分析和编码。而许多其他额外的开发步骤，虽然也是需要的，但却都没有像软件分析与编码一样对最终产品作出最直接的贡献，反而增加的开发过程的支出。 然后，Royce 介绍了需要额外的将 5 个重要的步骤添加到整个开发流程中，用于最大化地消除软件开发中的风险： 步骤1：程序设计优先 一个软件程序的初步设计阶段，将被插入到软件需求和软件分析阶段之间。程序设计人员将在此阶段开始进行软件整体的初步设计，包括设计、定义和指定数据处理模型，定义系统间的接口

在软件工程领域，有过很多软件开发模型，如瀑布模型、快速原型模型、增量模型、螺旋模型、演化模型、喷泉模型、RAD模型、敏捷软件开发模型、XP极端模型。这么多的模型各有各的应用场景、各有各的适用范围，但我认为最实用开发模型还是敏捷软件开发。 中国式软件开发思路是什么样的呢？从我接触过的大多软件项目来看，基本都有一个共同特点——就是必须快，客户都是急脾气，恨不得今天立项，明天就要你拿出产品来。 面对公司和客户如此快节奏的要求，我们有办法吗？人们从生产、生活中总结出来一套即高效又优质的开发模式——敏捷软件开发。 什么是敏捷软件开发呢？ 敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系、而又可以独立运行的小项目，并分别完成，从而实现快速开发的目的。 还是具体来说下敏捷开发是如何实现的？ 1、将大的系统拆分成子项目。 以前我们接受过的思想是立项后先要需求调研、分析，调研后出各种调研报告及需求说明书，需求搞定后，再进行概要设计（UE设计、UI设计、交互设计、数据库设计、框架设计），概要设计完成后再进行详细设计……这样一个周期下来，耗费太长，当进度进入下一阶段，当上一阶段有问题时，会影响到整个项目流程的各个阶段。

目录 产品项目开发流程 项目调研 项目立项 需求分析评审 原型设计 项目开发 项目测试 项目部署 后期维护 产品项目开发流程 目前市场上成熟的产品项目流程主要有项目调研，项目立项，需求分析评审，原型设计，项目开发，项目测试，项目部署以及后期维护等。 现基于市场上的开发流程以及以往的项目开发经验，个人对项目各个开发阶段进行描述以及项目整体开发流程进行总结。 项目调研 由于没有正式参加过项目调研，故省略...... 项目立项 主要由项目经理发起立项会议，组织相关人员参加立项会议并启动评审项目。在该阶段，项目经理提交项目立项申请书，该说明书主要包括以下内容：项目总体需求，项目目标，项目中技术难度，项目预期成果，项目主要开发人员以及项目总体开发计划（包含测试和验收）。 需求分析评审 一般的需求工程流程主要有 需求这一块，如果所在部门中并没有明确人员分工，就存在了一旦遇见和需求有关的问题，并不能立马解决以及没有相关需求文档资料查阅等问题。未来随着所在公司不断发展，建议由专门人员（并非开发人员）负责需求工作，对接客户需求。 在项目需求分析评审阶段，由于时间比较紧迫，最新开发的项目大概用了两周的时间。为了保障项目的顺利开展，我们不断对需求进行更改，评审会议也开了三次。但由于种种原因，并没有严格按照需求工作流程进行执行。 原型设计 基于项目立项申请书和项目需求文档说明书，项目经理确认项目开发架构

对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。 ---　　经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。” --　　-分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。” --　　-经理觉得奇怪：“我不是刚告诉你我的需求了吗？” --　　-分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。” --　　-经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？” ---　

对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。 ---　　经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。” --　　-分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。” --　　-经理觉得奇怪：“我不是刚告诉你我的需求了吗？” --　　-分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。” --　　-经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？” ---　

在软件工程领域，有过很多软件开发模型，如瀑布模型、快速原型模型、增量模型、螺旋模型、演化模型、喷泉模型、RAD模型、敏捷软件开发模型、XP极端模型。这么多的模型各有各的应用场景、各有各的适用范围，但我认为最实用开发模型还是敏捷软件开发。 中国式软件开发思路是什么样的呢？从我接触过的大多软件项目来看，基本都有一个共同特点——就是必须快，客户都是急脾气，恨不得今天立项，明天就要你拿出产品来。 面对公司和客户如此快节奏的要求，我们有办法吗？人们从生产、生活中总结出来一套即高效又优质的开发模式——敏捷软件开发。 什么是敏捷软件开发呢？ 敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系、而又可以独立运行的小项目，并分别完成，从而实现快速开发的目的。 还是具体来说下敏捷开发是如何实现的？ 1、 将大的系统拆分成子项目。 以前我们接受过的思想是立项后先要需求调研、分析，调研后出各种调研报告及需求说明书，需求搞定后，再进行概要设计（UE设计、UI设计、交互设计、数据库设计、框架设计），概要设计完成后再进行详细设计……这样一个周期下来，耗费太长，当进度进入下一阶段，当上一阶段有问题时，会影响到整个项目流程的各个阶段。

3 月，跳不动了？>>> 当突发事件来临时，当绝佳idea闪现时，如何快速搞定开发和部署，使之变身为产品？快，则应万变！Serverless 是当今炙手可热的技术，被认为是云计算发展的未来方向，如何利用Serverless Framework 实现快速上云？本文是王俊杰老师在「云加社区沙龙online」的分享整理，详细阐述了Serverless上云的基本思路、框架原理、组件架构等，带大家揭开Serverless的神秘面纱。 应对突发需求，如何借助Serverless快速上云？_腾讯视频 ​ 一、Serverless上云基本概念 感谢云加社区组织这次“技术应变力”的线上专题活动，并邀请我来进行分享，我将从Serverless的角度来进行解读。Serverless是最近非常热门的词，中文翻译为“无服务器”。有人认为既然是无服务器，就意味着不再需要运维，完全是按需付费的模式...... 其实这些理解都比较片面，描述的都只是Serverless的某个方面。 从2014~2020年，这几年Serverless关键词的谷歌搜索指数与日攀升，现在已经成为了非常火爆的技术名词。其实早在2006年就有人提出Pay as you go的概念，需要多少就买多少，但直到2012年，Serverless首次被提出。2014~2016年，大型云厂商纷纷发布函数计算相关的产品支撑这样一个无服务器技术。

花了几天时间把这本书读完了，可以说让我对产品经理的整个框架有了更清晰的认识，产品思维也得到了提升。本书的作者苏杰用自己在阿里工作这几年的亲身经历和切身体会，将一个产品经理的工作内容和所需能力以贴近实际的方式展现出来。 第一章讲的什么是产品经理，互联网行业的产品经理与传统行业的产品经理区别在哪，让我对产品经理有了更清晰的认识。 从第二章开始，作者结合自己的亲身经历讲述了一个产品需求是如何产生的。用户是需求之源，要从用户中来到用户中去，努力去了解用户，然后尽可能的采集需求。我们要听目标用户怎么说，也要看用户怎么做，因为有的时候用户说的和做法是不一致的，然后从定性和定量两个维度来采集需求。定性是了解，定量是验证，首先定性地说，以用户访谈的方式，记录用户所关心的问题，确定产品的方向，列出需求清单；然后定量地说，通过调查问卷等方式，确定产品的优先级；再定性的做，一边设计一边找用户来验证，做可行性测试；最后，定量的做，根据用户的使用情况做数据的分析，不断改进产品。需求的采集要尽可能的多，但留下了的总是少数，这并不意味着之前采集的需求是白费的，经过各种分析和评审，留下来的肯定是最值得做的。 通过第二章讨论了需求采集和分析，第三章讲述了一个项目的完整流程。从立项、需求、开发、测试到发布，产品经理贯穿其中。BRD、MRD、PRD等各种文档和原型设计，以及一些UML都需要产品经理来做

作者: 唐杰 分类: 职场人生 发布时间: 2011-10-19 16:40 唐杰求职产品需求文档 唐杰PRD 产品状态： [ ]即将离职 [√]已经离职 [ ]正式工作 文件标识： TangJie 当前状态： 求职中… 文档作者： 唐杰 完成日期： 2011-10-19 修订历史 　　　　　　　　　　　　　　 序号 版本 编写/修订说明 修订人 修订日期 备注 1 Beta 创建：HTML和docx简历 唐杰 2011-10-01 2 V1.0 修改：更新简历，修饰词语，并发布 唐杰 2011-10-08 3 V2.0 Beta 创建：基于文字版改进，发布 V2.0 Beta 唐杰 2011-10-18 同时发布原型版 目录 一、求职概述 1、唐杰背景介绍 2、唐杰概述及目标 3、参考文档 4、术语与缩写解释 二、简历角色 三、职业信息 1、基本信息 2、职业介绍 2.1、工作经历 2.2、项目经验 2.3、作品案例 3、技能介绍 四、简历模型 1、简历结构图 2、简历原型Demo 五、求职需求 1、作息需求 2、待遇需求 3、企业需求 一、求职概述 1、唐杰背景介绍 2007年以个人站长的形式进入互联网行业，开始学习网页设计、SEO推广、网站运营、用户体验优化、产品设计等多个知识体系，从中积累了综合能力； 2009年接触产品概念并开始向产品类工作靠拢，之后开始学习体验优化