项目管理-融资租赁业务系统

融资租赁业务系统外购外协（新能源车企的外部沟通，保时捷车企的沟通，易宝通联扣款协议厂商协调，中瑞gps数据厂商维护，跨部门沟通）
技术选型（自主提报系统的技术选择）
技术升级（框架升级，业务代码优化）
二次开发（迭代开发）

项目管理：业务可行性分析，需求评审，改造点梳理，研发工时排期，代码评审，上线管理，产线跟踪

1.工作如何计划开展

做好业务，团队，技术三个方面：
业务：要充分理解业务，不仅理解自己的产品，也要关心竞品，业内趋势，在充分理解业务的基础上，发表自己的看法，确保在大的业务方向上，团队不至于走太多弯路。
团队：  

1）首先要充分了解每个组员，包括大家的专业技能水平与性格特点。
2）针对每个人，要定期的1对1谈话，了解大家对自身、对团队的期望。
3）根据每个人自身的期望，以及你自己对他的了解，结合现有业务，给大家制定合理的目标。可以在定期绩效考评的时候做这些事情。
4）每隔一段时间的1对1谈话中，与之回顾之前目标的达成情况，对他的工作进行评价，提出表扬或改进建议。
5）团队还应该有一些整体的方案用以提升水平，比如培训、技术分享、集体的代码评审会议。尤其是技术分享氛围的建设，应该是要重点关心的。
技术：不停止追求技术进步的脚步，做好团队管理的同时，代码要坚持写，不然失去了对技术细节的了解，很多工作都不好开展。
明白团队的输出最大化才是最终目标，相信大家的技术，及时review代码，必要的时候给予帮助
思考如何提升开发团队的工作效率，积极引入业内领先的技术方案或开发工具，保持团队技术水平不要落后于时代。
关键的技术问题或技术决策上，要积极发挥作用，面对技术债务，也不要退缩保守，鼓励大家积极改进代码质量，要有担当。

2.如何跟外部厂商沟通

提前准备好沟通的安排，安排好会议或者语音，
明确沟通的目的，了解沟通方的需求
通知各个协调的厂商成员
记录好沟通过程的日志

3.跟厂商沟通的遇到的困难怎么解决

1，自身项目成员的沟通问题（沟通阻碍等）
2，分组之间的协作问题（异地办公）解决方法：定点集合沟通
3，信息传递问题（口头承诺、传递错误等）解决方法：沟通渠道、沟通方法
以上案例得出结论，今后我们需要关注以下几点：
1，分析所有利益相关者的沟通需求；
2，确定所有利益相关方的沟通方式，渠道、频率和详细程度；
3，制定详细的沟通计划并有效的沟通项目信息和更新
4，确认沟通是否有效，并收到反馈

4.如何选择相应的技术，选择依据是什么

1.微服务架构与单体架构

微服务架构将一个大型的应用程序分割成许多独立的小型应用，团队可以针对每个服务进行优化和扩展。然而也带来了复杂性和额外的管理开销。
单体架构则将所有功能集中在一个应用中，易于管理和部署，但在扩展和维护大型应用时可能会遇到挑战。

2.前端与后端架构

前端架构主要关注用户界面和用户体验，包括网站、桌面应用程序和移动应用程序。在前端架构中，通常需要考虑响应式设计、用户体验、交互以及跨浏览器兼容性等问题。
后端架构则关注于数据处理、业务逻辑和与数据库的交互等。在后端架构中，需要考虑并发性能、安全性、数据一致性和容错性等问题。
在进行技术选型时，需要权衡前端和后端的需求，选择能够满足两者需求的架构。

3.数据库的选择

数据库在应用程序中扮演着重要的角色，正确的数据库选择可以极大地影响应用程序的性能和可扩展性。以下是一些常见的数据库类型：
关系数据库（如MySQL、PostgreSQL）：适用于需要复杂数据操作（如事务处理、多表关联等）的应用程序。
文档数据库（如MongoDB、Cassandra）：适用于需要快速检索和查询大量半结构化数据的应用程序。
键值存储（如Redis）：适用于需要快速存储和检索键值对的应用程序。
时序数据库（如InfluxDB）：适用于需要监控时间序列数据的应用程序。
在进行技术选型时，需要仔细评估项目的需求，选择最符合项目需求的数据库类型。

4.考虑可扩展性和性能

