如何设计一个有价值的软件

对于广大程序员来讲，会在自己的身上贴上一个个的标签，比如Spring程序员、mysql数据库管理员、linux系统运维、VUE程序员等，自己就成为了专业人士，与此同时，这也锁定了自己的关注范围，平时关注的几乎都是技术细节、分工与工作量。程序员与软件的距离是最近的，但很多时候却觉得自己整天都在CRUD，感知不到软件的价值，感知不到自己的价值。

前几天我带着儿子去医院看医生，我提前在京医通微信号上挂号预约，当天到医院后开始依次取号、分诊、医生诊断、化验、开药、付费、取药等，这是一个经过医院精心设计的业务流程，很多环节都是在自助机器上完成的，相关的数据在软件信息系统中有序地流动，这很好地体现出了软件信息系统的价值。

软件信息系统的商业价值，一般体现在以下几个方面：

1. 通过系统固化、优化业务流程，提升流程执行效率，节约成本，降低风险。
2. 通过系统扩展业务渠道，使其延伸到电话、互联网、移动互联网等通道上
3. 通过系统将个人知识、能力转化为组织知识、能力。
4. 通过系统实现数据的信息化，辅助管理、决策。

这篇文章来分享《有效价值分析》这本书，学习一下如何设计出一个有价值的软件。

方案级需求 VS 问题级需求

做好软件需求工作，业务驱动思想是核心。传统的需求分析是站在技术视角展开的，关注的是“方案级需求”，而业务驱动的需求思想则是站在用户视角展开的，关注的是“问题级需求”

假设一个场景，你去医院看医生，对医生说，你能不能帮我把左胳膊砍掉，这支胳膊最近疼得厉害。大家一定觉得十分诧异，这种事情怎么可能会发生呢，但类似的事情在软件开发领域却一直在发生。把胳膊砍掉是“方案级需求”，最近胳膊疼得厉害是“问题级需求”。

如果有人找你说，你给我开发个什么什么功能吧，甚至还给你说了很多方案的细节，你要问他的第一个问题应该是，你想解决什么问题，然后基于他的问题，提出你的解决方案。我们需要牢记，客户是问题专家，而我们是解决方案专家。 如果针对一个方案级需求进行开发的话，目标是不清晰的，你没有搞清楚这个方案到底要解决谁的什么问题，最终在方案交付的时候就会遇到各种困难。

对于组织应用类软件，系统需求可以分为价值需求和详细需求，我们再做软件分析与设计时，也会从这两大方面来考虑。

价值需求

简单来说，价值需求就是从黑盒视角回答三个问题

1、整个软件系统为客户解决了什么问题、创造了什么机会？

这一步本质上就是分析软件系统的项目目标，也称为愿景，是一个组织类信息系统的灵魂。

作者给出了一个公式：需求=预期-现状。也就是说我们可以从两个角度来考虑这个问题，第一个角度是从现状来考虑，分析组织目前存在什么问题，以及如何通过软件来解决。第二个角度是从预期来考虑，分析目前存在什么新机会、新场景，如何通过软件来把握住这些机会和场景，这将给组织带来哪些新的价值。

2、对系统而言，最关键的干系人有哪些？
3、各个重要的干系人对系统的关注点是什么？有哪些担心（阻力点）？

对于任何软件项目而言，都会涉及各种干系人，它们有着不同的诉求和关注点，甚至存在着各种冲突。在分析需求的过程中，找对关键的干系人，搞定他们的需求，消除他们的顾虑，软件才能成功。

详细需求

详细需求就是从灰盒子视角回答三个问题

1、为了给客户提供业务、管理、维护支持，需要提供哪些功能？

信息系统的核心价值之一是支持业务，业务支持的核心是对业务流程的固化、优化和重构。

管理功能包含两方面：1、管理流程的固化、优化和重构，例如设置关键的规则与约束，关键流程的审批与审计等；2、基于某种目的来生成一些数据和报表，并在此基础上支持管理和决策；

维护支持指的是为了维持软件本身的正常运行所需要提供的技术层面的维护功能，比如功能可配置、数据的备份与迁移、错误调试、监控预警等。

2、系统所涉及的问题域中有哪些数据，之间是什么关系？

这个属于领域模型的范畴，要分析出系统如何对业务流程进行抽象，实体都具备哪些属性（数据字典），实体之间如何关联。这个问题更加细致地回答了系统都描述和支持了哪些信息。

