产品开发白皮书.docxVIP

产品开发白皮书（草稿）编写目的：扎扎实实为产品开发、测试、实施等提供完整的指导思路，合理协调好各个角色之间的关系，将各种角色拧成一股劲共同为打造优质产品这个目标而服务。角色矩阵图需求设计编码测试实施产品经理√√√技术经理√√开发人员√√测试人员√√实施人员√√√产品过程分解立项——功能需求——DEMO——设计（包括数据库）——编码——测试——验收——发布立项：产品经理完成立项文档。立项文档首先能够替代开发合同或者用户需求报告，这个是整个项目的核心思想。功能需求：1.罗列产品所有功能，告之整个产品有哪些功能模块。根据实际情况，通常按照迭代方式增加，能够预知多少罗列多少。没有专门的需求人员，由产品经理来完成。DEMO：产品不急的情况，一定要做demo。这个权利由总经理或者开发部经理来定。Demo的要求：能展现已知的功能界面和操作方式，用于跟客户的交付，便于更早从客户那边带来意见和需求。没有专门的人员由产品经理自己或者指派相关人员根据功能需求的描述展现。设计：根据功能需求，设计数据库和系统架构。由产品功能经理或者技术经理完成。编码：根据demo和功能需求，实现具体功能。测试：包含单元测试、代码走查、功能走查、系统测试、性能测试、部署验证、安全测试等等。具体需要什么的测试，由测试经理和产品经理根据产品情况共同决定需要做哪些测试。单元测试由开发人员完成，技术经理把关。代码走查，由开发人员和测试人员共同完成，技术经理把关。其他所有的测试，主体由测试人员来完成，其他角色协助完成，测试经理把关。验收：根据测试报告对照需求列表及各项指标，测试经理、产品经理、技术经理、总经理等主要人员，共同表决来决定产品是否符合验收。发布：只允许发布beta版以上的稳定版本，特殊情况经总经理允许发布演示版本，代码不得外泄。Bata版本即为至少经过一轮测试过程的测试版本。所有产品及补丁包全部纳入到公司的产品仓库中，统一管理。全部以客户能体验到的功能说话，不谈虚的已经完成多少了，只看功能需求模块的任务量，完成多少就是多少，还有多少没有完成。评审名称拟稿人参与人员通过准则立项文档产品经理市场人员、产品经理、测试经理、核心人员必须全部通过，送交总经理签字批准。通过之后准备立项大会。功能需求产品经理产品经理、测试经理、核心人员必须全部通过，否则按照意见修改。需求必须通过评审才允许编码，否则测试人员不接受测试。开发人员不得私自变更需求，编码实现过程中，若需求需要变更，先变更再邮件告知全体项目人员，否则开发和测试人员全部按变更前执行。概要设计产品经理产品经理、技术经理、测试经理必须全部通过详细设计产品经理产品经理、技术经理、测试经理测试计划测试经理产品经理、测试经理、核心人员必须全部通过测试用例测试人员测试人员、开发人员注：一切以评审结果为准，不得随意私自变更，相关变更内容必须告知相关人员。评审内容至少提前一天，发给各位评审员，否则不接受评审。整个开发过程采用敏捷开发方式，迭代进行。分阶段，分优先级完成功能需求。这里结合一个开源的项目管理工具（禅道项目管理）来协助我们完成产品的研发管理工作。立项某一天产品经理接到任务要完成一个新产品的研发工作，很兴奋，终于有活干了。那就开始吧，去立项。（通常情况下，这些立项工作个别人先行，不要把大家伙全召集起来再去搞什么立项工作，这样很耽误时间，毕竟不需要很多人参加立项工作，等到评审或者开立项会议再叫他们也不迟的，还是让人家先忙其他事情吧。）立项需要做什么呢？我们来仔细瞧一瞧。立项的目的：1.告诉大家这个产品要开工了，是纲领性文件。2.这个产品是给谁用的，客户用它来干什么能够实现什么价值。3.这个产品有哪些主要的功能。4.要完成这个产品，我们大概需要多少人，多少时间。5这其间可能会有哪些技术难点和风险。（这里面重点在前3点，这是产品的核心思想。第4点主要是想大致了解整个产品需要多少人力，因为我们根本无法预估很长的未来也很难控制，我们可以把有效的时间控制放在后面的迭代分析中。）在立项期间，我们可能会先做两件事情——《立项调查报告》、《立项可行性分析报告》。这个不是必须的，主要是让决策人心里有一个底，现在的市场情况怎么样、竞争对手怎么样、开发新产品是否有意义、我们的产品需要在什么地方需要注意的等等。通常情况下《立项可行性分析报告》通过之后再开始《立项建议书》的草拟，如果决策人已经决定要做了，那就无须考虑了，把它们当做参考意见直接干吧。《立项建议书》里面我们要考虑哪些问题呢？之前在立项目的里面提过一部分了。打开立项建议书，根据样板好好想一想新产品实质性的信息是什么，不一定要拘泥于样板，但是真实反映新产品的核心内容。能够确定并且是已知的一定要写清楚，不能确定的根据经验来预估，后面还有评审会帮你把关的，但不要糊弄大家。最终目的不要填满一份《立项建议书》