外包软件开发流程

外包软件开发流程
一.商务谈判
武汉-沃-航-科-技
一款软件准备开发时，首先就是和甲方公司进行接洽和商务谈判，初步了解用户需求以及这个项目甲方对资金以及工期和其他的各方面的预估，初步达成合作意向。

二.产品需求讨论
需求分析是做产品的头等大事，而需求分析的第一步就是找准产品定位。

产品定位实际上就是关于产品的目标、范围、特征等约束条件，它包括两方面的内容：产品定义和用户需求。

产品定义主要由产品经理从网站角度考虑，用户需求主要由设计师从用户角度考虑。

明确了产品定位，也就确定了产品设计的方向，统一了团队成员对产品的理解，可以避免团队内很多不必要的争执。

产品定义就是用一句话概括产品，包括如下三个方面：
使用人群：产品服务于哪类人群。

主要功能：功能范围的限定。

产品特色：与同类产品相比的竞争优势。

举例：一款音乐应用的产品定义。

使用人群：白领
主要功能：播放音乐
产品特色：音质清晰、更新速度快
用户需求概括起来就是：「谁」在「什么环境下」想要「解决什么问题」。

一般可以分解为一个个用户故事，包括如下三个方面：目标用户：目标用户是在使用人群细分的基础上得到的，它也在一定程度上影响了使用场景和用户目标。

拆解用户的时候考虑潜在用户量和商业价值。

使用场景：用户使用产品的环境，需要关注不同场景的特点。

用户目标：用户在不同场景下期望完成的目标，可从中提取出功能关键词。

三.prd输出和确认
一般一份PRD文档要包含以下这些内容：
1、概述部分：简单介绍一下产品的背景，产品的价值或者愿景，产品的简单介绍，一些预估的风险点，干系人，名词解释等等；
2、业务需求描述部分：定义好目标用户群体，业务流程图，业务架构图，脑图等等的介绍；
3、功能需求描述部分：这部分才是用到上面所述方法的点，每个功能点都可以用那样的方式描述；
4、非功能需求描述部分：与产品相关的一些辅助功能，性能要求、易用性要求等等；
5、接口描述部分：与外部有相关接口的需要在这个部分描述；
6、附录部分：培训信息、参考资料等，还可以有运营计划等等；完整的PRD文档中，最多的部分就是对功能需求的分解描述，AxureRP可以很好的支撑这个部分的全部内容，另外其实AxureRP也有流程图、UML图的功能，业务流程图、业务架构图等都可以在AxureRP 里面实现出来。

四.合同拟定
需求确认完成后就要开始拟定合同了。

合同要列出双方的责任与义务，验收方式，过程中遇到问题的解决情况，项目资金打款的问题
保密协议，软件所有权，知识产权、著作权归属，外包完工之后，售后的支援与帮助。

确定双方的沟通的机制及开发周期
双方的主要干系人，开发负责人，产品负责人，项目支持等
简历微信群，讨论组，文档上传共享的网盘等
开发是每周一个周期，进行功能的测试与UAT，然后将工期进展邮件抄送所有人主要是双方合作方式及实现方式
五.项目计划
一个软件项目进入系统实施的启动阶段,主要进行的工作包括:确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。

在软件项目管理过程中一个关键的活动是制定项目计划，它是软件开发工作的第一步。

项目计划的目标是为项目负责人提供一个框架，使之能合理地估算软件项目开发所需的资源、经费和开发进度，并控制软件项目开发过程按此计划进行。

在做计划时，必须就需要的人力、项目持续时间及成本作出估算。

这种估算大多是参考以前的花费作出的。

软件项目计划包括二个任务：研究和估算。

即通过研究确定该软件项目的主要功能、性能和系统界面.
六.需求变更计划
每做一次项目计划变更，都会影响到日后的成本估算、活动顺序、行程日期、资源需求及风险控管的决策，因此甲乙双方的项目经理、IT经理都必须以整体的视野、统一的要求，对变更进行控制、确认与纪录。

而需求变更的控制关键在于建立相应的控制组织、变更控制系统以及规范变更流程。

充分做好前期的需求调研、系统培训等工作。

深入企业一线，全面调查研究，最大程度地挖掘企业用户的潜在需求，发现可能要需求变更的地方，让企业用户尽快做出是否要进行需求变更。

一般把需求变更或者新需求的确认最迟时间定在系统培训阶段。

