项目进行了将近一个月了，在这段时间产生很多问题主要涉及以下几个方面：
需求本身冲突，需求文档出现不一致状况。需求和设计开发的冲突，主要是展现形式和技术实现的冲突跨项目组维护同一工程之代码和脚本冲突项目组间协调冲突基础系统和业务系统冲突下面就各种冲突的表现和最终解决方案做简单的描述和概括：
1.需求冲突：
需求冲突主要表现为项目组内需求不一致，总体需求和单个需求不一致，组间需求不一致。
对于项目组内的需求不一致主要是不同的需求人员对同一类业务展现方式的理解不一致造成的，如树的应用范围，树的展现方式，查询界面布局，分配界面的操作等问题，这些问题在审阅单个需求文档是很难发现，但在抽取统一的应用需求，做设计时就被发觉出来。此时要求需求项目组统一规定所有类似应用场景的操作模式，展现方法，达到整个产品的统一性。走需求变更流程。对于总体需求和单个需求不一致，主要表现为单个需求违反或者没有遵守总体需求的统一要求，此类问题通常在项目间会议交流过程中发现，此时就要求需求人员修改需求。走需求变更流程。组间需求不一致的表现为，在不同的项目组可能实现同一业务，出现两者之间均描述需求，或者两者直接均没有此需求描述，这时就要有发现人召集两边开发项目经理和需求项目经理协调，确认该功能点的负责方。确认后，需求修改走变更。2.需求和设计开发的冲突
主要表现为需求和技术实现上的冲突，进一步分为两类：一、需求要求的东西不能实现，此类需求通常打回修改需求，二、需求要求的东西可以实现，但技术风险大，沟通后下版本在处理，当然本次版本设计时会考虑扩展。
3.跨项目的维护冲突
历史工程由于项目重组后，出现多个项目组维护统一子代码工程和数据库脚本的问题，虽然使用了cvs和VSS等版本管理工具，仍然会出现代码被相互覆盖、错误提交等问题，错误排查时造成责任不清。对于此类子工程需确立主要负责人，出现问题即为第一责任人，尤其负责排查，相关项目组义务协助，相关人员必须高优先级解决，直至问题Over。4.项目组间协调的冲突
主要表现为功能界定不清晰，接口定义模糊，责任不清，很大程度是需求和规划人员本身界定不清晰延续下来的问题。这类问题发现一个跟踪一个，明确责任。5.基础系统和业务系统冲突
表现为也些功能是有基础系统做还是业务系统做？是有框架实现还是项目组自己实现？通常是由于业务系统的扩展，原来的框架和体系不能满足业务的需求造成的，最合理的办法是扩展框架和基础系统支持，但最常用的办法却是业务系统先自己实现，框架和基础下版本支持（这是一个现在还没有找到很好解决的问题，即，服务系统可能落户于客户系统的需求）。另外还有，架构设计与概要设计、详细设计边界界定的问题，目前交叉区域比较大。（在第一篇笔记中有兄弟提出不喜欢条条框框的列举，不知道这样会不会好一些）
下篇：
我的项目笔记(3)--人力资源管理！
