基金运营项目管理
作者：核心和客户平台-运营项目组
目录
目录... 1
前言... 2
一、敏捷管理与实际情况的结合... 3
1.1 敏捷项目管理的角色定位... 3
1.2 公司的扁平化管理上的需求... 3
二、高绩效团队... 4
2.1 团队的氛围... 4
2.2 团队构成... 4
2.3 团队成员职责... 4
2.4 人员的培养... 5
三、产品研发... 6
3.1 产品的研发过程... 6
3.2 原始需求与业务分析... 6
3.3 价值的挖掘... 7
3.4 范围的确定... 7
3.5 原型的重要性... 8
3.6 项目规划... 8
四、迭代开发的管理... 10
4.1 任务的拆解... 10
4.2 执行与过程管控... 10
4.3 自组织团队... 11
尾声... 13
前言
本文是我们运营项目组2019年做项目经历的一些思考和心得体会。在公司工作6年余，着实经历过一些艰难的项目，团队的成员通过勤奋努力加班加点，最终都完成目标。结果是好的，但是我一直在思考一个问题，是否有其他方式，能够高效的完成目标。我的思考是：个人的能力之外，还需要团队协作的赋能，团队良好的协作，才能使团队产生1+1>2的效果。
文章中，项目的场景与案例，来源于“运营管理系统”与“BPM流程管理系统”两个项目，所有的观点和原则，是我和运营项目组，在公司的大环境下结合敏捷项目管理摸索出来的经验，不是最好的，只是我们这么做了，效果还不错。希望大家能够提出更多的想法和建议。
一、敏捷管理与实际情况的结合
1.1 敏捷项目管理的角色定位
Product Owner（产品负责人）产品需求的提炼、条目化、优先级排序。产品负责人是产品的指路人，必须对产品有长远的规划和深入了解。
Scrum Master负责维护Scrum方法的秩序，并协助解决非技术问题。Scrum Master工作主要依靠个人领导力，协助、服务于整个团队,类似于传统的项目经理。Scrum Master保留了原有的管理和职业技能，但弱化了任务指派、下达时间指令等内容，增强了其组织协调的能力。具体工作主要靠高素质的团队成员自主驱动完成。
这样，如果团队内部推广Scrum方法，项目经理熟悉、使用之后，精力可以得到释放。可以同时负责多个项目，完成向全职Scrum Masterr的转变。
1.2 公司的扁平化管理上的需求
让我们看一下PMI给出的项目经理能力模型，这是传统的项目经理的能力三角，敏捷项目管理中淡化了项目经理的概念，增加了PO与SM的角色定位。
图1-1 项目经理能力三角
以往团队结构，每几个开发人员和测试人员之间，都会有一位项目经理。专注敏捷开发的Scrum团队，不需要像过去那样监督和控制个体，所以项目经理的职能变得弱化。当然了，并不是不需要项目经理了，其中
侧重管理的项目经理转型为Scrum Master；
侧重业务的项目经理转型为Product Owner；
侧重技术的项目经理，开始做回他们的老本行——开发、测试、建立标准和培养创新，最终成为技术大牛、测试专家、业务专家、资深权威或架构师。
二、高绩效团队
2.1 团队的氛围
信任、尊重、协同。
信任，“疑人不用，用人不疑”，高绩效团队彼此信任，分配的任务不需要担心是否能按时完成，或者完成的工作质量如何。信任是通过工作过程的良好反馈逐渐建立的，每次任务的分配，任务是否清晰，完成标准是否一致，工作者是否具备完成任务的资源，过程是否需要指导?这些问题，是团队安排任务需要思考的问题。团队对成员负责，成员就会对任务负责。
尊重，尊重是取得合作的前提。每个人都有自己的处事观、处理方法，高绩效团队不会因价值观等不同而强制性要求团队成员都要按照自己的想法、做法。每个人的技能栈不同，能力背景不同，要懂得换位思考，发挥团队成员的优势。另外，“外包”是现行的人力资源补充的一种模式，要给予“外包”形式的团队成员以尊重，考虑他们的感受，关注他们的发展，真诚对待，会获得一个负责任的，高产出的团队成员。
协同，通过有效沟通，每个团队成员相互理解，了解平时遇到的难题，是否能找到有效的方法进行解决，帮助团队成员更加高效的完成工作。在工作中，会遇到各种障碍，团队间的工作咬合，内部团队成员的相互任务的依赖等等。协同工作，才能使工作效率最大化。
2.2 团队构成
139团队，就是1个产品项目负责人（Product owner），一个（兼/全）职的Scrum Master，3个领域负责人（Team leader），9个团队成员（Team member），领域负责人管理各自管理<=3个左右团队成员。具体的细节交由各域负责人处理。这样就方便团队进行敏捷开发。
团队是虚拟团队，人员数量不是固定的，职责是交叠的，责任是团队赋予的（不是公司层面的授权），每一领域根据实际资源需求情况，来合理分配团队成员。比如项目负责人，可以为某一领域负责人。我们团队的领域，分为业务、开发、测试。
2.3 团队成员职责
产品项目负责人（PO）：
负责与利益相关方打交道，提炼需求，按照需求的价值以及紧急程度安排优先级。PO一个角色，对产品和项目负责。PO需要有一个清晰的项目目标实现路径。产品代办列表（Product backlog）上的每一项，是需要项目负责人确认的，每一个用户故事（User story）是需要PO定义目标标准的。权利越大，责任越大，PO需要对项目和产品的最终结果负责。要具备协调，统筹，破障能力，解决项目中遇到的各种问题。
领域负责人（TL）：
对负责的领域负责，开发负责人对开发任务的进度，代码质量负责。测试负责人对产品的业务符合度，产品的质量和稳定性负责。业务对需求负责，对于团队商定的目标负责。
团队成员（Team member）：
首先需要说明的是，团队成员包含产品与项目的负责人，包含领域负责人与具体领域的团队成员。团队成员对任务结果负责，按时，保质，保量完成既定工作。
另外，对于团队成员，及时反馈是项目负责的表现，我们鼓励反馈。任务工作遇到问题需要及时反馈出来，避免任务的延迟。团队成员，是项目执行的最小单位，是具体执行者，具体做事的人能够发现项目中的细节风险，与项目的障碍点，把这些及时反馈出来，对项目目标的达成，有非常积极的作用。
2.4 人员的培养
对团队成员的基本要求，包含专业技术能力，与工作态度两个方面。专业技术能力，能决定团队成员走的快慢，而工作态度是能决定团队成员走的多远。我们认为“态度”是选人用人的最优先考虑的因素。
对于团队成员的能力，可以简单划分为四类:
1. 需要被指导的。
2. 可独立工作。
3. 可提供指导的。
4. 可独挡一面的。
需要被指导的，一般指的是新手。新人造缺陷的速度远远超过造代码的速度，我们经常开玩笑说: “改一行错十行”。但是，现实情况是，由于种种原因呢，我们不得不使用新手。所以新手工作，我们要提供适当的指导，并且做好审核工作，避免由于新手能力问题，影响整体项目目标。新手如果出现工作问题，负责指导的“师傅”，负主要责任。
可独立工作，这里的独立工作，指“可独立工作”而非“应独立工作”。独立工作是件很危险的事情，容易形成信息孤岛。也容易使团队成员产生懒惰心理，每个人都希望被关注，工作被认可。团队成员的能力互补是很重要的，能避免项目在关键节点因为某个团队成员的意外情况导致项目目标的较大偏离。
可提供指导的，需要有很强的业务方面的要求，而不再限于技术，因为他们要经常参加对外的交流活动；此外，所做出的决策往往不是基于技术，而是也要基于业务。要找到既懂业务又懂技术的人很难，因此可以选择技术高手，但要要求他学习业务。其实工作年限比较久的程序员都会隐隐地意识到，领域的经验已经开始胜过技术经验。
可独挡一面的，要对业务的重视超过技术的人来担当，否则整个项目团队，都可能以光速南辕北辙。此外如果团队成立足够长，他应该是从“可提供指导”级别提拔过来的这个级别基本上就是产品经理/项目经理的高度，也就是敏捷管理的PO的高度。
最后一个级别的人非常难找，也很难培养。项目的成功与否，此级别的人往往起到至关重要的作用。
项目团队在形成时，尽量选择第2级别以上的人员。但是我们不应该放弃任何一个团队成员，可以放弃的团队成员，首先就不应该选入团队。对团队成员提供必要的指导，明确任务目标，责任，承认团队成员的价值。对团队成员的个人成长负起责任，往往能收获一个负责人的，高产出的团队成员。
三、产品研发
3.1 产品的研发过程
在产品的研发周期上，我们希望，能够重视迭代开发前的几个步骤(见图2)。原始需求是输入，经过“业务分析”，“价值挖掘”，“范围确认”，“产品原型”几个阶段，来完成我们的项目目标。其中，项目的目标，是与内部客户等利益相关方达成一致的，这样可以保障项目目标达成后的实际效果。
图2 产品研发过程
其中，有三个关键点：
可交付的成果，一般是指可上线的系统。也可以是每个迭代结束后的可演示的成果，也可以是与内部客户与利益相关方商定的具体的可度量的目标。
业务与IT共赢，业务端需求与IT建设目标与价值的协同，相互配合，既考虑项目的当前利益，又考虑项目的长期收益，在两者中选择合适的利益权衡点。
关键在抓每个阶段的交付物，每个流程中，留下的文档材料，对后期工作有非常大价值，是项目良好运作的基础。
3.2 原始需求与业务分析
原始需求，作为我们进行分析的最初材料，我们可以此为“自下而上的业务分析”基础。但是，我们也要有“自上而下业务架构”的理念。原始需求是点，IT系统建设是从业务整体视角去思考建设方向。
我们梳理了很多材料，为了方便展示整个基金运营过程，汇总了“基金运营的5大过程6大业务维度”，（详见图3）。体业务点的展开，可以查看项目归档的相关文件。
图3 基金运营的5大过程6大业务维度
3.3 价值的挖掘
三个目标价值： 安全运营，高效运营，服务化运营。
图4 价值挖掘
安全运营:
依靠风险控制模型，以及业务场景的流程管理等，来管控风险。降低风险发生概率，减少风险发生后的影响。
高效运营：
依靠BPM项目，打通系统中各个环节的障碍，为运营的数字化，自动化建设努力。节省运营成本，降低运营过程中发生系统问题的损失。
服务化运营：
为集团化运营打好基础，打造运营场景化，业务流程化，过程数字化系统。为服务输出做准备。
3.4 范围的确定
自上而下的业务架构设计，是系统持续建设的基石，使系统建设具有前瞻性，连续性。此业务架构图（图5运营业务架构图），绘制于2018年10月。整个运营系统建设是围绕着这个思路展开。系统以工作过程管理（BPM）与风险控制模型（RMM）为两大核心支柱，对运营系统的流程，风险保驾护航，建立基金运营安全高效的护城河。
图5 运营业务架构图
3.5 原型的重要性
产品原型，帮助业务与IT人员，在项目前期能快速的理解业务。并能在项目开始前，稳定业务需求，使业务与IT就要达成的目标达成一致。对项目的稳定推进，起到了积极作用。另外，业务流程的流程图，对开发，测试，业务等各个方面，在业务流程的理解上起到了非常积极的作用。
3.6 项目规划
项目规划，是在项目启动时，制定的项目进度节奏，明确约定了项目进展的阶段，以及每个阶段的可交付成果。每个项目阶段，需要定义一个或者多个里程碑事件(图6)，项目规划可以在业务分析，价值挖掘，范围确定的过程中根据实际情况，与客户及利益相关方商定微调。有了项目的规划，能让项目所有相关方对项目的目标达成一致。
图6 BPM项目规划及里程碑
BPM项目规划及里程碑，详细描述见下表。
阶段 |
主要任务 |
启动时间 |
预计交付时间 |
业务预研 |
一、完成业务调研，需求分析 |
2019.06.30 |
2019.09.01 |
第1迭代 |
一、完成B类-业务运营类流程BPM页面原型设计、前后端技术框架搭建、流程引擎及状态机开发工作； |
2019.09.10 |
2019.12.01 |
第2迭代 |
一、完成B类-业务类流程P001-P014及相关引申流程开发（包括：参数流程、产品发行、分红、一对多开放、清盘等）等开发工作； |
2019.10.14 |
2020.01.01（第2.1迭代蓝色部分） |
第3迭代 |
一、完成其他流程及开发； |
2020.02.03 |
2020.04.01（业务部分功能） |
表1 BPM项目规划及里程碑
四、迭代开发的管理
4.1 任务的拆解
在具体业务场景上，使用“用户故事”来理解需求；在偏技术与框架与的任务上，使用开发任务分解模式。以BPM系统为例，在任务分工上，1.分为前端开发（UI）；2.中台业务逻辑；3.后台流程中心；4.流程引擎；四个部分。
举一个用户理解需求的案例：
作为TA运营人员, 我想要在完成产品发行工作时能够从上游PDM(产品管理平台)提取产品信息数据, 以便于减少录入工作。
以这样的描述来理解需求，就很明确BPM与PDM系统对接的重要性。但用户故事也有在描述比较巨大的业务场景时，存在着一些障碍，所有我们辅助以“业务流程图”，“产品原型图”等工具，以及一些描述业务的电子表格，比如《0101.P001业务通知要素》、《0102.部门角色定义》、《0109.募集账户设置》等等文字材料，详见项目管理过程文档。
再举一个偏技术的任务拆解案例（表2）:
序号 |
模块 |
任务项 |
责任人 |
1 |
流程引擎 |
流程发起接口 |
wangy |
2 |
流程引擎动作接口 |
wangy |
|
3 |
流程引擎结束接口 |
wangy |
|
4 |
流程引擎接口代码重构 |
wangy |
|
5 |
引擎调用封装 |
库表改造 |
zhuyg zhuyg |
6 |
流程设计 |
||
7 |
流程改造实现 |
zhuyg |
|
8 |
流程与引擎接口调试 |
zhuyg |
表2 流程引擎任务拆解
4.2 执行与过程管控
迭代执行的过程管控，主要抓5个会议“需求评审会”，“迭代启动会”，“交付演示会”，“迭代总结会”，“每日站立会”。
需求评审会: 主要是用来各方对需求的理解达成一致，确认业务范围与业务规则。简单的需求，通过文字描述，复杂的需求，我们辅助以流程图，产品原型图等手段。
产出物： 需求范围。
迭代启动会： 根据“需求范围”安排本次迭代的计划，不仅仅包含开发、测试等工作的计划，包含所有达到本次迭代目标的所有工作。根据任务进行估时，任务的估时要客观，估时与计划本质上不是一回事，计划要考虑资源的投入度。任务与任务之间，要考虑依赖关系。
产出物：迭代计划。
交付演示会：与用户和利益相关方，就交付成果进行演示，演示过程中要梳理细节的业务点，整理问题checklist，非常简单的，及时处理；比较复杂的问题点，根据具体情况，列入后续计划中；对于业务上还未清晰，需要再分析的，或者暂时没有明确方案的，放入到产品代办列表（Product backlog）。
产出物： 问题checklist。
迭代总结会: 就本次迭代，展开总结与反思。给团队一个阶段性结果的成就感，让团队成员有一个总结反思的机会，反思本迭代做的好的地方，做的不好的地方。并整理对团队工作有建设性意见的建议，好的建议可以在下一个迭代进行实践。
产出物：经验&教训。
每日站立会：每日站立会，是对迭代内的计划执行情况的跟踪。以及发现迭代计划执行的问题、风险、障碍点，及时发现计划执行的偏离情况，团队群策群力解决问题。站立会，根据经验，建议采用“夕会”，在一天工作结束时举行。时间一般要控制在15分钟内，限制只讨论计划完成情况，以及遇到的问题，不讨论细节工作。如果确有细节工作要讨论，可以在站立会完成后，小范围的相关人员讨论，结果通过邮件等方式同步给其他团队成员。
产出物： 计划跟踪情况。
给大家分享一个BPM项目计划跟踪的案例，图7:
图7 BPM一期迭代1工作计划
4.3 自组织团队
在迭代开发管理这部分，再一次提到了与团队相关的方面。是希望重点突出一下良好的相互协作的团队，对项目的积极作用。这里提出的是自组织团队，建立良好的团队气氛(信任、尊重、协同)，明确团队成员责任，梳理好相互沟通的渠道，搭建相互协作的桥梁。项目中计划并不是总能很顺利的完成，中间会遇到很多障碍点以及责任模糊的灰色地带。自组织团队，鼓励团队成员及时上报风险，团队共同解决。项目上遇到的问题，是团队共同的问题，不追究个人问题，即使是个人的任务延迟（基于团队成员的信任）。关于个人任务的延迟，这里做一下解释说明，团队应该首先想到的是，任务分配是否合理？估时是否准确？执行人需要的资源是否到位？是否需要必要的协助？等等方面，还是先从管理上找原因。
尾声
感谢公司各位领导，让我有机会负责运营相关的两个项目（BPM&DSM），感谢各位同事，在项目开展过程中给予的支持和帮助，谢谢你们的配合。感谢团队中每一位成员，你们辛勤的工作，保障了项目的顺利进行。感谢我的家人，对我工作支持与理解。