《产品开发白皮书》由会员分享，可在线阅读，更多相关《产品开发白皮书（7页珍藏版）》请在金锄头文库上搜索。
1、产品开发白皮书（草稿）编写目的：扎扎实实为产品开发、测试、实施等供应完整的指导思路，合理协调好各个角色之间的关系，将各种角色拧成一股劲共同为打造优质产品这个目标而服务。角色矩阵图需求设计编码测试实施产品经理技术经理开发人员测试人员实施人员产品过程分解立项功能需求DEMO设计（包括数据库）编码测试验收公布立项：产品经理完成立项文档。立项文档首先能够替代开发合同或者用户需求报告，这个是整个项目的核心思想。功能需求：1.排列产品全部功能，告之整个产品有哪些功能模块。依据实际状况，通常依据迭代方式增加，能够预知多少排列多少。没有特地的需求人员，由产品经理来完成。 DEMO：产品不急的状况，肯定要做 d
2、emo。这个权利由总经理或者开发部经理来定。Demo 的要求：能呈现已知的功能界面和操作方式，用于跟客户的交付，便于更早从客户那边带来意见和需求。没有特地的人员由产品经理自己或者指派相关人员依据功能需求的描述呈现。设计：依据功能需求，设计数据库和系统架构。由产品功能经理或者技术经理完成。编码：依据 demo 和功能需求，实现具体功能。测试：包含单元测试、代码走查、功能走查、系统测试、性能测试、部署验证、平安测试等等。具体需要什么的测试，由测试经理和产品经理依据产品状况共同打算需要做哪些测试。单元测试由开发人员完成，技术经理把关。代码走查，由开发人员和测试人员共同完成，技术经理把关。其他全部的测
3、试，主体由测试人员来完成，其他角色帮忙完成，测试经理把关。 验收：依据测试报告对比需求列表及各项指标，测试经理、产品经理、技术经理、总经理等主要人员，共同表决来打算产品是否符合验收。公布：只允许公布 beta 版以上的稳定版本，特别状况经总经理允许公布演示版本，代码不得外泄。Bata 版本即为至少经过一轮测试过程的测试版本。全部产品及补丁包全部纳入到公司的产品仓库中，统一治理。全部以客户能体验到的功能说话，不谈虚的已经完成多少了，只看功能需求模块的任务量， 完成多少就是多少，还有多少没有完成。评审名称拟稿人参与人员通过准则立项文档产品经理市场人员、产品经理、测试经理、核心人员必需全部通过，送交
4、总经理签字批准。通过之后预备立项大会。功能需求产品经理产品经理、测试经理、必需全部通过，否则依据意见修改。需核心人员求必需通过评审才允许编码，否则测试人员不接受测试。开发人员不得私自变更需求，编码实现过程中，若需求需要变更，先变更再邮件告知全体项目人员，否则开发和测试人员全部按变更前执行。概要设计产品经理产品经理、技术经理、必需全部通过测试经理具体设计产品经理产品经理、技术经理、测试经理测试方案测试经理产品经理、测试经理、核心人员必需全部通过测试用例测试人员测试人员、开发人员注：一切以评审结果为准，不得任凭私自变更，相关变更内容必需告知相关人员。评审内容至少提前一天，发给各位评审员，否则不接受
5、评审。整个开发过程接受灵敏开发方式，迭代进行。分阶段，分优先级完成功能需求。这里结合一个开源的项目治理工具（禅道项目治理）来帮忙我们完成产品的研发治理工作。立项某一天产品经理接到任务要完成一个新产品的研发工作，很兴奋，最终有活干了。那就开头吧，去立项。（通常状况下，这些立项工作个别人先行，不要把大家伙全召集起来再去搞什么立项工作，这样很耽搁时间，到底不需要很多人参与立项工作，等到评审或者开立项会议再叫他们也不迟的，还是让人家先忙其他事情吧。）立项需要做什么呢？我们来认真瞧一瞧。立项的目的：1.告知大家这个产品要开工了，是纲领性文件。2.这个产品是给谁用的， 客户用它来干什么能够实现什么价值。3
6、.这个产品有哪些主要的功能。4.要完成这个产品， 我们或许需要多少人，多少时间。5 这其间可能会有哪些技术难点和风险。（这里面重点在前 3 点，这是产品的核心思想。第 4 点主要是想大致了解整个产品需要多少人力，由于我们根本无法预估很长的将来也很难把握，我们可以把有效的时间把握放在后面的迭代分析中。）在立项期间，我们可能会先做两件事情立项调查报告、立项可行性分析报告。这个不是必需的，主要是让决策人心里有一个底，现在的市场状况怎么样、竞争对手怎么样、 开发新产品是否有意义、我们的产品需要在什么地方需要留意的等等。通常状况下立项可行性分析报告通过之后再开头立项建议书的草拟，假如决策人已经打算要做了
7、，那就无须考虑了，把它们当做参考意见直接干吧。 立项调查报告.doc 立项可行性分析报告.doc立项建议书.doc立项建议书里面我们要考虑哪些问题呢？之前在立项目的里面提过一部分了。打开立项建议书，依据样板好好想一想新产品实质性的信息是什么，不肯定要拘泥于样板，但是真实反映新产品的核心内容。能够确定并且是已知的肯定要写清楚，不能确定的依据阅历来预估，后面还有评审会帮你把关的，但不要糊弄大家。最终目的不要填满一份立项建议书， 而是搞清楚立项建议书所涉及到的内容，便于后期项目成员清楚新产品是干什么的，需要自己怎么去做。完成初稿，跟最有阅历的人员（人不要多12 就可以）进行有效沟通、争辩，实际上就是
8、内审，找出立项建议书中是否有哪些不正确的信息、模糊的信息、遗漏的信息等等（此时建议只争辩和收集问题，不做是否通过判定）。收集相关问题进行整改，可能会修改多次， 由于指不定你会突然想起什么来。（这个环节很重要，避开多次评审，铺张大家的时间。）接下来就可以开头进行正儿八经的初审了，参与人员会扩至治理层和部分核心人员（具 体请参考评审表）。评审之前提前一天将评审内容发给各位评审员。会上介绍立项建议书内容，并接受提问、解答和争辩。信任问题不会很多，前面到底做了很多的功课和内审，最终大家进行表决，原则上多数通过即为通过。修改评审会上提到的微小问题，最终送总经理处进行签字确认。下面预备一下，召集各位成员开
9、立项大会，昭告天下。后面就可以动工了。禅道项目治理做什么事情？让治理员给你开一个新产品并赐予你该产品相应的权限，以“土地利用规划治理系统” 为例：这里仅仅开了一条产品线，里面描述了新产品的特点、主要功能目标和相关责任人，把立项建议书的部分内容黏贴过就 ok 了。首先明确一下产品和项目的概念。我们通常所说的项目，其实是产品的概念，比如我们做什么什么项目，其实是在做一个产品。而我们所说的项目几期几期，则是项目的概念。在开源软件中，禅道明确的将产品和项目区分了开来。比如我们正开发的“土地利用总体规划治理系统”，以前通常会排出一个很长的方案来，从需求、编码、测试等等等，那在执行的时候会怎么样呢，可能会
10、一次次在调整方案。为什么会这样呢，很简洁我们的工作不是传统行业没有什么标准时间，个人力量会有层次不齐，预估和执行多少会有偏差，大量的工作量叠加在一起就会造成偏差越来越大。这中间确定会有很多你之前没有预估到的事情，这样算 起来不延迟才怪呢。那在这里我们就把整个产品进行拆分，拆分成个一个个项目去实现。让想项目可执行程度更高，更精确，更能看到成果。产品经理需要有肯定的推断力量，能够指引产品线，分几个阶段来实现，给各个阶段来划定目标，就自然生成一个个项目了。因此， 产品是需求方，打算做什么。项目是执行方，解决的是如何做的问题。而测试则是保障方， 解决的是正确的做事情的问题。全部的一切都是围绕产品开放的
11、，产品是整个项目治理活动 的核心。（后面渐渐解析项目如何实现产品。）有了自己的产品线，你需要做定义需求功能点、拆分项目、建立一个团队、支配方案、添加文档等等工作。1. 添加文档首先将以有的文档和资料存储到产品文档库中，便于成员访问。进入产品视图，选择文档，点击页面右上角“创建文档”，创建相应的文档。创建文档时，留意对应的所属分类和文档标题，并附上相应的说明即可。文档所属分类是预先预设好了的，需要调整可以联系治理员在文档视图内进行编辑。2. 需求说实在话需求是产品成败的核心因素，不管以何种方式呈现但最终肯定要能够表达清楚让执行者和验证者知道要什么，除非整个产品就一两个人搞出来了，即使这样也不便利
12、日后的升级维护。需求是产品的指导书，不是操作手册！它的诞生肯定是权威人士一手策划的并且通过大家的全都认可，可以说在一段时间内它大家心目中的蓝图。没有蓝图的产品，每个人有每个人的样子最终就成了四不像，所以在这边特别特别强调需求的作用。需求如何诞生呢？第一，它是来自客户的明确要求和潜在意识想法。其次，来自阅历深厚的产品经理，能够深刻体会到客户日常工作中的痛处。第三，来自团队内部的集思广益。需求会经受哪些阶段呢？固然我们最期盼需求是完完整整的，但是在实际状况中，往往执行起来比较困难尤其是在国土行业。那我们首先确定产品的核心需求功能点，这些功能点不肯定一下子全部搞定，但我们总能够预知一些，那就确定多少
13、需求功能点，我们在项目中就去实现多少，实现的过程中其他部分需求也同步产生了。以这样迭代循的方式渐渐推动产品的脚步。操作步骤：进入产品视图，选择需求，点击页面右上角“新增需求”，就能弹出来了。下面我们来看看，需求里面我们写哪些重要的东西。1) 需求所对应的模块名称，这个依据产品状况来定。假如有 DEMO 或者产品模块比较清楚，这个可以在产品视图中模块中事先定义好，此处即可直接选择。假如需求定不下来，模块也无法确定的话，建议临时先不弄，后面再做关联。2) 需求所属的方案，是指该需求会在哪个方案里面被执行。通常意义上，还是先把功能点排列出来之后，再来编排你的方案比较合理一些。但假如你是一个方案性很强
14、的人，可以先排方案再做需求。3) 估量工时，就是你认为一般人员完成该需求或许需要多久，千万别抠得太紧不是每个人都像你那么强。4) 评审人员，通常选择阅历最足的那位，不过评审工作往往不是一个人的活，需要大家集思广益，获得大家的全都认可尤其是客户的认可才为关键。5) 需求描述，这是最重要的部分。我们建议：第一行描述功能的功能意义，让人知道该需求是干嘛的。其次部分为正确路径，描述客户正常操作习惯和步骤。这个肯定是客户最常用的动作，若不是那这个 需求就有问题了。第三部分为留意事项，这部分包括错误处理方法、技术细节等等信息。6) 附件添加，全部类型文件均可添加，若是图片也可以直接挂在“需求描述区”，直接黏贴也行。3. 的4. 的5. 的6. 的7.8.需求9.10. 操作步骤：工程师对需求理解得很透彻，对业务很精通1. 项目阶段项目立项、项目策划、需求开发、系统设计、代码编码、系统测试、系统实施、项目结项2. 变更类型立项文档、项目方案、设计、需求、编码、数据库、测试用例、操作手册、里程碑3. 版本测试版、最终公布版
