外包软件开发流程

外包软件开发流程外包软件开发流程 1 商务谈判商务谈判 武汉 沃 航 科 技 一款软件准备开发时 首先就是和甲方公司进行接洽和商务谈判 初步了解用户需求 以及这个项目甲方对资金以及工期和其他的各方面的预估 初步达成合作意向 2 产品需求讨论产品需求讨论 需求分析是做产品的头等大事 而需求分析的第一步就是找准产品定位 产品定位实 际上就是关于产品的目标 范围 特征等约束条件 它包括两方面的内容 产品定义和用 户需求 产品定义主要由产品经理从网站角度考虑 用户需求主要由设计师从用户角度考 虑 明确了产品定位 也就确定了产品设计的方向 统一了团队成员对产品的理解 可以 避免团队内很多不必要的争执 产品定义就是用一句话概括产品 包括如下三个方面 使用人群 产品服务于哪类人群 主要功能 功能范围的限定 产品特色 与同类产品相比的竞争优势 举例 一款音乐应用的产品定义 使用人群 白领 主要功能 播放音乐 产品特色 音质清晰 更新速度快 用户需求概括起来就是 谁 在 什么环境下 想要 解决什么问题 一般可以分解 为一个个用户故事 包括如下三个方面 目标用户 目标用户是在使用人群细分的基础上 得到的 它也在一定程度上影响了使用场景和用户目标 拆解用户的时候考虑潜在用户量 和商业价值 使用场景 用户使用产品的环境 需要关注不同场景的特点 用户目标 用户在不同场景下期望完成的目标 可从中提取出功能关键词 3 prd 输出和确认输出和确认 一般一份 PRD 文档要包含以下这些内容 1 概述部分 简单介绍一下产品的背景 产品的价值或者愿景 产品的简单介绍 一些预估的风险点 干系人 名词解释等等 2 业务需求描述部分 定义好目标用户群体 业务流程图 业务架构图 脑图等等的 介绍 3 功能需求描述部分 这部分才是用到上面所述方法的点 每个功能点都可以用那样 的方式描述 4 非功能需求描述部分 与产品相关的一些辅助功能 性能要求 易用性要求等等 5 接口描述部分 与外部有相关接口的需要在这个部分描述 6 附录部分 培训信息 参考资料等 还可以有运营计划等等 完整的 PRD 文档中 最多的部分就是对功能需求的分解描述 AxureRP 可以很好的支撑这个部分的全部内容 另外其实 AxureRP 也有流程图 UML 图的功能 业务流程图 业务架构图等都可以在 AxureRP 里面实现出来 4 合同拟定合同拟定 需求确认完成后就要开始拟定合同了 合同要列出双方的责任与义务 验收方式 过程中遇到问题的解决情况 项目 资金打款的问题 保密协议 软件所有权 知识产权 著作权归属 外包完工之后 售后的支援 与帮助 确定双方的沟通的机制及开发周期 双方的主要干系人 开发负责人 产品负责人 项目支持等 简历微信群 讨论组 文档上传共享的网盘等 开发是每周一个周期 进行功能的测试与 UAT 然后将工期进展邮件抄送所有 人 主要是双方合作方式及实现方式 五五 项目计划项目计划 一个软件项目进入系统实施的启动阶段 主要进行的工作包括 确定详细的项目实施范围 定义递交的工作成果 评估实施过程中主要的风险 制定项目实施的时间计划 成本和预 算计划 人力资源计划等 在软件项目管理过程中一个关键的活动是制定项目计划 它是软件开发工作的第一步 项 目计划的目标是为项目负责人提供一个框架 使之能合理地估算软件项目开发所需的资源 经费和开发进度 并控制软件项目开发过程按此计划进行 在做计划时 必须就需要的 人力 项目持续时间及成本作出估算 这种估算大多是参考 以前的花费作出的 软件项目 计划包括二个任务 研究和估算 即通过研究确定该软件 项目的主要功能 性能和系统界 面 6 需求变更计划需求变更计划 每做一次项目计划变更 都会影响到日后的成本估算 活动顺序 行程日期 资源需 求及风险控管的决策 因此甲乙双方的项目经理 IT 经理都必须以整体的视野 统一的要 求 对变更进行控制 确认与纪录 而需求变更的控制关键在于建立相应的控制组织 变 更控制系统以及规范变更流程 充分做好前期的需求调研 系统培训等工作 深入企业一线 全面调查研究 最大程 度地挖掘企业用户的潜在需求 发现可能要需求变更的地方 让企业用户尽快做出是否要 进行需求变更 一般把需求变更或者新需求的确认最迟时间定在系统培训阶段 也就是说 在系统培训完成后 开始准备双线并行前 企业用户还可以提出需求变更的申请 但是 当系统开始双线运行时 就不允许用户再提出需求变更等类似的请求了 如编码的内容和 规则 表单的数量和格式 数据流转和统计方式等 否则就要付出变更的代价 建立变更控制组织系统 项目启动时 尽可能地与客户沟通 尽快建立正式的对变更 进行控制的组织 通称变更控制委员会 CCB 成员可包括双方高层 挂名 甲乙双方的项 目负责人 相关的需求负责人等 负责裁定接受变更内容 方法 步骤等 建立该系统的 目的是统一管理需求变更和跟踪变更的状态 便于项目组测试人员 开发人员 系统分析 员以及 PM 相互之间的沟通和交流 建立变更控制系统目的不是让用户不提出变更 而是 让用户不轻易 随便的提出变更 严格规范变更流程 一旦需求分析阶段结束 此后如果用户要求有新的需求加入即将 交付的软件系统中 甲乙双方的项目组或变更控制委员会 要根据角色定义 确定变更流 程 规定严格的变更控制流程 并控制新需求提出的频率 7 项目验收项目验收 对互联网产品而言 验收有三层含义 产品功能用例化后 用例执行符合预期 与需 求吻合 正向操作的用户体验良好 设计和前端 UI 符合评审的标准 第一层应该是测试人员 应该重点关注的 但在小公司或创业公司 开发 产品本身就是测试 验收几乎等同于最后 一次测试 但是无论是否有 测试工程师 这个岗位 产品需求的用例化都是十分必要的 即便通过了专门的测试 产品或领导在验收时 潜意识也是在执行相关的用例 第二层 说的是普遍意义上的验收 产品通过 test 平台测试 部署到了 DEMO 平台 由产品需求人 员进行需求验收 当然 内部成员 相关领导都可以进行验收体验 对 DEMO 的验收 是 装成用户 后对产品的使用 通常是正向操作 同时除了逻辑和流程 验收人员会更加 关注用户体验 关于前端 UI 的验收 实际上是对 用户体验 的一部分标准化 而验收 的内容应该与 设计评审 通过的内容相吻合 如果没有设计评审 那么标准就是公说公 有理了 为了避免这种情况 需要在需求和设计评审前 界定清楚一些基本的准则和规范 比如符合公司的 VI 体系 符合 W3C 页面标准 符合 XXX 最直观的还是所见即所得的 需求设计交互页面 这个问题其实很好 好在专门提出了 UI 的验收 本质上是因为开 发对 UI 或者对前端 兼容性等很容易忽略 因为这是个 简单但很花时间 的活儿 做起 来没有成就感 当然 如果你们有一套自己的 UI 库或前端框架 那么能够规避很多前端上 的扯皮 但如果没有 开发和前端至少需要 50 的精力去搞页面 提前考虑标准 尽量使 用框架 让代码公用并易于维护 这是前端和攻城师的硬功夫 否则就沉浸在无尽的 BUG 中 更不用说验收了 至于谁负责 团队中的任意相关人都可以 前端 开发 产品 或者你们领导 总之 验收就是质量的最后把关 产品自己都看不过去 臭虫一堆 千万 不要有任何侥幸心理让用户帮着验收 8 迭代计划迭代计划 做产品 Roadmap 规划的时候 要想清楚哪些需求是包括在 MVP Minimal Variable Product 的 也就是说第一版必须抓住目标用户的痛点和切实需求 在时间 金钱 资源有限 的情况下 弄明白哪些功能点是必不可少的 对产品推出后成功是至关重要的 如何弄 明白这个问题 那就是从用户调研数据得来 没有经过用户验证过的产品原型一般来说都 很难经得起推敲 因为这是在设计师 或者产品经理 的假设上完成的作品 而并不一定 会获得用户的青睐和肯定 当有了 MVP 第一版 以后 就可以在市场的反馈结果上做 下一步考虑 哪些地方是需要修改的 哪些功能点是需要补充的 哪些地方其实用户反响 并不大可以移除的 把这些点做优先级排列 最重要和最紧急的放在下一个