总结
每个人都要能讲清楚过去2年坚持的价值，主张（包括对公司：服务+解决方案；对技术、。。。）的是什么？贡献是什么？各自都要准备，团队对团队，体系对体系。不是个人事情，是团队的事情。统一布局，每人负责哪一块（成绩、案例、工程、效率、体系、工作方法）。工资最高，首当其冲，公司是低毛利企业，不要陷入虚幻之中。
第一个，过去2年的总结与复盘，在研发团队管理和经营策略思路上观点是什么？快速交付的方式结合自研迭代
研发质量管控，更严格的标准，自研团队为主，外包辅助；
交付上，我们做了什么，填补了哪些空白，对标市场上，达到什么程度；
项目过程管理，以及复盘，做得不足的要总结和改善，应用情况怎样？
从0到1，以及快速交付两部分，快速内化。
第二个，看未来，未来技术战略及规划，技术发展与业务发展匹配度。本周五，要有一版。
第三个，研发团队整合（或融合）方案，6月份要完成。整合完后，如何评价每个团队的价值产出和交付产出。
过去2年
刚开始主要以搭建团队为主，没有介入具体的项目任务。那时，团队搭建初期，由于人手有限，每个系统都只有几个人，而且那时业务没有太详细的业务规划和系统要求，21年年中业务有过集中业务规划与业务场景梳理，后来也没太多输出；
21年10月开始接手网货项目，主导账户体系设计，以及系统开发交付进度把控，直到现在；关注系统设计，代码质量，测试质量和上线后的运维，不断打磨系统功能，优化系统实现，完善技术备选方案以应对紧急情况的发生；
22年去年8月份开始，接手产品中台，发现那时每新定义一个标准产品，都牵涉到系统好几个环节的改动，要花费大量的工作量。在我的坚持和主导下，重构产品定义，真正实现了配置化，现在业务那边要推出新的标准产品，完全不需要开发；主导系统的设计、架构，以及开发交付进度把控，直到现在；
SRM系统主要为业务辅助系统，平时需求也都由其他项目发起，主要主持系统改造工作，比如拆分服务，优化性能，提高系统可用性和可靠性；
之前经验更多是项目制的交付方式，这边更多是版本化的交付方式，各有优缺点，采用哪种方式主要取决于项目需要和业务方的要求；
对公司经营的思考
目前公司应该从成本控制、提高服务质量（即客户满意度，包括失效、破损率、安全性等）、提供更多增值服务（保险、金融、代收货款等）、优化线路；
产品中台对公司一定是有价值的，未来公司也一定会朝着产品化方向去发展，因为这是物流行业发展的必然趋势；作为公司老板，他一定想看到公司业务各运作环节的成本及收入数据，帮忙决策哪些业务作为战略客户，允许亏钱开展；哪些客户引入毛利率太低，甚至会亏本，不能引入；帮助公司规避运作风险，提高公司业务的利润率；目前业务最重点的工作是打单和逐步规范业务运作，落实各种运作规章制度的执行，将业务引入到线上运营，没有太多精力去产品化和梳理成本明细等细节；未来，这些细节问题一定会被关注和梳理清楚，运作也会更规范和标准；让业务人员不仅仅只需要进行线下运作，通过各种系统功能与操作规范的执行落地，未来业务操作的科技感和技术感会越发明显，真正培养和体现公司的科技实力；甚至成长为物流行业信息化的标杆企业，引领和参与中国物流行业的标准规范制定等；
国家经济发展的三驾马车分别是投资、消费和出口，目前来看都遇到了发展瓶颈；习大大提出的中国一带一路，鼓励各国的互联互通，促进沿线国家间的经济增加和贸易合作，给中国创造大量投资、出口机会，带动中国经济快速发展，物流行业在这个大规划中，绝对是第一批可以享受到政策红利的领域；世界经济大发展，需求增长旺盛，商品大流通，绝对离不开物流。
未来，由现有的合同制物流赚取差价苦力钱，发展到统一标准化、产品化运作体系，运作成本精细化；建立公司在物流行业的品牌和口碑，向其他企业输出完整的供应链行业解决方案+全套系统能力，帮助客户完成数字化能力搭建和转型，构建生态联盟；
如何直控运力，或者触达运力，通过直通宝APP还是太单薄，必须要提供司机或小车队SAAS系统，帮助他们解决日常管理问题和信息化系统建设问题；只有我们先提供能力输出给到他们，他们才会原因提供他们的能力给到我们，实现共赢；
对系统研发的主张
1、核心业务的运营支撑系统逐渐建设完成，底盘系统功能越来越稳定，服务层配合业务变化需要进行适当调整即可，人员投入成本呈现逐年降低到稳定在一个合理水平，支撑系统稳定运行和公司主体业务运作；
2、针对行业运作标准SOP，构建SAAS化的标准系统产品，对行业客户输出整体化的供应链行业解决方案+系统能力，增加用户的粘性，扩大合作客户群体，增加公司营收的同时，扩大公司在行业的影响力和品牌效益；
3、配合公司新业务领域的拓展，或者新的业务模式，搭建新的团队，开发新的业务系统，这块可采用项目制的方式运行，投入规模可按项目立项时确定的目标进行评估和决策；
研发效率的主张
项目制交付和版本方式交付，其实是一样的；版本化只是将整个项目划分为多个阶段，每个阶段归为一个版本，包括单周版本、双周版本和多周版本，主要依据该阶段的需求对应的研发工作量进行评定；是否版本交付，还是项目交付，主要由业务方决定；如果要整体完成才能投入使用，则项目交付，如果可以先部分投入使用，则分版本逐步交付使用；
影响效率的方面包括需求文档是否清晰描述，研发对需求的理解是否达成一致，通过对研发设计或方案的评审，可以拉通达成一致；通过对测试用例的评审，可以再次拉通达成一致；完全达成一致的情况下，研发效率是有保障的；业内也有相关的标准可以参考，比如一个增删改查是3天，还是2天，会因开发人员能力的不同有小许差异，但不会太大；开发能力更多会体现在开发思路、开发设计、开发实现和代码质量上；
工作方法总结
首先，会尽量提前加入到业务方的需求沟通，了解需求的背景和期望达成的目标；
然后，和产品经理一起讨论，实现业务需求的方式，提出自己的思考和见解，和业务、产品一起沟通，形成业务方认可，产品和技术方都认同的方案；
然后，参与需求文档的评审，把控系统整体修改思路，对开发人员提出技术要求；
评审通过，拆分开发任务，依据开发人员手头工作饱和度和熟悉情况，分配开发任务，由开发结合需求文档评估出工作量，最后输出开发计划和测试上线计划；
uat测试通过之后，必须在类生产环境VER再次验证，且要求业务方在VER进行业务验收，验收通过发邮件通知准予发版上线，并确认发版时间，业务方提前在用户群发布停机发版公告；核心功能及主流程，每个版本都要全部测试；尤其核心功能，还需要两个人交叉验证，保证测试质量；
生产发版之后，进行生产验证，确认通过，通知业务方发版成功；
对技术发展的主张
技术没有好坏，只有适合与否；目前公司系统的技术选择没有问题，只是在业务系统的可靠性和可用性，以及基础服务底盘的稳定性，需要进一步的提高；
公司未来可是尝试区块链技术，通过智能合约保障货主权益，完成货权转移和支付场景实现；
公司可以在物联网、人工智能和算法、智能仓储等领域不断探索，但要在投入产出能达到平衡的前提下才有意义；那些都非常烧钱，对业务规模和形态也都有比较高的要求，快递行业的小件标准件更容易适配；
对自己的总结
扎实的技术能力，丰富的项目经验，行业经验，和多年的技术团队管理经验；
不管是项目制的开发模式，还是版本化的开发模式，都得心应手；
比开发看得更全面，更容易抓住问题的本质，给出自己的建议和方案；
平时除了参与需求评审，评估需求的合理性；也会参与到开发设计中，把控开发设计及架构合理性；监督开发人员的代码是否按规范执行；及时跟踪各种问题，是否有人在负责落实和解决，有的比较棘手的生产问题，自己也会直接去解决。
对未来的展望
1、saas系统建设，应该考虑功能的配置化，以及单据状态统一管理的状态机；还有，saas系统应该单点突破，先做一两个轻量级的SAAS系统（订单管理和运输管理），支持最简单的小规模车队运输管理，或者最简单的库存管理功能；对司机、供应商、货主和其他客户，分别提供不同saas系统，解决他们的痛点；还有，SAAS系统一定要坚持移动应用为主，方便使用和推广；
2022年，阿里云776亿，天翼云579亿，移动503亿，联通361亿。可以看出，政企客户对数据的重视和私人定制化，是当今的趋势；
还有SAAS化系统，一定要保证客户数据的安全，加密传输和存储，保护用户隐私；真正做到数据隔离；统一集成调用的三方系统；还有一点，就是可以响应大客户的系统功能定制化服务。
2、平台化运营，以saas系统为抓手，将流量、运力资源引入到平台，撮合交易，收取服务费，运营车后市场服务，提供发票、油卡、保险、金融等服务。
3、物联网技术、自动化、智能化设备等都是好的技术，在未来的物流领域也一定能发挥作用，但要在投入成本与设备收益上达到平衡或盈利才有用武之地。
SAAS化3个阶段
1、数据逻辑隔离；共用同一套数据库和应用服务器，配置参数共享；
2、数据物理隔离；数据库和应用服务器分开部署，独立使用，配置参数独立化；
3、客户现场部署，完全独立，通过系统接口完成授权数据之间的交互与共享；