关于部门分层建议

经验分享

背景

• 基础数据没有一人衔接所有产品需求和技术实现
  
  • 最新暴露出来的问题就是，部分表几个月没有数据也没有，收益率曲线是在林富美电脑上跑的数据，再同步的
• 项目成果共享方式错综复杂
  
  • 指数报告自动化的内容，本来是应用端的，结果其他项目又要公用
  • 普E智选涉及金融数据平台，债券负面舆情，指数报告自动化的数据和文件
• 项目耦合方式错综复杂，东一个把 a 项目界面嵌入 b 项目，西一个把 c 项目调用 a 项目的数据
  
  • 把债券负面舆情嵌入金融数据平台
  • 普E智选调用金融数据平台后台上传的创新产品案例，这部分内容包含数据和文件两部分，需要单独为普E智选设计开发一个和其他项目不同的数据同步功能
  • 未来必然会发生，某一个项目改动，会忘记依赖它的项目同时改动的情况，导致出错
• 责任主体不明确，信息杂乱
  
  • 金融数据平台由多人开发阶段性地负责，发现问题，要层层询问
  • 二号系统每次的经常性的升级都是从黄涛的高强度开发阶段抠的时间
• 应用项目开发的需要前置知识，但前置知识归口混乱，无法找到统一的获取途径
  
  • 普E智选的数据模块，即使开了多次“拉通会”拉通会，也没有获得确切的说明，最后发展到陈丽君和涂敏陪着刘建调 sql
• 部分面向用户的项目，质量和用户体验较差
  
  • 问卷项目每次导数据都要手动，一出现问题就炸锅

分析

工作内容（项目）应分为“应用项目”和“基础数据”

成果共享

项目成果共享，应该在“基础数据”和“业务经验”上。应用项目由于对应的客户不同，应该分别对待，为其量身定制，以提高产品质量。

责任主体划分

为什么2号系统要找到黄涛？相信对这个问题一直有疑惑。

其实，是因为他熟悉业务，而不是因为其他人做不了。现在形成的是把业务分散到不同的开发人员头上。这样其实是不明确的，比如人员变动就会导致这部分业务混乱。

较为合理的方式是，每个项目的业务应该归口到项目经理身上，这样安排其他员工进行参与时，项目经理可以把完成该工作的仅仅是必要的前置背景，结合项目文档给相应员工讲清楚即可。

不同项目的要求和特点是不同的

基础数据的特点和要求：

• 每日监控异常，发现立即修复
• 专人分析质量，对部分质量不高的内容，制定优化计划。对优化工作有记录，有考评。
• 在开发应用项目之前，需要把数据准备到一个质量较高的程度

应用项目的特点和要求：

• 明确的版本和分支的管理（如在版本迭代的过程中，能及时响应生产环境的） bug，同时不影响新功能的开发
• 除了对基础数据进行消费之外，其余数据应该和用户是直接或者间接挂钩，或者为独享型的数据（比如 app 上上传的各项内容，本身样式和内容都是为 app 展示用的，没有设计共享给其他项目）
• 针对用户特点，制定更有针对性的用户策略和用量统计
• 需要颜值高，交互便利，响应速度快
• 针对自己的业务需要，对基础数据进行针对性地加工，以满足特异化地需求

建议

成立基础数据项目组，和应用项目剥离

• 这个基础数据项目组，专门负责全部的基础数据，而这个小组的组长专设产品和项目经理，建议项目经理由胡扶林担任，产品经理由数据部同事担任。对全部的基础数据来龙去脉进行梳理，掌控。
• 其他部门研发的加工后数据，应该交接给该小组进行维护，包含需求的维护和数据的维护。
• 应用项目作为这些数据的消费者，仅仅是在基础数据本身的“更新机制，关联逻辑，数据含义”框架内，进行只读操作。产品经理要使用这些数据，需要向该小组了解清楚其意义。
• 部分数据是某个应用项目率先将要用到，也应该将其分离成两个部分，基础数据项目组前置性地进行开发。
• 历史原因积聚的很多基础数据划分给了应用库的，需要逐步抽离出来交接给基础数据项目组，以满足未来公用的需求。

如图所示，蓝色的基础数据，全部交由该组负责。分配好后，胡扶林可联通产品经理开始展开梳理工作，并向公司产品、it、技术部门提供一套清晰的在线文档(每次改动有版本记录作为依据)，维护在“元数据管理系统”，供查阅。

定期向两位经理进行汇报，避免人员离职时交接不透彻带来地风险。

应用项固定应用项目经理，将开发人员作为流动人力

之前的模式，所有人员疲于应对公司大大小小的项目。同时因为项目经理并非离职性的变动，所以大家没有怎么经过交接。为了尽可能地提高效率，又要争取尽量原班人马来维护。

我提出一个方案：固定项目经理。

具体说明：

• 明确项目经理，除非离职，或彻底改换负责人，否则自始至终地对产品负责
• 针对历史欠账，项目经理对之前该项目不熟悉的内容重头进行专项梳理工作，对多次迭代的，要把文档整体清晰，而不是各个临散的存放。对于基础数据的依赖，要向基础数据小组了解清楚具体的内容。
• 项目经理要比之前更深入地了解各端的大致实现
• 具体每个项目开发时，项目经理向资源池或者其他地方调配人力，能够为新加入的成员，讲清楚其开发所需的，必要的，对应模块的来龙去脉。
• 一位项目经理可以负责两个甚至更多的项目，其实没有问题，只是不同时间点上有侧重

另外，由于应用项目本身牵扯细节多，比如用户和权限策略，交互细节等。本身不适合公用。项目成果的公用，应该停留在基础数据层面。

摈弃之前的“A项目做完了，嵌到B项目里面”的做法，改为“A项目开发完了，他的基础数据，功能逻辑可以复用到B项目当中”。面向用户的项目，必须有较高的质量。

开展后备干部培训计划

轮岗现在没有条件，但是我们可以让组长们，为项目经理讲解清楚各端的情况。

我建议：在接下来相对没有忙的一个月中，面向全部门，展开后备干部培训计划。

主讲人：各组组长，运维
时间：每天下午 5 点，预计持续两周到一个月

草拟的提纲：

• 前端
  
  • 项目的组织形式，运行原理
  • 涉及技术方案，完成一个项目的做了哪些事情
• ui 的工作内容，工作量，配合方式
• 后端
  
  • 项目的组织形式，运行原理
  • 涉及技术方案，完成一个项目的做了哪些事情
• 数据
  
  • 包含的数据有哪些方面
  • 调度服务机制
  • 开展了哪些工作
  • 基于 mysql 日志的同步，刘建开发的数据同步等，数据同步流程和时间点
• 测试工作
  
  • 测试工作包含的有哪些，我们现在做了哪些
  • 测试和开发交流沟通中存在的问题，需要如何配合
• 运维工作
  
  • 打包，部署，发布具体实现方式
  • 公司现有环境，服务器的布局
  • 暴露给开发人员的内容，和开发人员的配合方式
• 各端均有的
  
  • 工作量评估方法
  • 工作质量评价方法
  • 工作痛点，前置依赖有哪些
  • 需要如何管理和保障其工作的正常开展

数据的跨部门协调

产品经理应该按照下图的方式，对数据加以研究，和使用：