给A项目组的建议:
A项目组的问题：
l 产品从专业角度给客户H的印象是不如B项目组
A项目组产品实现了很多功能，但没有对功能进行归纳，B项目组这边做的还可以。
从抽象的角度看问题、讨论问题、解决问题会避免过早的陷入细节，同时从抽象的角度进行沟通也更容易把握重点。B项目组将需求分解为诸如凭证、余额等概念，让提出需求的人从新审视自己提出需求，这也许是客户H认为B项目组比A项目组强的方面。
l 代码重叠
A项目组产品由于是分业务实现，编程人员之间很少沟通（从客观角度来说，彼此之间也不知道要沟通的点，技术问题除外），这就造成代码重叠（具有高度类似的枚举），让人很是迷惑。
l 技术实现
记录新值老值日志处理，A项目组实现的很仓促，只要过一下MSDN中关于Linq这方面的类的实现，就会发现其实只要DataContext本身已经提供了这样的功能。这就提醒A项目组如果是涉众的实现，一定要做足功课，最基本也要做到熟悉系统已经提供功能。
总结：
B项目组关于底层架构的分析晚点发给你，他写的很粗略，但也许会有一定参考的价值，先研究一下。A项目组这段时间会了解一下架构思路并进行整理，究竟他实现的是否合理，等A项目组综合后再讨论。
l 两种路线
A项目组走的是实现为主，分析的领域以一个个独立的业务为主，B项目组这边是宏观把握全局，孰好孰坏很难评定。
l 业务抽象
A项目组下一步可以提高的地方。
l 团队建设
A项目组没有经验，但目标应该没有错：每个人都能成长、有能力宏观把握产品走向和架构。
l 关于B项目组
B项目组有丰富的经验，并且对要做的东西都进行了验证和推理，有的已经做了。因此在讨论的时，仅仅论证具体的实现的优劣没有意义，因为他有东西在印证他的架构，A项目组也尽量避免这种无意义的讨论。等A项目组真正完全了解了他的架构，也许那时的讨论才有意义。
B项目组经理也是一个善谈的人、对技术很热爱，也很愿意分享和讨论，这样A项目组和B项目组以后的合作应该不会存在障碍，A项目组需要更好的利用这个平台。