可扩展性和性能是技术选型中需要考虑的关键因素。团队需要评估所选择的技术是否能够提供所需的性能，以及是否易于扩展和维护。以下是一些需要考虑的因素：
性能测试：在选择技术后，需要进行性能测试，以确保其能够满足项目的性能需求。
扩展性：团队需要评估所选择的技术是否易于扩展。如果一项技术难以扩展，那么可能需要花费大量的时间和资源来重构或替换它。
并行处理：对于需要处理大量数据或请求的应用程序，团队需要考虑所选择的技术是否支持并行处理。
负载均衡：对于分布式系统，团队需要考虑如何实现负载均衡，以确保系统在高负载时仍能保持良好的性能。

5.考虑安全性

安全性是任何技术选型中都不可忽视的因素。团队需要考虑以下因素：
数据加密：在传输和存储数据时，需要考虑如何加密数据以保护敏感信息。
访问控制：需要考虑如何控制对系统的访问，包括用户认证和授权等。
安全审计：需要定期对系统进行安全审计，以确保没有安全漏洞和威胁。

在软件架构的技术选型过程中，我们需要综合考虑多个因素，包括业务需求、技术熟悉度、社区支持、项目需求等。
正确的技术选型可以帮助提升软件的质量、可维护性和可扩展性。在选择技术后，需要进行性能测试以确定其是否满足项目的性能需求。
同时，还需要考虑可扩展性、性能、安全性和可维护性等因素。最后，我们需要定期对技术选型进行反思和总结

5.项目延期风险

一、项目延期的原因分析

项目延期是项目管理过程中常见的问题，其原因多种多样。首先，缺乏明确的项目目标和范围，导致需求频繁变更或者需求理解出现偏差，从而延长项目周期。其次，人为因素，如团队成员技能匮乏、沟通不畅或者决策不及时等，也会直接导致项目进度延误。此外，外部环境的变化，比如市场竞争、政策法规的调整等，也可能成为项目延期的一大原因。因此，项目延期的原因是多方面的，需要全面分析并找出根本解决之道。

二、影响项目延期的因素

影响项目延期的因素包括但不限于需求变更频繁、人力资源不足、沟通不畅、技术难题、风险评估不足等。需要从项目管理的各个环节进行全面审视，包括项目规划、项目执行、项目监控和项目收尾等各个阶段的因素都可能会对项目延期产生影响。因此，项目延期并非单一原因所致，而是众多因素共同作用的结果，需要全面把握以及综合应对。

三、如何建立有效的项目管理计划以应对延期

要建立有效的项目管理计划以应对延期，需要从多个层面入手。首先，项目规划阶段要足够细致，明确项目目标、范围和时间节点，确保项目开展有明确的方向和目标。其次，在项目执行阶段，需要建立严格的项目执行计划，合理分配资源并监控进度，避免资源浪费和进度滞后。此外，项目监控阶段需要建立科学的监控机制，及时发现问题并作出调整。

四、项目延期的风险评估与应对策略

项目延期可能引发一系列风险，因此需要对延期进行风险评估并制定相应的应对策略。风险评估需要综合考虑项目的各个方面，包括时间、成本、质量、人力资源等方面的风险，并针对不同风险制定相应的缓解措施与应急预案，以最大程度减少风险带来的损失。

五、合理调整资源与进度，最大程度减少项目延期对业务影响

针对项目延期，合理调整资源与进度是至关重要的。需要根据项目延期的具体原因，合理调整项目资源的分配以及项目的进度安排，以最大程度减少项目延期对业务的影响。有效的资源调整和进度安排不仅可以缓解项目延期带来的影响，还能够为项目的后续推进奠定更加坚实的基础。

六、总结项目延期应对的关键要点

项目延期是项目管理中常见的问题，需要全面分析其原因和影响因素，并建立有效的项目管理计划以应对延期。针对项目延期的风险评估和应对策略至关重要，而合理调整资源与进度则是应对项目延期所需着重考虑的关键因素。只有全面而科学地应对项目延期，才能最大程度地减少其对业务的影响，确保项目顺利进行。

6.如何拆分系统

提报，签约，合同，签章，请款，销售管理，订单中心，自主提报，配置平台，附件平台，前置系统，字典服务，取消平台   
预审 （app，小程序，人脸，附件扫描）产品中心（渠道，员工信息，产品信息 ，内容管理）    贷前  贷后 （融后管理，gps，结算平台  资方运营，资方 ） 风控  （告警平台，二手车评估，风控，审批，车辆管理平台）

1.微服务易于实现
2.微服务易于维护
3.微服务易于部署
4.微服务易于更新

拆分的原则：

1.单一职责原则  

分层的原则之一就是每一层都是专注于自己所处的那一层的业务功能，每个微服务只专注于解决一个业务功能。通过DDD（是一种解决复杂软件的思维方式，是一种思想；以业务为主导，自顶向下的进行业务领域划分,业务模型驱动架构设计）的指导，可以更加清楚地划清不同业务之间的界限
⒉高内聚

