阅读笔记

Posted 2020-10-26 但为君故。

软件项目总会有失败，而在导致失败的各种问题中，需求问题是最多的。

当我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。

客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。

所以，需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。

那么如何避免这些问题？首先要深入地去理解客户的业务，进而想到客户的心坎儿上去，这样做出来的东西必然是客户满意的。

所以要记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。

客户是非技术的，所以他们提出的很多需求常常比较理想而不切实际，但我们作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。

不能客户怎么说软件就怎么做。客户提出的原始需求往往是不考虑技术实现，基于非计算机管理的操作模式提出来的。

因此，我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。

想要了解用户的需求就必须要进行需求调研，而进行需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。

需求调研的初期需要召开项目动员大会，这是十分必要的。

需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。

需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。

那么我们应当如何做需求调研？

文章中将它总结为以下几点：

初识、拜访、研讨会、需求调研、迭代、需求捕获、功能角色分析与用例图、业务流程分析、用例说明、查询报表分析、子用例与扩展用例等等等等。

需求调研是需求分析中最重要的一环，我们需要对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。

由于业务的不同，对软件的需求自然是不同的，因此我们在进行需求调研的时候，什么部门的需求就应当跟什么部门谈。同时，纵向又可以划分为多个层次，如高层领导、中层领导与基层人员，理解这些方面格外重要：
划分清楚角色，弄清楚每个角色的需求提出者与决策者，就是为了在今后的需求调研中找对正确的人，使今后的调研工作事半功倍。

在进行这一工作时，有一些建议：

树立良好的职业威信；

进行详细角色分析，将与会各方代表对号入座；

从宏观上制订目标与方案。

在“拜访”这一阶段，经过一番交往后，我们将逐渐在客户中结识一批可以帮助我们的人。

今后一段日子里，我们将依靠他们去学习和认识业务知识，收集业务需求，为日后的软件研发提供素材。

至于“研讨会”，它是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。

项目经理需要根据实际情况，合理地与客户组织研讨会。

但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。

而我们在做需求分析时，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。

需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。

因为客户毕竟是非专业，我们应当有这种自信，在理解客户真实意图以后，能够提出比客户更优的解决方案。

“迭代”有几个步骤：

需求捕获->需求整理->需求验证->再需求捕获••••••

需求分析就是按照这样的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。

业务流程分析有几个步骤：

清除低效环节、简化业务瓶颈、整合可用资源，以及将繁琐任务自动化。