精华内容
下载资源
问答
  • 产品内部发布会流程
    千次阅读
    2019-12-23 20:56:12

    我的博客即将同步至腾讯云+社区,邀请大家一同入驻:https://cloud.tencent.com/developer/support-plan?invite_code=2p5qjwxvujms4

    产品工作主要分为四个阶段:

    立项阶段,包括市场调研、产品规划;(发现需求)
    需求阶段,包括需求收集、需求整理、文档输出、技术讨论;(寻找解决方案)
    开发阶段,包括项目跟进、项目发布; (实现解决方案)
    运营阶段,包括数据统计与分析、意见收集、活动运营。(让有需求的人使用和持续改进)

    (注:一般性项目需求基本可从“需求阶段”开始)

    整个流程中各个角色负责的基本工作如下:
    在这里插入图片描述

    立项

    产品经理工作流程中的“立项”阶段主要解决产品该不该做、为什么做的问题,分为市场调研、产品规划两个部分。

    所谓产品该不该做即产品与服务所对应的目标对象是否有相应的需求,提供的产品与服务是否能满足相应的需求。

    当然,以上定义即使回答都是肯定的,产品与服务也不一定可以去做,这还要看目标对象或者市场是否足够大,这里的“足够大”取决于你的资源量。比如,一个小区的居民需要购买日用品,一个个体户可以提供一个小商铺(产品)满足居民的需求,同时自己能够过活,对于个体户来说这个社区的需求是足够大的,但对于一家可覆盖多个小区的超市来说,一个小区的需求则是不够的。

    关于“市场调研”:
    市场调研是发现潜在市场需求的过程,所做的事包括:

    目标市场发展趋势调研,分为三种市场:现有市场、细分市场、新兴市场;
    新技术发展趋势调研,可运营的技术至少不会被淘汰;
    自身与竞争对手分析(如:SWOT分析),市场主要有那些竞争对手,他们的突出优势是什么;
    注意:
    
    对于已被淘汰的产品或者服务,要分析其相关的失败经验;
    对于尚在人间的产品或者服务,可以通过什么方法超越;
    现有产品或者服务是否可以改进与创新。
    关于“产品规划”:
    产品规划是产品定位、用户需求细分阶段,所做的事包括:
    
    产品定位,做什么样的产品或者核心功能;
    a. 面向哪些用户(目标市场)、用户特征是否具有普遍性(分类);
    b. 解决用户什么问题,这些问题是否具有普遍性。
    
    确定产品目标,期望产品是什么样子,量化的指标是什么;
    a. 产品的路标规划(大目标的拆分);
    b. 初步进行资源和时间的分配。
    
    初步的产品运营规划,要完成相应目标采取什么运营策略;
    

    关于输出物
    输出《竞争及市场分析文档》
    输出《市场需求文档》

    产品满足用户的哪一个核心需求;
    与同类产品相比你的独特性是什么;
    分解用户。根据产品的核心价值,将用户分解成不同角色;
    变成用户。每类角色回答两个问题:该角色为什么会使用此产品;该角色该怎么知晓和到达这个产品。
    确定角色成就。确定产品如何满足不同角色的成就感;
    确定用户需求满足过程中的关键点;
    提升关键点的转化率;
    形成闭环,让产品能够自我成长;
    大干快上,快速迭代。

    需求

    产品经理工作流程中的“需求阶段”主要解决产品要做成什么样,怎么做的问题。

    经历了上一阶段对需求的可行性评估,在这一阶段需要整理、细化需求,使需求成为团队成员(不仅仅只是开发)能够看懂、实现的充分依据*(也许以后还会讨论需求文档是否真有必要?)*。最后还需要与团队成员细致讨论,确定开发进度与里程碑,以在后期充分把控项目进度。

    这一阶段可分为三个部分:需求收集、需求整理、需求评审。

    关于“需求收集”
    规划阶段对产品(服务)基本的核心需求已经有个初步的收集,但随着产品的深入思考和讨论,会源源不断产生新的需求点,在这一阶段收集的时候可以先不考虑需求是否可行、是否有意义,只要尽量收集就好。

    需求的来源可以有以下方式:

    现有产品优化;(用户使用时产生的不爽)
    逻辑缺陷;(缺陷需要迅速解决)
    用户的反馈;(用户调研,包括内部与外部用户)
    竞品分析的成果;(抄袭?微创新?)
    管理层提案;(可能是无法拒绝的)
    合作方提案;(与外部合作,可能有个性需求)
    数据分析结果;(增长黑客?)
    创新。(产品差异化)
    

    关于“需求整理”
    需求整理主要是对之前收集的需求进行分析,确定优先级,并细化成文档的过程。当然,同时还涉及到运营计划的拟定,所需资源的预估。

    具体工作如下:

    需求条目的整理与管理,根据需求需要消耗的资源、紧急程度、重要性确定需求优先级;
    由于资源的有限性,需产品小组内部讨论,确定当前版本可做需求(如果是合作平台项目,需与合作方充分沟通相关要求);
    细化需求:
    需求的背景与目的,为什么要做;
    具体功能点的逻辑、流程、规则等;
    项目涉及(影响)的平台、渠道、功能等;
    数据统计与其他非功能性(服务器、后台)需求。
    与运营人员拟定初步的运营计划,开始着手准备可能的运营素材;
    预计需要支持该产品的部门(团队成员)以及可能的经费、物资预算;团队成员大概分工:
    项目产品经理,协调各方面资源,及时输出文档;
    项目经理,协调开发进度,制定里程碑;(许多公司由产品经理兼任)
    项目其他成员,评估各自任务,过程中与产品经理及时、充分沟通。
    

    注意:

    有限的资源包括技术资源(前端、后端、测试)、设计(界面、交互)、编辑(文案)以及推广资源等;

    交互设计和界面设计工作要尽早开始,以便有时间空间调整;
    内容资源主要是内容运营人员所产生的文案内容;
    推广资源也需要及早收集汇总;
    较大项目发布需保留旧版本入口,避免因新旧版本反差较大造成用户投诉。
    

    关于需求评审
    需求评审一定程度上决定了产品工作能不能愉快的进行下去,就好比战时出征前的誓师大会,搞得好士气将大增,搞得不好那…需求评审需要达到几个目的:让团队认同产品、说明产品功能点、明确分歧点、确定时间点。表面上的工作如下:

    通过邮件召集项目需求评审,邀请项目相关人员进行评审讨论:
    由产品经理讲解需求,技术同学评估;
    针对分歧点进行讨论,确定解决方案;
    项目经理确定各部分负责人与相关排期。
    会后根据讨论点对需求进行迭代优化(同时更新文件存档);
    项目经理确定项目相关里程碑与时间点
    项目计划须由项目经理最终确认,并最好通过可记录的方式(比如邮件)通知相关人员;
    里程碑是指诸如“技术预研结束”、“架构设计完成”、“测试、发布完成”等项目关键点的完成时间;
    开发计划一旦发布,就必须按照里程碑去定时检查是否完成;
    如果开发进度有变动,无论提前还是推迟,都必须在开发计划邮件中进行补充说明。
    

    为什么说以上是表面上的工作?因为要让团队认可产品不仅需要产品本身确实是可以满足用户需求的,在内在方面则要求产品经理本身的个人说服力也能潜在影响团队成员对产品的认同度。

    关于输出物
    包括以下文档输出(部分文档可能部分项目暂不需要,输出的文档最后进行共享、备份):

    ★★★《产品需求文档》,把功能分类进行详述,需分版本;
    《UI/交互设计文档》,主要涉及原型图和交互稿;
    《统计需求文档》,项目涉及的数据统计需求;
    ★★★《需求评审会议纪要》,主要涉及会议决议、项目计划、团队成员等信息;
    培训材料(内部交流所需,ppt)。
    --------------------------------------正文分割线----------------------------------------

    关于产品部/个人文档存储、共享规范,下面有一个简单的案例分享:
    在这里插入图片描述
    文档存储文件夹结构图

    文档存储文件夹结构如图所示;
    使用员工分类是避免各自负责的项目相互影响,同时便于个人管理,若出现人员离职情况,可直接将该人文件夹中的文档移至“历史文档”;
    共用资源可放一些工作会用到的文档,比如预算、运营流程、产品流程、公司规章等;
    每个人下面会有n个项目和一个公共资源(包括每个项目可能用到的数据等内容);
    如果是大项目可能还包含若干小项目以及需求、原型、运营资源、设计稿、交互稿以及其他文档;
    文档名称规范建议:
    项目(作为项目文件夹名):[类别]项目名
    需求文档(或其文档):[项目名]需求名_时间版本(或标准版本号)(如:[豆瓣主站]豆瓣市集项目需求文档_v20150630)
    (付)图片:[项目名]需求名_尺寸。(如:[豆瓣主站]豆瓣市集首页宣传用图_360*200)

    开发

    产品经理工作流程中的“开发阶段”主要为产品实现阶段,产品经理在这一阶段需要进行进度把控、资源协调,并最终完成产品的发布。

    这一阶段,将其称之为**“产品经理黑盒”**,因为对于产品经理来说,并不用关心也无法清楚的知道产品实现的具体开发细节、测试细节等,而只需要关注最终的输出物在功能、界面、逻辑上是否符合预期与要求。

    这一阶段可分为两个部分:项目把控、产品发布。

    关于“项目把控”
    产品经理在这一过程中虽然主要工作是跟进、协调,但也还有一些额外的工作需要准备。

    产品Q&A文档,主要用于对应产品后期的培训或者客服解答用户疑问需要;
    产品与竞争对手同类产品的对比(性能、效率等),提炼产品优势,把握后期推广点;
    以前期准备的初步运营计划为基础,与运营同学细化运营工作内容。
    

    项目跟进、协调工作部分:

    这一部分工作主要考验产品经理的沟通和协调能力。

    设计稿、交互稿跟进与确认,设计输出物需要及时确认与评估,快速修改、完善;
    开发进度跟进与确认,对评审确定的时间点要及时梳理;
    跟进开发进度,与开发同学沟通功能细节;
    协助项目经理对里程碑进行检查;
    协调各方资源的合作与沟通,做好桥梁。
    测试跟进,对主要流程和可能出现的问题进行体验,结合需求:
    在测试环境对整体项目稳定性进行体验、测试;
    对可能影响到的功能、后台进行体验、测试;
    对统计数据进行体验、测试;
    对于客户端需对旧版本兼容性、升级后数据稳定性进行体验、测试;
    对涉及平台、渠道进行体验、测试。
    

    注意:

    在这个过程中可能出现需求变更(应尽量少)以及未考虑到的问题(当然,这要求在需求整理阶段尽量想全),应做到

    针对可解决问题与变更,适当调整功能流程;
    针对不可解决问题,应及早反馈与沟通,并及时调整产品策略;
    如果可能尽早发给业务、客服部门提前体验(特别是活动项目)。
    

    关于“产品发布”
    产品发布意味着产品正式与用户见面,需慎重、慎重、慎重!

    产品发布前需与运营同学确定推广方案与计划,细节:
    广告图,需提前一周提设计需求;
    用户触达应根据计划提前作规划;
    需要的文案根据产品优势提前准备好;
    新闻稿也需与编辑提前准备。
    产品发布之前(最好提前三天)应周知各相关部门,特别是对客服同学的培训与通知;
    周知需求提出方;
    周知项目改动可能影响到的功能负责人;
    周知业务部门。
    对于合作项目涉及到联调时间,在规划上应予以考虑;
    确定产品发布的用户范围:
    部分发布需确定发布规则,可针对用户地理位置或者条件是否满足进行发布;
    全量发布,针对所有用户范围。
    注意:
    	发布时应关注用户反馈,简单反馈应及时迭代;
    	检查数据,发现异常应及时分析原因并解决;
    	较大项目发布需同时保留新旧版本,避免因新旧版本反差较大造成用户投诉。
    

    关于输出物
    包括以下文档输出:

    《产品体验文档》,描述体验环境、问题、修改建议;
    《产品Q&A文档》,描述产品功能、使用帮助。
    

    运营

    产品经理工作流程的“运营阶段”所要做的主要是配合与总结,并为下一个产品循环做准备,当然这个前提是你所在的公司将产品策划与产品运营做了明确的区分,如果没有,你可能还要关注“产品运营的工作流程”。

    所谓“配合和总结”:即配合好运营同学做好运营工作,同时需要通过各种数据和各渠道的反馈来了解这个上线的产品到底对用户有没有用处,用户究竟有没有去用。如果用户用了,那么要考虑如何让这个产品更好用;如果用户不用,那么要搞清楚为什么不用,产品是否有问题。

    这一阶段可分为三个部分:运营、意见收集、数据统计与分析。

    关于“运营”
    运营的工作本身已经足够写很多篇长文进行介绍了,在这里笔者只是简单介绍一下基本的概念与工作内容。

    所谓互联网产品运营简单来说就是“找到产品的目标用户,通过各种有节操无节操的方式将用户吸引来使用产品,然后维护与留住用户,同时时不时愉悦一下用户促进其进行消费(消费型产品)或者创造价值(UCG产品),并对沉默用户进行激活。”

    从以上概念可以看出运营的基本工作内容可以分为五个部分:

    找到产品的目标用户;
    吸引目标用户使用产品;
    维护与留住用户;
    保持用户的活跃度;
    沉默用户激活。
    

    不同的产品类型在每个部分都对应了不同的衡量指标,而评估运营工作质量的好坏,则是看在不同阶段对应的指标是不是达到了相应的预期目标。

    粗看产品策划主要跟产品玩,产品运营主要跟用户玩,但其实产品策划与产品运营的工作是相铺相成的。没有好产品再好的运营也没人用,没有好运营在好的产品也无人问津*(写这句话时有点虚,要知道神一样的产品和运营都是有的!)*,同时作为策划和运营都需要“了解产品、了解用户、了解市场“,并为统一的公司目标共同努力。

    关于”意见收集“
    ”意见收集"是产品需求的一个重要来源,可能包括用户槽点(需要改进)与用户创意(新功能),需注意以下几个方面:

    用户并不知道自己需要什么,他所说的并不一定是他想要的;
    用户的个性想法很多,但你面对的是用户整体;
    可以迅速解决的问题,需要马上解决。
    

    意见的来源,可见:

    产品本身具有意见收集功能,可进行意见收集;
    通过合作渠道、公司内部人员进行意见收集;
    通过社交网站、社区论坛进行意见收集;
    通过客服、运营以及市场同学进行意见收集;
    通过数据分析结论进行收集。
    

    关于“数据统计与分析”
    “数据统计与分析”从产品设计开端时就应该作为重点考虑的“功能”,为了让产品有据可循,而不是头脑发热的产物必须做好产品关键流程与产品目标数据的统计与收集。产品发布后,所有的数据都将是验证产品好坏的直接证据,通过分析这些数据及时作出总结与下一步规划是一个出色的产品经理必备的素质(重要!这里自行脑补3遍)。

    做好这一步的大目的:

    明白产品的缺陷,为下一步改进做准备(工作上的,重点);
    扩大自己在团队中的影响力,为后期工作铺路(团队上的,请意会);
    让领导知道你做了什么,个人工作评估为数不多的依据(个人上的,请意会)。
    

    小目的:

    在产品各个时期发现产品问题,及时改进;
    为后期迭代产品积累原始需求;
    快速配合运营工作,提高短板数据。
    

    数据统计与分析本身也属于一个大的工作项,这里不做详细描述,只是建议产品经理需要有数据思维,把看数据作为每日的工作习惯,及时从数据中发现问题,并跟进解决问题。

    关于输出物
    包括以下文档输出:

    《运营计划》,描述产品的主要运营规划;
    《意见收集资料》,简单罗列用户意见与初步分析;
    《产品数据分析》,通过一段时间的运营,分析数据得出结论与后期计划。
    
    更多相关内容
  • 软件产品发布基本流程

    千次阅读 2020-08-12 15:12:09
    产品发布前准备 发布之前,所有程序由测试人员进行确认测试;检查缺陷管理系统(比如:JIRA)内登记的所有bug都已关闭,或者遗留的bug不影响系统的使用,如果有严重bug未解决(级别为很严重以上)不能发布; ...

    产品发布前准备

    1. 发布之前,所有程序由测试人员进行确认测试;检查缺陷管理系统(比如:JIRA)内登记的所有bug都已关闭,或者遗留的bug不影响系统的使用,如果有严重bug未解决(级别为很严重以上)不能发布;
    2. 测试人员编写软件测试报告》,给出发布与否的建议,由项目经理决定产品是否正常发布,还是做让步发布(产品有缺陷但是不影响正常使用)
    3. 确定发布后,构建工程师(配置管理员)进行程序打包;标记源码包、文档版本标识,移交《项目标准环境检查表》。
    4. 构建工程师打好包后邮件通知相关人员(包括CM和项目经理),提交产品安装包; 
    5. CM(配置管理员)负责源码、文档入基线库。

    源码包括:

    1. 数据库创建脚本(含静态数据)
    2. 编译构建脚本和所有源代码;

    文档包括:

           需求、设计、测试文档,安装手册、使用手册、二次开发手册、产品介绍(ppt)、使用demo和项目经理提交的产品发布说明等等。

    1. CM把安装包、使用文档等放置至公司产品库并提交《基线建立通知单》
    2. 如果软件产品需要部署到客户或者内部环境,需要做上线前的各项准备。
    • 产品版本发布计划

           按照制定版本规划计划,使开发和测试活动具有预先设定的时间和版本规划。说明如下:

    版本名称

    包含功能

    所在SVN目录

    演化说明

    0.0.0

    AB

    /Trunk

    第一个未通过测试初始化的基线版本

    0.0.1

    A、B

    /branch/0.0.1

    0.0.0的修改分支,修改AB功能的BUG,合并到主干trunk中,修改下一个版本0.1.0中的BUG,同时形成0.0里程碑版本

    0.0.2

    F、G

    /branch/0.0.2

    由于项目进度紧张,需要提前开发0.2.0基线版本的功能F、G,但是此时版本0.1.0还未开发完成

    0.0

    AB

    /tag/0.0

    第一个通过测试的里程碑功能版本

    0.1.0

    ABCDE

    /Trunk

    第二个未通过测试初始化的基线版本,在0.0.1分支修复BUG的同时,主干依然继续开发增加CDE功能

    0.1.1

    A、B、C、D、E、X

    /branch0.1.1

    0.1.0的增加新功能分支,临时增加新功能X,此时增加的功能C、D、Ebug还未修改,将在主干中直接修改

    0.2.0

    A、B、C、D、E、F、G、X

    /trunk0.2.0

    第三个未通过测试初始化的基线版本,是将分支0.0.2与0.1.1同时合并到主干,此时bug未修改

    图表 1软件版本路线图

    产品发布

           项目经理编写《产品发布说明》(一份产品发布说明只能对应一个产品版本)

           产品发布说明的内容应该包括:

    1. 产品发布时间;
    2. 产品版本说明;
    3. 产品概要介绍;
    4. 本次发布包含的安装包、文档说明;
    5. 本次发布包含或者新增的功能特性说明;
    6. 遗留问题及影响说明;
    7. 版权声明以及其他需要说明的事项。

            项目经理或者高级经理发送产品发布邮件,通知开发、测试、市场、销售各相关部门并附上产品发布说明和产品介绍;或者以产品发布会议的形式进行通知。

    产品发布后

    1. 产品发布后,在使用过程中可能还会发现一些bug。在不影响正常使用的情况下,这些bug将在下一版本发布时解决;如果bug严重影响使用,必须打patch或者按照流程重新发布。

    产品临时发布

    1. 临时发布。软件产品未正式发布前,可能需要一个临时版本供开发人员或者用户应急使用,这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员;构建工程师需要为源码、文档打tag标记。
    2. 软件产品发布后,即建立了一条发布基线。所有用户安装及二次开发必须在此基线上进行,开发人员不能直接从SVNcheck out代码编译交付用户使用或者进行二次开发。
    项目标准环境检查表
    项目名称
    分项环境受控权限合格
    硬件配置管理服务器20.100.24.3
    数据库服务器20.100.24.3
    应用开发服务器20.10.10.16
    网络及相关设备100M
    软件开发平台Windows XP SP2/Win 7(客户端/宿主机)
    AIX Version6.1、Windows XP SP2/Win7/Win8(服务端)
    数据库Oracle9i、Oracle10g、Oracle11g、Mysql5.0以上版本
    应用服务器Weblogic10g、Weblogic11g、Tomcat6以上版本、JDK5.0以上版本
    开发工具MyEclipse8.0以上版本
    编译器JDK5.0以上版本、GCC
    编制计划工具Microsoft Project 2003/2010
    设计过程工具Microsoft Visio 2003/2010
    数据库建模工具Microsoft Visio 2003/2010、PowerDesigner 15.1.0、UML
    软件测试工具Jmeter、loadrunner、QTP
    配置管理工具SVN、CVS
    办公软件Microsoft Office 2003
    Microsoft Office 2007(文档格式需保存为2003兼容)
    工作制度
    产品发布说明
    项目名称项目经理
    产品标识发布人发布日期
    产品配置组成发布地址
    软件包名称及版本
    文档1名称
    文档2名称
    文档3名称
    文档4名称
    产品描述
    ①新版本增加(或新系统)的功能特性在“功能特征”处填写
    ②变更编号或软件问题描述:当属于让步发布时,在“缺陷”处填写尚未解决的问题说明(没有请填“无”)。
    ③版权声明以及其他需要说明的事项
    功能特征:
    遗留缺陷:
    版权声明以及其他需要说明的事项:

    产品集成检查列表
    项目名称填写项目编码填写检查日期:填写集成负责人:填写
    集成环境:
    1.硬件设备环境
    序号设备名称及型号数量备注设备运行检查软件安装测试检查人检查日期
    1
    2
    2.网络通讯环境
    序号有线/无线网络带宽环境检查检查结果检查人检查日期
    1上行10Mb/s,下行10Mb/s
    3.软件环境
    序号软件名称及版本说明配置登记软件检查检查人检查日期
    1
    2
    3
    4
    5
    6
    7
    8
    9
    产品构件、模块清单:
    序号构件、模块名称类型来源提供人单元测试配置管理检查日期
    1自主研发入配置库
    2自主研发入配置库
    3自主研发入配置库
    4自主研发入配置库
    5自主研发入配置库
    6自主研发入配置库
    7自主研发入配置库
    8自主研发入配置库
    9自主研发入配置库
    10自主研发入配置库
    11自主研发入配置库
    接口、界面UI符合情况:
    序号接口、UI名称检查依据检测方式检查结果检查人检查日期
    1《XXX编码规范》
    2《XXX界面规范》
    3
    4
    5
    6
    7
    8
    9
    检查问题跟踪
    序号检查项目检查结果问题描述优先级解决方法确认日期确认结果
    1组件的功能是否满足要求2014/12/2合格
    2组件的状态是否满足要求2014/12/3合格
    3组件是否完备2014/12/4合格
    4集成的软件环境有没有准备好2014/12/5合格
    5
    总体结论:
    1.检查全部通过,可以进行软件代码的集成。
    2.检查未通过,重新进行集成环境准备。
    3.集成环境检查问题需要进一步跟踪。
    展开全文
  • 华为内部硬件开发设计流程

    千次阅读 2020-12-05 10:51:17
    点击上方“大鱼机器人”,选择“置顶/星标公众号”福利干货,第一时间送达华为内部硬件开发设计流程2007年,以2年的工作经验去一家小公司去面试。当时笔试完,对方对我很认可。但当时他说:“我...

    点击上方“大鱼机器人”,选择“置顶/星标公众号”

    福利干货,第一时间送达

    华为内部硬件开发设计流程

    2007年,以2年的工作经验去一家小公司去面试。当时笔试完,对方对我很认可。但当时他说:“我需要招一个,在大公司待过的,最好知道硬件开发流程和规范的。虽然你题答得不错,但是我们需要一个有丰富经验的,最好在华为待过的。”

    当时,我就在想“华为的规范和流程是啥样的”。后来我去了华为,我把能想到的华为硬件开发的几个不一样的点,跟大家分享一下。

    NO.1 文 档,评 审,设 计

    当时刚入职时,三个人做一个电路板。虽然电路复杂一些,还是有一些人力过剩的。所以,我就被安排去写一个PCI转UART的逻辑。

    我当时是新员工,也急于表现自己,利用周末的时间,估计用了一周的时间,就写完代码,开始仿真了。我以为我的导师兼主管会表扬一下,结果没有,他说:“你为什么没有召集大家讨论?然后再写方案,评审?然后再动手写代码?”我当时是不理解的,觉得我一个人就搞定的事情,为啥要这样劳师动众?

    后来反思过后发现了以下问题:

    第一、 从主管的角度,不知道新员工的个人能力,你能把做的事情讲清楚了,他才放心。

    第二、 从公司的角度,有一套流程来保证项目的交付。那么则不再太依赖某个人的个人能力,任何一个人的离职,都不会影响项目的交付。这也是华为最了不起的地方,把复杂的项目拆得非常细碎,这样不需要特别牛的人来交付项目。这是为什么华为的工程师的收入是思科的N分之一。

    第三、 从效果角度,毕竟一个人的想法是有限的,把想法文档化的过程,就是整理思路的过程;讨论的过程,就是收集你自己没有想到的过程。正式的评审,是大家达成意见的过程。提前讨论,让相关的人都参与到你的设计中,总比你设计完了,被别人指出一个致命的问题要强得多。

    就是因为华为把一项工作拆散了,所以沟通,文档,评审,讨论,变得非常重要。这个工作模式的缺点,也是显而易见,沟通成本高,工作效率低。

    NO.2 硬件领域的人员构成

    在华为内部里面,人员角色非常多。硬件的人是对产品开发阶段,端到端负责的。做单板硬件工程师,可以涉猎最多的领域,同时也是工作内容最杂,接触人最多,扯皮的最多的工种。

    但是也因为有人专门负责画PCB、EMC、电源、逻辑,原本硬件工程师应该做的领域。那么硬件工程师就武功尽废,变成“连连线”。

    其实不然,正是由于每个人都是一个小的领域,没有人统领,所以一个好的硬件经理的作用非常的重要,是贯穿所有领域和全部流程的关键角色。正如原来华为内部论坛上有一个人比喻的,硬件工程师更像是处理器里面的“Cache”,是所有环节的中转站。大公司把人的分工分的这么细,也是防止某一拨掌握了太多公司的核心技术,出去单搞了。

    NO.3 华为的流程

    其实华为的流程,很多人都知道IPD流程是从IBM来的,我个人理解:IPD流程已经在华为变种,结合了中国人的特点,华为的企业特点进行了变通和优化。如果华为僵硬的套用IBM的这套流程,也必定不会这么成功。

    那么概括一下华为的硬件开发流程:

    需求分析→总体设计→专题分析→详细设计→逻辑详设→原理图→PCB→检视→粘合逻辑→投板→生产试制→回板调试→单元测试→专业实验→系统联调→小批量试制→硬件稳定→维护。

    流程的根本在于,这个环节做好了,再进入下一个环节。所有的环节其实跟其他公司并没有太大的区别,只不过严格把握了进入下一个环节的考核条件。令硬件工程师最纠结的是“没有个节点跟’投板’对应”。

    华为支撑IPD流程的系统是PDM(又名爬的慢)

    PDM的中文名称为产品数据管理(Product DataManagement)。PDM是一门用来管理所有与产品相关信息(包括零件信息、配置、文档、CAD文件、结构、权限信息等)和所有与产品相关过程(包括过程定义和管理)的技术。华为所有的器件资料,产品部件,工具,文档,原理图,PCB,逻辑代码等都存在这个系统上。但是系统过于庞杂,其实比较难使用,跟服务器归档、SVN归档、也容易搞混淆。

    NO.4 归一化

    1

    器件归一化

    硬件工程师一般都能够理解,在一个板子上面的,尽可能的选择成本更低的器件,选择更少种类的器件,便于集中采购,同时也便于加工。但是其他公司可能没有对器件归一化的工作做得那么细致和严格。

    第一, 由于华为整个公司使用的器件种类非常的多,所以如果减小一个器件编码,带来的收益是十万人民币到几百万,而其他公司可能达不到这个高的收益。所以如果能减少一个编码,宁愿选择可能成本更高的器件。但是这个也需要按照每年的器件直接成本收益*器件发货数量,与编码成本+加工成本差异,进行对比的。不过器件归一化之后,器件的价格又可以跟供应商重新谈价格,这个收益是迭代的。所以,有时即使是成本占优,也会倾向去器件归一化的结论。例如,逐步去除了5%精度的电阻,归一化到1%。

    第二, 器件归一化,都是需要进行专题分析的。因为也有工程师为了归一化,对电路原理没有充分分析,导致的归一化带来“问题引入”。所以,当时我的部门当时有一个表格,“器件归一化分析.xls”的excel表格,把每个器件,原来选型,归一化的选型,更改的原因,都做好记录和原因分析。一是让每个做归一化的员工都充分考虑分析,二是问题都有记录,便于评审,三是出了问题,好打板子。

    2

    单板归一化

    除了器件归一化,更高一个层次的归一化,就是单板归一化。(单板这个概念,我稍微澄清一下,我刚到华为的时候,也觉得这个词很奇怪。因为通信设备,都是机框,背板,加各个功能模块的电路板,各个功能模块的电路就叫做“单板”,硬件工程师,一般也叫做“单板硬件”)

    单板归一化带来的好处,首先是电路的种类少,电路的种类少的好处有三个:

    一是生产成本降低;

    二是硬件维护成本降低;

    三是软件开发和维护的成本降低。

    第一、单板归一化的先决条件首先是处理器归一化。其实,华为的有的产品这点做得其实不好,X86、MIPS、ARM、PPC全部都用个遍,所以一个硬件平台,需要配备各种软件人员,操作系统搞N套,VxWorks和Linux,BIOS各种配套。

    第二、单板的归一化,要注意产品的衍生。第一个版本的机框上的单板所实现的功能,如果后续的产品可以使用,应该直接可以用,不需要再开发。如果不注意这点,第一个版本的单板,到第二版本时,发现不能相互借用。反过来,再修改第一个版本的电路板,来适应新版本。有时问题更糟糕,就是完全不能兼容,只好重新开发。单板的规划显得非常重要。

    第三、单板归一化时,虽然电路部分兼容了,但是结构件不兼容。对于市场人员的配置来说,仍然是两种配置。一样是失败的。

    3

    平台归一化

    那么如果发现不同的硬件平台的架构雷同,功能类似。那么机框也可以归一化。只需要制作不同的电路功能模块,就可以实现不同的功能需求。

    但是不同的硬件形态都是有他存在的意义的,如果强行归一,市场未必会接受这种事情的发生。例如用一个运营商的平台去归一一个企业应用或者家庭应用的产品,可能就未必能够成功。

    4

    网络架构归一化

    这个说法是我自己想的,早在08年的时候,华为就在讨论“云管端战略”了,当时不是很理解。当我们一个运营商平台部门,跟“服务器”的部门合并的时候,似乎理解了点什么。

    当X86处理器足够强大的时候,所有的运算,不管是否性价比最高,都送到云端进行处理,那么所有中间的存储和计算都显得不重要了。那么整个网络的结构,就是终端+管道+云存储和云计算。

    NO.5专题分析

    我觉得很多硬件工程师有个误区,觉得自己的核心竞争力是在于会使用几个软件(cadence、Protel),画画原理图,画画PCB。我早期的一份工作就这样,最大的本事就是照葫芦画瓢,抄Demo板,抄以前成熟的电路,如果碰到了新的电路设计,一般是按照参考电路先画出电路,再通过调试,去尝试,碰到问题,再去解决问题。

    那么我现在的观念是,硬件工程师最值钱的地方是在于懂硬件原理,懂得电路分析,模电数电原理,电磁场理论,而不是会使用画图软件。

    那么华为是怎样做电路设计的呢?为什么会有专题分析的说法呢?为什么电路设计的时候要做专题分析?

    第二、当电路设计过程中,碰到一些新的问题,之前团队中没有接触过的问题,或者认为是重点,难点的内容,会专门做这个问题点的专题分析:例如我们做过的一些双BIOS启动,摄像头的红外LED的驱动,主备倒换啊,之类的,就会把一个问题点分析透,然后再动手做画原理图。

    第三、那么在开发硬件的时候,Demo只是作为参考,每一个依据都是来自于datasheet,除了看芯片的数据手册之外,还要仔细查看数据手册的勘误表errata,核对datasheet与Demo的差一点,如果器件有checklist还得核对checklist。曾经开发AMD的时候,datasheet、Demo、checklist,三个文档对不上的情况。也出现过,一个比较难复现的问题,后来查看了Errata,发现是厂家芯片升级了,修正了bug,而我们还在采购老版本的芯片。

    第四、由于项目本身有交付时间要求,那么在有限时间内其实不可能做到每个问题点都做得深入透彻。那么问题来了:

    是怎么做到的呢?首先,每个项目都有《问题跟踪表》,而硬件团队由于事情非常的杂,所以把这个表要用的非常好,不然丢东拉西很正常。我曾经把这个表应用到家里装修。这个表的原理很简单,就是记录,问题内容,责任人,完成状态,完成时间。但是只要你坚持用,你会发现,你问题不会跟踪丢,做事情会比较有条理,而且会有成就感。用了这个表以后,发现问题之后,先记录下来,即使现在不解决,那么也会识别他要不要解决,什么时候解决。其次、问题分优先级,任何项目都是带着风险前进的,那么识别出高风险的问题,优先解决高风险的问题,带着低风险的问题继续走。这也是华为电路设计中“0欧姆”电阻用的比较多的有一个原因,识别出风险之后,但是又分析不清楚,或者来不及分析,只好做兼容设计。这里不得不感慨一句,在你的设计过程中,你马虎对待,没有分析清楚的问题,最后一定会暴露出来。

    所以,在“菊花厂”做硬件工程师,“专题分析”是设计硬件最核心的工作,而不是画原理图。通过这个方法,用1~2个月做电路分析,而用1~2周时间画原理图,取代了,画图,调试,改版,再调试,在改版的形式。多快好省,是不可能同时实现的,那么硬件工程师有责任做很好的折衷和权衡。

    NO.6 专题攻关:器件选型规范

    一、关于“器件选型规范”:

    在我进入华为的时候,当时整个公司都在“规范”运动,什么都写规范,人人都写规范,什么任职、绩效、技术等级都看规范。(大公司用KPI来引导,容易搞成“运动”)。所以当时,按照器件种类,很多人写了各种器件选型规范。当时,原理图评审的时候,听得最多的就是“规范就是这样写的”,这里面有一些问题:

    1、写规范的人不一定水平高,或者写得不细致,如果出现错误那就更是害人了。

    2、规范有时抑制了开发人的思维,什么都按照规范来,不一定适合实际的设计场景;例如我需要低成本设计,但是规范强调的是高质量,就不一定适用。

    3、有了规范之后,也会导致部分开发人员不思考,例如晶振要求在50MHz以上,放pF级的电容进行电源滤波,而低于50MHz的不用。大家都不想为什么,自然也不知道为什么;再例如网口变压器防护,室内室外,按照各种EMC标准的设计要求,直接照着画就可以;但是很少有人想为什么,也不知道测试的结果怎样,等实际碰到困难时就抓瞎了。的确在有的时候提高了工作效率和产品质量,但是工具也发达,人也就越退化,这是必然。

    4、有些器件的选型,不适合写规范,因为器件发展太快,有可能等你规范写好,器件都淘汰了。例如:在X86处理器进入通信领域了之后,处理器选型规范就显得多余。

    规范确实能带来好处。但是,并不是所有工作都适合用规范来约束。硬件工程师要能跳出“参考电路”、跳出“规范”,从原理思考问题和设计。

    当然规范还是非常有用的一个手段,是大量的理论分析+经验积累+实践数据的精华。我觉得当时我看得最多的规范,是《器件选型的降额规范》,这是基于大量试验,实际案例,总结出来的器件选型的时候,需要考虑的内容。

    例如:规定选用铝电解电容的时候,需要考虑稳态的工作电压低于额定耐压90%;而钽电容,稳态的降额要求在50%;而陶瓷电容,稳态的降额要求在85%;因为这里考虑了一些器件的实效模式、最恶劣环境(高温、低温、最大功耗),稳态功率和瞬态功率的差异……等等因素。

    二、器件选型需要考虑的因素:

    在华为的PDM系统上,器件都有一个优选等级“优选”“非优选”“禁选”“终端专用”等几个等级。工程师可以根据这个优选等级来直观的感受到器件是否优选。

    那么器件的优选等级,是考虑了哪些因素呢?

    1.可供应性:特别是华为这样厂家,有大量发货的产品。慎选生命周期处于衰落的器件,禁止选用停产的器件。我2005年时曾设计过一个电路,设计的时候就是拷贝别人的电路,结果加工的时候发现器件根本买不着,由于器件停产了,只能在电子市场买翻新的器件。对于关键器件,至少有两个品牌的型号可以互相替代,有的还要考虑方案级替代。这点很重要,如果是独家供货的产品,是需要层层汇报,决策,评估风险的。

    2.可靠性:

    散热:功率器件优先选用RjA热阻小,Tj结温更大的封装型号;处理器选型,在性能满足的情况下,尽量选择功耗更小的器件。但是如果是Intel这样垄断的器件,你也只有忍受,加散热器,加风扇。

    ESD:所选元器件抗静电能力至少达到250V。对于特殊的器件如:射频器件,抗ESD能力至少100V,并要求设计做防静电措施。(注:华为是严格要求,禁止裸手拿板的。我本来也不理解,后来我带团队之后,发现兄弟们花大量的时间在维修单板;我们的团队就非常严格要求这一点,看似降低效率,其实还是提高效率的。至少不用总怀疑器件被静电打坏了。)

    所选元器件考虑更高的湿敏等级。

    安全:使用的材料要求满足抗静电、阻燃、防锈蚀、抗氧化以及安规等要求。

    失效率:避免失效率高的器件,例如标贴的拨码开关。尽量不要选择裸Die的器件,容易开裂。不要选择玻璃封装的器件。大封装的陶瓷电容不要选择。

    失效模式:需要考虑一些器件的失效模式是,开路还是断路,会造成什么后果,都需要评估。这也是钽电容慎选的一个重要原因。

    3.可生产性:不选用封装尺寸小于0402的器件。

    尽量选择表贴器件,只做一次回流焊,就完成焊接,不需要进行波峰焊。部分插件器件不可避免选用的话,需要考虑,能否采用通孔回流焊的工艺完成焊接。减少焊接的工序和成本。

    4.环保:由于华为大量的产品是发往欧洲的,所以环保的要求也比较严格。由于欧盟提出无铅化要求,曾经整个公司的几乎所有的硬件工程师都在做无铅化的整改。

    5.考虑归一化:例如某产品已经选用了这个器件,并且在大量出货的时候,往往有时这个器件的选型并不是很适合,也会选择,因为不但可以通过数量的增多来重新谈成本,还可以放心的选用,因为经过了大批量的验证。这也是为什么倾向于选用成熟期的器件,而慎选导入期和衰落期的原因。

    6.行业管理:某一个大类,例如:电源、时钟、处理器、内存、Flash等等都是有专门的人做整个公司的使用的规划和协调,提前进行市场调研,分析,编写规范。他们会参与到新器件的选型上来。

    7、器件部门:专门有器件部门的同事,会分析器件的失效原因,可靠性分析,拍摄器件的X光,评估器件寿命等等工作。

    8、成本:如果在上述因素都不是致命的情况下——上述的因素都是浮云,紧盯第八条。

    NO.7 开会

    开会第一部分 “华为的会议”

    1、首先大公司就是“会多”,因为公司大,部门多,人的职责划分的细,所以一件事情,需要很多人参与。容易出现扯皮的事情。我刚到华为时,非常不适应,什么都写文档,什么都评审,什么都开会;所以不适应这么多会议,开会时就会无聊,所有的贪食蛇的最高纪录都是那段时间破的。

    2、任何事情还是有主要负责人的,华为给予负责人足够的权利,所以能够推动事情的发展,协调到资源。例如行销有足够的强势去推动研发实现客户的需求。产品经理、客户经理的能量还是很大的,能够跟研发的部长直接进行对话,推动研发干这干那。

    3、所有问题最终都是会记录,跟踪,保证完成的。这就是为什么哪怕有些设备的质量,性能并不能让客户足够满意的时候,客户还愿意用华为的设备。就是这个原因,运营商都喜欢用华为的设备。一个问题出来了,还没确定是哪家的问题,华为的兄弟就冲上去了。联通2个人参加会议,华为6个人来参加会议,通过试验举证,证明是Juniper设备的问题。然后给出充分的报告告诉客户,这不是我们的问题,这是XXX厂商的问题。

    4、林子大了,什么鸟都会有。所以推、拖、赖的事情自然总是有发生。这就需要强大而明确的绩效评价体系,去引导员工去主动承担任务,而不是去划清界限。这种“划清责任”的事情也不可避免。否则就是三个和尚没水喝。注:华为的这种凡事充分讨论的做法,在电信运营商的领域是适用的,放在消费者领域、甚至企业IT领域往往会不适用的,因为没有足够的利润率去支撑这么做。所以我说的一些华为的一些优点,各位华为手机的用户不用向我吐槽,:-)

    5、在开会的过程中,经常人们容易进入误区,或者过于发散,或者过于保守。在产品定义阶段的会议,往往都有人提醒,发散的时候不要收敛;在问题解决的会中,往往会提醒,不要过去发散,聚焦问题。这个能够提醒大家的人往往就非常重要。当然有时也会流于形式,各位朋友可以看下一篇案例《华为内部讨论如何给孙杨涨姿势》,会议中不断有人提醒聚焦,但是大家还是比较发散。

    第二部分 《罗伯特议事法则》

    什么是《罗伯特议事法则》?

    一百年前有个好小伙子,名叫享利.马丁.罗伯特,二十五岁,中国人叫愣头青。他毕业于西点军校在南北战争期间奉命主持一个地方教会的会议。结果呢——搞砸 了。人们争个不亦乐乎,什么结论都没有。总之一塌糊涂。这个会开了比不开还要糟糕。这个小伙子呢,有点一根筋。说我要研究一下,弄个规则,否则我就再也不开会了。他研究上下几千年的开会讨论,有一个结论:人大概是特别爱争论的一个动物,最难被道理说服的动物,分歧一旦出现。很难在短时间内靠语言交流说服对方。否则吵个几天几夜都不会有结果。而且越吵越觉得自己有道理,对方是个笨蛋。所以双方找到共同点达成一个结论一定要有一个机制。他把这个研究当作一个战争一样。把人的争论本性当作敌人。最后这个小伙子打赢了。

    打赢的结果是1876年罗伯特议事规则。他自费出版买了一千本到处送人。1915 愣头青罗伯特成了将军,他修订了这规则。一开始人家不重视,嘴上没毛说话不牢的小家伙行吗。唉,没想到,真行,他们一实行这个规则,吵架没了,会开下去了。墨水瓶,板凳也不乱飞了。结果罗伯特议事规则成了世界上最通行的议事规则。

    开会经常有三个问题。

    一,跑题:就是你说李连杰,我扯到成龙,我说猪八戒,你扯到温家宝李鹏。跑得没个边了。而且老人家特别爱摆掌故,一开头,我给你们讲个故事,这一讲,就讲到中饭了。

    二,一言堂:这一个一言堂呢,是领导者爱讲话,谁是领导就哗哗哗说个没完,一讲就全他讲了。第二个呢,农村有一些特别爱讲话的。也有从来不讲话的。。

    三,野蛮争论:一讨论问题,就说你上次多报了五元钱,你不是好孩子,怀疑别人的品德。一百句话中抓住人家一个词不放。甚至打起来。会议就没法子开了。

    四,打断:不得打断别人的正当发言。

    罗伯特议事法则的一条就是:主持人来解决以上问题。但是一般的企业往往,领导出现的时候,主持人是不会去提醒领导,“你跑题了”,“你一言堂了”,“你不应该打断别人的正常发言”,这就是国外的科学的一些理论和方法到了中国往往不适应中国的土壤,不能生搬硬套的典型案例。

    其实在华为,已经能够在大多数会议中,做到发生“跑题、一言堂、打断、不文明”时,有主持人去提醒,并拉回到正轨上。但是一些会议也做不到,比如:领导比较强势,领导自己是主持人,主持人是个马屁精,一些政治敏感问题,就不能去破坏和谐。此处不展开细说。

    那么华为是怎么去解决这些问题的呢?

    1、“以客户为中心”,所以领导再大,大不过客户,客户需求一律允诺,一律搞定。所以大家都是为了搞定客户,当大家在原则性的问题上不会有大的分歧。

    2、 绩效导向,一切是按照结果去评价绩效的。所以在一些问题上,如果领导提出了某个方案,但是可能存在重大隐患时,底下人是有责任去提醒和反对的。否则造成重大严重后果后,领导跑不掉,一样会修理底下的人。都是拴在一条绳子上的蚂蚱。当某个同事提出跟领导不同的意见时,并有价值时,会从绩效结果上去认可这个兄弟。这就是教育员工,鼓励提出反对意见,鼓励纠正领导的错误。

    3、 教育主管。华为提倡狼文化,所有的主管能够被提拔上去,一般都是狼性十足,能讲会说,精力旺盛,在开会时balabala一顿,与员工沟通时也是balabala一顿自己说得爽。那么就会容易造成一言堂,或者跑题。那么在主管培训的时候,都会教育带团队的人,要会倾听,会交流,沟通时要把握节奏和分寸。

    第三部分 减少无效会议

    我曾经支持过CCB的网络建设一段时间,当时刚去的时候,跟他们的IT规划部,开了一个会。当时,开会时就是典型的“一言堂”,他们一个领导过来,一顿狂骂:“你们华为的设备怎么怎么不行,你们思科的设备也是狗屎,你们西门子服务太差。。。。。。”,建行的人,还有设备厂商的人都被骂蒙了,就听他一顿牢骚,骂完设备厂商,开始骂自己的员工“balabala”。然后所有人都不知道这哥们想干嘛,这哥们也讲不出自己想要什么样的设备,性能和服务。然后气愤愤就走了。

    一言堂、跑题、不文明,这些都不是致命的,最致命的就是“无效会议”。当这位领导走了之后,大家继续按照自己的思路,方法,继续讨论,然后花2分钟讨论一下,怎么应付这位领导。所以我们开会时需要的,但是如何开的有效是有套路的。

    那么如何做到呢?

    第一、 例行会议,有议题。例如周会,一周例会的议题做事先的安排,不是很随意的说一下。订好议题,订好每个议题的时间,保证不跑题。

    第二、 会议要有纪要,每次开会的会议主持人,会议纪要人都明确。会议纪要是很重要的一件事情,也需要很高的技巧,即需要有效参与会议讨论,有需要记录下关键要点,不记流水账。

    第三、 会议纪要要分为:

    结论(会议结论不随意更改);

    遗留问题(要符合SMART原则);

    要有责任人;

    要求完成的时间等等。

    纪要有模板,提醒大家纪要要符合SMART原则。

    第四、 勤跟踪,要闭环。所有的遗留问题,在下次会议的时候都会回顾,看看是不是完成了,有没有拖延,直到有个交代。当然,如果返现任务安排有问题,根据评估也会进行问题的关闭和挂起。

    第五、 所有的决议都是需要有理有据的,不能是拍脑袋。因为事前拍脑袋,事后就会拍大腿。然后就有人拍屁股走人了。这样就不会决议是下级服从上级,少数服从多数。当然,这样的话就会存在效率问题,因为有些问题就会因为短时间研究不清楚,决策不下来。这是就有了CCB(这个CCB不是建设银行的意思,CCB(Change Control Board) 在CMMI(Capability Maturity Model Integration)中,是“变更控制委员会”的含义,CCB可以由一个小组担任,也可以由多个不同的组担任,负责做出决定究竟将哪些已建议需求变更或新产品特性付诸应用。典型的变更控制委员会会同样决定在哪一些版本中纠正哪些错误。CCB是系统集成项目的所有者权益代表,负载裁定接受那些变更。CCB由项目所涉及的多方成员共同组成,通常包括用户和实施方的决策人员。CCB是决策机构,不是作业机构,通常CCB的工作是通过评审手段来决定项目是否能变更,但不提出变更方案。至少会保证,决策的决议是集体的智慧。)

    NO.8 测试

    1、从进度的角度对比华为和小米的测试

    按照小米UI每周发布的进度,周四一天的内测。我按照华为的流程怎么套都套不出来。

    疑惑点在于:

    1、内测是指开发人员自测试,还是测试人员的测试?

    2、如果是指开发人员自测试,那么测试人员在哪里测试?

    3、如果是测试人员测试,那么开发人员的自测试呢?开发转测试的点在哪里?

    华为背景的朋友一定会问:测试人员怎么可能用一天的时间完成测试?

    也许有人说,小米的效率就是高。

    那么我们来看一下华为的测试流程,你就知道是否可以压缩到一天完成相关的测试。

    首先说明一点,华为的软件部门,包括UI、或者网站的开发团队也是按照小步迭代进行开发的,在产品稳定后,新增需求会拆分成细小的版本,进行最短周期的开发测试。也可能华为的拆解需求的能力弱于小米,但是这里我们单纯谈测试流程。

    测试是产品开发过程中必不少的环节,在华为的研发人员中,有近三分之一的人员是测试人员。

    华为的测试体系在国内算是起步较早,大概经历了这样几个阶段:

    1) 青铜器时代: 手工作坊式测试

    1996年研发测试团队成立手工作坊方式的研发过程和测试

    2) 铁器时代:IPD和CMM阶段

    1998年华为与IBM合作,开始引进IPD流程

    1999年左右引入CMM理念

    产生IPD-CMMI流程

    2004年在IPD基础上开发PTM流程,自动化测试规模开展

    2006~2007年左右PTM趋于完善

    注:上图中各个TR点的含义如下:

    HLD:概要设计文档;

    LLD:详细设计文档;

    1. UT

    单元测试的对象是LLD中所划分定义的程序单元或模块,它也是单元测试用例设计中可测试的最大单元。该测试对象可能由一个或多个函数或者类组成,测试设计就是对测试对象进行测试用例设计。

    UT的目的,是通过函数运行来检查模块代码对于LLD文档的顺从性,验证每个函数的输入输出响应,与它在详细设计文档中预先定义的是否一致。函数是产品开发实现的最基本单位,下一个实现单位是模块,从测试的角度看,希望UT完成后,每个函数都牢固可靠,下一步的IT测试将聚焦在函数之间配合能否实现分配需求,而不用担心函数本身的输入输出响应问题。

    单元测试比较适合开发人员做。

    2.IT

    集成测试是指把若干个经过单元测试的单元组装到一起而进行的测试,集成测试应依据HLD,主要发现接口、依赖中的错误或不完善的地方。集成测试的对象为若干个单元测试对象的组合,至少为两个。

    IT的目的,是根据模块设计对模块的分解,从已验证的函数开始,逐层向上集成,得到一个可运行的模块。

    IT可以由开发人员做,也可以由测试人员做。不难看出,UT是面向每一个单元的测试,IT是测试单元之间的接口,可以把UT/IT归为“单元级”测试。

    3.ST

    CMM定义的系统测试:系统测试是针对软件项目组所承担开发的软件系统进行的整体测试,将软件系统作为整体运行或实施明确定义的软件行为子集的测试。主要采用的测试方法是黑盒测试,即不管程序内部的实现逻辑,以检验输入输出信息是否符合规格说明书中有关需求规定的测试方法。可见ST的测试对象是规格说明书,更确切的说,是模块需求规格说明书,所以一般也称为MST。模块SRS文档给出了模块的输入输出的相应要求。MST后,每个模块是牢固可用的。

    4.BBIT

    BBIT为模块间接口测试,验证模块之间的接口能不能配合,有时和联调混在一起,其实目的并不相同。BBIT的目的,是根据系统设计对系统的分解,从已通过验证的模块开始,逐层向上集成,得到一个可运行的系统。而联调一般涉及软件、硬件或者不同产品间的配合测试。MST和BBIT可以归到“模块级” 的测试,一个验证模块,一个验证模块间的接口。

    以上UT/IT/MST/BBIT一般由开发人员完成,系统基本可以运行起来了,测试人员可以开展SDV、SIT、SVT了。

    5.SDV

    SDV虽然属于测试人员开展的系统测试,但是有点偏灰盒测试,因为SDV验证各子系统的配合是否满足设计需求(DR),对内部的实现还是关注的,验证多个模块集成以后是否满足设计需求。

    6.SIT

    SIT也是验证设计需求是否得以满足,与SDV不同的是,SIT完全把系统当作一个黑盒来测试,不关心内部具体的实现。实际应用中,SDV和SIT 虽然都属于系统一级的测试,往往由不同项目组(子系统)的测试人员分别测试,他们只关注各自的子系统,所以还是把SDV和SIT归为“子系统级”的测试比较好。

    7.SVT

    SVT是验收测试,其测试对象是产品包需求OR。产品包需求给出了产品的范围,从产品可能的应用环境的角度刻画系统,SVT的目的就是确认(或验收)产品包需求给出的各种应用场景产品均能满足。

    即使是网页开发项目,外包项目,终端的项目,华为的测试仍然会经历以下几个测试阶段:

    SIV:System Integration Verify 系统集成验证

    SDV:System design Verify 系统设计验证

    SIT:System Integration Test 系统集成测试

    SVT:System Verification Test 系统确认测试(系统模拟测试)

    迭代结束后,在正式对外发布前,会将历次迭代实现的所有Story再做一次测试,测试 的主体在测试人员,包括功能、非功能,并要给出测试报告。这个活动就称为SIT或发布测试。

    如果Story 测试、迭代SDV测试都自动化了,则本次测试主要是执行自动化用例、如前 面有测试不充分,则补充测试,以及详细性能测试。如果用例自动化程度不高,则本次测试会 刷选部分用来进行测试。测试结束后需要给出测试报告。

    SIT测试重点:所有迭代开发完成后,由迭代开发团队中的测试人员完成对全系统进行回归测试,达到TR4A的质量标准。遗留问题要满足TR5的DI(缺陷密度)目标。

    4) 集团军时代:IPD-RD-I&V阶段

    2008年左右开始推广敏捷,研发组织演变为PDU方式

    引进迭代开发模式,形成IPD-RD-I&V流程

    系统集成与验证流程:IPD-RD-I&V(I&V:Integrationand Verification)

    项目管理论坛

    《测试计划》编写完成后需要进行评审,参与人员有项目经理,测试经理和系统工程师,测试组长需要根据评审意见修改《测试计划》,并上传到VSS上,由配置管理员管理。

    项目管理者联盟

    待开发人员把《SRS》归纳好并打了基线,测试组长开始组织测试成员编写《测试方案》,测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介,测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审,评审人员包括项目经理,开发人员,测试经理,测试组长,测试成员和系统工程师,返回评审结果。测试组长组织测试成员修改测试方案,直到评审通过后才进入下个阶段――编写测试用例。

    测试用例是根据《测试方案》来编写的,通过《测试方案》阶段,测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项,用例级别,预置条件,操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案,而测试方案又覆盖了测试需求点,这样才能保证客户需求不遗漏。同样,测试用例也需要通过开发人员,测试人员,系统工程师的评审,测试组长也需要组织测试人员对测试用例进行修改,直到评审通过。

    在我们编写测试用例的阶段,开发人员基本完成代码的编写,同时完成单元测试。转测试部后直接进行系统测试。测试部对刚转过来的测试版本进行预测试,如果软件未实现CheckList清单上的10%,测试部会把该版本打回。否则,软件转测试部进行系统测试。根据《测试计划》进度安排,测试组长进行多轮次的测试,每轮测试完成后测试组长需要编写测试报告,其中包括用例执行通过情况,缺陷分布情况,缺陷产生原因,测试中的风险等等,这时测试人员就修改增加测试用例。待到开发修改完bug并转来新的测试版本,测试部开始进行第二轮的系统测试,首先回归完问题单,再继续进行测试,编写第二轮的测试报告,如此循环下去,直到系统测试结束。在系统测试期间,测试人员还需要编写验收手册,验收用例和资料测试用例等。

    修改问题单,直到满足规定的缺陷密度,才能够通过相关TR点。

    如果验收发现的缺陷率在SOW规定的范围内,那么验收成功。如果超过规定的缺陷率,需要质量回溯。

    2、不可思议的小米5%

    雷军说:

    那么我们看华为的硬件测试过程,就知道成本出在哪里了。

    第一、 全程测试参与的流程:

    第二、 多层级的测试与试验

    对于电路的设计,会进行单元测试、整机测试、小批量试制、HALT试验、环境试验、EMC试验、热测试、进入生产环节之后会进行HASS试验。特殊的设备还会进行盐雾试验、硫化试验。整机结构还会进行:跌落试验、挤压、扭曲等等。

    HALT(Highly accelerated life test)高加速寿命试验。HALT是一种发现缺陷的工序,它通过设置逐级递增的加严的环境应力,来加速暴露试验样品的缺陷和薄弱点,而后对暴露的缺陷和故障从设计、工艺和用料等诸方面进行分析和改进,从而达到提升可靠性的目的,最大的特点是设置高于样品设计运行限的环境应力,从而使暴露故障的时间大大短于正常可靠性应力条件下的所需时间。

    环境试验是为了保证产品在规定的寿命期间,在预期的使用,运输或贮存的所有环境下,保持功能可靠性而进行的活动。是将产品暴露在自然的或人工的环境条件下经受其作用,以评价产品在实际使用,运输和贮存的环境条件下的性能,并分析研究环境因素的影响程度及其作用机理。

    HASS应用于产品的生产阶段,以确保所有在HALT中找到的改进措施能够得已实施。HASS还能够确保不会由于生产工艺和元器件的改动而引入新的缺陷。

    硬件工程师最怕HALT试验,因为会超越器件的限制范围去进行测试。但是为什么要这么做呢,其实是找到整个设备的最薄弱点,然后对最薄弱点进行改进。但是由于超出了器件的允许的工作范围,异常的情况特别多,原因也复杂。但是按照规范必须分析清楚,并给出优化措施。这是非常烧脑的意见事情,很多经典的问题都是HALT试验过程中产生的。

    由于我本人非测试出生,有讲的不对的地方请专家指正。现在小米开始不复当年风光了,想到雷军的5%,就写下这些。

    -END-

    整理文章为传播相关技术,版权归原作者所有 |

    | 如有侵权,请联系删除 |

    往期好文合集

    手把手教你详细的硬件电路设计

    学好单片机必须要了解的的8个电路设计

    基础电路设计知识:电阻、电容、电感、二极管、三极管、mos管!

      最 后  

     

    若觉得文章不错,转发分享,也是我们继续更新的动力。

    5T资源大放送!包括但不限于:C/C++,Linux,Python,Java,PHP,人工智能,PCB、FPGA、DSP、labview、单片机、等等

    在公众号内回复「更多资源」,即可免费获取,期待你的关注~

    展开全文
  • Google Play 上架完整流程 系列文章目录、 一、创建内部测试版本、 二、检查并发布内部测试版本、

    Google Play 上架完整流程 系列文章目录


    【Google Play】创建 Google 开发者账号 ( 注册邮箱账号 | 创建开发者账号 )
    【Google Play】创建并设置应用 ( 访问权限 | 内容分级 | 受众群体 | 类别及联系方式 | 商品详情 )

    【Google Play】App Bundle 使用详解 ( 简介 | 应用内更新 | 即时更新 | 灵活更新 )
    【Google Play】App Bundle 使用详解 ( 按条件分发 | 国家地区 | SDK 版本 | 设备功能 | 按需分发 | 资源分发 )
    【Google Play】App Bundle 使用详解 ( 应用模块化 )

    【Google Play】创建和管理内部测试版本 ( 创建内部测试版本 | 检查并发布内部测试版本 )






    一、创建内部测试版本



    进入 Google Play 控制台页面 https://play.google.com/console/developers ;

    在这里插入图片描述

    点击 " 创建新版本 " 按钮 , 进入如下界面 ;

    在这里插入图片描述

    将 APK 安装包拖动到 App Bundle 下的矩形框中 , 然后等待 APK 上传完毕 ;

    在这里插入图片描述

    上传完毕后 , 会在下方列出上传的应用 , 并在版本名称处自动生成一个版本名称 , 点击 " 保存 " 按钮 , 即可将当前的应用及配置保存到 Google Play 后台 ;

    在这里插入图片描述

    点击上传文件列表中 , 最右侧按钮 , 可以查看当前应用的最新信息 ;

    在这里插入图片描述

    最后 , 点击 " 检查发布版本 " 按钮 , 即可完成最后的发布操作 ; 在这里插入图片描述





    二、检查并发布内部测试版本



    Google Play 会检查应用是否合规 , 如果出现错误 , 需要开发者排除相关错误 , 这里我遇到了 没有设置 隐私政策 , 以及没有提供 64 位 的动态库的问题 ;


    参考如下两篇博客解决 :


    检查合规后的页面如下 :

    在这里插入图片描述

    点击 " 开始发布内部测试 " 按钮 , 弹出如下对话框 , 点击 " 发布 " 按钮 ;

    在这里插入图片描述

    版本上传成功 , 在内部测试页面可以查看该版本内容 ;

    在这里插入图片描述

    展开全文
  • 浅析-腾讯产品项目的流程

    万次阅读 多人点赞 2020-05-10 17:04:24
    笔者有幸学习到腾讯产品经理对产品项目的流程管理,特此整理并结合实际工作经验分享给大家。 长话短说,腾讯产品项目的主体流程划分成了七个阶段,“概念阶段(CONCEPT)”、“提案阶段(PROPOSAL)”、“原型开发...
  • IPD产品开发流程详解

    万次阅读 多人点赞 2021-02-25 09:49:22
    IPD的思想来源于美国PRTM公司出版的《产品及生命周期优化法一书,该书中详细描述了这种新的产品开发模式所包含的各个方面。 最先将IPD付诸实践的是IBM公司,IBM公司实施IPD的效果不管在财务指标还是质量指标上得到...
  • Testflight内部测试流程介绍

    千次阅读 2017-01-22 15:40:14
    另外也还提供了2000个外部测试名额,不过外部测试是需要通过苹果审核的,当然流程时间较比内部测试,就要多很多了。 不过添加内部测试账号,需要先把对应账号添加到项目成员才行,iTunes Connect有一系统操作,同时...
  • 研发团队轻量级内部测试流程

    千次阅读 2014-10-15 08:20:04
    本文中讨论的研发团队内部测试流程是组织研发过程中需要标准化的协作流程中的一种,是一套用于规范需求、开发和测试人员进行服务发布质量控制的流程性指南和说明,确保整个团队对产品质量保证有一个统一认识,促进...
  • Google Play 上架完整流程 系列文章目录、 一、上架正式版、 二、创建版本、 三、设置正式版应用的 国家/地区、 四、正式版发布
  • 【IPD流程学习 二】IPD主要流程

    千次阅读 2020-02-13 17:52:26
    上一篇博客详细论述了产品开发过程中遇到的问题,看来不光是我自己感受到了,其实大家都有那种很累但是又没产出的感觉,是整体的流程机制出了问题,所以才要搞流程变革,而其中和我们开发人员最密切相关的就是IPD...
  • 企业对接钉钉流程(企业内部应用-H5微应用)开发前准备:企业自主研发H5微应用 官方文档写的很全了,非常值得细读。 本片,我们企业要接入钉钉(企业内部应用-H5微应用),取钉钉后台数据用。 开发前准备: 开发者...
  • Apple应用(Uni-App)发布流程

    千次阅读 2022-03-28 14:35:10
    Apple应用发布流程一、证书申请二、 准备发布1. 准备发布三、应用发布1. 新建App 一、证书申请 见:Apple应用证书申请流程 二、 准备发布 1. 准备发布 准备一台MacBook 安装XCode 13.3 安装HBuilderX 3.3 三、应用...
  • 详解ASIC设计流程

    千次阅读 多人点赞 2020-06-04 04:09:58
    参考中外文以及互联网资料,写一篇ASIC设计流程文章供大家参考,文中有不妥之处,还望批评指正,谢谢!
  • 简述基线发布流程

    千次阅读 2016-02-22 16:10:35
    以下内容为自己总结 首先确认本基线包含内容已经完成,项目经理整理基线发布清单,并提出基线发布申请,CCB成员审核基线发布并签署意见,配置管理员执行基线发布操作,同时通知相关人员。
  • 发版流程及对外版本规范

    万次阅读 2018-06-06 18:41:05
    一、版本编译、验证、发布 二、BUG追踪 三、不定期的版本发布 四、人员职责 一、版本编译、验证、发布 说明: 对外app的发布,只能通过jenkins自动编译平台进行release。 目的: 1. 保证对我统一出口,...
  • 史上最全测试流程详解----超详细

    万次阅读 多人点赞 2021-11-29 15:06:05
    对于测试流程基本很多做过测试的大牛,小哥哥,小姐姐都能说出个十之八九,但是对于细节,可能还需要一些整理文件,这不,我整理了一些测试的全部流程,希望能给大家带来帮助,有不妥的地方,请大家指正。...
  • 互联网产品研发流程

    千次阅读 2017-05-16 01:37:40
    研发流程研发流程相当关键,关系到整个研发团的开发效率,现在的产品的研发一般产品经理(Product Manager)为中心来展开,招一个靠谱的PM在有些时候可以扭转乾坤~ 在之前经历的公司中,有一家公司的流程让我...
  • SpringBoot版本:2.1.1 ==》启动流程分析汇总 接上篇博客SpringApplication对象创建 目录 流程分析 1、getRunListeners(String[] args) 1.1、SpringApplicationRunListener接口 ...2、发布ApplicationSt...
  • 发布经过分析后,创建若干子发布,子发布则负责组件发布的所有流程,包括组件 MR 的创建,组件 tag 的创建,发布 CI 的触发等。 主发布和子发布涉及的所有状态如下: created: '待分析', analyzing: '分析中', ...
  • 苹果账号打包发布APP流程详解

    万次阅读 2017-03-14 14:41:39
    3、关于AppStore内部测试描述文件发送变化需要从新下载,否则导出安装包报错,错误如下 (AN APP ID with Identifier ‘此处为bundle ID’ is not available,plaese enter a different string)
  • 游戏产品开发流程

    千次阅读 2019-08-12 17:24:05
    通常开发一款新游戏大体上按照如下流程来进行: 1)概念阶段– Concept 主策根据产品创意,确定游戏策划草案,包括游戏的形态、游戏概述、游戏核心玩法、市场定位、特色及卖点等。然后,完成市场分析,竞品...
  • 一、产品概述 1.1 产品名称 懒饭 1.2 产品版本 1.3.1 1.3 产品定位 快节奏的都市生活中,年轻人属于自己的时间、空间正在遭受挤压,人们开始更多地在美食当中寻找安慰。忙碌一天之后,回到厨房,哪怕是一碗面条...
  • 微软SDL流程终极整理总结

    千次阅读 2022-02-11 16:10:17
    微软软件安全开发流程(SDL) ...开发团队的所有成员都需要接受适当的安全培训,了解相关的安全知识,培训对象包括开发人员,测试人员、项目经理、产品经理等。项目的中期可开展针对性的培训,例如代码
  • 开发流程模型

    千次阅读 2016-10-18 10:15:11
    描述:一次迭代过程包括了所有软件开发流程、每一次迭代均产生一个可发布产品、该产品为最终产品的一个子集。 适用于事先不能完整定义产品的所有需求,计划多期开发的项目。 喷泉模型 描述:以用户需求为...
  • 务”,也就是下图中从左到右的流程。 但很多中国传统企业的关注重点和能力构建是从右向左进行的,以卫 Sir 当前所在企业为例,靠贸易起家,借着行业的红利期快速完成了原始积累。 之后开始在贸易的基础上...
  • Google Play 上架完整流程 系列文章目录、 一、测试链接、 二、配置测试权限、 三、下载测试应用、
  • 敏捷开发流程的8个步骤

    万次阅读 2022-02-15 18:32:06
    一、敏捷开发流程的8个步骤包括: 1、目标制定,目标对齐:通过市场调研、业务思路、风险评估...4、需求梳理:然后产品负责人(Product Ower)对这个列表进行梳理,并在需求梳理(Backlog Grooming Meeting)讲解具体每
  • 2、一款电商产品定位需要考虑到很多方面的因素,一般公司创始人在最开始指明产品定位,然后在产品的发展过程中不断对产品定位进行调整,成功的产品总是在不断的调整中才得以找到自己适合的位置。 3、目前主流的...
  • 相比国内渠道一直有商务和运营对接cp方,google play则是完全的自动化,从开发者账号——游戏/App上架——手动/违规下架,整个流程只有你和google play的开发者后台,谷歌的各种政策改变,通知沟通基本都是开发者...
  • 近日,阿里巴巴产品专家金桐从自动化的烦恼,到分层自动化单元测试、业务服务层测试和UI测试的优劣势分析,再到阿里巴巴分层自动化的实践之路,为大家提供一套分层自动化实施解决方案。 自动化...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 183,098
精华内容 73,239
热门标签
关键字:

产品内部发布会流程