华为是怎样研发的——需求跟踪
来源:网络 作者:佚名 关注:548次 更新时间:2023-04-18 10:16:58

1.png

业务需求( Business requirement ) 表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。使用前景和范围( vision and scope )文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求( project charter 或 market requirement )文档。

例如有个公司,一定要做一款“智能硬件”,其目的也许不是为了销售,只是正好上市,打造一个概念“涉足智能硬件”的概念,务必使用新技术,或者涉足新领域,便于资本市场炒作。那么这个产品需求分析的时候,就不能按部就班,按常理出牌。步子就是要大,哪怕扯到蛋,也要步子大。这就是“业务需求”的一种体现。所以在产品的需求分析阶段,要把“指导思想”搞清楚。

再例如我在华为做IPC的时候,指导思想是“华为要做监控安防领域的苹果”,占领技术制高点、产品制高点,避免同质化,避免陷入价格战。那么在这款产品的市场定位上,首先定义为“平安城市”+“高端园区”,所以在特殊功能,性能指标方面,最求极致;而在成本,复杂度上面做出妥协。

最终出来的产品,据说华为IPC6221成为一款PK神器,在很多项目所向披靡。

研发的人员一般也担心风险,进度,对于有挑战的需求往往会望而生畏。而且每个人的理念不一样。当时一位同事做廉价产品做出过成绩,降成本很有心得,所以死扣这款产品的成本。但是这款产品的指导思想很清晰,所以设计理念得以落实。这个产品的市场经理当时根据室外环境、园区环境供电距离远的特点,提出了“穷凶极恶”的概念(在恶劣的情况下能够正常工作),实际上会增加成本,也会增加电路的设计难度。但是为了差异化竞争,为了占领高端市场。

248108298_2_2022070712175522.jpeg

虽说需求都是可以讨论,但是如果研发理解了需求背后的原因,可能更容易去权衡各个需求的优先级。“多快好省”肯定是不可能兼得的,但是理解需求背后的原因之后,就可以更好的进行取舍和排序。

2.png

用户需求( user requirement ) 描述的是用户的目标,或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

首先,对于用户需求,不要“意淫”,有的研发人员往往意淫出一些需求,因为程序员、硬件攻城狮往往会把自己放在客户的角色上,但是开发人员往往不具备客户的行业经验,或者不具备客户使用产品的场景。用主观意识去使用和认知产品,往往就往往不符合客户需要的原本的模样。

另外,对于运营商产品,客户的表述往往就是用户需求,因为客户是长期从事相关产品的使用,属于专业人员,专业能力较强,而且产品往往配套培训和材料;但是对于个人消费品或者是一些企业用户,用户说的往往并不是用户需求。因为

由于开发人员往往会把自己放置在用户的角度思考,往往就会出现需求的范围蔓延,无端的增加了很多原本没有讨论过的需求。避免需求在开发过程中的走样。往往我们需要进行“范围管理”。

项目范围的管理也就是对项目应该包括什么和不应该包括什么进行相应的定义和控制。它包括用以保证项目能按要求的范围完成所涉及的所有过程,包括:确定项目的需求、定义规划项目的范围、范围管理的实施、范围的变更控制管理以及范围核实等。项目范围是指产生项目产品所包括的所有工作及产生这些产品所用的过程。项目干系人必须在项目要产生什么样的产品方面达成共识,也要在如何生产这些产品方面达成一定的共识。

范围管理的目的是在项目开发过程中,出现范围蔓延。制约一个项目的条件是项目“三约束条件”——范围、时间、成本。

范围的蔓延,势必影响项目的时间和成本。

在一个项目中这三个条件是相互影响、相互制约的,而且往往是由于范围影响了时间和成本。项目一开始确定的范围小,那么它需要完成的时间以及耗费的成本必然也小,反之亦然。很多项目在开始时都会粗略地确定项目的范围、时间以及成本,然而在项目进行到一定阶段之后往往会变得让人感觉到不知道项目什么时候才能真正结束,要使项目结束到底还需要投入多少人力和物力,整个项目就好像一个无底洞,对项目的最后结束谁的心里也没有底。这种情况的出现对于公司的高层来说,他们是最不希望看到的,然而这样的情况出现并不罕见。造成这样的结果就是由于没有控制和管理好项目的范围。可见项目的三个约束条件中最主要还是范围的影响。