内聚性又称块内联系，是指模块功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的一种度量。若一个模块内各元素联系得越紧密，则它的内聚性就越高。相关的行为都聚集在一起，方便交付功能，部署发版
3.低耦合  

模块间耦合程度的高低取决于模块间接口的复杂性、调用的方式及传递的信息
4.恰当的“微”

微服务也不是越小越好。服务越小，微服务架构的优点和缺点也就会越来越明显。服务越小，微服务的独立性就会越高，但同时，微服务的数量也会激增，管理这些大批量的服务也将会是一个挑战。所以服务的拆分也要考虑场景
5.拥抱变化  

好的系统架构都不是一蹴而就的，而是通过不断地完善、不断地演进而来。

拆分的方法：

1.横向拆分  横向拆分，即按照不同的业务功能，拆分成不同的微服务
2.纵向拆分  纵向拆分，即把一个业务功能里的不同模块或组件进行拆分
3.使用DDD   一个微服务，应该能反映出某个业务的领域模型。使用DDD，不但可以减少微服务环境中通用语言的复杂性，而且可以帮助团队搞清楚领域的边界，理清上下文边界。建议将每个微服务都设计成一个DDD限界上下文（Bounded Context）。这为系统内的微服务提供了一个逻辑边界，无论是在功能还是在通用语言上。每个独立的团队负责一个逻辑上定义好的系统切片。最终，团队开发出的代码会更易于理解和维护。

微服务设计的规范和原则：

单体架构往往以烟筒式方式发展，往往存在两个主要问题：中心化和高耦合。
所谓中心化，就是数据集中存储在单个数据库中，业务系统集中部署在单台服务器上，通过集群部署方式提供服务能力，然而中心化的问题，也就是单点问题。

所谓高耦合，主要是指其中一个功能模块升级，其它的模块都得一起升级。模块依赖度高的本质是架构腐烂。因为本来架构可能就没有设计好，但是，在实际场景中，随着快速迭代开发，研发换了一波又一波，产品走了一茬又一茬，难免系统架构腐化严重。

如果解决单体架构的问题呢？方案很多，主要有：SOA、微服务架构。
SOA（Service-Oriented Architecture，面向服务的架构）是一种高层级的架构设计理念，可通过在网络上使用基于通用通信语言的服务接口，让软件组件可重复使用。SOA 集成了独立部署和维护的服务，并允许它们相互通信和协同工作，以构建一个跨不同系统的软件应用。

如何 做单体架构 到微服务架构的升级呢 ？

1.准备好微服务治理基础设施  

微服务首先需要有微服务基础设施，没有微服务基础设施，实践微服务就是一场灾难。
api网关、服务网关
api管理，流量管理，网关安全，监控日志，协议转换
应用服务树 
业务域，应用管理，服务管理
集成中心
注册中心，配置中心，负载均衡等
监控大屏，熔断监控，链路追踪，告警中心，在线调试
微服务框架
spring cloud  dubbo sdk
日志中心
链路日志，日志查询，日志分析

2.单一责任原则（SRP）

SRP是微服务架构重要的原则。

每个微服务都应该负责一个单一的业务，并确保做好这个业务，这个业务粒度的大小取决于你对业务和架构综合考虑。
SRP能够确保微服务职责单一性、功能完整性拆分， 这样，就便于维护、测试和部署。

3.松耦合原则

什么是松耦合：松耦合是指每个微服务都应该是独立的，并通过API与其他服务进行通信。
松耦合的优势：可以降低 级联故障 的风险，也可以提高服务可扩展性，提高微服务的可复用性。
尽量做彻底解耦，包含数据库层的解耦：
数据库层的解耦，就是避免一个微服务与其他微服务共享数据库，因为这可能会导致数据不一致，并且会使故障排查变得非常困难。
每个微服务也都应该只管理自己的数据，每个微服务都有自己的数据库来存储数据，以确保可扩展性和可靠性。
在设计微服务时，应该专注于创建小型、松散耦合和高度内聚的服务。

4.领域驱动原则，不数据驱动原则，也不是界面驱动原则

DDD是一种软件设计方法，它专注于特定业务领域的软件设计。
微服务架构、微服务设计非常适合采用DDD，为啥呢？
因为每个服务都可以设计为特定业务领域的具体实现。
领域驱动设计，首先应建立领域模型，确定领域限界上下文，然后才进行微服务拆分，

