专业程序员进阶之路:从需求出发

简介: 在软件开发中,需求管理是关键,尤其对程序员的成长至关重要。文章以AI智能回收机项目为例,揭示了混乱、不清晰的需求如何阻碍项目进展。需求是设计的基础,没有正确需求意味着设计错误。程序员往往无形中承担了部分需求分析工作,需学会从用户角度理解和控制需求。需求过程包括问题定义和需求分析,前者清晰陈述问题,后者侧重业务而非技术。正确接收需求需深入业务、挖掘本源、全面考虑需求关系。通过学习和实践,程序员能提升需求管理能力,进而专业进阶。

在软件开发的征途上,需求管理是每位程序员进阶的必经之路。作为专业程序员,能否准确把握需求,不仅关系到项目的成败,更是个人技术进阶的重要一课。本文将探讨如何从需求出发,实现专业程序员的进阶之路。

混乱的需求:进阶绊脚石

我们正在进行的的 AI 智能回收机项目,遇到的最大挑战便是需求问题。

功能规格书从一开始就存在缺陷,它没有清晰地描述业务和问题,也没有详细说明如何满足这些需求。随着项目的推进,需求的不断变更、不清晰、不完整和变形问题层出不穷。

我们还经常遇到只有简单描述,甚至是口头传达的需求,有时我们甚至被默认应该了解这些需求。非专业软件人员,如机械、电子、测试、实施人员、项目经理等,还时不时地告诉我们要加入某个功能或指导我们如何设计功能。

实际上,问题的核心在于我们没有接收到正确的需求,或者没有正确地接收需求。

需求是软件项目的源头,如果源头存在问题,那后续的活动就不可能顺利进行。

从一个程序员的角度来说,没有正确的需求就没有正确的设计。如果总是处于混乱的状态中,我们将难以踏上专业进阶之路。

理论上,高级别的程序员才会参与软件需求分析过程,但实际上,我们在这里都不知不觉地承担了部分需求分析的工作。我们很难对别人提出要求,但作为需求的接收者,可以尝试从我们自身来控制需求的正确性。

拨开迷雾:认识真实的需求

什么是软件需求?这个看似简单的问题其实并不好回答。作为程序员,我们更关注的是,当要进行设计的时候,什么是我们的输入,这些输入是否正确。

许多人可能没有意识到自己在进行设计,完全是依赖一种朴素的想法、直觉和本能在进行开发,而忽略了设计前的思考,没有考虑设计的输入输出。

事实上,只要你在写代码之前有思考过如何实现功能,你已经在做设计了。而设计的输入,正是我们要讨论的需求。

需求是个复杂的工程,需要经过开发才能得到我们想要的结果。简单来说,需求过程可以分为两个环节:问题定义和需求分析。

问题定义

在进行设计之前,需要对系统要解决的问题做出清晰的陈述。

这里的问题可以是当前系统存在的不足或者缺陷,也可以是当前系统想要解决的已知业务存在的问题(创造新价值)。

问题定义只定义“问题是什么”,应该是一个简单的描述,并且听起来像一个问题,而不涉及任何的解决方案。

问题定义应该用用户的语言来书写,从用户的角度来描述问题,不应该用软件的专业术语来叙述。

定义好的问题,必须是具体的、可度量的、可实现的、可验证的,还要取得相关人员的共识。

需求分析

业务场景是需求的灵魂。需求分析的本质在于业务分析,而非技术分析。

需求分析的任务是对问题域进行研究,从业务线索入手,而非系统结构。

需求分析的过程就是分析人员基于业务领域知识,将问题放到业务场景中,通过分解、组合,选择一种技术可行的业务解决方案。

需求分析的结果就是软件功能规格书中定义的内容,是软件设计的输入,应该具有正确性、完整性、可行性、可验证性等特点。

摸索中前进:正确接收需求

当接收到需求时,开发人员的本能反应通常都是考虑技术上如何实现,但这些需求是真正的需求吗?

作为开发人员,我们接收到的大多数需求已经经过了多次中转,这导致需求的准确性和完整性受到影响。中转人员很容易在转述需求时加上自己的理解,项目经理或者部门主管也会从他们所认为的项目和技术角度来控制需求,以至于我们难以直接得到原始需求。哪怕我们可以直接面向用户,也会遇到用户无法准确表达需求、扭曲甚至放大需求的问题。

