程序员和产品经理的斗争，从根本上就是个伪需求

产品经理，对大量存在的、技术不扎实的、喜欢敷衍了事的程序员，不具备识别能力、预警能力和准确的管理定性定量能力，从而让产品经历看似成功的上线到最后的无限内耗慢性死亡，不夸张的说，这是目前9成以上产品设计的现状。

f团队人员组成，与一般互联网项目相比优势之一就是需求分析师经验丰富，均可算是某一业务领域的专家，比起辛辛苦苦白手起家的web2.0创业型项目来说，我们可说有着无比清晰的系统建设方向，靠谱的需求来源。需求的方向性是明确的，这点对于开发者来说是最好不过了，我们说“靠谱”很重要，企业应用应该不至于让你被需求雷死：）。既然如此，为什么不用好这些资源呢？因为是企业内部，我们总是能和需求方以及业务专家保持直接有效的沟通，他们能够且应该比开发人员更了解业务该如何设计和系统该如何被使用，这便是实施领域驱动设计最为重要的资源和前提，业务是最具有价值的，因而我们希望并且应该做到当业务在系统中被实现时，它是可重用，可理解，可验证的，而不是用一堆晦涩的脚本或者数据库表来描述牵强的描述它。往往我们在和业务专家沟通的时候，他们已经参与或者在帮助我们设计业务，他们期望系统中业务的运行/实现方式是如他们所描述的一致，这对于业务的深入和衍进具有很大的意义，业务在专家的脑子里，若我们的设计映射了这种业务描述，那么也就等于系统/业务设计也就在他们的脑海中。

组建2-3个Scrum团队，3-4人，每组一个Master，ok，开工，初步定义sprint周期为2周，可由一位需求分析师暂代ProductOwner角色，来全程跟进，将项目需求进行分析后，对功能进行合理拆分为backlog，进入迭代，每个sprint结束需交付可用产品/系统功能，交付需求方或测试验收验证，依据情况可让已交付功能上线。休整后进入下一个sprint。依此，磨合一段时候后，确定一个稳定的迭代周期，快速响应需求，定期准时交付可用产出。迭代期间进行每日会议，及时沟通。由于是长期的内部系统，无需对较大项目或复杂需求做详尽估时（预估的几乎不可能准确，准确的代价是拒绝了变化，这是不符合期望的），只需总是按照迭代周期向客户进行交付，稳定的周期对用户进行反馈，我们将欢迎变化，你可以在任何时候提出变更，当然变更总是有代价，提出人心知肚明，而合理评估后欣然接受相信一定是客户期望的态度，稳定的交付周期也会让客户明确感知开发成效，藉此将树立团队形象。