3、所处的业务环境会带来哪些约束和质量要求？包括安全性、稳定性、易用性、性能、可维护性和可移植性。

比如，对于银行系统来讲，安全性和稳定性是最重要的。对于客服支持系统来讲，性能的重要性更高一些，要不然“请稍等”就变成客服的口头禅了。这些约束之间往往是相互矛盾的，要结合具体的场景做适当的取舍。

从业务流程到软件功能的四个阶段

阶段一：业务流程识别

企业或组织的核心价值在于响应外部客户的服务请求，通过一系列的协作满足服务请求，为客户带来价值，同时为企业／组织带来价值。

业务流程是端到端的，所谓的端到端，实际就是服务请求从提出到满足的全过程。也就是判断一个流程是否完整，应该站在服务请求的立场，判断服务请求是否满足或者被拒绝。

在识别业务流程时，通常会采用先外后内、先业务后管理的顺序进行。具体可分为以下四个步骤。（1）识别外部引发的主、变、支流程：业务流程大多是响应外部客户、外部员工服务请求的，因此先识别它们。（2）识别内部引发的主、变、支流程：有些服务请求是由内部员工主动发起的，诸如销售流程，还有些是在特定时间、状态下发起的，因此识别完外部的，还需要从内部补充。（3）识别管理流程：有一部分业务流程是为了实现控制、监督、管理等意图，需要单独识别。（4）判断业务流程优先级：业务流程是信息系统交付的最小单元，因此对业务流程做优先级判断，有利于做出更合适的迭代计划。

阶段二：业务流程分析与优化

在标识出相关的业务流程之后，接下来的关键任务就是逐个流程进行了解与分析，绘制出流程图，并对关键流程做适度的优化。

要做好业务流程分析与优化，首先要深入理解两个概念：第一，业务流程是分层的；第二，业务流程分析的关键是厘清流程八要素。

阶段三：功能场景识别

完成了前两个阶段以后，就要着手设计功能相关的场景了，毕竟，软件系统是解决问题的载体。为了将业务场景最终转换为软件系统，需要先将业务流程转换为用例，或叫用户故事。

用户故事，是一种轻量的、有效的用户需求描述方式，它希望用户或用户代表以“作为xxx（角色），希望通过系统xxx（解决方案、功能要求），以便达成×××业务目的、要解决的业务问题”的形式提出需求。因此从本质上，还是“用户视角”，也具有业务场景的特性。

这一步需要做的是，基于流程图识别出系统角色和功能场景，并绘制出用例图。

阶段四：功能场景分析

功能场景分析是以“场景 — 问题/挑战 — 方案”的逻辑来分析每个业务场景，从而导出所需的功能。该任务一共有五个步骤，实际上就是对这一思维逻辑的一些补充：概述业务场景、细化业务场景的业务步骤（也就是场景部分）、遍历步骤分析困难并导出功能（也就是挑战、方案部分）、识别环境与规则、分析实现方式并完成初步交互设计。

在 xxx 场景下，用户会遇到什么问题或挑战，我们的应对方案是什么。

软件需求分析的check-list

很多失败的软件项目，都是由失败的软件需求分析决定的。为了使软件项目成功，在软件需求分析阶段，总结出自己的一个check-list，是非常有必要的。

软件的价值需求列表要明确，在分析阶段就要明确软件要解决哪些人的哪些问题，能够为公司创造什么机会。如果不能通过讲故事的方式演绎出关键的痛点或机会，说明对问题的理解不到位。
识别出软件的关键干系人，能够明确地说出他们每个人主要的关注点是什么，顾虑点是什么。如果有一个关键的关系人在软件开发完将要交付时，由于自己的需求或顾虑没有被满足，就会很麻烦。
用时序图和用例图清晰描述出业务流程，并分析出流程的主体、变体和异常情况。以住酒店为例，流程的主体和办理入住，到期后退房，流程的变体是换房和续房，异常情况是客人没有带身份证等
软件包含哪些用于支持管理和决策的功能场景，每个场景的必要性是什么，软件是否提供了合适的数据用来支持这些场景。
软件交付以后的监控预警、错误调试的需求如何解决，是否有数据备份与迁移的需求，软件包含哪些配置项用于应对以后的变化
软件中的数据是否完整，数据依赖是否合理
软件的关键约束与质量要求是什么，安全性、稳定性、易用性、性能、可维护性和可移植性等。如果描述不出来具体的要求，可以描述使用场景和使用频率。

本文首发在我的公众号 老朱的读书随想，感兴趣的可以关注我哦。