产品开发过程

EVT : Engineering Verification Test， 工程验证测试 产品开发初期的设计验证。设计者实现样品时做初期的测试验证，包括功能和安规测试，一般由RD(Research & Development)对样品进行全面验证，因为是样品，问题可能较多，测试可能会做N 次。 DVT: Design Verification Test，设计验证测试 解决样品在EVT 阶段的问题后进行，对所有信号的电平和时序进行测试，完成安规测试，由RD 和DQA(Design Quality Assurance)验证，此时产品基本定型。 DMT: Design Maturity Test，成熟度验证 可与DVT 同时进行，主要极限条件下测试产品的MTBF(Mean Time Between Failure)。HALT(High Accelerated Life Test）& HASS(High Accelerated Stress Screen)等，是检验产品潜在缺陷的有效方法。 MVT: Mass-Production Verification Test，量产验证测试 验证量产时产品的大批量一致性，由DQA 验证。 PVT: Pilot-run Verification Test，小批量过程验证测试 验证新机型的各功能实现状况并进行稳定性及可靠性测试。 MP: Mass

OPD？这是什么玩意？google一下。忘记说了，最近google被封锁的厉害，那就百度一下吧。可惜，OPD找不出是什么。你今天你找不到是正常的，因为之前还没有OPD，而现在才开始有OPD这个东东。相信很多人听过敏捷个人了，这个词汇到现在已经很容易被搜索到了，敏捷个人创立以来，我一直未放弃对IT技术方法的实践和整理，而OPD就是我又要创建的一个东西，全称是Open Product Development。没错，是OPD，不是IPD，当然两者会有些关系，之所以我取Open，是因为我的IT产品开发方法大多数不是原唱，而是来自现有IT界中的已有方法，我只是类似在敏捷个人体系发展中占据的角色一样，我是一个集成者。OPD的工作无非就是把这些方法无缝的配合在一起，这个事情看起来考谱吗？ 靠不靠谱不能太随意下结论，现在重要的是先了解一下OPD是什么，看看是不是适合你和你的团队需要？如果需要的话，如何去学习、掌握并用在实际的工作中。 OPD是什么？ OPD （Open Product Development），它是由敏捷个人创始人周金根创立的另一个新方法体系，这一个来自实践的开放产品开发方法，它结合了精益创业Lean、企业架构TOGAF、架构描述语言ArchiMate、业务分析知识体系BABOK、敏捷开发Scrum、软件产品线、模型驱动架构设计OpenExpressApp。

先了解一下制造业中的精益思想，有助于我们加深了解精益产品开发。 精益思想五大核心原则 定义价值 识别价值流 让价值持续流动起来 用户价值拉动 精益求精 精益价值观 挑战现状 改善 现地现物 尊重 团队协作 精益生产模式 准时化：仅在 需要的时间 生产 需要数量 的 需要的 产品，目的是灵活应对变化，消除生产过剩的浪费。 自动化：自动 发现异常 ， 停止生产 并 现时、现地 分析问题决绝 根本原因 ，目的通过不断的发现问题、暴露问题、解决问题，让我们生产变得更加可靠，让生产系统能够更加顺畅地运作。 精益制造与精益产品开发实践体系 精益产品开发的目标一定需要从用户的角度或者从组织外部的角度出发来定义。我们把这个目标定义成：“顺畅和高质量的交付有用的价值”。 这里面有三个关键词： 顺畅，交付的过程要顺畅，也就是让价值能够持续流动起来； 高质量，交付出去的东西要符合质量要求； 有用，交付的价值必须是用户能够接收愿意买单的才能被称为有用的价值。顺畅、高质量、有用，这三者缺一不可，构成了精益产品开发的最终目标。 精益产品开发的定义：最小可行产品、持续部署、AB测试、可操作指标、产品运用的迭代循环及其他策略。 最小可行性产品：新的产品语序团队已最小的努力收集关于客户的需求。以楼盘为例，各位有没注意到，大部分楼盘在建设初期会建展厅、户型模型、然后开始开放给购房者，让购买者参与进来

作者：By Niall Richard Murphy,Liz Fong-Jones, and Betsy Beyer,with Todd Underwood, Laura Nolan,and Dave Rensin 翻译：张翔 校验：妙晓光 王运祥 王文勤 徐梦茹 齐凯华 郭晓东 运维是一门很难的学科。 不但没有解决如何很好地运行系统，即便那些已经在使用的最佳实践也是高度依赖环境且未被广泛采纳的。 并且最重要的，没有解决如何良好地管理运维团队这一问题。人们普遍认为，对这些问题的详细分析源于二战期间致力于改善盟军军事进程和产出的作战研究，但事实上，长期以来我们一直都在思考如何更好地实践。 尽管有这么多的努力和想法，可靠的生产运维仍然是难以保障的,特别是在信息技术和软件可操作性领域， 例如: 企业通常将运维视为成本中心， 这使得对结果进行有意义的改进变得困难甚至不可能。 这种短视的方法还没有被广泛理解， 但对它的不满却已经引发了IT领域对如何组织工作方面的一场革命。 这场革命源于试图解决一系列普遍问题， 并诞生了两个不同的解决方案: DevOps 和 SRE(Site Reli‐ability Engineering)。 尽管单从描述上看，他们是企业完全不同的两个方面，需要单独讨论，但事实上，它们的相似之处，要远比我们想象的多。 但首先，我们需要来了解一下每种原则的背景。

本文继 20年研发管理经验谈（五） 如何进行产品研发业务外包？ 　　进行产品研发业务外包的方式没有绝对的标准。行业分析师指出,理解其中的差异通常与一家公司管理层的成熟度有关,而不是与公司本身规模或者存在的历史有关。最佳的方式是把产品线和研发分成两类：一类是构成该公司未来竞争力的核心要素,另一类是非核心要素,把非核心的部分外包。 　　许多情况下,OEM公司倾向于将自己无力承担的工作外包出去,即使是系统中的关键部分。“许多厂商将软件开发外包给印度和其它地方的软件设计商,这并不是因为它们不是核心业务,而是因为这些厂商不具备这样的开发能力和团队。”市场咨询公司Pittiglio Rabin Todd & McGrath(PRTM)欧洲创新业务主管David Percival表示,“没有足够的人手导致了许多公司将软件开发这种核心的研发业务外包。” 　　比较适宜的做法应是充分利用自己的内部资源来定义和制订产品规格,监督第三方合作伙伴开发,然后在内部进行测试和验证。Percival认为,这可能要求OEM厂商的开发队伍重新进行技能训练。 　　另一个厂商经常犯的错误是将一些比较先进的开发工作外包。因为他们老产品的技术档案太糟糕和复杂,只有他们自己内部开发人员才能维护这些文档。“结果导致公司宝贵的研发资源和团队被禁锢起来,公司依赖外部伙伴来开发新的和令人激动的产品,而这些产品正是其竞争力的来源。

一直以来，我个人都觉得一件事一个流程只有做到规划化和流程化才有可能做到最好，否则可能会面临混乱、错误，甚至是失败。 一个完整的产品开发流程，最近团队也一直在磨合，我们试图找到一种最合适、最舒服的协作状态，虽然过程磕磕碰碰，遇到各种挑战，但总算是有所成长。 产品开发流程的各个阶段大致是这样的：产品策划文案-UI/交互-需求评审-用例评审-开发-测试-验收。需要考虑的问题是“人"和“时间”--每个阶段由谁负责，负责的人需要何时介入，把握好这两个流程节点中的关键因素，才是我们能够完成任务的关键 流程中有个至关重要的原则就是及早的识别并且排除风险，项目成功的概率就越高。 产品策划文案 这个阶段正常是需要提前至少一个版本规划好，提前规划留出足够的缓冲时间来思考和完善需求，并且这段时间可以让UI、交互、技术负责人介入，提早发现技术上的风险点、UI/交互上的风险点、逻辑流程是否完善，目的就是让需求更加的完善，更早的发现和识别风险 另外又遇到临时重要紧急的需求排期需要特殊的进行处理 UI/交互 在产品策划文案之后和下一个版本开始之前就需要介入，最好在下个版本开发工作完成之前完成对应的文档，不影响下个版本的进度 需求评审 需要所有利益相关者的参与（产品，开发，UI、交互，测试，数据），识别歧义并且消除歧义，发现风险并且消除风险，尽量的提前发现并且降低可能存在的风险因素

一直以来，我个人都觉得一件事一个流程只有做到规划化和流程化才有可能做到最好，否则可能会面临混乱、错误，甚至是失败。 一个完整的产品开发流程，最近团队也一直在磨合，我们试图找到一种最合适、最舒服的协作状态，虽然过程磕磕碰碰，遇到各种挑战，但总算是有所成长。 产品开发流程的各个阶段大致是这样的：产品策划文案-UI/交互-需求评审-用例评审-开发-测试-验收。需要考虑的问题是“人"和“时间”--每个阶段由谁负责，负责的人需要何时介入，把握好这两个流程节点中的关键因素，才是我们能够完成任务的关键 流程中有个至关重要的原则就是及早的识别并且排除风险，项目成功的概率就越高。 产品策划文案 这个阶段正常是需要提前至少一个版本规划好，提前规划留出足够的缓冲时间来思考和完善需求，并且这段时间可以让UI、交互、技术负责人介入，提早发现技术上的风险点、UI/交互上的风险点、逻辑流程是否完善，目的就是让需求更加的完善，更早的发现和识别风险 另外又遇到临时重要紧急的需求排期需要特殊的进行处理 UI/交互 在产品策划文案之后和下一个版本开始之前就需要介入，最好在下个版本开发工作完成之前完成对应的文档，不影响下个版本的进度 需求评审 需要所有利益相关者的参与（产品，开发，UI、交互，测试，数据），识别歧义并且消除歧义，发现风险并且消除风险，尽量的提前发现并且降低可能存在的风险因素

如果你与软件行业有若干联系，但是还不知道Joel这个人以及他的博客，那么赶快拿起百度，然后尽可能多的了解他和他的思想，对你肯定有好处。这篇是他博客中的经典之作，收录在他的两本书中：《Joel on Software》和《Smart & Gets Things Done》,这两本书主要收录和整理了他的博客中的经典文章，有必要一看。 要翻译出原作者的味道真的很难，所以我们经常骂一些翻译过来的中文书籍太烂，特别是由那些不懂技术的人翻译的技术书籍。所以如果你是是程序开发人员，再次善意的提醒您：“学好英文”，这句话被很多人重复，也不多我一个了，当然听不听由你。 你有没有听说过 SEMA ？这是一个非常复杂的软件开发团队评价体系。等等！千万别去研究它！仅仅是理解它就将花掉你六年时间。所以我自己搞了一套软件开发团队评价体系，信不信由你，这套体系最大的优点就是只需三分钟就可掌握！你可以把省下的时间去读医学院了。 Joel 的12条测试问题 你们用了源代码管理软件吗？ 你们是否一步就能实现从源代码到可发布的产品？ 你们每天都把源代码管理系统的代码做一次生成操作吗？ 你们有软件Bug管理系统吗？ 你们在编写新代码前解决bug吗? 你们有没有一个时常更新的进度计划？ 我的这套体系非常简洁，你只需对每个问题回答“是”或者“否”就可以了，你不需要去算什么每天写的代码行数或者平均bug数等等，回答“是