在用户的经理这一块，我读到了浓浓的讽刺意味。作者说，用户的经理会从中干预，且出于自负，想充当用户的角色，却不承认自己不是典型的用户，固执己见，认为自己比用户更知道他们需要什么。这可能就是用户和客户的区别了吧。客户就是因为花钱，才想更多的干涉吧。没有设身处地的体会过工作流程，或者说想要的，站的角度不一样，对软件的需求也不同。作者对用户经理的怨气很重呃，不过说的也有理。查询所需时间从用户到经理到总裁再到开发人员，一分钟被主观的放大到了五分钟，虽然这个现象并不能帮我们解决问题，但却是产生问题的原因。
开发经理眼中有的是荣誉，为了向别人介绍新技术和年终奖忽略了故事优先级的重要性。而销售人员更喜欢撤销这种功能。领域专家给出的也许是专业性，指导性意见，但与用户需求和站的高度不一样，也不能百分之百达到用户想要的标准。
客户和用户之间或许也存在冲突，客户希望安全，技术新颖，而用户只在乎方便。就连介于开发人员和用户之间业务，系统分析师也会因为个人原因出现差错。
做这些了很多模块来阐述很多角色在开发之前的定位，可以说是每种角色都有自己的局限性。站在自己角度考虑的同时，都忽略了其他因素。将符合用户需求这件事情定义的这么细看起来是很恐怖的，可以说用户是一个群体或者是多个群体，想达成统一意见都不太可能。也许，方案既定下来，很多事情都是无可奈何的吧。也许，这就是众口难调，软件开发的天堑所在？
接下来，作者根据情况说了几点糟糕情况。用户很少或没有用户怎么办，只能退而求其次实行一些不如人愿，但相对来说还算靠谱的方案。
程序员向测试人员解释如何测试这个功能。。我自己写的程序参数不多，同学想看一下有时候就会报出一些错误，程序是按自己设想的逻辑实现的，测试也是按实现的来，自己很难发现错误，我建议测试人员应该抱着怀疑，挑错的心态来完成测试，错误越多越好。