如果是 数据驱动原则/界面驱动原则 ，那么，是一上来就定义数据库表结构，就去调整领域逻辑代码。
领域模型和领域服务应具有高度通用性、稳定性，通过接口层和应用层屏蔽外部变化对业务逻辑的影响，保证核心业务功能的稳定性。
基于领域模型进行拆分，围绕业务领域按职责单一性、功能完整性拆分。

5.架构分层职责明确，严守调用规范，规避 “微服务小泥球”

“大泥球”单体，主要的问题：

代码腐化：业务代码经过长时间的迭代，有很多重复代码。比如一个功能可能有 3,4 种实现。
业务逻辑交织：业务应用经过长时间发展，功能变多，业务功能里的逻辑代码可能相互引用，交织不清。
代码复杂：功能多，业务逻辑复杂，只有少数员工能理解。这也是代码腐化一种。
维护性变差：修改 bug 或增加新功能时，牵一发而动全身。一个 bug 没修好可能导致整个软件不可用。

扩展性变差：增加新功能时，牵一发而动全身
编译发布变长：软件代码量大，编译时长变长，导致发布时长也变长。
化解“大泥球”单体的措施，是微服务架构。微服务架构最基本的一个点：分而治之，由大化小。
松耦合：划分为一个一个小的微服务，代码之间逻辑交织降低。
独立部署：每个划分的微服务都是一个独立的项目，可以独立部署。
编译发布改善：划分为独立的小项目，编译时长变短，发布时长相应变短。
故障隔离：由于划分为一个一个微服务，故障仅发生在独立的微服内。
可扩展性：每个服务可以独立横向扩展，也可以从应用程序中提出独立功能变成服务，扩展变强。
职责单一团队：每个小的微服务都由一个小型的高度专注的团队负责。
技术异构：每个团队可以选择适合该业务的技术。

微服务架构目的就是把一个大单体划分为各种微服务，松耦合，独立自治。
每个小颗粒职责单一，边界明确，可以通过简单组装完成大的功能
严格遵守分层架构原则，上层服务可调用下层服务，下层服务不涉及业务逻辑。如上下层服务需交互，可通过逻辑解耦方式实现，如消息队列或中转
各层职能定位清晰，只能上层调用下层，也就是说只能从外层调用内层服务，下层服务通过封装、组合或编排对上层暴露，服务粒度由细到粗。

微服中，各层职能定位清晰：

基础层为各层提供资源服务
领域层负责领域业务逻辑的实现
应用层负责服务的编排和组合
接口层对外进行服务暴露

6.进行全方位的监控、记录

监控和日志记录对于微服务架构的安全、维护和调优都至关重要。
在拥有数百个微服务的项目中开发的主要困难之一是调试非常困难，因为服务分散、日志分散，很难找到失败的原因。
因此，每个服务都应该有日志记录和监控措施，以跟踪其性能并检测错误。

7.通过CI/CD实现devops （开发运维一体化），提升工程效能

CI/CD是一种软件开发运维过程实践，打通开发和运维环节，实现应用程序的构建、测试和部署自动化。
任何微服务都应该是可持续部署的，实现微服务的快速高效部署，缩短了微服务上线时间。

8.基于业务需求变化频率进行微服务拆分

这是一条扩展原则，是一条针对特定场景的的微服务拆分原则。
分离变和不变， 是 设计领域遵守的一条  核心的原则。
识别变动频繁的业务需求和领域模型，考虑业务变更频率与相关度，将业务需求变动较高和功能相对稳定的业务进行分离。
经常性变动必然会导致代码的频繁修改和版本发布，分离变和不变，可以有效降低频繁变动业务对稳态业务的影响。

9.基于吞吐量进行微服务拆分

这是一条扩展原则，是一条针对特定场景的的微服务拆分原则。
识别领域模型中性能压力较大、高吞吐量的功能，并且进行解耦，解除独立的微服务。
两个好处：
避免高吞吐服务，拖累整个系统的性能， 由于局部的性能拖累整体性能。
解耦之后，可以对高吞吐量服务定制个性化的 扩容缩容策略、熔断保护策略、限流策略。

10.基于技术异构因素进行微服务拆分

这是一条扩展原则，是一条针对特定场景的的微服务拆分原则。
领域模型中有些功能虽然在同一个业务域内，但在技术实现时可能会存在较大的差异，也就是说领域模型内部不同的功能存在技术异构的问题。
比如，在尼恩的go+java 双语言云原生架构实操中， 有的可能用go，有的则是 Java，当然，还有的微服务用大数据架构。
所以，对于这些存在技术异构的功能，可以考虑按照技术边界进行拆分。

7.主要工作

