2.5.2　对需求分析的误解

关于需求分析，很多软件工程师仍存有很多错误的认识。下面列出几个典型误解。

误解1：需求分析和软件工程师没有关系。

1）常见问题

很多软件工程师（也称研发工程师）认为，需求分析是产品经理的工作，和软件工程师没有关系。根据我曾做过的一些小范围的调研结果来看，软件工程师中写过需求文档的占比比较低。

另外，在很多公司，软件工程师在需求评审中的参与度也是偏低的。很多软件工程师只是被动地接受产品经理给出的需求，而不会思考和评判这些需求的合理性。在很多团队中，软件工程师和产品经理的关系在一定程度上都存在着问题。

2）危害

软件工程师被动地接受产品需求，会影响自身的工作积极性。前面也提到，写代码是需要激情的。对于被动参与的项目，对于不了解用户价值的产品，软件工程师很难产生工作上的激情，从而影响最终产出物的质量。

软件工程师不深入参与需求分析工作，也会影响沟通效率。人和人的沟通效率在很多时候都是比较低的，如果软件工程师对需求的理解只是一知半解，必然会影响执行效果。在很多场景下，不可能要求产品经理把所有细节都写在交流文档中，很多细节的决定权实际上在软件工程师手中。软件工程师对于产品需求的理解，会影响这些细节实现的质量。

另外，对于一个系统来说，仅有“产品需求”是不够的，还需要分析“系统需求”。例如，对于一个“春晚抽红包”的产品，产品经理会考虑游戏规则、交互逻辑等，但是仅有这些信息是不够的，还需要考虑系统容量、容错能力等需求。后者肯定是产品经理想不到的，而对于系统设计来说，这些是非常重要的输入信息，需要由软件工程师给出。

3）正确做法

对于偏用户方向的产品项目，软件工程师需要深入参与需求评审。软件工程师应该对自己研发的产品有深入的理解，而不能仅成为被动的接受者。我强烈建议软件工程师也应该学习产品设计方面的知识，这对于一名软件工程师的职业发展也是有利的。在产品需求之外，软件工程师还需要整理系统的需求。可以按照2.5.1节中描述的方法，给出关于系统需求的详细和定量描述。

对于很多本身就具有技术性的项目，很多软件工程师事实上兼任着产品经理的角色，只是很多人没有察觉到而已，而这时应从产品经理的角度来思考用户的需求和产品的定位。

误解2：做需求分析时考虑实现细节。

1）常见问题

很多软件工程师在参与需求分析或需求评审时，并没有考虑需求本身的合理性，而是大量考虑系统实现的细节。很多研发人员在发表意见时，经常想到的是：这个需求不好做，所以还是不要做了。

对于没有产品经理参与而由软件工程师自己来主导的项目，很多软件工程师会忽略需求分析，直奔系统设计，甚至直接开始编写代码。的确，对于很多软件工程师来说，编写代码才是最令人兴奋的事情。

2）危害

以上做法会影响软件工程师对需求分析的“聚焦思考”。人类虽然是这个星球上最高等的生物，但在“多任务”处理方面，很多时候还不如一个廉价的CPU。我们很难在思考实现机制的时候，也同时把“需求分析”这件事情做好。所以，这是我们作为人类的一个局限性，这也印证了中国的一句古话：不能一心二用。

另外，以上做法还存在一个更大的危害，即“实现决定需求”。软件的价值来自软件对用户需求的满足度。如果我们从实现的角度而不是从用户的角度来确定需求，这必然会影响软件的价值，从而导致软件研发的失败。

3）正确做法

要从用户的角度来确定需求。有些功能虽然实现起来很简单，但是如果对用户没有价值，就不要去实现；有些功能虽然实现起来很复杂，但是如果对用户非常有价值，也要努力去实现。需求的重要性，一定是从用户的角度来考虑的，根据对用户价值的高低来确定，而不是根据实现的难易度来确定。

有些读者会问：

“在做需求分析和需求评审的时候，还要不要考虑实现的成本？”

“有些功能根本就做不出来，怎么办？”

在做需求分析的时候，我们在实现方面要考虑以下两点：第一，实现的可行性，如果不具备实现的可行性，那么这样的功能即使被提出，也是没有意义的，有时需要修改需求，降低用户的满意度，使之可以被实现；第二，在确定开发的先后顺序时，可以考虑实现的成本，可以根据ROI（Return On Investment，投资回报率）来确定功能的开发顺序。