1
协作程度
项目复杂度雷达图分析
为什么项目做的这么艰难？到底是哪里难？1、项目难？2、过程难？（前面难、中间难、后面难？）3、人难？事难？或者人难办事难做？分数解释如下1、2、3、5、8采用斐波那契数列，得分越高说明越复杂，需要多加关注。分析如下:1、团队协作得分为5偏高，是因为软件开发是需要团队高度协调行动，在这一块需要重点关注人员，进行团队建设，提升团队凝聚力；2、不确定性得分为5偏高，需重点关注项目风险，目前最大的风险在于人员变动及需求变更及紧急需求插入，因此要注意在开发中间也要不断进行需求确认，如有变动进行快速响应调整，需要考虑时间余量的设置。3、变革性得分3偏低，目前主要是做功能优化迭代，整个系统大的主体功能均已完成，对整体系统的变革性来说不是特别高，因此这一块需重点关注系统的完善性、可用性及可维护性，为系统的长期稳定运营做保障；4、独特性得分为2偏低，就现有团队而言，项目并不是完全没有接触过，或多或少均接触过，在这一块主要关注业务知识的传递交接，业务的跨组别学习；5、跨职能部门得分为8最高，目前所有需求均来自业务部门，且存在多方业务，各个业务部门存在部门墙，无法进行管控，协调困难，且其需求也经常变化，最终均需经过业务部门验收，因此这一块需重点关注交付速度、质量、变更控制；针对目前交付质量差、业务验收进展缓慢（业务方通常无法集中精力进行验收，所以验收均耗时较长）的现状，目前的解决方案如下：1、研发侧：改变现有的开发习惯，每天提交代码，每日下班前各成员需提交一次代码，进行代码集成，避免出现提测或转预发布时解决大量代码合并冲突带来的时间、质量损耗，将合并代码分散至每天，避免最后一刻合并代码带来的巨大损耗及风险。做代码质量审核，提交规范、代码规范审查。2、测试部：分工明确，目前测试部门分工不太明确，职责不够细分，存在测试资源浪费的情况；3、产品部：需仔细梳理需求，与业务部门多次确认与跟进需求变化情况，减少中途需求变更的情况，避免开发中途出现紧急需求，需与业务部门保持频繁沟通。
5
8
不确定性
2
变革性
变革程度
3
团队协作
项目
独特性
跨职能部门
