书的风格非常适合实干的人看，因为他提供的一套确实可以实行的框架，包括思考模式，方法，表格，工具等，让虚无缥缈的“客户需求”能转换成切实可行的目标。而且，书中的道理告诉你，即使程序员也需要明白需求再开始写代码，无论你是不是产品经理都需要掌握的技能。书中大量的实例与说明，证明作者的功力确实是经过长年累月积累下来的，有些项目内部的经验也拿出来分享了，这是令人振奋的。
“导致进度超期，成本超支的项目中，最主要的原因之一是项目的重新启动。”这句话我体会很深，虽然暂时我只是执行层面的，但是换位思考也觉得项目一开始的评估评审的困难。我的思维结构里确实缺乏严谨的量化思维，从小也很少有这方面的训练。现在我对“需求”的定义已经改变，不同的公司因为业务不同造就不同的需求。很显然，我说的话会跟书里不断提到的概念表面上一样，但是看了作者的介绍后我发现还是有不一样的地方，作者的“业务”显然是更微观，更细致的。而我的所说的只是“产品业务方向”，如果要落实到实践，说实话也是无从下手。 一本让人感到羞愧的书确实是好书，因为每读一次都需要你鼓起勇气，不知不觉间锻炼人的自信。
“学会用数据说话是技术人员走向成熟的一个要点”。这让人兴奋，但是又无从下手。我们习惯对时间感性，对数字感性，“大概”“差不多”是我们的特色，对一个事物的认识，我们习惯知道个大概就好。不过，为了能做出个优秀的项目，进行这方面的训练很有必要。
需求优先级
这个人人都知道，但是定义起来困难重重。你问客户，客户说啥都重要，都关键，都高优先级。书中介绍的方法可以尝试，我觉得还是有可行性的。但是效果取决于你对业务的熟悉程度。
首先是，你需要从业务价值的角度定义优先级。确定好了之后找到技术开发人员对非关键优先级的需求进行分析，将技术依赖性高的基础性的需求升级优先级。最后再由项目管理人员从项目风险角度出发，将一些低优先级高风险的需求提升优先级。
其中，业务分析优先级时，可以采用“满意度+不满意度”的评分方法。比如两个需求，同样对用户来说有的话都是“比较满意”，但是一个如果没有则会造成“非常不满意”，那么这个优先级肯定相对较高。
需求对接、需求方案review
基本上如果有需求小组的话，一份方案或SRS出来后，需要先经过需求小组对接，再在研发团队内部对接。如果有需要可能还会找用户进行review。
需要明确的是，review和对接的目的是为了，尽早发现问题，找到错误，统一意见。
另外针对需求小组内部对接可以采取类似“结对编程”的方法，进行桌查、轮查。