Oracle神谕

对软件设计和改进的过程中，将自己当作用户，对自己的软件认真仔细的走一走。

我们是作为研发的成员，我们的目标在于生产软件。但是更为关键是软件研发出来后如何使用？如何使用问题又归结到软件如何进行设计？设计决定研发成果（功能体），而研发成果又促成了软件如何进行使用。但是反向的逻辑就是要在设计的过程中，充分考虑使用者的感受和习惯。在设计时，要这样想？如果你再用这个系统进行运作，你会怎么样？感觉是"哦！酷毙了"还是"shit！一堆...."。
 　　当然作为我们研发出来的后的实施团队就更加重要，因为软件体是固化的（交付后一阶段的研发成果），但是使用的方法和思路要给使用者提供，如果没有一定的思考，就很难让用户满意。
　　其实，根本上是两个方面。一是，如果你使用，如何进行设计；二设计出来后，如何进行实施？

事找人，不是人找事。--- ---
关键是如何形成待办事项？
(1)将需要做的事情一一列出，并按照事情紧急及重要程度排列；
(2)有些事情不是短时间内（一天半天）就能完成的，最好能跨越周期安排相应的事项，形成日程安排（计划调度），必要时按照甘特图的形式进行辅助。

第一大恶人!

（1）客户的需求是非常关键的，哪怕我们就把原来的需求罗列出来。这个也是非常重要的，然后是相应的解决方法，如果是已经开发出来的，将产品演示出来。如果没有就实际说明是需要进行开发的。给客户的需求一定要留一章来讲PPT；
（2）客户的需求和我们目前的产品的差异度，主要还是将前提的调研结果与我们的产品的吻合度、差异度（将来开发的重点）；但是这个东西也比较敏感，如果感觉差异较大，可能影响客户的选择。中间可能自己清晰，操作过程模糊处理。
（3）重视需求调研阶段。一定要将此阶段作为重点，在整个研发周期中要有一定的比例，另外实施周期也是非常关键的。
（4）产品的业务流程的演示是非常关键的。一定要保证业务流程的演示正常、讲原有的功能比较好的功能点展示出来。
（5）Portal的方面的重视。我们分离出对外或协作单位的Portal。用户在目前的情况下，一般是比较拒绝客户直接在企业系统中使用的。Portal的使用，可以为客户提供一个专门的门户来进行使用。
（6）在前期的项目接单过程中，也要强调团队协作，需要一个总体的协作或者售前的Team Leader。特别是对应大的客户。
（7）细节决定成败。

      客户需要的是运营经验+管理系统的支持。一般很少有公司说，我们运营模式很不错，但是IT有些差，我来给你完善的需求你来给我们实现。更多的是要你的系统能给运营本身带来什么东西？能够给管理带来什么提升？ ...提升...
     IT的投入带来运营的提升，带来公司价值的提升，这才是关键。你来指导，而不完全是定制。强势未必是件坏事情。
     强调研发是对的，但是更多的是你已经实现了什么？你的产品功能如何？如何来提升价值？运营咨询+IT技术支持+ 产品研发

软件研发和项目运营是两件事情。项目运营中会出现很多系统在测试阶段没有出现的问题，这个时候要非常谨慎。
开放式的项目方式的操作方式是最复杂的，因为代码没有冻结的时刻，随着运营的过程，系统要不断的进行调整、测试、上线。

... ...