UML,你什么都不知道

《软件需求最佳实践》这本书如果在我上学时来看,几乎提不起任何兴趣。上学时写软件开发文档,完全是为了交差,追求又臭又长,UML 是用来混凑篇幅的绝佳工具。

没有亲自考虑设计中大型规模的系统或项目,是没法体会到 UML 这套工具的优势的。当你做的系统足够复杂时,你需要有一个工具能帮你分析、描述这个系统的核心逻辑。

但对一个复杂的系统进行需求分析,你往往无从下手。大多时候我们被迫应付着业务方的需求,毕竟产研团队基本是不背业务团队 KPI 的,做好系统,支撑业务就行了。随着时间的变化,系统堆叠的功能越来越多,它越来越没法满足业务多变的需求。

需求的变更导致开发、维护的成本越来越高。我们越来越害怕变化,希望业务能够保持一个高度的稳定,但很多东西是无法控制的,行业市场的变化、组织结构的变化甚至商业模式的变化,都让我们觉得无所适从。

我们希望控制变化的成本,无法评估的变化是一个噩梦,整个项目像陷入一个沼泽地,投入大量的资源,其产出却微乎其微。

大部分的后端系统都是从业务功能模块这个维度分解,系统被划分为 XX 管理、OO 管理等,对后端系统的认识停留在管理就是增、删、改、查等操作,页面设计就是左导航、列表页、详情页。因为对业务缺乏深入的分析了解,导致在这个基础诞生的系统往往也是短命的。

这本书提供一个 SERU 需求分析框架,并辅以案例详细说明。

S ( Subject ):主题域,通过划分每个子业务确定对应系统的边界范围;
E ( Event ):事件,指业务的主要活动及流程
R ( Report ):报表,主要指数据统计类需求
U ( User Case ):用例,需求的最小粒度单位,根据用例确定界面原型及细节。

最关键是在案例详细阐述了 UML 的用法,能把你之前学的组件图、部署图、状态图、时序图、用例等在需求分析中串起来,UML 应该是做后端系统的 PM 非常值得学习的技能之一。

书中讲到的内容也偏架构师方面的内容。以主题域为例,每一个业务都是不同的子系统组合支撑起来的,而子系统间的连接是受制于公司的组织架构的,换句话说,公司的组织架构直接影响其 IT 系统的架构方式。这就是著名的康威定律( Conway's law ) 。

由于后端系统涉及到组织架构,那后端系统的政治性就无法避免,每一个后端系统都有大量的利益相关者。高层对这个系统的目标和期望、中层的管理需求、基层的使用需求、开发团队的技术能力都决定着这个系统的运作演化方式。

每一个系统其实都是各种利益博弈后的结果,尤其在大公司,几乎一个核心系统就对应着一个小组,假如小组 A 接管了原先小组 B 负责的系统,那小组 B 几乎注定是要被解散的。如果小组 A 内部新开发了一个很 NB 的系统,那小组 A 的内部组织必然分化,小组 A 人手必然扩大,组长及核心人员在公司话语权必然上升。

书中还提到领域模型( Domain Model ),讲的非常少,能够在深入理解业务的前提下进行建模,想必做需求分析也应该是得心应手的。这本书值得细读的,就是第四、五、六章,其它章节能跳就跳吧。


推荐阅读:架构之路——穿行在产品和业务之间
推荐理由:做后端的 PM 了解一下架构的东西没有坏处,还能涨涨内力。

Comments
Write a Comment