外包软件开发流程.doc

外包软件开发流程
一. 商务谈判
武汉-沃-航-科-技
一款软件准备开发时，首先就就是与甲方公司进行接洽与商务谈判，初步了解用户需求以及这个项目甲方对资金以及工期与其她得各方面得预估，初步达成合作意向。
二. 产品需求讨论
需求分析就是做产品得头等大事，而需求分析得第一步就就是找准产品定位。产品定位实际上就就是关于产品得目标、范围、特征等约束条件，它包括两方面得内容：产品定义与用户需求。产品定义主要由产品经理从网站角度考虑，用户需求主要由设计师从用户角度考虑。明确了产品定位，也就确定了产品设计得方向，统一了团队成员对产品得理解，可以避免团队内很多不必要得争执。
产品定义就就是用一句话概括产品，包括如下三个方面：
使用人群：产品服务于哪类人群。
主要功能：功能范围得限定。
产品特色：与同类产品相比得竞争优势。
举例：一款音乐应用得产品定义。
使用人群：白领
主要功能：播放音乐
产品特色：音质清晰、更新速度快
用户需求概括起来就就是：「谁」在「什么环境下」想要「解决什么问题」。一般可以分解为一个个用户故事，包括如下三个方面： 目标用户：目标用户就是在使用人群细分得基础上得到得，它也在一定程度上影响了使用场景与用户目标。拆解用户得时候考虑潜在用户量与商业价值。 使用场景：用户使用产品得环境，需要关注不同场景得特点。 用户目标：用户在不同场景下期望完成得目标，可从中提取出功能关键词。
三. 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测试不就是用来测试用户需求与主要功能点得，而就是当产品有了一定得用户基数以后，团队对产品有了一些新得设计想法时，不能确定这个新设计就是利大于弊还就是弊大于利，于就是对一些访问用户展示新得设计，同时对另一部分访问用户保留原有得设计，这样可以从用户转化率等其它目标变量来测试究竟哪一版得设计更改。