上周末从马丁那里拿到这本书，我安我的兴趣点挑着读，已经读了不少，对一些点需要反复研读的，我还录了音，一有时间就听听想想，真的非常适合现阶段的我。谢谢马丁~~

今天早上读了铁律41：站在客户的立场上设计需求，而不是追着客户问需求。

读完后，我的理解：

通常情况下，服务和产品的提供者总比客户要专业得多。我们以客户为中心，就是要站在有益于对方的立场上，提出各种建议方案供其选择，而不是天天追着客户问需求。轩为客户即使在某一方面非常优秀，但毕竟在所需服务项目的领域不是专家（要不也不会找上你，不是吗？），所提出来来的需求往往是肤浅、模糊和飘忽不定的。

作为服务提供方，应以更开阔的思路与客户进行沟通，在与客户初次接触之后，要按照“善意有益于对方”的原则，站在客户立场上，帮他们设计几套结构严密的服务提供方案，尽量将各种细节考虑周全。与客户再次沟通时，将这几套细致的方案讲解清楚，供其选择，在接触过程中，还要特别挖掘连他们自己的都没有意识到的潜在需求。

--------------------------

几天前我读过一则铁律17：在大公司的锻炼和沉淀是创业的另一笔资本。

读后，我一直在思考我在HP这么多年，在这里我沉淀了什么？今早读到41则时我才恍然大悟：HP的项目动作中，把以“客户为中心”这一理念模型化了。

我们每一个项目都分：

项目需求确定（这一阶段就是和用户沟通，了解和理解用户需求）--> 需求分析（从专业的角度来分析需求的可行性及调查现有系统中是否已有实现的功能）-->设计阶段（设计实践方案，并写出完整的设计文档，向用户说明，只有用户能理解能明白，他们才会签字，这一阶段才算完）--> 设计方案构架（在设计系统中进行（这是一个纯开发的系统，与真的系统只有基本功能上是一样的），进行小规模的可行性测试，把构架文档写好，发给用户review，他们签字方可进行下一步。其实在这一步，我们会处理掉很多潜在的风险，如果现阶段不能处理的，也会写出可行性方案作为备案，就算真的发生也可以快速反应。如果近期不能发生，也会把文档留给下一次动作的人，可以节省时间。）-->全面测试(这次的系统是一个更接近真实系统的环境，用是设计人员进行功能上的测试，然后是用户体验测试。这个阶段如果用户也签字了，项目就差不多完成了90%了)-->传到一个非常干净的系统去检查配置的合理性--> 传到真实系统-->一个月的后续支持。

在这种环境中工作了很时间，这种思维早就行成，我会不自觉的这样分解和操作，我想就这是HP给我的最大的一个财富嘛。