互联网产品的开发流程

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

互联网新产品的开发流程

1.战略规划

我没有参与过战略方向的制定,仅有幸以旁听的形式进行过几次战略讨论,这些讨论会与其说是战略讨论会,不如说是公司管理层极力说服大家朝着某个战略方向走,也就是战略思想灌输。

2.前期分析

这个阶段需明确项目的主体目标,主体目标的明确需通过一系列的分析得出,而不是凭空而来。

首先要了解整个领域的情况,竞争对手,用户,甚至需要关注一下国家政策。对于互联网产品来说,了解竞争对手的成本相对较低,通过对竞争对手的分析,可以发现对手做的好的和不好的地方,可以为自己的产品节省大量时间。

其次发现项目的优势和劣势,可考虑那些优势会是带来商业利益的关键点,那些劣势会阻碍项目进程,考虑如何去克服,尽量避免乐观思维。

最后,尽管不是这阶段最重要的,可与技术专家沟通项目目标,考虑技术选型。理想情况是,尽可能利用现有的东西,尤其是开源产品。另外,技术专家经过初步分析后,可能会考虑人员招聘的需要。

3.需求设计

3.1.需求概念设计

这阶段的开始往往是伴随着头脑风暴会,选出一些靠谱的功能,

然后由产品经理给出一个功能范围定义,最好能附上部分核心功能的交互流程。通过需求确认会议,找上老大们敲定下来项目的功能范围,需要有会议记录,否则会出现项目进行中会有老大们跳出来要求改方向的事故。

3.2.正式立项

召开立项会议,确定项目负责人和项目组成员,并由产品经理根据概述文档或MRD向老大们和项目组成员阐述本项目的主要任务内

容和目标,描述产品是什么,为什么要做成这样,能解决用户的什么问题,市场优势是什么,未来发展预期等等。帮助项目组成员理解项目的目的、目标和意义,对产品达成统一认识。

4.需求确定

根据以上阶段积累的产品蓝图,产品经理撰写一系列的文档,主要产出物是PRD和交互原型。

4.1.PRD(Product Requirement Document产品需求文档)

PRD侧重对产品的产品功能和性能的说明,相对于“概述文档”中的同样内容,要更加详细,并进行量化。简单来说,这份文档的作用就是文字化需求——“怎么”去开发,对产品涉及的方方面面:流程图(Visio)、表格(excel)、逻辑、实现中需要注意的事项、小细节等进行尽可能详细的描述;简而言之,这份文档是可以无所不包的,目标是帮助大家规避开发风险,在不开发任何一行代码的情况就已经清晰地认识到全部的产品目标、开发过程和工期、实现难度等等。

4.2.交互原型

对于开发人员而言,也许一份好的PRD文档足以让他们立刻开始编码工作,但就整个项目来看,技术层面的开发风险(我们是否在正确的开发产品)往往能够通过经验、技术化手段来规避;产品风险,或者称之为体验风险(我们是否在开发正确的产品)——我们开发的产品用起来究竟“怎样”,就需要通过图像化的“文档”,帮助大家了解到产品最终在用户手里的使用体验。

交互设计师根据产品需求做出交互原型,真实再现用户交互过程,并与PM进行内部评审。(视情况,如没有交互设计师此步骤由产品经理与美工配合完成)

4.3.需求评审

相关领域的顾问(即有丰富经验者:产品专家、技术专家,不是项目团队成员)、PM和项目组成员(如项目组中没有美术还可以邀请他们参加)参与的评审PRD和交互原型的会议,一般项目经理、产品负责人需参与会议。会议必须有主持,并在会后出MEMO(备忘)或PRD更新说明。

项目组中的开发人员接到PRD后,需评估完成开发的大致时间,以及任务分解安排。

4.4.界面和视觉设计

由美工(视觉设计师)设计页面风格、布局、关键界面等,交由产品经理和交互设计师进行效果图评审。效果图通过后,美工产出效果图、layout和资源给前端开发工程师。前端开发工程师根据设计

页面切图,编写HTML,CSS,JS源代码。

5.开发和测试阶段

5.1.系统设计

在编码之前,开发人员应视其系统需要,进行概要设计、数据库设计,并进行内部讨论和评审,邀请顾问参与。除系统设计的基础思路外,需考虑差异化设计,保证互联网产品的安全性、可靠性、可扩展性等。互联网是一个快速变化的世界,我们所面临的用户、环境每天都在改变,这就要求系统设计能够适应这种情况,为产品开发做到快速迭代打好基础,降低因产品版本升级带来的系统重构风险。

5.2.程序开发

开发人员对文档有疑问或不理解,需与产品经理进行沟通,了解其真实涵义,不得以任何理由私自更改已确定的PRD、原型、设计图和资源等。确有功能需做调整,开发人员需与产品经理共同协商完成。

5.3.α(alpha最初)测试

在开发小组内部进行,测试的方法也较多,黑盒、白盒、压力、应力等。此阶段应完成80%以上的需求开发,测试以PRD为准。测试完成后,收集反馈,修复BUG,优化流程。

5.4.集成测试

测试工程师根据PRD、交互原型和效果图分析测试需求,指定测试计划,撰写测试用例。在开发完成α测试后,根据测试用例开始集成测试。

5.5.产品验收

测试工程师宣布产品通过集成测试后,申请产品经理验收。如产品与PRD和交互原型相差较大,产品负责人有权不接受产品,责任由开发部门负责。

6.产品发布

产品经理验收通过后,测试工程师安排产品在生产环境进行部署的计划。系统发布需要有严格的发布规范和工具来支持,尤其要支持“版本恢复”功能,一旦新版本出现问题,可以立刻能恢复到之前的稳定版本。

7.系统运维

系统运维是指系统的日常管理和维护,这包括对服务器硬件、网络、带宽方面的维护,以及软件系统的日常管理。

在互联网项目中,系统运维的核心工作是对服务器和网络的管理。在项目开始的时候,需要进行硬件选型、网络规划;在项目上线后,要对硬件和网络实施不间断的监控,并及时进行调整。往往,很多开发人员不具备系统级的知识和经验,因此他们所开发的程序经常对这些方面的问题考虑不足。这就需要运维团队的系统专业人员给出建议。关于系统对CPU、内存、磁盘、网络等方面的要求,运维团队需要和开发团队紧密合作,来不断完善系统。

8.产品运营

随着产品的上线,运营工作也随之开始。运营的核心目的是让产品活的更好、活的更久。产品运营通过使用产品内部资源,尽可能留

相关文档
最新文档