项目管理：业务可行性分析，需求评审，技术讨论，改造点梳理，研发工时排期，进度跟踪，代码评审，上线管理，产线后续跟踪
敏捷管理：关键词：冲刺周期（迭代周期2-6周），业务需求，开发任务，需求列表，每日站会，评审会，燃尽图（任务进度跟踪），版本发布
（迭代前）流程：客户市场调研，功能提出，产品负责人提出产品功能列表，计划会（需求评审），创建迭代任务，拆分任务，估计工时，排优先级，规划迭代
（迭代中）开发：任务记录花费，跟进缺陷，代码检查，多版本发布
（迭代中）测试：记录缺陷，测试用例，用例评审，测试优先级，测试重点
（迭代后）上线后：回顾会，周报创建，问题回顾，缺陷统计，项目走势，迭代进度
敏捷开发（Agile）是一种以人为核心、迭代、循序渐进的开发方法。
优点：敏捷确实是项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版的产品。敏捷注重市场快速反应能力，也即具体应对能力，客户前期满意度高。
缺点：但敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。需要项目中存在经验较强的人，要不大项目中容易遇到瓶颈问题。

在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
简单地来说，敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。

敏捷开发流程的8个步骤包括：

1、目标制定，目标对齐：通过市场调研、业务思路、风险评估制定公司规划和目标，根据这一目标产生所有部门的目标并实现对齐；
2、产品规划：产品研发部门根据目标制定产品关键路线图，这个路线图中分布着不同的产品特性和其完成时间；
3、组织产品待办列表：产品规划产生的需求、客户需求、市场人员收集到的缺陷等将组成产品待办列表；
4、需求梳理：然后产品负责人(Product Ower)对这个列表进行梳理，并在需求梳理会(Backlog Grooming Meeting)讲解具体每一个需求，团队成员根据需求的复杂程度评估每个任务的工作量，输出本次迭代的待办事项列表，完成优先级排序等工作；
5、迭代规划：通过Sprint计划会，明确要执行的工作、冲刺目标等，
6、迭代开发：期间会进行每日站会、性能测试、CodeReview、Demo、测试等工作；7、Sprint评审：由每个任务的负责人演示其完整的工作，由PO确定Sprint目标是否完成，版本什么时候对外发布，新增bug的紧急程度等等。
8、开回顾会议：回顾会议由Scrum团队检视自身在过去的Sprint的表现，包括人 、关系、过程、工具等，思考在下一个Sprint中怎么样可以表现得更好，更高效，怎么样可以和团队合作地更愉快。
技术：
其他：技术分享，业务归纳

8.自我评价

核心经验

