如果你的项目失败了，应该是做了失败的需求分析
|
曾经尝试过这样一些小技巧，在每个功能模型的入口页暗藏了一个计数器功能，一段时间后只要收集回log记录，一看就知道哪些是“不再需要的”，也就不必再费心去做更多的升级了。当然，这种举动只能起到“马后炮”的效果，无法“防范于未然”，仍然浪费我们大量的开发资源与时间。 是否能够事先预防呢？这必须从另外一个角度来看，那就是能否在最开始有效地划分优先级。也许这样的回答会令你失望，优先级划分经常是“拍脑袋”的产物，没有理由也没有原因，它就是最高优先级。这样的方法显然是不正确的，真正基于业务领域知识来衡量需求的必要性和充分性是解决之道。 需求分析就是向下分解+向上提炼，外加一些规范化。需求分析是什么？需求分析是业务分析，需求分析是一种分解活动，需求分析是一种提炼与整合行动，需求分析是一种规格化活动。需求分析我们输出的产物就是需求规格说明书（PRD也叫需求文档），需求分析也是检验一个合格产品经理的标准，产品做什么？最主要的还是以把握客户需求为准。需求又可分为： 业务需求用户需求软件需求功能需求非功能性需求设计约束其实，需求获取也有失败，并不是完整的表现；需求获取的问题主要表现在： 捕获范围不足缺乏计划性缺乏科学性捕获对象不明确捕获手段不足 有时候就会导致项目的终止或失败。那我们的需求标准是什么呢？怎样的需求才能被记入到PRD里面呢？也就是我们的标准，需求的标准： 完整性不失真有优先级有技术早期介入这样的PRD才不会有争议，即使有变更也需要及时的知会项目组成员。需求分析的过程我在前篇文章中有提到，需求的验证和评审是一个反复的过程，就是为了解决争议。 从我参与的软件项目过程中来看，主要的原因如下，也希望给你得到些许提醒： 1、沟通失真沟通失真，从客户的描述到项目经理的理解、分析员的设计、程序员的编码、商业顾问的诠释，每个角色都根据自己的特点和需求对信息进行了不同的加工，从而导致信息的内容有了很大的改变。因此，对于软件需求工程而言，克服沟通失真就成了一个要点。根据相关的研究显示，在信息的传递过程中，如果没有采取任何措施，那么在沟通过程中信息衰减可能的最大值高达60%。而在软件开发过程中，需求信息通常要经历用户代表、需求人员、设计人员再到开发人员，因此最坏的情况下，开发人员获得的信息仅是原来的8.4%，这是一个十分可怕的结果。怎样才能够更好地避免这种问题的出现呢？其实关键的手段有两个： 文档：如果信息在传递的过程中仅靠口口相授的话，就难免发生遗忘、加工等情况，因此必须在这个过程中有效地利用文档，将达成共识的信息文档化。但这种方法只是用来辅助沟通的，而不是代替沟通，文档的好处就是有依据，避免了后期的扯皮，也有利于需求的管理及变更。Review：国内常将其翻译为“评审”，但这一翻译却容易给人误导。评审在很多人的脑海中就是得出一个通过与否的结论，这也是导致需求评审工作流于形式的罪魁祸首之一。顾名思义，Review就是再（Re）看（View）一遍的意思，其本质含义是通过再次的审读，尽早地暴露出错误。而最简单、最有效的Review就是在用户代表阐述了需求之后，需求分析员用自己的语言再复述一遍，以确保沟通没有失真。解决失真的最有效的办法就是及时的复述。2. 客户的需求放大用户在描述自己的需求时做了许多“添砖加瓦”的事。“用户要么不会说，要么就会添油加醋”的现象，在我的实践中是屡见不鲜的。而在这种现象的背后有什么潜在的原因呢？我认为至少有两方面关键因素： 客户希望支付的成本尽可能少，获得的效益尽可能多（想马好，又不想马吃草）。这种思维对于任何一个客户、任何一个人而言都是本能反应。而当用户对开发成本越不了解时，这种心态就会越强烈，更加担心自己“亏损”了；因此，在需求协商时就会采取尽可能增加功能的方法来降低“亏损”的风险。要解决该问题并不是件容易的事，一方面需要提升软件估算实践的有效性，另一方面则需要产业成熟度的提高。解决方案的选择权交给了不熟悉技术的客户。许多需求团队在进行需求捕获活动时，经常预期用户能够直接告诉他们要做什么（What），而不太关心用户提出需求的真正动机（Why）。但是，这样就将解决方案的选择权交给了并不熟悉技术的客户代表，而一旦客户代表选择的解决方案不是最合适的，就必将引发后续的需求变更。因为，对于一个特定的问题，可能的解决方案会有很多，因此用户可能在使用软件的过程中不断发现其他可选的、更合适的替代方案，从而导致了不必要的需求变更。而要缓解这一现象的关键就在于，在需求捕获的过程中多问“为什么”。3. 项目经理的需求控制（编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
