关于需求
最初理解需求很是简单，就是客户想要做的东西，你帮他实现了，这部分的内容就是需求。然而在实际工作中，需求的获取变得复杂起来。我们通常想象的场景是将软件交给用户，用户看到以后很是兴奋。最初是界面上达到一定效果，随着现在软件集成度的增强，很多需求已经不仅仅停留在界面上面了。理解业务流程真正的内涵成为首要任务，而我们面对用户的需求，最为重要的往往不是客户、不是我们的成员，而是引起需求变化的原因。需求的变化会导致一系列的影响，所以对于架构也好，业务理解也好，最为成功的方法就是在于自己对于需求的理解、识别和适用变化的能力。我们可以根据需求设计软件，但是我们通常会被它牵制起来。前面说到R哥管理的那个项目，这是他第一次挂帅做的项目，可是3个月过去了，用户似乎没有看到他们想要的东西。仔细分析下，实际上就是需求变化引起了项目难以驾驭。R哥的思维方式决定了项目开始时专注于某些细节的复杂度，以及决定用新潮的技术手段。由于开发节奏无法保证，已导致用户在需求提交后不能在短期内看到效果，而在这个过程中，新的需求又被他引导性的提出，上次提的还未消化，新的又来了。新的软件没有掌握好频繁集成的效果，开发的代码一直处于未持续发布的状态，所以用户似乎永远看不到东西。后来我加入后，慢慢改善这情况 。我们将改善软件发布环节，正确在需求反馈后2-3天为时间段向用户展示演示效果并且获得反馈，不以频繁演示新功能为目的而浪费宝贵的市价，但是我们通过使用短迭代、增量发布的方式告诉用户，让用户的需求和我们实际开发效果是紧密相联的。
还有一个问题是，我们的程序员并不一定要求是全面的业务人员。程序员有创新精神并且他们也了解开发工具和环境，但所有的业务流程关键部分不应该由他们来定夺。R哥是程序员出生，他潜意识的认为程序员就是业务开发的定夺者。实际上，开发人员不应该参与业务方面的决定。这也是他越界思考的一个误区，很多时候他的想法很好，但却是自作主张，很多业务流程都是基于自己思维的范畴并未有真正融入到业务的大范围中去，所以他开发出来的内容，用户们还未参与具体的讨论，显然已经不具备满足用户的需要了。所以身为项目经理首先还是要判断，哪些是自己决定不了的，决定不了的就应该交给用户，不要想到自己是一个全才能给一个企业做出重要的决定，那个已经不属于你工作职责的范围了。如果遇到的问题涉及到会影响系统的某些功能，那就应该把这个问题如实的告诉业务相关负责人。如果客户领导授权给你处理时，你也要委婉的拒绝，因为作为你本身的职责你应该是看不到客户企业的业务需求的。但是你需要做到的时，还是要准备几套方案，不管从是技术角度出发也好，还是从业务角度出发也好，介绍每个方案时都将优缺点对比出来，和客户一起讨论每种选择的影响，无论客户做什么决定，最好你要让他们彻底了解清楚之后再做，当一切改变原本需求之后，我想我们应该涉及到了成本变更问题，很多事情就应先以这个为起点进行谈判了，因为决定是对方下的。
在协助R哥解决那个项目的时候，逐渐明白了这些道理并且亲自参与去实现。那个项目很快的进入了一个正常的过程，但随后发现项目组中有个W爷，他的一些习惯很有意思.............