- 最重要的“岗位方向"和“行业经验”,比如说，“超过10年”，“互联网运营经验”，“行业覆盖电商”，“互联网教育”；
在融资租赁行业担任java开发
重 点 产 出 \color{#FF7D00}{重点产出}重点产出
就是你对突出的“成绩”和“工作价值”，比如说，“曾带领团队”，“实现业绩3xx增长”，“单日GMV超过200万”；

关 键 技 能 \color{#FF7D00}{关键技能}关键技能
- 是你掌握的“硬技能”和“软技能”，比如说“掌握互联网线上运营全流程”，“擅长数据分析”，”有很强的项目推进能力“和“协同能力”；

工 作 风 格 \color{#FF7D00}{工作风格}工作风格
- 这里工作风格要和你的”目标“公司和”岗位“相匹配的，比如说你要想加入一家创业公司，你可以写”持续保持创业心态“和”学习动力“，“有加入创业公司的决心”；

9.为什么选择贵公司
贵公司是绿色交通跟科技产融的引领者，发挥产融服务价值，聚焦科技驱动，数字驱动，创新驱动，敢为天下先，引领环保、便捷、高效的综合智慧交通新变革。
属于行业的龙头公司，业务范围广泛，有更高的平台，对于个人是更好的发展空间,并且 公司的企业价值观我也非常认可，不甘于平庸，为了梦想和事业拼尽全力，乐观并且坚强的面对问题和挑战，永远保持信心有足够的定力，我们也要拥抱变化，创新的开展工作，实事求是，踏实认真发扬实干精神，钉子精神，以创造价值为准绳，高质量交付成果

10.优点跟缺点

11.系统功能改造要点

数据查询卡顿问题 原因（由于订单量长期积累，导致表数据过多，查询较慢）
合同配置代码流程繁琐，配置化升级
单点项目到微服务项目改造 接口拆分改造
厂商签约对接功能改造（初始开发代码繁琐，且不易新增厂商，代码改动量过大）使用工厂设计模式，接口 将每个厂商抽象出来，每次新增厂商只需要重写一下接口就好
新能源业务剥离改造 （新能源项目对原有项目代码侵入性太强，不易开发维护，耦合度太高）采用责任链模式新开发出一个微服务单独对接新能源厂商

12 项目中遇到的风险
 

1.需求

需求变更导致的项目计划变更风险

1. 提前制定详细的需求变更流程。
2. 在项目开始前，制定严格的需求变更评审机制，比如增加审批环节。
3. 避免频繁的需求变更，如果必须变更，尽可能在项目早期变更。

2

需求变更导致的测试用例追加及测试工作变更风险

1. 在需求变更时，同步更新测试用例。
2. 测试团队应与开发团队密切沟通，以便及时调整测试计划。

3

产品规划和定位不清晰

1. 在项目开始前，进行充分的市场研究，明确产品规划和定位。
2. 制定明确的产品路线图。
3. 提高与干系人的沟通和交流，确保产品定位的理解一致。

4

干系人对需求的决策时间较长

1. 提高需求决策的效率，可以设立固定的需求评审会议。
2. 尽早与关键干系人接触，了解他们的需求和期望。

5

频繁添加额外的需求，产品规模比估计的要大

1. 在需求收集阶段，进行详细全面的需求分析。
2. 避免在项目中途添加新需求，如果有新需求，应按照需求变更流程进行处理。

6

需求不清晰，产品定义含混的部分比期望需要更多的时间

1. 制定详细的需求文档，并经过多次评审。
2. 定期与干系人进行沟通和确认，确保需求的明确和清晰。

7

需求涉及到模块重构导致额外工作量

1. 在项目开始前，评估需求涉及的模块重构工作量。
2. 在计划中预留足够的时间用于模块重构。
3. 采用模块化设计，降低模块间的依赖。

8

涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多

1. 在进入新领域前，进行足够的技术调研。
2. 提前对项目时间进行合理预估，考虑学习新领域的时间。
3. 可以寻求外部专业团队的支持和帮助。

9

开发额外不需要的功能(镀金)延长了计划进度

1. 避免镀金，聚焦核心需求。
2. 提高团队的需求理解和产品思维，避免不必要的开发。
3. 确定需求时，应考虑产品价值和开发成本。

2.人员

10

项目人手不足

1. 预测需求：在项目开始之前，基于项目规模和复杂性预测所需的人力资源。
2. 确保冗余：预留一定的人力冗余以应对突发情况。

11

招聘人员所花时间比预期的长

1. 预期需求：预测可能需要的角色和技能，提前开始招聘流程。
2. 优化流程：创建和维护有效的招聘流程，如筛选、面试、评估等，以加速招聘。

12

项目结束前有人离职

1. 激励机制：提供一定的激励机制以留住人才。
2. 备份计划：在关键岗位上进行人员的备份和交叉培训。

13

新入项目成员，额外的沟通成本

1. 明确角色：为新员工明确定义他们的角色和任务。
2. 建立沟通机制：例如定期会议、项目管理软件等，以减少沟通成本。

14

有问题的成员拖慢团队效率

1. 及时反馈：对问题成员给予及时的反馈和指导，帮助他们提高效率。
2. 调整团队：必要时可以考虑调整团队组成。

15

项目缺乏关键核心人员

1. 确定关键岗位：在项目开始时确定关键岗位和所需的技能。
2. 培训或招聘：对现有员工进行培训或招聘新员工来满足需求。

16

关键人物只能兼职参与

1. 充分利用：最大限度地利用关键人员的时间和技能。
2. 分摊任务：将关键人员的部分任务分摊给其他员工，减轻他们的负担。

17

没有找到项目急需的具有特定技能的人

1. 内部培训：针对特定技能进行内部培训。
2. 寻求外部帮助：如通过外包或聘请顾问。

18

任务的分配与人员技能不匹配

1. 明确技能：明确每个员工的技能和优势。
2. 灵活分配：根据员工的技能和优势分配任务。

19

新人太多，学习上手时间长

1. 系统培训：提供系统的培训和指导。
2. 伙伴制度：为新员工分配经验丰富的伙伴，以帮助他们快速上手。

3.流程

20

缺乏必要的标准规范，增加了工作失误与重复工作

1. 制定标准：为各个工作流程制定详细和标准的规范。
2. 培训员工：对员工进行培训，确保他们理解并遵守这些标准。

21

文档工作多影响进度

1. 优化文档工作：只创建必要的文档，避免过度文档化。
2. 利用工具：使用文档工具来加速文档的创建和更新。

22

进度跟踪不准确，导致无法预知项目是否已落后于计划进度

1. 实施跟踪：采用有效的进度跟踪工具和技术，如甘特图或看板。
2. 定期检查：定期检查项目的进度，并进行必要的调整。

23

任务描述信息不够，导致沟通成本高

1. 完善任务描述：在分配任务时，提供完整和明确的任务描述。
2. 提高沟通效率：采用高效的沟通工具和方法，减少沟通成本。

24

变更管理不能及时跟踪记录，周知各端开发和测试

1. 制定变更管理流程：包括变更的提出、评估、批准和实施。
2. 提供变更信息：将变更信息及时通知给所有相关人员。

4.计划

25

计划是“最佳状态”(但不现实，只能算是”期望状态”)

1. 实际预测：在计划时充分考虑可能出现的问题，使计划更接近实际情况。
2. 定期调整：在项目执行过程中定期对计划进行调整，以适应实际情况。

26

计划遗漏了必要的任务

1. 任务明细：在计划时，对任务进行详细的分解，尽可能减少遗漏。
2. 定期检查：在项目执行过程中定期检查是否有遗漏的任务。

27

工作量远大于估算

1. 准确估算：采用有效的估算方法，如专家判断、类比估算等，提高估算的准确性。
2. 调整计划：如果发现工作量远大于估算，及时调整计划。

28

没有预留缓冲时间(学习，评审，分享等)

1. 预留缓冲时间：在计划时预留一定的缓冲时间。
2. 制定学习、评审、分享等活动的明确计划。

29

任务分配不合理，工作量不均衡

1. 公平分配：在分配任务时，考虑到每个人的能力和工作量，公平地分配任务。
2. 定期调整：在项目执行过程中定期调整任务分配。

30

加班过多影响效率

1. 有效管理：有效管理工作时间，避免不必要的加班。
2. 提高效率：通过优化工作流程、提高技能等方式，提高工作效率，减少加班。

31

先决条件的任务不能按时完成，影响后续任务

1. 明确先决条件：在计划时明确任务的先决条件。
2. 提前开始：对有先决条件的任务提前开始，以防止延误。

32

目标日期提前，但没有相应地调整产品范围或可用资源

1. 重新评估：如果目标日期提前，重新评估产品范围和资源需求。
2. 调整计划：根据重新评估的结果，调整项目计划。

33

人员休假影响

1. 预测需求：在计划时考虑到人员休假的影响。
2. 备份计划：对关键岗位进行备份和交叉培训，以应对人员休假的影响。

34

节假日前后请假多，效率降低

1. 充分计划：在计划时充分考虑到节假日前后可能请假的情况。
2. 提前准备：在节假日前后，提前完成或安排更多的工作，以应对效率的降低。

5.沟通

35

跨团队协调管理，沟通链路过多

1. 设定明确的协调角色：确定一个或几个关键人员负责跨团队的沟通协调。
2. 利用有效的沟通工具：比如共享文档、项目管理软件等，降低沟通复杂性。

36

缺乏激励措施，效率打折扣

1. 设定激励机制：比如设定项目目标完成奖励、优秀团队成员奖励等。
2. 提供成长空间：提供更多学习和发展的机会，激励团队成员提高工作效率。

37

项目成员间有冲突，导致信息沟通不到位

1. 建立冲突解决机制：比如定期团队会议，让团队成员有机会表达和解决冲突。
2. 提供冲突调解：如果需要，找专业的人力资源或团队建设专家提供冲突调解。

38

沟通方式信息传递方式不明确不统一

1. 制定沟通规范：明确沟通方式、信息传递方式，并让所有团队成员都知晓。
2. 培训团队成员：对团队成员进行沟通规范的培训，确保他们都能遵循。

39

对其他外部依赖沟通不到位

1. 确定关键接触点：找出外部依赖的关键接触点，并建立稳定的沟通机制。
2. 制定沟通计划：制定与外部依赖的沟通计划，并确保按计划进行沟通。

6.技术

40

复杂的技术调研选型时间长

1. 确定专业人员进行调研：专业人员可以更快更准确地进行技术调研。
2. 建立技术库：建立技术库，记录以往项目的技术调研和选型经验。

41

开发环境不稳定导致联调延期

1. 维护稳定的开发环境：定期对开发环境进行检查和维护。
2. 备用环境：准备备用环境，以防主要开发环境出现问题。

42

线上紧急问题修复影响当前开发进度

1. 预防：优化代码和设计，减少线上问题的发生。
2. 快速响应：建立紧急问题快速响应机制，快速修复线上问题。

43

上线计划不完善

1. 制定完善的上线计划：包括预上线检查、上线步骤、备份和回滚计划等。
2. 上线预演：在真实上线前进行上线预演，检查上线计划的完善性。

44

测试环境问题影响测试进度

1. 维护稳定的测试环境：定期对测试环境进行检查和维护。
2. 测试环境备份：定期备份测试环境，以防测试环境出现问题。

45

研发提测质量低于预期影响测试进度

1. 优化开发过程：优化代码和设计，提高开发质量。
2. 开发自测：要求开发在提交测试之前进行自测，降低提测质量低于预期的风险。

46

设计有逻辑漏洞导致返工

1. 设计评审：设计完成后进行设计评审，发现和修正设计漏洞。
2. 代码审核：在开发过程中进行代码审核，发现和修正设计漏洞。

47

方案设计评审不够，设计存在漏洞和问题

1. 设计评审：进行充足的设计评审，确保设计的质量。
2. 邀请专家参加评审：邀请领域内的专家参加设计评审，利用他们的专业知识找出设计的漏洞和问题。

48

对技术难点调研评估不足

1. 充足的技术调研：对技术难点进行充足的调研，准确评估技术难度。
2. 请教专家：如果自己无法评估技术难度，可以请教相关领域的专家。

49

code review 未能提前发现代码问题

1. 强制code review：在提交代码前强制进行code review，降低代码问题的风险。
2. 培训：对开发人员进行code review的培训，提高他们发现代码问题的能力。

50

开发自测不充分

1. 强制自测：在提交测试前强制开发进行自测。
2. 自测培训：对开发人员进行自测的培训，提高他们的自测能力。

51

代码管理不到位

1. 代码版本控制：使用版本控制系统，如Git，对代码进行管理。
2. 代码管理规范：制定代码管理规范，比如合并请求、分支管理等，并确保所有开发人员遵循。

52

测试难度和复杂度未提前充分考虑

1. 测试计划：在项目开始前制定详细的测试计划，充分考虑测试难度和复杂度。
2. 测试设计：在开发过程中进行测试设计，发现并处理可能的测试难度和复杂度。

53

部署过程不熟悉导致过长时间

1. 部署文档：制定详细的部署文档，提供部署步骤和注意事项。
2. 部署培训：对负责部署的人员进行培训，使他们熟悉部署过程。

7.外部依赖

54

外部依赖接口没有按承诺交付

1. 提前沟通：尽早与外部依赖方沟通接口需求和交付时间。
2. 合同保障：在合同中明确接口交付的时间和质量，以便在出现问题时有法律依据。
3. 寻找备用方案：寻找其他可替代的外部接口，以备不时之需。

55

外部依赖产品不稳定，有问题

1. 测试：在依赖外部产品前，进行足够的测试，确保其稳定性。
2. 技术支持：要求外部产品提供技术支持，以便在出现问题时能够快速解决。
3. 寻找替代产品：在市场上寻找其他可替代的稳定性更好的产品。

56

外部合作关系难以预期

1. 明确合作关系：在合作开始前，与合作方明确合作关系，包括权责、利益分配等。
2. 维护关系：定期与合作方进行沟通，解决在合作过程中可能出现的问题，维护良好的合作关系。
3. 风险备案：提前评估可能的风险，制定应对措施。

57

其他

服务器没有及时到位

1. 提前采购：根据项目需求尽早开始采购服务器。
2. 备用方案：准备备用服务器或云服务以防止服务器延迟。
3. 与供应商保持沟通：持续跟踪服务器的到位情况，确保其按计划到达。

58

移动端设备机型不全面

1. 设备采购：提前进行设备采购并测试以满足测试需求。
2. 利用模拟器：在设备不全的情况下，可以使用模拟器进行部分测试。
3. 与合作伙伴合作：借用或租赁合作伙伴的设备进行测试。

59

法律法规

1. 法律咨询：寻求专业法律咨询，确保项目符合所有相关法律法规。
2. 持续关注：持续关注相关法律法规的变化，以便及时调整项目策略。
3. 法律培训：对项目团队进行法律培训，提高他们的法律意识。

60

技术大趋势

1. 保持学习：鼓励项目团队关注并学习最新的技术趋势。
2. 技术研究：定期进行技术研究，以便选择最适合项目的技术。
3. 技术升级：如果必要，可以考虑进行技术升级以跟上技术趋势。

61

商业模式

1. 市场研究：进行市场研究，了解和分析不同的商业模式。
2. 商业模式设计：根据项目需求和市场情况设计适合的商业模式。
3. 持续调整：根据市场反馈持续调整商业模式，以求最大化项目收益。

62

市场竞争

1. 竞品分析：进行竞品分析，了解竞争对手的情况。
2. 市场定位：明确自身的市场定位，找准竞争优势。
3. 竞争策略：制定和执行有效的竞争策略，以应对市场竞争。