商业的本质是供需和交换。软件行业也一样，生产别人所需要的软件并获得相应回报，就是成功。《软件需求》这本书是一本软件需求领域的工具书，很全面且具体，可以跳读。
在我所工作或了解的软件公司中，发现不论是初创企业还是中大型企业，他们都存在一个相似的严重问题，那就是没有摸清用户需求。这个问题既会导致初创企业迅速失败，也会导致成立多年的公司被拖垮。
在软件领域，我充分相信国人的智慧，如果摸清楚用户需求并确认利润巨大，那么实现它并不是一件多难办的事情。但确认需求问题会难倒绝大多数企业和个人，需求问题是软件企业的第一问题，也是主要矛盾，不解决这一问题，后续问题就难以展开。
那么软件企业首先要分析用户需求，需求问题是如此重要，它关乎到企业的生存，因此必须由 CEO 进行分析和判断，优秀的 CEO 也一定是位卓越的需求分析师，对于初创企业更是如此。当分析确定这是一个真正的需求后，则需要以最低成本和最高质量给出一个仿真原型，必须让用户能够看到，因为用户可能不知道自己想要什么，但他们一定知道自己不想要什么。且需求分析问题不是一个阶段性工作，而应该贯穿始终，因为用户的需求会随着各种因素不断变化和成长。
验证需求是否为真的唯一群体是用户本身，他们是软件的使用者和付费者。我所经历的公司似乎都没有重视需求验证这一过程，导致一家公司走向项目制并面临破产，一家公司迟滞不前不得不研发第二款产品，这难道不是个很重要的问题吗？试问下自己费劲吧啦的研发一款软件既没有用户需要用，也没有用户愿意付费，这不是闭门造车的自嗨行为吗？这既不成熟，更是愚蠢。
需求是如此重要，但有的老板竟然口头表达，试想下两军交战，将军的指挥都是以口头命令和传达的，这难道不会乱套吗？需求问题对后续的工作都是引导性质的，一个需求错误很多人的工作都白干，就像一个将令错误就会死很多人。需求问题必须要以非常完整具体的文字表达出来，并让员工参与进来，进行详细的需求评审和现实验证，在这个问题上非常值得花费较多的时间，若更完善一些，应该让更多的用户参与进来，求同存异，需求问题会解决的更好，需求文档会更加具体全面，这一步做好能让所有人事半功倍。
当需求问题明确后，需要明确开发模式，我比较倾向于敏捷开发和模块化开发。这个过程中需要排列优先级，有些研发团队会从头开始研发，不分优先级，这会降低效率，我们会将优先级分为三个等级：非常重要，重要和一般。先从最重要的问题开始着手，一鼓作气，再二竭，三而衰。严格执行这样的顺序会让研发同事越来约有信心，并且很多代码和功能可以实现重用，提升效率。
在研发过程中，可能会出现突发需求问题，这时候如果这个需求是重要或一般的需求，就应该先放到一边，如果是非常重要的需求，那么就应该和研发同事沟通交流，告知为什么会出现突发需求，能否降低新需求的等级，并记录情况以避免这种情况再次发生，同时，在研发开始之前，也应该告知团队，会存在这种情况的发生，因为完全获取用户的全部重要需求很困难。
在软件企业中，我认为：需求>商业价值>产品>代码质量>测试>研发，我发现很多企业不是这个顺序，或者完全相反。这个问题在我的经历和认知中会耗死很多中小软件企业。需求排第一无可争辩，因为做的东西别人根本不需要那就别谈别的了。第二是商业价值，能验证有庞大的用户需求了，就需要验证产品的商业价值，因为若想研发极高质量的软件，必须能有商业价值，若用户连几十块钱都不愿意付，那么这个产品早晚要失败。第三个是产品，产品需要完整清晰的让用户使用，解决其问题。第四个是代码质量，很多程序员可能都经历或见过“屎山”代码，能跑就行，但对于企业层面，这是一个定时炸弹，要么倒塌要么重构，任何后果对于企业都是巨大的成本付出，甚至能搞垮这个企业。因此，宁愿给研发两倍的研发时间来编辑和优化代码，也要比重构屎山好的多的多，成本低的多，可悲的是老板们似乎大都只要效率不要质量。第五个是测试，这是规范研发质量的前置动作，测试应该与研发并行，以求及时快速的找出 bug。最后是研发。
这个过程中，我认为任何步骤犯错都将造成下一步二次方的失败，并且会让后续错误成本相加。例如现在犯了一个 2 元的需求错误问题，那么成本应该是 2>4>8>16>32>64，并将其相加，也就是 126 元。如果你在测试阶段犯错，那么就是 96 元，这还没有考虑犯错后的用户体验问题带来的成本丢失，只会更多。因此越早在源头解决问题，越能节省人力和经济成本。和书中的需求错误 1 美元，用户体验丢失 100 美元类似。这就像是去一家饭馆吃饭，难吃且贵，你不会再去第二次，也不会让朋友去。
因此，为避免这种情况发生，最好把问题尽可能的扼杀在摇篮中，不要等到呈现在用户面前再去纠错。内部同事审查和 debug 环节十分重要，尤其对于研发阶段，因为代码只需要写一遍，但是后续看和审查不止十遍，这会造成极高的人力和经济成本的浪费。因此着重强调代码质量既是个必须要做的事情，也是个省钱的事情。
软件行业从业者往往有很多自信且有才华的年轻人，他们的思维活跃且有自己的判断，这会出现一个问题，就是沟通问题，并不是说他们不能理解同事的话，而是在他们的理解可能与原本话的目的有所不同，或者看重点不一样。类似于你说“这座古桥上的月亮真圆”，有人会关注桥，有人会关注月亮，有人会关注圆不圆，沟通成本就这么来的，更不要说复杂的研发过程了，研发过程中的一个需求包含着许多信息，很多时候都会理解错误或偏差，两个人之间是这样，多人之间就更多了，巨大的沟通成本就这么悄无声息的来了。因此非常建议落实到文字中，并规范其用词，这会节省巨大的沟通成本。
还有一种情况，管理者的愚蠢命令会让研发任务陷入泥沼。这时候我们就要化身成为一名需求分析师了，要充分了解为什么管理者要这么做，目的是什么，并动之以情晓之以理，注意态度，不卑不亢，不能因为他们的愚蠢和拍脑袋的决定让自己和团队的辛苦付之东流。
最后，书中有很多需求分析、需求管理、需求验证等实用知识，有兴趣的朋友可以看一看。
我们正在做一款面向个人股票投资者的决策辅助工具「棱镜」，它能够将你的分析决策逻辑由文字和框架转化为算法，让计算机和算法辅助你共同决策，欢迎来看看。