今天，因为开发团队的体制调整，笔者在基础结构及技术调查方向上又增加了开发小组的管理工作，负责Web页面（包括业务逻辑和数据访问）的制造以及单体。因为原来主要负责技术调查工作，所以角色转换的同时需要先明确团队现有的软件开发过程是否有问题，从而进行改善。
项目存在问题：
本次开发团队的体制调整实际上是因为内部矛盾的激化，一位直线经理和业务经理（客户代表角色、最终成果物审核）因为成果物审核问题产生了争议，最终导致直线经理退出项目组。团队因多年从事对日软件外包工作，熟悉从详细设计开始的下游设计及开发工作，本项目是第一次直接面对日本客户，存在许多风险和问题。
1.直接面向客户产生的问题
对日软件外包，我们面对的是日本做上游设计的软件开发公司，以概要设计及详细设计为起点，所以分歧主要是设计与实现方法不一致进而需要修改设计的小问题。在大方向已经确立的前提下，成功的估算和守住交付期限即可得到良好的客户满意度。
对于直接面向客户，我们因为没有需求分析和概要设计先例，可以说基本上是零经验。而客户公司的IT改进部门对系统蓝图的印象模糊，且其要求的系统功能过于宽泛，导致开发团队无法以客户需求为基础进行需求分析。而客户公司存在的问题为，需求来源于不同的部门，且要求实现的层次和程度各有不同，在统一意见和对各部门需求的调查整理工作上看，客户公司的IT改进部门是失败的。这也是他们不愿意甚至不可能积极提供需求和确认需求的原因。在客户IT改进部门的没有提供适当的系统需求的前提下就要求我们的软件开发团队进行作业，则是把负担加在了开发团队的肩上。
2.客户代表（业务经理）的问题
为了解决客户需求没有或不明确的问题，则设立项目主要负责人——项目组的业务经理作为业务代表，主要负责与客户的沟通工作和提供日本客户无法提供的功能的需求。所以很多“虚拟”的和“假定”的需求就被提出出来，但因为这部分需求来源于客户代表（业务经理），所以口口相传没有进行事前记录和整理，这就是引发此次内部矛盾的主因。
3.工程审核问题
因为客户代表提出的需求没有记录，在设计人员进行概要设计和详细设计后，所进行的内部审核也没有客户代表参加，所以设计人员对于需求的出发点就有可能与客户代表（甚至是客户）背道而驰。所以在设计的工程审核阶段，大部分设计被叫停甚至是返工，严重导致了时间的浪费、成本的增加并遭到设计人员因返工而产生的不满情绪。
4.项目团队成员问题
因为长时间从事对日软件外包，就如同被动享受填鸭式教育，使得项目团队每天按任务计划（WBS）做事，不能积极地为软件开发过程作出时间安排和调整。比如，一个子模块的开发时间安排的比较长，而测试时间比较短，作业人员不会自己协调时间，而是“打擦边球”。开发时间长了就在完成开发作业后“休息”，等着测试开始时间的到来，这也为项目的顺利进行带来隐患。
开发人员产生了对上游设计的依赖性。没有良好的上游设计就无法进行作业，这也是工程审核时无法通过的原因。没有积极地试图改进、优化开发过程，而是抱残守缺，缺乏积极向上的态度。
5.（中间）成果物问题
严格地遵守时间进行作业，严格地提交要求的成果物，但是缺少在软件开发过程中制作作为过渡使用的中间成果物的意识。以至上一步作业无法为下一步作业做铺垫，相比之下是浪费了更多的时间。在数据准备方面缺乏前瞻性，不能测试先行，不提整备数据而是使用测试数据进行单体测试，导致发生系统测试时正确数据上马后出现问题的风险。
不知道大家的项目中是否也会出现这样的问题，如果有请写在评论中，如果有好的解决方法也请写在评论中。下一篇文章我会提出我对此项目组工作的改进建议，同时也会整理大家的问题和建议。希望我们能在良好的项目文化和项目管理下工作，让我们的心情更愉悦，让我们更快地成长，让我们的项目能够顺利交付。由此希望大家多提意见，给我更多的力量，谢谢。
m(*^_^*)m
项目存在问题：
本次开发团队的体制调整实际上是因为内部矛盾的激化，一位直线经理和业务经理（客户代表角色、最终成果物审核）因为成果物审核问题产生了争议，最终导致直线经理退出项目组。团队因多年从事对日软件外包工作，熟悉从详细设计开始的下游设计及开发工作，本项目是第一次直接面对日本客户，存在许多风险和问题。
1.直接面向客户产生的问题
对日软件外包，我们面对的是日本做上游设计的软件开发公司，以概要设计及详细设计为起点，所以分歧主要是设计与实现方法不一致进而需要修改设计的小问题。在大方向已经确立的前提下，成功的估算和守住交付期限即可得到良好的客户满意度。
对于直接面向客户，我们因为没有需求分析和概要设计先例，可以说基本上是零经验。而客户公司的IT改进部门对系统蓝图的印象模糊，且其要求的系统功能过于宽泛，导致开发团队无法以客户需求为基础进行需求分析。而客户公司存在的问题为，需求来源于不同的部门，且要求实现的层次和程度各有不同，在统一意见和对各部门需求的调查整理工作上看，客户公司的IT改进部门是失败的。这也是他们不愿意甚至不可能积极提供需求和确认需求的原因。在客户IT改进部门的没有提供适当的系统需求的前提下就要求我们的软件开发团队进行作业，则是把负担加在了开发团队的肩上。
2.客户代表（业务经理）的问题
为了解决客户需求没有或不明确的问题，则设立项目主要负责人——项目组的业务经理作为业务代表，主要负责与客户的沟通工作和提供日本客户无法提供的功能的需求。所以很多“虚拟”的和“假定”的需求就被提出出来，但因为这部分需求来源于客户代表（业务经理），所以口口相传没有进行事前记录和整理，这就是引发此次内部矛盾的主因。
3.工程审核问题
因为客户代表提出的需求没有记录，在设计人员进行概要设计和详细设计后，所进行的内部审核也没有客户代表参加，所以设计人员对于需求的出发点就有可能与客户代表（甚至是客户）背道而驰。所以在设计的工程审核阶段，大部分设计被叫停甚至是返工，严重导致了时间的浪费、成本的增加并遭到设计人员因返工而产生的不满情绪。
4.项目团队成员问题
因为长时间从事对日软件外包，就如同被动享受填鸭式教育，使得项目团队每天按任务计划（WBS）做事，不能积极地为软件开发过程作出时间安排和调整。比如，一个子模块的开发时间安排的比较长，而测试时间比较短，作业人员不会自己协调时间，而是“打擦边球”。开发时间长了就在完成开发作业后“休息”，等着测试开始时间的到来，这也为项目的顺利进行带来隐患。
开发人员产生了对上游设计的依赖性。没有良好的上游设计就无法进行作业，这也是工程审核时无法通过的原因。没有积极地试图改进、优化开发过程，而是抱残守缺，缺乏积极向上的态度。
5.（中间）成果物问题
严格地遵守时间进行作业，严格地提交要求的成果物，但是缺少在软件开发过程中制作作为过渡使用的中间成果物的意识。以至上一步作业无法为下一步作业做铺垫，相比之下是浪费了更多的时间。在数据准备方面缺乏前瞻性，不能测试先行，不提整备数据而是使用测试数据进行单体测试，导致发生系统测试时正确数据上马后出现问题的风险。
不知道大家的项目中是否也会出现这样的问题，如果有请写在评论中，如果有好的解决方法也请写在评论中。下一篇文章我会提出我对此项目组工作的改进建议，同时也会整理大家的问题和建议。希望我们能在良好的项目文化和项目管理下工作，让我们的心情更愉悦，让我们更快地成长，让我们的项目能够顺利交付。由此希望大家多提意见，给我更多的力量，谢谢。
m(*^_^*)m