248108298_9_20220707121755648.jpeg

产品工程过程分为需求分析、概要设计、详细设计、编码、测试、安装试运行、验收等七个阶段,项目保障过程包括项目计划、项目跟踪与监督、需求管理、质量保证、配置管理、同行评审等保障性工作过程。上图也体现了各个环节对需求的控制和理解,这个过程管理的。

 3.png

功能需求( functional requirement ) 规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。功能需求有时也被称作行为需求( behavioral requirement ),因为习惯上总是用“应该”对其进行描述:“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。

对于硬件项目,在项目启动后,会写一个《需求规格跟踪表》。

需求为什么需要文档化呢?如果你开发出来的产品,被别的同事质疑,这也没有那也没有时,你一肚子委屈过,你就非常能够理解。

Ø开发人员通过文档化的过程查错补遗;

Ø便于评审,在早期发现技术上的问题;

Ø后续阶段开发任务可能由他人承担,输出文档便于他们开展工作;

Ø维护人员开展维护工作需要;

Ø文档是必要的交付件;

“所有的过程分析都要形成文档。我们现在有一个严重的问题是,大家好像不喜欢写文档,对于需要的实现方案,通常都是一个负责人在脑袋里想想该怎么实现,然后邮件或电话找几个相关人员讨论一下就算可以了,可能连个会议材料或会议纪要都没有。而老外可不是这样的,他们非常非常重视文档,他们认为一个人在脑袋里想的东西是不清晰也不全面的,有时候心里想的认为很正确的方案实际上可能存在致命缺陷。他们要求必须把心里的想法形成文档才能有效的避免这种问题。写文档的过程中,可以更加有效的、更进一步去整理您原来心里的思路,很多问题在您写过文档的过程中您就能发现;另外,文档写作多使用图表,浪费口水的文字尽量少用,和我们一起工作的系统工程师在系统架构分析中就画了五六十张图,就算看不懂他写的英文,从图中我们就能够很清晰的指导整个产品的系统架构。”

——摘自一位华为员工的瑞典出差报告

248108298_10_20220707121755788.jpeg

上面的表单的后面几列是在开发的各个阶段去检查,原先确定的需求、规格等数据是否变化。例如在原理图、PCB、测试阶段,去检查是否出现了需求丢失,或者发生需求变更。如果发生需求变更,需要记录原因,决策者。

4.png

 系统需求( system requirement ) 用于描述包含多个子系统的产品(即系统)的顶级需求。系统可以只包含软件系统,也可以既包含软件又包含硬件子系统。人也可以是系统的一部分,因此某些系统功能可能要由人来承担。 最终决定市场对产品的综合评价是否满意。

对有很多子系统的巨大产品进行跟踪能力管理是一项巨大的工程,但这很必要。并不是所有的公司都会因为软硬件问题而造成严重的结果,然而应该严肃地对待需求跟踪,尤其对涉及你业务核心的信息系统。考虑了应用技术的成本和不使用的风险后,才能决定是否使用任何改进的需求工程实践。随着产品的发展,要把时间投向回报丰厚的地方。

需求管理系统包括模型管理、与WBS关联、版本管理、条目化管理、需求追踪、需求控制、模板管理、统计查询功能,系统组成结构如下图所示。

248108298_11_20220707121755928.jpeg

需求管理和需求跟踪是研发工程师的入口,所以我们需要重视和理解。


免责声明:
1.IPD百科网所有文章文档均于网上收集整理所得,版权属于原作者。
2.IPD百科网分享的所有资源仅供学习和研究之用,请在下载后24小时删除。如用于商业用途,请到所有方购买版权,追究法律责任与本网站无关。
3.以任何方式登录或者进入本网站或直接、间接使用IPD网站资源我们均视为您自愿接受并完全同意本声明。
4.如有内容侵犯您的版权或其他利益的,请联系13212350979 我们会在收到消息后24小时内删除。

联系我们

Contact us

联系电话:021-61990302                  邮箱地址:office@ipdwiki.com
Copyright © 2022 IPD百科网 All rights reserved 沪ICP备2021008520号-5  
沪ICP备2021008520号-6