所在业务在早期没有营销费用，买家购买商品的折扣优惠是由卖家提供的，所有订单的最终价格是由卖家和业务方确定的，整个购买流程很简单。
现在此业务收受到公司重视，业务团队能申请到营销费用，业务团队能主动补贴折扣优惠。一件东西进行促销时，用户购买此物品后，由业务方出钱补贴折扣的费用，而卖家不需要考虑优惠折扣。实现这种营销需求需要和第三方的团队合作，例如商家营销团队、账务团队。
项目开始的时候，我方向这2个团体介绍业务背景，提产品需求，开头很顺利：业务边界范围的界定、接口交付时间、联调测试时间、系统上线时间。
1周之后获知：账务团队重新安排了开发负责人，然后和这个开发同事沟通之后，才发现之前讨论的需求他完全不了解，然后重新开始讨论产品需求和实现方案，结果之前定的时间点全部废弃。因为负责的同事说实现的方案很复杂，第一次无语了。。。然后我发开始消减产品复杂度。。。重新定时间评审需求、确定每个进度的时间点。
总结：核心业务如果依赖第三方的团队，在项目初期应该尽量他们沟通，确认项目初期是否有已经开展、是否有不清楚的细节，虽然在项目开始的时候重新安排开发负责人的情况很少，但确实存在，而且重新评估复杂度之后，发现对deadline影响很大。
对于这种问题除了项目初期尽量暴露出来之外，发生的时候，要和产品需求方重新确定需求中是否有些模块可以折中成简单的规则，例如：每个商家的每个订单的转账补贴由实时结算的方式改为 每个商家补贴日结+提供日结明细流水的方式，因为这种方法能够继续复用账务系统现有的日结逻辑，不需要汇款系统新开发实时结算模块。
基于这个教训，我们之后和营销系统、账务系统每隔2天都会互相通报进度，分批次提供或者要求提供 API接口，在自己业务系统通过mock方式完成所有的流程后，分批开发、联调接口，这样能够在比统一交互时间点更早的时间进行联调和自测。双方系统API接口能够并行的联调、测试、开发，充分利用时间。
测试环境不稳定：在业务主流程开发联调完成之后，账务系统同事通知说他们的测试环境不稳定，但是我们自以为他们会将这个问题搞定，等了一天之后发现依然不稳定，就顺便问了下他们什么时候能搞定，结果才知道：和国足踢进世界杯一样，希望渺茫，⊙﹏⊙b！！！之前还想再等等，如果再等下去，那就餐具了！我们果断去他们的工位上开始沟通测试方案，用一天的时间现场自测、磨合，之后开始业务测试----在聊天工具上沟通测试中的问题，之后测试很顺利。
在项目中，PM是不能接受需求有太大的变化----判断依据是在当前的技术实现的复杂度，而不是依赖于产品功能的描述。所以能被接受的需求变更，一般属于产品功能的简化需求。
在跨团队合作中，一个需求简单的变化，如果没有同步给合作团队，很有可能造成项目的延期。这种变化即使由产品方通知了合作团队，技术团队也要再次沟通确认，合作方的技术团队很有可能因为这个小小的需求变动将技术实现方案大改，而且不会主动通知。PM要时刻关注这种变化，并且保证所有团队时刻了解最新的产品需求。
这次项目中，临时决定有个功能在此活动不会被使用（业务方来不及统计数据），但是随后的活动都会被使用，但是未及时同步到位，结果遭到合作方的吐槽，说是如果这样，此版本就可以不开发这个功能了，延期到下个版本。不过最后所有的功能都按时上线，\(^o^)/~。
这种问题归根结底是一定要把沟通放在第一位。
做好业务边界的划分，保证新业务功能模块和当前系统的关联关系最少，易于从逻辑上或者物理结构上进行切分。独立的业务模块只处理一件事件，而且将这个事情处理的很完美。而且易于之后应用于其他业务场景，做功能扩展也不会历史业务包袱。
健壮性分为业务实现的健壮性和系统服务的健壮性。
业务实现的健壮性体现在业务的幂等性、事务性、容错性等方面。和REST架构风格中POST/PUT类型接口的实现原则一样，最好每个接口要有幂等性的特征，query类型的接口天然支持幂等性，但是ADD/UPDATE/DELETE类型的接口需要一些特征参数来实现这些原则。一个完成的交易业务由多个子流程A、B、C等子流程组成的。如果C流程失败了，应该如何处理当前交易业务呢？
有2种场景：
1、 如果当前交易是另外一个交易的附属流程，因为前置条件符合业务场景，则次交易流程是不允许失败的，那么事务在这种场景是不合适的，只能通过业务状态来重试，保证最终成功。
2、 第二种方式也很常见：如果C失败，通过事务/分布式事务来将A、B的操作全部回滚，此次业务操作失败。
如果2种方式都是可选的，第1种方式比较合理，因为可重试的实现方式，不会因为某个流程暂时性错误：数据库连接失败、线程池任务添加失败等等，而影响其他业务流程，同时这些接口能暴露到管理界面便于之后的人工干预、系统自动的补偿操作。
通过业务健壮性来保证给提供使用方的服务的最终状态肯定是符合预期结果的。
系统服务的健壮性体现在良好的错误通知和恢复策略。系统中单个节点宕机或者一段时间内服务不可用或者压力过大，不应该导致整个服务集群不可用。所谓的Load Balance、Failover、Failback、Throttle(Sampler) 这些软硬技术策略能够发挥很大作用。
监控分为业务监控和系统应用环境的监控。
业务系统监控主要关注业务接口的RT/QPS、成功和失败次数，核心业务的成交量等。在某个时间段内的如果有数据指标波动较大，有可能是某些业务接口出现问题了；或者一些偶发的错误报警也需要关注，这些偶然的也有可能是代码逻辑的bug或者，系统快达到瓶颈导致的。
系统应用环境的监控就很常见了系统的Load、CPU、MEM、磁盘IO、网卡流量、JVM等。
业务管理界面：之前一直强调系统的幂等性、容错性，既可以通过系统自动重试来达到最终一致性，也可以便于暴露接口到管理页面，由管理人员人工干预进行补偿操作或者数据订正。本次系统基本上所有的服务接口都暴露到管理上，很容易做数据订正和业务重试。
配置项管理界面：高可配置性是一个系统能够很容易做到服务的高可靠性、易扩展性。通过修改配置能够停用/启用不重要的流程，启用/停用压力过大的服务。。。这次系统上线开始做活动，因为新版功能上线怕账务计算错误，通过配置临时停止划款操作，账务总额确认通过后，才启用这个业务配置。
每次的项目都会有不如意的地方，在项目流程上的：沟通不顺畅、人员变动、需求被强制大改；有些是依赖的第三方系统的细节不透明，首次使用之后，经常会在遇到状况才发现某些隐藏规则
原文地址：http://blog.csdn.net/liu251/article/details/37881647