很多时候,我们需要通过一个相对曲折的过程去接近并获取真正的需求。

业务为基

真正的需求往往来源于业务过程中遇到的问题。深入理解业务知识,对业务事件、实体和规则有详细深入的了解,是理解需求的基石。对整个业务过程以及实际的业务场景有了正确的感知,才能理解需求的来龙去脉,提出正确的解决方案。基于业务领域知识和业务场景来理解和分析需求才是需求开发的正确之道。

深入本源

我们接收到的需求很多都是告诉我们要做什么,却没有人告诉我们为什么要这么做。问题经常会被表象所掩盖,在问题定义时,首先要做的就是揭开表象,分析问题背后的问题,寻找问题的本源。要多问为什么,层层去挖掘问题背后的原因,判断哪些原因是可以通过软件系统来解决。同时还要认识到并非所有的问题都要依靠软件来解决,有时更改硬件环境或者调整业务比技术更实际更有效。

思虑周全

用户会从不同的角度、不同的层面、不同的粒度提出需求。由于用户的背景不同,因此难免出现片面的、甚至相互矛盾的需求。每个单独的需求通常都是整体需求的一部分,很少有孤立存在的需求。因此,当我们对需求进行分析时,要将需求放在整体需求当中进行考虑。要全面考虑需求之间的关系,识别相互竞争、相互矛盾的状况,及时察觉错误,明确约束条件。

实践中成长:走上进阶之路

这里分享的内容只适用于开发人员理解和接收需求内容,以便更好的进行开发活动。如果你想更进一步,进阶为需求分析师甚至系统分析师,那么你还得去学习更专业的需求开发知识。作为开发人员,只有通过不断的学习和实践来掌握需求开发的技能,才能走上进阶的康庄大道。

结论

需求管理是软件开发的核心,它直接影响到项目的成功和程序员的职业发展。通过正确理解需求、深入业务本源、全面思虑需求关系,程序员可以在实践中不断成长,走上专业进阶之路。记住,进阶之路永无止境,保持学习、保持实践,是每一位专业程序员的不懈追求。

相关文章
|
监控 测试技术 API
【开发规范】Breaking change 破坏性变更
【1月更文挑战第26天】【开发规范】Breaking change 破坏性变更
|
Python
Python 采集77个教学课件PPT模板
Python 采集77个教学课件PPT模板
337 0
|
移动开发 数据可视化 UED
从网页到应用:简易教程教你如何在线生成App
本文将介绍一种简便的方法,让您能够将网页封装成APP。通过这种技术,您可以将您的网页应用程序转化为移动应用程序,从而更好地满足用户的需求。无需编程知识,只需几个简单的步骤,即可轻松将您的网页转化为功能强大的应用程序。
|
6月前
|
存储 数据挖掘 Apache
浩瀚深度:从 ClickHouse 到 Doris, 支撑单表 13PB、534 万亿行的超大规模数据分析场景
浩瀚深度旗下企业级大数据平台选择 Apache Doris 作为核心数据库解决方案,目前已在全国范围内十余个生产环境中稳步运行,其中最大规模集群部署于 117 个高性能服务器节点,单表原始数据量超 13PB,行数突破 534 万亿,日均导入数据约 145TB,节假日峰值达 158TB,是目前已知国内最大单表。
1368 10
浩瀚深度:从 ClickHouse 到 Doris, 支撑单表 13PB、534 万亿行的超大规模数据分析场景
|
人工智能
技术心得记录:关于自补图的认识和构造(无证明)
技术心得记录:关于自补图的认识和构造(无证明)
801 0
|
监控 Dubbo Java
超详细的Sentinel入门
随着微服务的流行,服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
超详细的Sentinel入门
|
消息中间件 测试技术 领域建模
DDD - 一文读懂DDD领域驱动设计
DDD - 一文读懂DDD领域驱动设计
48210 6
|
负载均衡 Java Nacos
SpringCloud的基本使用
SpringCloud的基本使用
172 0

热门文章

最新文章