项目经理与工程师间的“脑裂”

type

status

date

slug

summary

一、项目范围巨大，交付物众多

这个交易集团旗下有16个平台系统，主要包括建设工程、产权交易、航运、医药等。协定的交付物包括：现状分析、蓝图、一纲三策、16个系统及主数据的数据标准、技术架构（数据流向图、技术架构图、数仓分层图、采集/集成方案、安全方案、网络架构图）、技术平台，以及20多个制度规范和管理办法。

1️⃣ 现状分析、蓝图、一纲三策属于BA（业务架构）层面。这些文件需要经过客户公司信息化组长、经理、书记和CTO兼首席经济师的层层评审。政府单位的要求特别高，华为的经验不能直接套用，文件经历了无数次修改。举个例子：客户对数据治理中提到的组织建议非常敏感，要求把所有实体组织改为虚拟组织。考虑到数据治理需要全集团参与，16个平台的负责人及党委书记分别在相关数据治理虚拟组织中担任什么身份，也经过了反复battle和论证，最终达成共识后才提交CTO确认定稿。

2️⃣ 数据标准术语属于IA/DA（信息架构或数据架构）层面。16个平台的数据标准需要逐一找客户确认，并针对客户的16个平台系统及子公司进行培训。每个系统的具体标准，我们都会拉上相应接口人和负责人反复确认。数据治理是长期甚至永续的工作，我不敢说帮他们完全制定了完善的数据标准，但至少我们交付团队依据客户的输入，仔细分析，完成了大半任务。考虑到任务的艰巨性，当时华为现场交付团队共11人,其中7人专门做IA。严格来说，IA不仅包括数据标准，还包括数据模型、数据质量等。只是考虑到客户的规划和项目的有限时间，客户决定"横着吃面包"而非"纵着吃"，我们只能适当缩减工作量，否则这个项目肯定完不成。

3️⃣ 技术架构属于TA（技术架构）层面。当时华为现场交付团队共11人，10人主要做BA和IA，剩下一个人就是我。我已经成为团队唯一最懂技术架构的人。当然我也不是单打独斗——我持有华为云的云计算解决方案架构师认证，背后还有众多经验丰富的同事、华为云产品部的架构师和朋友支持。考虑到避免为代表处新增成本，我在项目管理之外主动认领了这件事，成为客户眼中的项目经理兼架构师。

4️⃣ 还有20多个数据治理的制度规范和管理办法。华为本身有成熟且强大的交付物套件，但远远不够。政务人员的挑剔程度超出想象，这些文档我们来来回回改了很多遍。本来我认为自己是项目经理，可以完全安排手下人一起干活。但对于技术方面的规范和文档，不能对其他人要求太高，于是我也主动参与进来，只把文档排版和基础优化工作交给手下。这就是我最后不愿意承认自己是项目经理的原因——整个项目是大家一起戮力同心、咬牙坚持过来的，同事们都非常配合，没有给项目管理添太大麻烦。20多个文件其实有相近和重复的部分，比如数据安全管理细则和数据安全管理办法。最终我们主动找客户合并了相关文件，仅保留16个。

5️⃣ 项目还有隐形的交付任务——平台系统培训。因为客户公司、B公司、C公司对华为的数据治理理论和工具都不清楚，需要培训。哈哈，这是合同外的，我这里参考另一篇文章称之为"理念导入"。一开始我是拉产品部的ITA或研发进行赋能，但对于一些复杂产品，ITA讲得比较笼统。在技术交流中，客户发现我比较在行，就委托我针对华为云数据治理模块对他们进行赋能。于是，我成了我们团队、甚至华为整个大数据云计算交付中，对DataArts数据集成、数据开发、数据治理、数据目录、数据地图、数据服务、数据安全、数据模型功能最熟悉的人。在准备和执行赋能的过程中，我发现华为云产品还有不小的改进空间，因此成了团队中提需求最多、采纳需求最多的人，跟产品部混成了老熟人——或者说成了产品部的"一生之敌"。哈哈，不过还好，我现在离开了，他们总归会松一口气。

二、项目运作复杂，参与方较多

该项目是联合拓展项目，主要参与方有三个。考虑到项目机密，暂时用公司A、B、C描述。以我团队为代表的A公司负责咨询、蓝图顶设、数据治理规范、数据和技术架构设计、平台搭建和技术支持；B公司负责项目具体实施与开发；C公司负责大屏、中屏可视化和部分应用及运维。

在这个项目中，我们团队并非全程参与，只参与了整个项目周期的五分之三。A、B、C三家公司的工作量存在衔接和依赖关系。最开始是咨询先行，这时我和B、C公司的核心人员主要参与咨询相关工作，但以我们A团队为主。一开始项目还和和气气，到了后期，我们A和B就出现了工作量边界模糊的问题。比如具体的数据模型——因为建模需要深入业务，考虑到内容众多，我们入场时就谈好了项目边界。但B公司还是反复来找我们掰扯。

一次会议上，B公司拿他们做了三年的一个大项目与这个总共10个月的项目对比工作量,要求把模型"甩锅"给我们做。我们当然不认账。最后问题升级到双方高层，拿出以前的会议纪要才算尘埃落定。反思这个问题：B公司的PM中途换过，所以他不清楚此事之前已经说明白了。但他又没有直接询问自己的领导，反而一遍遍因为推进难度来找我们沟通。

另外是产品的接受度问题。B、C公司作为项目的具体实施和运营方，即便我拉上产品部一起对他们进行了深度辅导，对华为云产品还是不够熟悉。到了交付中后期，B公司员工明显学习不到位，他们继续来找我们掰扯，对比他们的可视化工具与华为云的通用SQL脚本加成熟调度器哪个更优。

当时跟他们沟通时，我没有给好脸色，但也没撕破脸。我向他们和客户指出：通用SQL脚本的优势是业界人才多、上手门槛低、调优空间大，而可视化界面没有调优空间、性能差、学习成本高、批量化操作能力弱。我请求他们给出核心诉求——是认为工作量大，还是产品不会用？对方哑口无言。

然后我们进入下一个议题。对方要求我给调优建议，点开编辑框一看，他们招的人连SQL语言的nvl和coalesce都不懂，写了一堆if语句。可见是为了成本优势招的性价比开发人员，脚本开发质量很差。我针对这些问题分别给了解答和规范案例赋能。言尽于此了。我对这个项目的整体结果感到焦虑，但又无法向客户明说。好在最终我们咨询和规范这部分内容顺利交付，只能祈祷B公司后续顺利吧。

（路上打字晕车，未完待续）

一、项目范围巨大，交付物众多

二、项目运作复杂，参与方较多

tacjin