也就是说，在系统培训完成后、开始准备双线并行前，企业用户还可以提出需求变更的申请，但是，当系统开始双线运行时，就不允许用户再提出需求变更等类似的请求了，如编码的内容和规则、表单的数量和格式、数据流转和统计方式等，否则就要付出变更的代价。

建立变更控制组织系统。

项目启动时，尽可能地与客户沟通，尽快建立正式的对变更进行控制的组织，通称变更控制委员会(CCB)，成员可包括双方高层(挂名)、甲乙双方的项目负责人、相关的需求负责人等，负责裁定接受变更内容、方法、步骤等。

建立该系统的目的是统一管理需求变更和跟踪变更的状态，便于项目组测试人员、开发人员、系统分析员以及PM相互之间的沟通和交流。

建立变更控制系统目的不是让用户不提出变更，而是让用户不轻易、随便的提出变更。

严格规范变更流程。

一旦需求分析阶段结束，此后如果用户要求有新的需求加入即将交付的软件系统中，甲乙双方的项目组或变更控制委员会，要根据角色定义，确定变更流程，规定严格的变更控制流程，并控制新需求提出的频率。

七.项目验收
对互联网产品而言，验收有三层含义：产品功能用例化后，用例执行符合预期与需求吻合，正向操作的用户体验良好设计和前端UI符合评审的标准第一层应该是测试人员应该重点关注的，但在小公司或创业公司，开发/产品本身就是测试，验收几乎等同于最后一次测试。

但是无论是否有“测试工程师”这个岗位，产品需求的用例化都是十分必要的，即便通过了专门的测试，产品或领导在验收时，潜意识也是在执行相关的用例；第二层说的是普遍意义上的验收，产品通过test平台测试，部署到了DEMO平台，由产品需求人员进行需求验收，当然，内部成员、相关领导都可以进行验收体验。

对DEMO的验收，是“装成用户”后对产品的使用，通常是正向操作，同时除了逻辑和流程，验收人员会更加关注用户体验；关于前端UI的验收，实际上是对“用户体验”的一部分标准化，而验收的内容应该与“设计评审”通过的内容相吻合。

如果没有设计评审，那么标准就是公说公有理了。

为了避免这种情况，需要在需求和设计评审前，界定清楚一些基本的准则和规范，比如符合公司的VI体系、符合W3C页面标准、符合XXX，最直观的还是所见即所得的“需求设计交互页面”这个问题其实很好，好在专门提出了UI的验收。

本质上是因为开发对UI或者对前端、兼容性等很容易忽略，因为这是个“简单但很花时间”的活儿，做起来没有成就感。

当然，如果你们有一套自己的UI库或前端框架，那么能够规避很多前端上的扯皮，但如果没有，开发和前端至少需要50%的精力去搞页面。

提前考虑标准、尽量使用框架、让代码公用并易于维护，这是前端和攻城师的硬功夫，否则就沉浸在无尽的BUG中，更不用说验收了。

至于谁负责？团队中的任意相关人都可以，前端、开发、产品、或者你们领导。

总之，
验收就是质量的最后把关，产品自己都看不过去，臭虫一堆，千万不要有任何侥幸心理让用户帮着验收。

八.迭代计划
做产品Roadmap规划的时候，要想清楚哪些需求是包括在MVP (Minimal Variable Product)的。

也就是说第一版必须抓住目标用户的痛点和切实需求。

在时间金钱资源有限的情况下，弄明白哪些功能点是必不可少的，对产品推出后成功是至关重要的。

如何弄明白这个问题？那就是从用户调研数据得来。

没有经过用户验证过的产品原型一般来说都很难经得起推敲，因为这是在设计师（或者产品经理）的假设上完成的作品，而并不一定会获得用户的青睐和肯定。

当有了MVP（第一版）以后，就可以在市场的反馈结果上做下一步考虑，哪些地方是需要修改的，哪些功能点是需要补充的，哪些地方其实用户反响并不大可以移除的。

把这些点做优先级排列，最重要和最紧急的放在下一个产品迭代周期的开发之首，再对新的产品原型做用户测试再做迭代。

A/B测试不是用来测试用户需求和主要功能点的，而是当产品有了一定的用户基数以后，团队对产品有了一些新的设计想法时，不能确定这个新设计是利大于弊还是弊大于利，于是对一些访问用户展示新的设计，同时对另一部分访问用户保留原有的设计，这样可以从用户转化率等其它目标变量来测试究竟哪一版的设计更改。