F)项目经理如果发现有成员任务没完成，而且失去联系，则将该子任务重新指定劳动者去完成(可以内部协调，也可以向master申请新的资源);(为了提高效率，项目经理可以在劳动者完成任务后即报告给master,释放控制权,但保留联系,只有在任务清场后才彻底脱离关系)
G)项目经理在项目完成后，会将结果合并，并将完成信息报告给Master，Master接到报告后会通知业务去进行订单交互；
H)具体的交付由客户、业务和项目经理一起完成,当然会将交互结果汇报给Master.
I)订单交付完成后，Master指示项目经理清场,并将项目经理解职(成员清场可以在项目经理确定任务完成时就进行)。
J)中途出现问题可以从C和E重新开始.
从上面的逻辑和过程可以看出，Master的职责比原来要单一很多，因为大的通信和计算部分都是由可以负载和替换的具体劳动者完成，所以Master很难会成为瓶颈。这也是为什么管理非常好的企业，总经理都比较闲的原因。但这种方式的劣势是增加了设计和实现的难度，同时如果因为项目经理挂掉，重新启动项目的成本也会比较高(也可以采用一些方法减少些成本)。当然，任何事情都不会是完美的，就看怎么取舍了。
上面那位牛人提出的Master横向扩展，不是不可以，但实现起来会很困难，因为如果要保证可靠性和一致性，最终一定有一个地方需要统一，只能由一个点来担当这种统一的职责(但可以有对等的备份)，否则像Google这样的大牛公司的GFS实现中的Master也肯定不会采用领导者选举算法来保证某一时刻只能有一个领导者的办法。因此我觉得，要减轻领导者压力，只能采用剥离其担负的非关键性业务或者功能来实现。提高领导力，也只能升级设备。
另外，由于原来master担负的任务分割结果可能会重用，在这种模式下，需要增加一个指示来指示项目经理如何管理任务分割结果(比如大文件分割等).当然，细节需要处理的地方还很多，套用一句话：思路决定高度，细节决定结果。 好的架构也必须契合好的管理，好多东西都是相互借鉴和渗透的，高层次上大家也都是统一的，随着层次越高，统一性越强，最终上升到的高度就是哲学。
我目前在考虑的就是这种扁平化下的项目经理负责制，仿照现实生产活动中的敏捷制造方式。当然，这些也算是这段时间准备实现自己的mp，进行学习和思考的一点想法，写得不好，欢迎大家拍砖.